[ECOS] Re: SNMP lockup
Sat May 9 10:28:00 GMT 2009
On 2009-05-09, Grant Edwards <firstname.lastname@example.org> 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) 220.127.116.11.18.104.22.168.1.6.1
and the second interface's address is 22.214.171.124.126.96.36.199.1.6.2
Those have always been handled correctly.
The problematic OID, 188.8.131.52.184.108.40.206.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 220.127.116.11.18.104.22.168.1.6.
But, 22.214.171.124.126.96.36.199.1.6 isn't a scalar value, it's a table, so
188.8.131.52.184.108.40.206.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
There also remains the open question of why well-known,
brand-name, hideously-expensive SNMP managers are sending out
that invalid OID...
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss