Re: Aren't completed short OIDs in tables wrong?

[Robert S. <rs...@fr...>]

On Thu, 31 Aug 2017 17:54:05 +0200 Ignacy wrote:
IG> I've come across a problem that has been traced down to the way
IG> the table helper handlers are processing OIDs.
IG> 
IG> I have a table indexed by a MacAddress.  If I pass a short OID,
IG> i.e. one that has less bytes than required
IG> (say, ...RowStatus.6.1.2.3), at best no error occurs and the
IG> missing bytes in the OID are completed with zeroes and at worst
IG> my implementation of the table aborts miserably.

Are you using snmpget or snmpgetnext?

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

I'm not sure I see the problem here. If you pass and incomplete
OID, there is no 'right' entry for a snmpget.

IG> I have the impression that the call to parse_one_oid_index()
IG> should have the "complete" argument set to 0 instead, so that
IG> short OIDs would simply fail as expected.  I can't find any
IG> explanation for this not being actually the case.  The code has
IG> been committed in one block in November 2001 with no
IG> explanation whatsoever.
IG> 
IG> Does anybody know the reason why such completion should be
IG> desirable? If so, it looks
IG> netsnmp_table_iterator_helper_handler() needs a fix, but I
IG> haven't looked any deeper into it at this time.

The compare functions for the helpers expect to have a full OID to
compare against. So for short OIDs, zeros are added so the compare
functions don't have to deal with logic for lengths.