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.
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)
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
I've observed something similar with SNMP Responder, where I'm using SysnameObjectInstance to place into IF-MIB::ifMtu.1 -> 32
I get the following output on the client side (net-snmp snmpget/walk)
and on the SNMP Responder side: