RE: Silvercreek issue

"Joan Landry" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <A9FCB77F97940A418A61FD9BB71E4170035AD7F6@dexbe012-6.exch012.intermedia.net>
Dave,
I am able to reproduce this problem using any value over 128 as the
length of the sub identifier of an Octet String:

Here is an example using the snmpNotifyFilter Table:
There is one row in this table having an instance of:
4.97.98.99.100.1.2.3
Which correlates to the following index:
snmpNotifyFilterProfileName = "abcd"
snmpNotifyFilterSubtree = 1.2.3

This is a walk of the table using MgSoft:
***** SNMP QUERY STARTED *****
1: snmpNotifyFilterMask.4.97.98.99.100.1.2.3 (OCTET STRING)
(zero-length) 
2: snmpNotifyFilterType.4.97.98.99.100.1.2.3 (INTEGER) included(1)
3: snmpNotifyFilterStorageType.4.97.98.99.100.1.2.3 (StorageType)
nonVolatile(3)
4: snmpNotifyFilterRowStatus.4.97.98.99.100.1.2.3 (RowStatus) active(1)
***** SNMP QUERY FINISHED *****

If I issue a get-next of snmpNotifyFilterType.5.97.98.99.100.1.2.3
The result is
Response binding:
1: snmpNotifyFilterStorageType.4.97.98.99.100.1.2.3 (StorageType)
nonVolatile(3)
Which is correct:

However, if I issue a get next of
snmpNotifyFilterType.129.97.98.99.100.1.2.3
The result is:
Response binding:
1: snmpNotifyFilterType.4.97.98.99.100.1.2.3 (INTEGER) included(1)

Which is wrong - it should have worked the same as when the length was
5. Instead it treats and number of 128 as 0 and responds with the
incorrect next OID.


I am registering this mib via the the following code:
   netsnmp_tdata_create_table("snmpNotifyFilterTable", 0);
   table_info = SNMP_MALLOC_TYPEDEF(netsnmp_table_registration_info);
   netsnmp_table_helper_add_indexes(table_info, 
        ASN_OCTET_STR, /* index: snmpNotifyFilterProfileName */
        ASN_PRIV_IMPLIED_OBJECT_ID, /* index: snmpNotifyFilterSubtree */
0);
   table_info->min_column = COLUMN_SNMPNOTIFYFILTERMASK;
   table_info->max_column = COLUMN_SNMPNOTIFYFILTERROWSTATUS;
   netsnmp_tdata_register(reg, snmpNotifyFilterTable_data, table_info);

and creating the row above using:
    len = strlen(entry->snmpNotifyFilterProfileName);
    netsnmp_tdata_row_add_index(row, ASN_OCTET_STR,
entry->snmpNotifyFilterProfileName, len);
    netsnmp_tdata_row_add_index(row, ASN_PRIV_IMPLIED_OBJECT_ID,
      entry->snmpNotifyFilterSubtree,
entry->snmpNotifyFilterSubtree_len *4);
    netsnmp_tdata_add_row(table_data, row);


Thanks for any ideas on this issue and how it can be resolved.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Dave Shield
Sent: Wednesday, July 28, 2010 5:15 AM
To: Joan Landry
Cc: [email protected]
Subject: Re: Silvercreek issue

On 20 July 2010 13:43, Joan Landry <[email protected]>
wrote:
> I am getting errors in the Lexicographic ordering tests in silvercreek
> using netsnmp-5.5
>
> Does anyone know if there is a fix for these bugs in netsnmp code?
> When I walk the tables - the ordering is correct - but if you specify
> the instance on a get-next where the instance in the request is
> Lexicographically greater than a row in the table the returned object
is
> not correct.

Is this a general problem, or does it just affect the example that you
mention?   Because that particular test seems to be testing the
handling of 32-bit overflow.


> The request OID
>
1.3.6.1.6.3.15.1.2.2.1.3.4294967295.128.0.31.136.128.5.144.12.252.0.0.2.
> 100.7.118.51.117.115.101.114.50

Note that the subidentifier value 4294967295 equates to 0xffffffff
which is the maximum valid value for an individual subidentifier.
Incrementing this value (to identify the next row) on a 32-bit system
might easily wrap back to 0, rather than moving on to the next column.
   I suspect that this may well be what's happening here.

Of course, if you are seeing similar errors with other tests (that
don't involve such large subidentifiers), then that would indicate a
more serious problem!

Dave

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.