Re: lexographic issue with get-next

On 22 July 2010 16:21, Joan Landry <[email protected]> wrote:
> There is a bug in the code where net-snmp is not responding correctly to a
> get-next request where the instance  contains a length, followed by a name,
> where the length is > 128.

I presume you are aware that such an OID is not valid?
OIDs are limited to a maximum of 128 subidentifiers.
   (See RFC 2578, section 3.5)

So it's not unreasonable if the Net-SNMP code doesn't handle
such OIDs correctly.   (Though it would clearly be better to
do something sensible, rather than the behaviour you describe)


> I ... would be very appreciative if someone can point me to where the
> function resides that takes an incoming get-next request and determines
> the correct instance to respond with from a lexographically perspective
> of the incoming request.

This is typically handled by one of the helper handlers.
For scalar objects, this is done in the MODE_GETNEXT branch of
heleprs/instance.c:netsnmp_instance_helper_handler()
For table objects, this is probably the main task of the various
table_xxx helpers - again, look at the helper_handler() routine,
and concentrate on the MODE_GETNEXT branch

But remember that many places will be working with OID buffers
of the form
        oid    name_loc[MAX_OID_LEN];   (from netsnmp_variable_list)

where MAX_OID_LEN is defined as 128.


Dave

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users