Okay, I really like standards – preferably open standards. And I really like SNMP, although sometimes I think that having the word “Simple” in its name was a mistake.

I love simplicity. I think for all of OpenNMS’s power, it is at heart a simple product. But some vendors confuse simplicity with sloppiness, and it causes me no end of grief.

For example, a client called me with the news that he was unable to get OpenNMS to discover one of his devices for data collection. Digging into the logs we find that there is a null pointer exception when it is trying to retrieve the ifSpeed from the device. Using UCD’s snmpwalk you get:

snmpwalk -c public 10.1.1.1 ifTable.ifEntry.ifSpeed
interfaces.ifTable.ifEntry.ifSpeed.1 = Wrong Type (should be Gauge32 or Unsigned32): 160000000
interfaces.ifTable.ifEntry.ifSpeed.10001 = Wrong Type (should be Gauge32 or Unsigned32): 160000000
interfaces.ifTable.ifEntry.ifSpeed.40001 = Gauge32: 38400
interfaces.ifTable.ifEntry.ifSpeed.40002 = Gauge32: 38400
interfaces.ifTable.ifEntry.ifSpeed.40005 = Gauge32: 44000000
interfaces.ifTable.ifEntry.ifSpeed.50001 = Gauge32: 10000000
interfaces.ifTable.ifEntry.ifSpeed.50002 = Gauge32: 10000000
interfaces.ifTable.ifEntry.ifSpeed.50003 = Gauge32: 38400

Now, how can you get part of the MIB right, and then blow it on the other part? I assume it is because of the high value, but it should still fit into 32 bits – 2^32 ~ 4 billion (unless my math is wrong).

Luckily, OpenNMS is open, so the source code change to ignore the wrong numbers was pretty simple to do.

A much harder fix will be for the problem where the SNMP agent does not respond correctly to snmpgetbulk requests. Ain’t it grand to be able to work around the issues, though?