[ECOS] RE: SNMP lockup

[Danny Sade <danny@channelot.com>]

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:grante@visi.com] 
Sent: Saturday, May 09, 2009 13:28
To: ecos-discuss@sources.redhat.com
Subject: Re: SNMP lockup

On 2009-05-09, Grant Edwards <grante@visi.com> 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