This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: SNMP lockup
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 : 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.
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
header_simple_table().
--
Grant Edwards grante Yow! Send your questions to
at ``ASK ZIPPY'', Box 40474,
visi.com San Francisco, CA 94140,
USA
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss