RE: Silvercreek issue

[Joan L. <Joa...@ov...>]

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: dav...@go... [mailto:dav...@go...] On
Behalf Of Dave Shield
Sent: Wednesday, July 28, 2010 5:15 AM
To: Joan Landry
Cc: net...@li...
Subject: Re: Silvercreek issue

On 20 July 2010 13:43, Joan Landry <Joa...@ov...>
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