Bit more robustness for legacy systems

[iigorr]

Some devices (e.g. Emerson PSU) do not seem to support getbulk. We have introduced a configuration option "bulkget", which allows to switch to simple getnext.

This is also introducing more robust termination criteria for the walk. If the same oid reappears, the walk is terminated. This might also fix the hanging request as described in #8.
Also if the iid is None or empty, which would lead to an invalid oid (terminated by .), the walk is terminated.

/cc @totallyunknown

[brian-brazil]

This should appear as a v1 option rather referencing protocol details.

This is also introducing more robust termination criteria for the walk. If the same oid reappears, the walk is terminated.

Do you have example output from snmpwalk for where this happens? That sounds like quite a broken device.

[totallyunknown]

Here is the output of the snmpwalk. The device itself doesn't support getbulk

$ snmpwalk -M+/usr/share/mibs/emerson/ -v 2c -c public 10.224.6.4 -m ALL 1
SNMPv2-MIB::sysDescr.0 = STRING: uCOS ENP_SCUP 2.01
SNMPv2-MIB::sysObjectID.0 = OID: EES-POWER-MIB::ees
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (128797300) 14 days, 21:46:13.00
SNMPv2-MIB::sysContact.0 = STRING: Nobody
SNMPv2-MIB::sysName.0 = STRING: ENP_SCUP
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
SNMPv2-MIB::sysServices.0 = INTEGER: 12
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (128797400) 14 days, 21:46:14.00
SNMPv2-MIB::sysORIndex.0 = INTEGER: 1234567890
SNMPv2-MIB::sysORID.0 = OID: EES-POWER-MIB::powerMIB
SNMPv2-MIB::sysORDescr.0 = STRING: The Mib module for powerMIB entire
SNMPv2-MIB::sysORUpTime.0 = Timeticks: (0) 0:00:00.00
EES-POWER-MIB::identManufacturer.0 = STRING: Emerson Network Power
EES-POWER-MIB::identModel.0 = STRING: M522BB01
EES-POWER-MIB::identControllerFirmwareVersion.0 = STRING: 2.07
EES-POWER-MIB::identName.0 = STRING:
EES-POWER-MIB::systemStatus.0 = INTEGER: normal(2)
EES-POWER-MIB::systemVoltage.0 = INTEGER: 53382
EES-POWER-MIB::systemCurrent.0 = INTEGER: 2352
EES-POWER-MIB::systemUsedCapacity.0 = INTEGER: 6
EES-POWER-MIB::psBatteryVoltage.0 = INTEGER: 53363
EES-POWER-MIB::psBatteryCurrent.0 = INTEGER: 25
EES-POWER-MIB::psInputLineAVoltage.0 = INTEGER: 225531
EES-POWER-MIB::psInputLineBVoltage.0 = INTEGER: 225531
EES-POWER-MIB::psInputLineCVoltage.0 = INTEGER: 225531
EES-POWER-MIB::psTemperature1.0 = INTEGER: 31702
EES-POWER-MIB::psTemperature2.0 = INTEGER: -999999
EES-POWER-MIB::psStatusCommunication.0 = INTEGER: normal(2)
EES-POWER-MIB::psStatusBatteryMode.0 = INTEGER: FloatCharging(2)
EES-POWER-MIB::psSMACNumber.0 = INTEGER: 0
EES-POWER-MIB::psSMBATNumber.0 = INTEGER: 0
EES-POWER-MIB::psSMIONumber.0 = INTEGER: 0
EES-POWER-MIB::alarmLastTrapNo.0 = Counter32: 0
End of MIB

snmpget vs snmpbulkget

$ snmpget -M+/usr/share/mibs/emerson/ -v 2c -c public 10.224.6.4 -m ALL 1.3.6.1.4.1.6302.2.1.2.6.1
EES-POWER-MIB::psInputLineAVoltage = INTEGER: 249226

$ snmpbulkget -M+/usr/share/mibs/emerson/ -v 2c -c public 10.224.6.4 -m ALL 1.3.6.1.4.1.6302.2.1.2.6.1
Timeout: No Response from 10.224.6.4

[brian-brazil]

I don't see where it's returning the same OID twice.

[iigorr]

With snmpwalk it's working fine. But with python-netsnmp it seems to be different.
If I track the responses in walk_oid like this:

...
      for v in vl:
        print v.iid, v.tag, v.val
...

Then i see this output:

0 .1.3.6.1.4.1.6302.2.1.1.1 Emerson Network Power
0 .1.3.6.1.4.1.6302.2.1.1.2 M522BB01
0 .1.3.6.1.4.1.6302.2.1.1.3 2.07
0 .1.3.6.1.4.1.6302.2.1.1.4                                 
0 .1.3.6.1.4.1.6302.2.1.2.1 2
0 .1.3.6.1.4.1.6302.2.1.2.2 53314
0 .1.3.6.1.4.1.6302.2.1.2.3 2392
0 .1.3.6.1.4.1.6302.2.1.2.4 7
0 .1.3.6.1.4.1.6302.2.1.2.5.1 53318
0 .1.3.6.1.4.1.6302.2.1.2.5.2 66
0 .1.3.6.1.4.1.6302.2.1.2.6.1 226210
0 .1.3.6.1.4.1.6302.2.1.2.6.2 226210
0 .1.3.6.1.4.1.6302.2.1.2.6.3 226210
0 .1.3.6.1.4.1.6302.2.1.2.7.1 32558
0 .1.3.6.1.4.1.6302.2.1.2.7.2 -999999
0 .1.3.6.1.4.1.6302.2.1.2.8 2
0 .1.3.6.1.4.1.6302.2.1.2.9 2
0 .1.3.6.1.4.1.6302.2.1.2.10.1 0
0 .1.3.6.1.4.1.6302.2.1.2.10.2 0
0 .1.3.6.1.4.1.6302.2.1.2.10.3 0
0 .1.3.6.1.4.1.6302.2.1.3 0
0 .1.3.6.1.4.1.6302.2.1.3 
0 .1.3.6.1.4.1.6302.2.1.3 
0 .1.3.6.1.4.1.6302.2.1.3 
0 .1.3.6.1.4.1.6302.2.1.3 
//and so on

Endless loop.

[brian-brazil]

Can you reproduce that with snmpgetnext?

[brian-brazil]

I'm going to presume this is dodgy hardware.