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
