Potential issue snmpwalk stall, OID increase

[glupescu]

I am new to PySNMP and SNMP in general, so if there is the potential of a mistake on my side, on how I use the framework. Nevertheless I've noticed similar behaviour on a different approach (through export), when using PySNMP Responder. For the sake of this bug I'm going to list both outputs.

I'm using PySNMP5 (master:becd15c7) and a very slight modification of the https://github.com/etingof/pysnmp/blob/master/examples/v3arch/asyncore/agent/cmdrsp/implementing-snmp-table.py, mainly adding more objects like

for idx in range(1, 16): mibInstrumentation.writeMibObjects( (exampleTableColumn2.name + (idx,), 'GE500-' + str(idx)), )

What happens is that snmpget works perfectly fine but snmpwalk goes into a loop ever increasing oid and not returning anything but the 1st entity

➜  mysnmp snmpget -v2c -c public 127.0.0.1:1161 1.3.6.6.1.5.2.1
SNMPv2-SMI::dod.6.1.5.2.1 = STRING: "GE500-1"
➜  mysnmp snmpget -v2c -c public 127.0.0.1:1161 1.3.6.6.1.5.2.2
SNMPv2-SMI::dod.6.1.5.2.2 = STRING: "GE500-2"
➜  mysnmp snmpget -v2c -c public 127.0.0.1:1161 1.3.6.6.1.5.2.3
SNMPv2-SMI::dod.6.1.5.2.3 = STRING: "GE500-3"
➜  mysnmp snmpwalk -v2c -c public 127.0.0.1:1161 1.3.6.6.1.5.2
SNMPv2-SMI::dod.6.1.5.2.1 = STRING: "GE500-1"
SNMPv2-SMI::dod.6.1.5.2.15 = No more variables left in this MIB View (It is past the end of the MIB tree)

I've observed something similar with SNMP Responder, where I'm using SysnameObjectInstance to place into IF-MIB::ifMtu.1 -> 32

 ....
    def readGetNext(self, varBind, **context):
        name, value = varBind
        print(name)
        print(self.name)

        if name >= self.name:
            print("NOT OK")
            import pdb; pdb.set_trace()
            # This object does not qualify as "next*, pass the call
            MibScalarInstance.readGetNext(self, varBind, **context)

        else:
            print("OK")
            cbFun = context['cbFun']
            # Initialize response value from *gethostname()* return
            value = self.syntax.clone(2)
            cbFun((self.name, value), **context)

I get the following output on the client side (net-snmp snmpget/walk)

➜  mysnmp snmpget -v2c -c public 127.0.0.1:1161 IF-MIB::ifMtu.1
IF-MIB::ifMtu.1 = INTEGER: 1
➜  mysnmp snmpget -v2c -c public 127.0.0.1:1161 IF-MIB::ifMtu.4
IF-MIB::ifMtu.4 = INTEGER: 1
➜  mysnmp snmpwalk -v2c -c public 127.0.0.1:1161 IF-MIB::ifMtu
IF-MIB::ifMtu.1 = INTEGER: 2
Timeout: No Response from 127.0.0.1:1161

and on the SNMP Responder side:

2020-04-10 11:24:42,544 INFO loaded new MIB tree ID managed-objects-1
2020-04-10 11:24:42,544 INFO starting I/O engine...
1.3.6.1.2.1.2.2.1.4
(1, 3, 6, 1, 2, 1, 2, 2, 1, 4, 1)
OK
1.3.6.1.2.1.2.2.1.4.1
(1, 3, 6, 1, 2, 1, 2, 2, 1, 4, 1)
NOT OK
> /etc/snmpresponder/managed-objects/__IF-MIB.py(85)readGetNext()
-> MibScalarInstance.readGetNext(self, varBind, **context)
(Pdb) continue
(1, 3, 6, 1, 2, 1, 2, 2, 1, 4, 2)
(1, 3, 6, 1, 2, 1, 2, 2, 1, 4, 2)
NOT OK
> /etc/snmpresponder/managed-objects/__IF-MIB.py(85)readGetNext()
-> MibScalarInstance.readGetNext(self, varBind, **context)
(Pdb) continue
1.3.6.1.2.1.2.2.1.4.1
(1, 3, 6, 1, 2, 1, 2, 2, 1, 4, 1)
NOT OK
> /etc/snmpresponder/managed-objects/__IF-MIB.py(85)readGetNext()
-> MibScalarInstance.readGetNext(self, varBind, **context)

[RamonSalem]

Hello, any updates in this behavior?

[glupescu-dn]

I started using https://github.com/etingof/pysnmp/tree/release-4.4.12 which looks fine and stable.