#85 pysnmp fails on some HOST-RESOURCES-MIB:hrStorageAllocationUnits and net-snmp succed

[Fabrice Bacchella]

The attached script fails on one of our windows, with the attached output.

But snmpget succed:
snmpwalk -c public -v 2c XXX HOST-RESOURCES-MIB:hrStorageAllocationUnits
HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.2 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 65536 Bytes

The system is:
SNMPv2-MIB::sysDescr.0 Hardware: Intel64 Family 6 Model 13 Stepping 3 AT/AT COMPATIBLE - Software: Windows Version 6.3 (Build 9600 Multiprocessor Free)
SNMPv2-MIB::sysObjectID.0 MSFT-MIB::dc

[Ilya Etingof]

According to the log, your agent returns

HOST-RESOURCES-MIB::hrStorageAllocationUnits.2 == 0

which violates the contraints for that MIB object as specified in MIB. I wonder how Net-SNMP works in this case and why it returns 65535 instead of 0...

A quick fix would be to either disable MIB lookup completly or copy and modify HOST-RESOURCES-MIB so that it would have different (less strict) constaints for that object.

I will also look into the possibility to tell pysnmp via some flag to ignore MIB constraints violations like these...

[Fabrice Bacchella]

I made some more test, I think my pasted line for net-snmp was wrong, it returned
HOST-RESOURCES-MIB::hrStorageAllocationUnits.2 = INTEGER: 0 Bytes.
And the disk that return that is a
HOST-RESOURCES-MIB::hrStorageType.2 = OID: HOST-RESOURCES-TYPES::hrStorageCompactDisc.

That's not illogical value for that kind of device. I'm not sure that checking constraints violation for message received should be done by default (see https://en.wikipedia.org/wiki/Robustness_principle).

I had another problem. Using asychronous IO, with the asyncio python module, the exception was raised in a external thread, on which I have no access and could't catch that exception. So indeed I disable mib lookup while walking the tree and do the resolution only when needed.

[Fabrice Bacchella]

Another case where constraints violations is a problem. I'm walking FCMGMT-MIB::connUnitPortTable whose index expect a range from 1 to 2147483647:

    connUnitPortIndex OBJECT-TYPE 
        SYNTAX INTEGER (1..2147483647)
   ...
        ::= { connUnitPortEntry 2 }

But when walking it on a HPE MSA 2040, I got a row 0:
FCMGMT-MIB::connUnitPortUnitId['P....E .........'][0] "50 0C 0F F1 B9 45 20 00 00 00 00 00 00 00 00 00 "

I know it's a bug, but because of constraints check, I can't read values from this row. Adding a flag to ignore constraints violations would be very helpfull again.