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: dave.shi...@googlemail.com [mailto:dave.shi...@googlemail.com] On Behalf Of Dave Shield Sent: Wednesday, July 28, 2010 5:15 AM To: Joan Landry Cc: net-snmp-users@lists.sourceforge.net Subject: Re: Silvercreek issue On 20 July 2010 13:43, Joan Landry <joan.lan...@overturenetworks.com> 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 Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users