I've tried some other tables of the standard MIB, and found out that access to table .iso.org.dod.internet.mgmt.mib-2.transmission.dot3.dot3StatsTable.dot3StatsEntry with index 0 also locks the system. For example: snmpget -v 2c -c public -m : 10.10.100.20 .1.3.6.1.2.1.10.7.2.1.6.0
My guess is that there are some more cases like these. So IMHO fixing the problem within the agent will be a better solution i.e. the agent should detect a request for a table entry with index 0 and respond with an error. Thanks Danny -----Original Message----- From: Grant Edwards [mailto:[email protected]] Sent: Saturday, May 09, 2009 13:28 To: [email protected] Subject: Re: SNMP lockup On 2009-05-09, Grant Edwards <[email protected]> wrote: >>> What I'd like a pointer on is the interface numbering in SNMP >>> OIDs. Are the interfaces supposed to be numbered 1..N with >>> interface 0 being non-existent? Or are eCos interface numbers >>> off by one and they should really be 0,1 instead of 1,2? After doing some more reading, I've concluded that the interface numbers are correct. OIDs for objects that are single, scalar values end in .0. OIDs for table entries end in .1 through .N where the table contains N values. The correct OID for the first network interface's physical address should be (and was and still is) 1.3.6.1.2.1.2.2.1.6.1 and the second interface's address is 1.3.6.1.2.1.2.2.1.6.2 Those have always been handled correctly. The problematic OID, 1.3.6.1.2.1.2.2.1.6.0, does not refer to the value at "index 0" of the interface physical address table, but refers to the scalar value identified by 1.3.6.1.2.1.2.2.1.6. But, 1.3.6.1.2.1.2.2.1.6 isn't a scalar value, it's a table, so 1.3.6.1.2.1.2.2.1.6.0 isn't a valid OID. AFAICT, error #2 (no such name) is the appropriate error to return in that case. That is now handled correctly after my posted fix. What I'm now wondering is how many problems are waiting to pop up when a similar requests received for "index 0" of other table objects? There also remains the open question of why well-known, brand-name, hideously-expensive SNMP managers are sending out that invalid OID... -- Grant -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
