networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.72k stars 335 forks source link

snmp-ups pw driver not working for Eaton Network-M2 #2488

Open akelleher opened 1 week ago

akelleher commented 1 week ago

Environment: RHEL 8.9, NUT 2.8.0. Talking to Eaton Network-M2 with firmware 3.0.5

I am having trouble with snmp-ups when using the default pw MIB, which I think is centered around ups.alarms.

When no alarms are present, the driver starts OK and I can query with upsc and get expected results. However, when I introduce an alarm (i.e. by shutting off power input), the same query returns "data stale".

[~]$ upsc eatonups@localhost
Init SSL without certificate database
Error: Data stale

Starting the driver with debug flags, and then shutting off power, gets me the following (at the end of the output):

[~]# upsdrvctl -d -DDDDD start
<snip>
 225.914524     [D1] snmp_ups_walk: processing unitary device (1)
 225.914539     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.8.1
 225.914552     [D1] snmp_ups_walk: processing unitary device (1)
 225.914565     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.6
 225.914578     [D1] snmp_ups_walk: processing unitary device (1)
 225.914591     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.1.0
 225.914601     [D1] snmp_ups_walk: processing unitary device (1)
 225.914611     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.1.0
 225.914628     [D1] snmp_ups_walk: processing unitary device (1)
 225.914642     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.1.0
 225.914658     [D1] snmp_ups_walk: processing unitary device (1)
 225.914673     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.2.0
 225.914687     [D1] snmp_ups_walk: processing unitary device (1)
 225.914700     [D1] SU_CMD_MASK => 1.3.6.1.4.1.534.1.9.2.0
 225.914713     [D1] snmp_ups_walk: processing unitary device (1)
 225.914730     [D1] snmp_ups_walk: processing unitary device (1)
 225.914744     [D1] snmp_ups_walk: processing unitary device (1)
 225.914759     [D1] snmp_ups_walk: processing unitary device (1)
 225.914774     [D1] snmp_ups_walk: processing unitary device (1)
 225.914788     [D1] get_and_process_data: ups.alarms (1.3.6.1.4.1.534.1.7.1.0)
 225.914800     [D2] su_ups_get: ups.alarms 1.3.6.1.4.1.534.1.7.1.0
 225.914816     [D2] su_ups_get: requesting nut_snmp_get_int() for ups.alarms, without daisy template originally
 225.914833     [D3] Entering nut_snmp_get_int()
 225.914845     [D3] nut_snmp_get(1.3.6.1.4.1.534.1.7.1.0)
 225.914862     [D3] nut_snmp_walk(1.3.6.1.4.1.534.1.7.1.0)
 225.914875     [D4] nut_snmp_walk: max. iteration = 1
 225.924943     [D2] => 5 alarms present
 225.925007     [D3] nut_snmp_walk(1.3.6.1.4.1.534.1.7.1.0)
 225.925019     [D4] nut_snmp_walk: max. iteration = 2147483647

Then I get no more output from the driver as if it has crashed. The process is still present until I kill it.

This issue does not occur using the ietf MIB but that is missing the temperature information from the UPS which I would like to use.

arnaudquette-eaton commented 1 week ago

hi @akelleher could you please send in an snmpwalk on 1.3.6.1.4.1.534?

akelleher commented 1 week ago

Attached output of: snmpwalk -v3 -l noauthnopriv -u <username> <IP> .1.3.6.1.4.1.534, both online and on battery. snmpwalk-output-on-battery.txt snmpwalk-output-online.txt

arnaudquette-eaton commented 1 week ago

@ericclappier-eaton can you please check that one?