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
