[ECOS] Re: SNMP lockup
Thu May 14 15:03:00 GMT 2009
On 2009-05-14, Danny Sade <firstname.lastname@example.org> wrote:
> I've tried some other tables of the standard MIB, and found out that access to table
> with index 0 also locks the system.
> For example:
> snmpget -v 2c -c public -m : 10.10.100.20 .188.8.131.52.184.108.40.206.220.127.116.11
> 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
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