SwOS 1.6 vs CollectD: SnmpGetNext fail

SwOS
1

CollectD - a monitoring tool - uses SnmpGetNext request to fetch various interface counters. This does not work with RB250G running SwOS 1.6, as it replies back with a malformed packget when CollectD tries to request data for the non-existent Port6:

2012-06-21T17:13:52+00:00 localhost daemon info collectd[5022]: snmp plugin: host 44.128.156.98: snmp_sess_synch_response successful.
2012-06-21T17:13:53+00:00 localhost daemon err collectd[5022]: snmp plugin: host 44.128.156.98: snmp_sess_synch_response failed: Timeout (parse header: message overflow: 75 len + 2 delta > 61 len)

tcpdump output shows that:

17:11:32.483825 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 105)
    44.128.156.1.47970 > 44.128.156.98.161: [bad udp cksum 0x91ca -> 0xe003!]  { SNMPv1 { GetNextRequest(62) R=2055248100  .1.3.6.1.2.1.2.2.1.14.5 .1.3.6.1.2.1.2.2.1.20.5 .1.3.6.1.2.1.2.2.1.2.5 } } 
17:11:32.485484 IP (tos 0x0, ttl 254, id 39635, offset 0, flags [none], proto UDP (17), length 89)
    44.128.156.98.161 > 44.128.156.1.47970: [udp sum ok]  [len59<asnlen75]

And yes, I can reproduce it manually:

With physical port 5:

# PORT=4
# snmpgetnext -v 1 -c public 44.128.156.98 .1.3.6.1.2.1.2.2.1.14.${PORT} .1.3.6.1.2.1.2.2.1.20.${PORT} .1.3.6.1.2.1.2.2.1.2.${PORT}
17:06:35.976060 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 105)
    44.128.156.1.47831 > 44.128.156.98.161: [bad udp cksum 0x91ca -> 0x47ad!]  { SNMPv1 { GetNextRequest(62) R=1071494435  .1.3.6.1.2.1.2.2.1.14.4 .1.3.6.1.2.1.2.2.1.20.4 .1.3.6.1.2.1.2.2.1.2.4 } } 
17:06:35.977886 IP (tos 0x0, ttl 254, id 15059, offset 0, flags [none], proto UDP (17), length 112)
    44.128.156.98.161 > 44.128.156.1.47831: [udp sum ok]  { SNMPv1 { GetResponse(69) R=1071494435  .1.3.6.1.2.1.2.2.1.14.5=0 .1.3.6.1.2.1.2.2.1.20.5=0 .1.3.6.1.2.1.2.2.1.2.5="Port5" } } 
IF-MIB::ifInErrors.5 = Counter32: 0
IF-MIB::ifOutErrors.5 = Counter32: 0
IF-MIB::ifDescr.5 = STRING: Port5

Trying to get the next OID in tree, refering non-existing to physical port 6:

# PORT=5
# snmpgetnext -v 1 -c public 44.128.156.98 .1.3.6.1.2.1.2.2.1.14.${PORT} .1.3.6.1.2.1.2.2.1.20.${PORT} .1.3.6.1.2.1.2.2.1.2.${PORT}
17:06:39.548947 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 105)
    44.128.156.1.43823 > 44.128.156.98.161: [bad udp cksum 0x91ca -> 0x9249!]  { SNMPv1 { GetNextRequest(62) R=26214195  .1.3.6.1.2.1.2.2.1.14.5 .1.3.6.1.2.1.2.2.1.20.5 .1.3.6.1.2.1.2.2.1.2.5 } } 
17:06:39.550805 IP (tos 0x0, ttl 254, id 15315, offset 0, flags [none], proto UDP (17), length 89)
    44.128.156.98.161 > 44.128.156.1.43823: [udp sum ok]  [len59<asnlen75]
Timeout: No Response from 44.128.156.98.

It sould response with the next OID in the tree or with a message when the request has ended the tree, like:

    44.128.156.98.161 > 44.128.156.1.52598: [udp sum ok]  { SNMPv1 { GetResponse(30) R=1971931419  noSuchName@1 .1.3.6.1.2.1.2.2.1.20.5= } }

Please FIX it.

2

Same bug with cacti.

Solution:
"Older SNMP devices need the max oid’s of the device reduced to as little as 1 to work. "
http://forums.cacti.net/viewtopic.php?f=21&t=37258

3

Hello,

no, you simply have to set the “Maximum OID’s Per Get Request” in Cacti accordingly. I have no issues with the default (10) and my RB250GS.
Try to change this setting to “1” and check how it goes.

But yes, this is definitly a bug. (already in my list included :slight_smile: ).

Ronny