I have a program handling pass_persist from snmpd. It works fine for get and getnext requests.
Get on 0.0 returns 0.0, and GetNext on 0.0 returns 0.1:
user@debianbase:~$ sudo snmpget -v 2c -c public localhost 1.3.6.1.3.0.0
iso.3.6.1.3.0.0 = STRING: "192.168.153.0"
user@debianbase:~$ sudo snmpgetnext -v 2c -c public localhost 1.3.6.1.3.0.0
iso.3.6.1.3.0.1 = Gauge32: 0
But if I try to walk the OIDs I'm handling, it acts strangely. I expect to see a series of getnext requests from the client, but that isn't what I see. The output of snmpwalk on 0.0 is just the result of a Get on 0.0:
user@debianbase:~$ sudo snmpwalk -v 2c -c public localhost 1.3.6.1.3.0.0
iso.3.6.1.3.0.0 = STRING: "192.168.153.0"
If I perform a packet capture, it seems like my application is responding correctly, but the client performs a Get instead of a GetNext after the initial response
GetNext on 0.0:
10:38:37.238144 IP (tos 0x0, ttl 64, id 29006, offset 0, flags [DF], proto UDP (17), length 69)
localhost.43142 > localhost.snmp: [bad udp cksum 0xfe44 -> 0x6c7c!] { SNMPv2c { GetNextRequest(26) R=607525872 X:0.0 } }
Response from agent for 0.1:
10:38:37.238892 IP (tos 0x0, ttl 64, id 29007, offset 0, flags [DF], proto UDP (17), length 70)
localhost.snmp > localhost.43142: [bad udp cksum 0xfe45 -> 0x673b!] { SNMPv2c { GetResponse(27) R=607525872 X:0.1=0 } }
Now I expect to see a GetNext on 0.1, but instead the snmpwalk client does a Get for 0.0:
10:38:37.239027 IP (tos 0x0, ttl 64, id 29008, offset 0, flags [DF], proto UDP (17), length 69)
localhost.43142 > localhost.snmp: [bad udp cksum 0xfe44 -> 0x6b7d!] { SNMPv2c { GetRequest(26) R=607525873 X:0.0 } }
And my agent responds correctly with the 0.0 value:
10:38:37.240000 IP (tos 0x0, ttl 64, id 29009, offset 0, flags [DF], proto UDP (17), length 82)
localhost.snmp > localhost.43142: [bad udp cksum 0xfe51 -> 0x07f4!] { SNMPv2c { GetResponse(39) R=607525873 X:0.0="192.168.153.0" } }
If I perform a walk on any OID that isn't in 1.3.6.1.3, the walk behaves as expected and performs a series of GetNextRequests, but skips over my 1.3.6.1.3 oid tree that I am handling with my agent.
