Aren't completed short OIDs in tables wrong?

[Ignacy G. <ign...@gr...>]

Hi,

I've come across a problem that has been traced down to the way the
table helper handlers are processing OIDs.

I have a table indexed by a MacAddress.  If I pass a short OID, i.e.
one that has less bytes than required (say, ...RowStatus.6.1.2.3), at
best no error occurs and the missing bytes in the OID are completed
with zeroes and at worst my implementation of the table aborts
miserably.

It appears the problem is caused by the call to parse_one_oid_index()
from table_helper_handler() in agent/helpers/table.c.  The "complete"
argument is set to 1, which means that the missing bytes from the OID
are to be completed with zeroes.  Then, in
netsnmp_table_iterator_helper_handler()
(agent/helpers/table_iterator.c), snmp_oid_compare() fails to properly
identify the right entry, by comparing a completed OID with an
incomplete one.

I have the impression that the call to parse_one_oid_index() should
have the "complete" argument set to 0 instead, so that short OIDs would
simply fail as expected.  I can't find any explanation for this not
being actually the case.  The code has been committed in one block in
November 2001 with no explanation whatsoever.

Does anybody know the reason why such completion should be desirable?
If so, it looks netsnmp_table_iterator_helper_handler() needs a fix,
but I haven't looked any deeper into it at this time.

Cheers,

Ignacy

-- 
To err is human, to moo bovine.