[ECOS] Re: SNMP lockup

Grant Edwards grante@visi.com
Thu May 14 15:03:00 GMT 2009

On 2009-05-14, Danny Sade <danny@channelot.com> wrote:

> 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 :  .
> My guess is that there are some more cases like these.

Probably.  SNMP is a mess to start with, and the UCD
implementation doesn't have a very good reputation.

> 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.

I don't see how that's possible.  Unless I'm misunderstanding
the way the agent code works, it doesn't know whether a request
is for a table or a scalar. AFICT, all it knows about is a
mapping from OID values to callbacks.  When an OID match is
found the corresponding callback is then passed the OID and is
supposed to "do the right thing".

However, I agree that the error should be handled as generally
as possible.

One possibility is to add a check in the utility funciton
header_simple_table().  That's the routine used by at least
_some_ of the callbacks to (among other things) check the max
index value. However, I don't know for sure that
header_simple_table() isn't also used for scalar values by
specifying a max index value of 0.  Presumably if the max index
value is > 0, then the entity is a table and an index value of
0 should be an error.  But that's just an educated guess. I
don't even know that all table-handling callbacks use

Grant Edwards                   grante             Yow! Send your questions to
                                  at               ``ASK ZIPPY'', Box 40474,
                               visi.com            San Francisco, CA 94140,

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 mailing list