Is NUT using the same SNMP v3 user as your SNMP Set or a different one?
If it is a different one (e.g. an SNMP v1 or v2c string) does that user /
community string have read/write access?
tcpdump to listen for packets across UDP 161 is one way to check what is
actually being sent.
Thank you,
David Zomaya
Tripp Lite
________________________________
From: Nut-upsuser <nut-upsuser-bounces+david_zomaya=tripplite.com at
alioth-lists.debian.net> on behalf of Lee Damon <nomad at
ee.washington.edu>
Sent: Wednesday, April 29, 2020 5:00:16 PM
To: nut-upsuser Mailing List
Subject: [EXTERNAL] [Nut-upsuser] SNMP shutdown timing out
This is an EXTERNAL email. Please take a moment and think before clicking any
links or opening any attachments from this email. If suspicious, please forward
to ishelpdesk at tripplite.com for review.
________________________________
I'm in the process of trying to get NUT to manage an APC SmartUPS.
Monitoring of the UPS is working fine:
$ upsc nutdev1 at localhost
Init SSL without certificate database
ambient.1.humidity.alarm.high: 60.00
ambient.1.humidity.alarm.low: 30.00
ambient.1.temperature.alarm.high: 40.00
ambient.1.temperature.alarm.low: 10.00
battery.charge: 94.00
battery.charge.restart: 0
battery.current: 0.00
battery.date: 03/14/20
battery.packs: 0.00
battery.packs.bad: -1.00
battery.runtime: 5160.00
battery.runtime.low: 120
battery.voltage: 27.00
battery.voltage.nominal: -1.00
device.mfr: APC
device.model: SMART-UPS 1400
device.serial: WS9831004667
device.type: ups
driver.name<https://urldefense.proofpoint.com/v2/url?u=http-3A__driver.name&d=DwMFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=VdKSS_Vk98WT0ADZ-mQe_3zCfrLacAAuMS7JSj5wn1w&s=hM67G_Mcn7oW5yo4o44Na9wyw26mxM8hKXFExeGyhJQ&e=>:
snmp-ups
driver.parameter.authProtocol: MD5
driver.parameter.mibs: apcc
driver.parameter.pollinterval: 2
driver.parameter.port: 192.5.37.191
driver.parameter.privProtocol: DES
driver.parameter.secLevel: authPriv
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: apcc MIB 1.2
driver.version.internal: 0.97
input.frequency: 60.00
input.sensitivity: high
input.transfer.high: 132
input.transfer.low: 103
input.transfer.reason: selfTest
input.voltage: 120.90
input.voltage.maximum: 122.20
input.voltage.minimum: 120.20
output.current: 0.00
output.frequency: 60.00
output.voltage: 120.90
output.voltage.nominal: 115
ups.delay.shutdown: 20
ups.delay.start: 0
ups.firmware: 70.11.D
ups.id<https://urldefense.proofpoint.com/v2/url?u=http-3A__ups.id&d=DwMFaQ&c=f9s1WCuF-N6cmD_YaZ7gBg&r=lhr3k4au5dVQgHY_iS-v_t9g8PHVkn8Px_wyaupZGfQ&m=VdKSS_Vk98WT0ADZ-mQe_3zCfrLacAAuMS7JSj5wn1w&s=Cv5z1Xm7dspkGCX9gosuUR3R9b6cDZLJnumKkJ4s1Ms&e=>:
apcups
ups.load: 14.00
ups.mfr: APC
ups.mfr.date: 07/28/98
ups.model: SMART-UPS 1400
ups.serial: WS9831004667
ups.status: OL
ups.temperature: 24.70
ups.test.date: 04/29/2020
ups.test.result: Ok
I can use snmpset to halt the UPS.
snmpset -v 3 -a MD5 -A NutScan at Password43LongerWord -l authPriv -u nut -x
DES -X NutScan at Password43LongerWord apcups
SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0 i 2
(Passwords are temporary, I don't care if they leak.)
I am aware of the note in the MIB that states "Setting this variable to
turnUpsOffToConserveBattery(2) causes a UPS on battery to be put into
'sleep' mode. The UPS will turn back on when utility power is restored.
Attempting to turn off a UPS that is not on battery will result in a badValue
error." so tests are being done with the UPS on battery.
However, when I try to tell it to shut down the UPS it fails with a timeout.
$ sudo snmp-ups -DDDDDDD -a nutdev1 -k
Network UPS Tools - Generic SNMP UPS driver 0.97 (2.7.4)
0.000000 send_to_all: SETINFO driver.parameter.port
"192.5.37.191"
0.000027 send_to_all: SETINFO driver.parameter.mibs "apcc"
0.000044 send_to_all: SETINFO driver.parameter.secLevel
"authPriv"
0.000049 send_to_all: SETINFO driver.parameter.authProtocol
"MD5"
0.000067 send_to_all: SETINFO driver.parameter.privProtocol
"DES"
0.000071 debug level is '7'
0.001365 SNMP UPS driver: entering upsdrv_initups()
0.001371 SNMP UPS driver: entering nut_snmp_init(snmp-ups)
0.008570 Setting SNMP retries to 5
0.008575 Setting SNMP timeout to 1 second(s)
0.008605 SNMP UPS driver: entering load_mib2nut(apcc)
0.008610 load_mib2nut: trying classic method with 'apcc' mib
0.008613 su_find_info: "ups.model" found
0.008615 Testing ups.model using OID .1.3.6.1.4.1.318.1.1.1.1.1.1.0
0.008617 Entering nut_snmp_get_str()
0.008619 nut_snmp_get(.1.3.6.1.4.1.318.1.1.1.1.1.1.0)
0.008637 nut_snmp_walk(.1.3.6.1.4.1.318.1.1.1.1.1.1.0)
0.008640 nut_snmp_walk: max. iteration = 1
0.027623 load_mib2nut: testOID provided and matches MIB 'apcc'!
0.027636 load_mib2nut: using apcc mib
0.027639 su_find_info: "ups.model" found
0.027641 Entering nut_snmp_get_str()
0.027642 nut_snmp_get(.1.3.6.1.4.1.318.1.1.1.1.1.1.0)
0.027644 nut_snmp_walk(.1.3.6.1.4.1.318.1.1.1.1.1.1.0)
0.027646 nut_snmp_walk: max. iteration = 1
0.051176 Detected SMART-UPS 1400 on host 192.5.37.191 (mib: apcc 1.2)
0.051192 su_find_info: unknown info type (load.off.delay)
0.051195 su_find_info: unknown info type (load.on.delay)
0.051197 su_find_info: unknown info type (load.off.delay)
0.051199 Initiating UPS shutdown
0.051201 upsdrv_shutdown...
0.051203 Unknown template type: shutdown.return
0.051204 entering su_instcmd(shutdown.return, (null))
0.051207 su_find_info: "shutdown.return" found
0.051209 entering nut_snmp_set(.1.3.6.1.4.1.318.1.1.1.6.1.1.0, i, 2)
6.059576 [nutdev1] nut_snmp_set: can't set
.1.3.6.1.4.1.318.1.1.1.6.1.1.0: Timeout
6.059591 su_instcmd: cannot set value for shutdown.return
6.059593 Unknown template type: shutdown.reboot
6.059595 entering su_instcmd(shutdown.reboot, (null))
6.059599 su_find_info: unknown info type (shutdown.reboot)
6.059601 su_instcmd: shutdown.reboot unavailable
6.059602 Unknown template type: load.off.delay
6.059603 entering su_instcmd(load.off.delay, (null))
6.059606 su_find_info: unknown info type (load.off.delay)
6.059608 su_instcmd: load.off.delay unavailable
6.059609 Shutdown failed!
This *might* be related to the question I asked yesterday about nut-scanner but
given the difference in error reported (nut-scanner was complaining about auth)
I don't think so.
I'm using nut packages from EPEL 8 for all of this.
I've set SELinux to permissive (even tried 'disabled') and it
doesn't appear to be blocking anything.
Anyone have any suggestions for what I can try next?
nomad
________________________________
This message is for the addressee's use only. It may contain confidential
information. If you receive this message in error, please delete it and notify
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no
responsibility for viruses which may infect an email sent to you from Tripp Lite
and which damage your electronic systems or information. It is your
responsibility to maintain virus detection systems to prevent damage to your
electronic systems and information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200429/4961d098/attachment-0001.html>