#2669 GET_NEXT doesn't work through proxy

[Andy Caldwell]

When handling a GET_NEXT request, the proxy code checks if the current OID lies within the proxied OID-space (in which case it just re-writes the requested OID to the real OID and forwards the request) or is before the proxied OID-space (in which case it translates it to the OID that comes logically before the real OID-space and forwards it).

Unfortunately, the code compares the requested OID to the real OID-space, not the proxied OID-space and thus always does the second option. This means you can't snmpwalk or snmptable through the proxy.

Fix is to compare ourname to sp->name (not sp->base).

[Andy Caldwell]

Attached patch with the proposed fix.

[Bill Fenner]

See also https://sourceforge.net/p/net-snmp/patches/1282/ . Are these the same problem or just related?

[Andy Caldwell]

I dont think so, #1282 is about leaving the top of the proxied space while this (#2669) is about walking into the proxied space. Related but not the same.

[Bill Fenner]

I see. So this example is about a get-next of .1.3.999 when the proxied space is .1.4 (but the destination is .1.2), and the other is about a get-next of .1.4.999 trying to walk out of the proxied space?

(I haven't done any proxying, so a concrete example with an snmpd.conf and a misbehaving snmp operation would really help.)

[Andy Caldwell]

Sounds like a reasonable request, if you configure a proxy as:

proxy -v2c -c pass localhost .1.2.123 .1.3.123

You'd expect to see the following:

• A GET on .1.2.123.4 is served by a GET on .1.3.123.4
• A GET_NEXT on .1.2.123.4 is served by a GET_NEXT on .1.3.123.4
• A GET_NEXT on .1.2.122.23 (the last valid OID in the .1.2.122 space) is served by a GET_NEXT on .1.3.122.0xffffffff (so we get the first element in the proxied space back).

Unfortunately, since .1.2.123 < .1.3.123 and the code compares the wrong OID we always fall into the third bullet when handling a GET_NEXT inside the proxied space meaning we always get the first element of the proxied area back, rather than the element after the requested one.

If the OIDs were the other way round, then we'd always fall into the second bullet even when we want the first, this is likely harder to spot since the effect is that walking into the proxied area may skip over some of the first OIDs in that area depending on what the previous valid OID in the tree was (and what sub-OIDs are valid in the proxied space).