Page 1 of 1

snmp problem with 1.3.x series

Posted: Wed Oct 21, 2015 5:42 pm
by mayheart
I've started upgrading my switches to 1.3.3, I've noticed that LibreNMS and a few other monitoring systems breaks.

To me it looks like the problem is 1.3 announces it's name is OpenWRT regardless of what the system name setting is in the GUI. 1.2 does not have this behaviour. Software auto assumes it's a OpenWRT device and ignores the Netonix mibs.

== debug output ==

=1.2 behaviour=


DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -OQUs -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.92.231:161 sysUpTime.0 sysLocation.0 sysContact.0 sysName.0
sysUpTime.0 = 110:8:31:09.69
sysLocation.0 = Topsite
sysContact.0 = temp
sysName.0 = TopsiteSW01


DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqv -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.92.231:161 sysDescr.0

DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqvn -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.92.231:161 sysObjectID.0
.1.3.6.1.4.1
DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -OUqv -m SNMP-FRAMEWORK-MIB -M /usr/local/www/librenms/mibs udp:192.168.92.231:161 snmpEngineTime.0
No Such Object available on this agent at this OID
DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqv -m HOST-RESOURCES-MIB -M /usr/local/www/librenms/mibs udp:192.168.92.231:161 hrSystemUptime.0
110:8:31:30.51



=1.3 behaviour=


DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -OQUs -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.94.198:161 sysUpTime.0 sysLocation.0 sysContact.0 sysName.0
sysUpTime.0 = 42:19:32:54.18
sysLocation.0 = Topsite2
sysContact.0 = temp
sysName.0 = OpenWrt
DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqv -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.94.198:161 sysDescr.0

DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqvn -m SNMPv2-MIB -M /usr/local/www/librenms/mibs udp:192.168.94.198:161 sysObjectID.0
.1.3.6.1.4.1.46242
DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -OUqv -m SNMP-FRAMEWORK-MIB -M /usr/local/www/librenms/mibs udp:192.168.94.198:161 snmpEngineTime.0
No Such Object available on this agent at this OID
DEBUG: SNMP Auth options = -v2c -c public
/usr/local/bin/snmpget -v2c -c public -Oqv -m HOST-RESOURCES-MIB -M /usr/local/www/librenms/mibs udp:192.168.94.198:161 hrSystemUptime.0
42:19:33:14.79
Using hrSystemUptime (42:19:33:14.79)
[RRD Disabled]RRD[update /usr/local/www/librenms/rrd/192.168.94.198/uptime.rrd N:3699194] Uptime: 42 days, 19h 33m 14s

Re: snmp problem with 1.3.x series

Posted: Wed Oct 21, 2015 6:50 pm
by mayheart
I also notice 1.3 doesn't respond to firmwareVersion.0 was this removed?

(1.2) # snmpwalk -v2c -c public -Osqnv -m NETONIX-SWITCH-MIB -M mibs:mibs/netonix/ udp:192.168.92.231:161 firmwareVersion.0
Wrong Type (should be OCTET STRING): 114994395

(1.3) # snmpwalk -v2c -c public -Osqnv -m NETONIX-SWITCH-MIB -M mibs:mibs/netonix/ udp:192.168.94.198:161 firmwareVersion.0
No more variables left in this MIB View (It is past the end of the MIB tree)

Re: snmp problem with 1.3.x series

Posted: Wed Oct 21, 2015 7:50 pm
by Eric Stern
sysName issue: A reboot should fix this. After a firmware upgrade the system hostname gets reset to OpenWRT and changes to the Switch Name don't take effect until the next reboot. I've fixed this in 1.3.5.

firmwareVersion issue: Its still there. You probably just need the new MIB file. We got an official PEN and the MIB file was modified in 1.3.0. Its available here: viewtopic.php?f=17&t=251

Re: snmp problem with 1.3.x series

Posted: Sun Oct 25, 2015 2:52 pm
by Dawizman
Any ETA on 1.3.5?

We've got two WISP switches out in the field right now, and they both stop responding to SNMP requests from PRTG after a few days. I'm wondering if this is the same issue? A reboot of the switch does not fix it, however a restart of our PRTG server does.