[Net-snmp-patches] [ net-snmp-Patches-3140833 ] Fix GETNEXT processing in proxy mode

[SourceForge.net <no...@so...>]

Patches item #3140833, was opened at 2010-12-20 16:07
Message generated for change (Tracker Item Submitted) made by jsafranek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3140833&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Safranek (jsafranek)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix GETNEXT processing in proxy mode

Initial Comment:
Sending for review here, the patch changes the processing of GETNEXT proxied
requests quite significantly and I am not sure I didn't screw something up.


Having following entry in snmpd.conf:
proxy -v 2c -c public <remote host> .1.3.6.1.4.1.211.1.1.1.3.3.2.2.1 .1.3.6.1.2.1.1.5

and issuing 'snmpgetnext localhost .1.3.6.1.4.1.211.1.1.1.3.3.2', one would
expect that the request is proxied to the remote host (which works well) and
value of .1.3.6.1.2.1.1.5.0 is returned (which does not work at all).

snmpd asks the remote agent for next of .1.3.6.1.2.1.1, (=.1.3.6.1.2.1.1.1.0),
which is outside of .1.3.6.1.2.1.1.5 tree and snmpd discards the returned
value.

snmpd should ask for the first value in .1.3.6.1.2.1.1.5 tree. Problem is, it
does not know, which OID it is -> I've added some woodoo^Hheuristics, which
asks the remote host for next of .1.3.6.1.2.1.1.4.4294967295, which must be
.1.3.6.1.2.1.1.5 (if it exists) or the next value (.1.3.6.1.2.1.1.5.0
in our case).

I hope I got all the OID copying right, at least it seems to work on my system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3140833&group_id=12694