nut icon indicating copy to clipboard operation
nut copied to clipboard

Cannot shutdown APC SU-1000 with AP9617

Open dwmw2 opened this issue 5 years ago • 9 comments

When I attempt to shut down I get an error:

   0.121544	Initiating UPS shutdown
   0.121547	[D1] upsdrv_shutdown...
   0.121552	[D2] entering su_setOID(instcmd, shutdown.return, (null))
   0.121559	[D3] su_find_info: "shutdown.return" found
   0.121565	[D1] entering nut_snmp_set(.1.3.6.1.4.1.318.1.1.1.6.1.1.0, t, 200)
   0.151626	[su1000] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: wrongType (The set datatype does not match the data type the agent expects)
   0.151632	[D1] su_setOID: cannot execute command 'shutdown.return'

Using v2.7.4 from Fedora 33 the error is different:

   0.086717	Initiating UPS shutdown
   0.086720	upsdrv_shutdown...
   0.086726	Unknown template type: shutdown.return
   0.086732	entering su_instcmd(shutdown.return, (null))
   0.086740	su_find_info: "shutdown.return" found
   0.086745	entering nut_snmp_set(.1.3.6.1.4.1.318.1.1.1.6.1.1.0, i, 2)
   0.127311	[su1000] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: (genError) A general failure occured
   0.127321	su_instcmd: cannot set value for shutdown.return
 $ snmpget  -u nut 192.168.122.104 .1.3.6.1.4.1.318.1.1.1.6.1.1.0
SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0 = INTEGER: 1

 $ snmpset  -u nut 192.168.122.104 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 i 2
Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0

 $ snmpset  -u nut 192.168.122.104 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 t 200
Error in packet.
Reason: wrongType (The set datatype does not match the data type the agent expects)
Failed object: SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0

Using SNMPv1 doesn't make much difference.

 $ snmpset  -v1 -c private 192.168.122.104 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 i 2
Error in packet.
Reason: (genError) A general failure occured
Failed object: SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0

 $ snmpset  -v1 -c private 192.168.122.104 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 t 200
Error in packet.
Reason: (badValue) The value given has the wrong type or length.
Failed object: SNMPv2-SMI::enterprises.318.1.1.1.6.1.1.0

dwmw2 avatar Jan 03 '21 05:01 dwmw2

Full output of ./snmp-ups -a su1000 -DDDDD -k: shutdown-attempt.txt

Driver running with debugging: driver-run.txt

 $ upsc su1000
ambient.1.humidity.alarm.high: 60
ambient.1.humidity.alarm.low: 30
ambient.1.temperature.alarm.high: 40
ambient.1.temperature.alarm.low: 10
battery.charge: 100
battery.charge.restart: 0
battery.current: 0
battery.date: 05/03/20
battery.packs: 0
battery.packs.bad: -1
battery.runtime: 2580
battery.runtime.low: 120
battery.voltage: 27.60
battery.voltage.nominal: -1
device.mfr: APC
device.model: SMART-UPS 1000
device.serial: QS0023121408
device.type: ups
driver.name: snmp-ups
driver.parameter.pollfreq: 15
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.122.104
driver.parameter.snmp_version: v3
driver.parameter.synchronous: no
driver.version: 2.7.4-2077-g699bf8b4
driver.version.data: apcc MIB 1.3
driver.version.internal: 1.12
input.frequency: 50
input.sensitivity: low
input.transfer.high: 253
input.transfer.low: 196
input.transfer.reason: selfTest
input.voltage: 237.90
input.voltage.maximum: 240.50
input.voltage.minimum: 236.60
output.current: 0
output.frequency: 50
output.voltage: 237.90
output.voltage.nominal: 230
ups.delay.shutdown: 20
ups.delay.start: 0
ups.firmware: 60.11.I
ups.id: SU 1000
ups.load: 3.60
ups.mfr: APC
ups.mfr.date: 06/03/00
ups.model: SMART-UPS 1000
ups.serial: QS0023121408
ups.status: OL
ups.temperature: 27.40
ups.test.date: 01/02/2021
ups.test.result: Ok

dwmw2 avatar Jan 03 '21 05:01 dwmw2

Hello, I am having nearly the same issue with an APC SmartUPS 750 and an AP9631 Card

   0.053337	Initiating UPS shutdown
   0.053475	upsdrv_shutdown...
   0.053544	Unknown template type: shutdown.return
   0.053679	entering su_instcmd(shutdown.return, (null))
   0.053820	su_find_info: "shutdown.return" found
   0.053891	entering nut_snmp_set(.1.3.6.1.4.1.318.1.1.1.6.1.1.0, i, 2)
   0.069026	[ups01] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: (genError) A general failure occured
sudo /lib/nut/snmp-ups -DDDDD -a ups01

upsdrvctl_debug.txt

sudo /lib/nut/snmp-ups -DDDD -a ups01 -k  

shutdown-attempt.txt

henningkessler avatar Oct 14 '21 18:10 henningkessler

same issue using smart-ups 1500 with ap9631 card

Shutting down the UPS ...:Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic SNMP UPS driver 1.21 (2.8.0)
No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'!
Please report it to NUT developers, with an 'upsc' output for your device.
Going back to the classic MIB detection method.
Detected Smart-UPS 1500 on host 192.168.151.2 (mib: apcc 1.6)
Initiating UPS shutdown
[apc] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: (genError) A general failure occured
Shutdown failed!
Driver failed to start (exit status=1)
Shutdown failed. Waiting for UPS batteries to run down.
:; snmpget -v2c  -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6.1.1.0
iso.3.6.1.4.1.318.1.1.1.6.1.1.0 = INTEGER: 1

:; snmpset -v2c -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6.1.1.0 i 2
Error in packet.
Reason: (genError) A general failure occured
Failed object: iso.3.6.1.4.1.318.1.1.1.6.1.1.0
:; upsc apc
Init SSL without certificate database
battery.charge: 100
battery.date: 11/15/2024
battery.runtime: 120
battery.runtime.low: 120
battery.voltage: 27
device.contact: Unknown
device.description: APC Web/SNMP Management Card (MB:v4.1.0 PF:v7.2.2 PN:apc_hw05_aos_722.bin AF1:v7.2.2 AN1:apc_hw05_sumx_722.bin MN:AP9631 HR:05 
device.location: hello
device.mfr: APC
device.model: Smart-UPS 1500
device.serial: AS1327113887
device.type: ups
driver.name: snmp-ups
driver.parameter.pollinterval: 2
driver.parameter.port: 192.168.151.2
driver.parameter.synchronous: auto
driver.version: 2.8.0
driver.version.data: apcc MIB 1.6
driver.version.internal: 1.21
input.frequency: 60.20
input.sensitivity: high
input.transfer.high: 127
input.transfer.low: 106
input.transfer.reason: noTransfer
input.voltage: 121.60
input.voltage.maximum: 122.30
input.voltage.minimum: 121.50
output.current: 2
output.frequency: 60.20
output.voltage: 122.30
output.voltage.nominal: 120
ups.firmware: UPS 08.3 (ID18) 
ups.id: apc
ups.load: 21.40
ups.mfr: APC
ups.mfr.date: 07/04/2013
ups.model: Smart-UPS 1500
ups.power: 243
ups.realpower: 215
ups.serial: AS1327113887
ups.status: OL
ups.temperature: 36
ups.test.date: Unknown
ups.test.result: Ok

nahez avatar Dec 07 '25 03:12 nahez

Interesting, looking at various representations of the MIB, I see e.g. https://mibs.observium.org/mib/PowerNet-MIB/#upsBasicControlConserveBattery for .1.3.6.1.4.1.318.1.1.1.6.1.1 (with no trailing .0) described there or in https://networkupstools.org/protocols/snmp/APC-Powernet.pdf as:

The [upsBasicControl] category has one OID, which any Management Card or PowerNet Agent can use to put a UPS that is running on battery into “sleep mode.” [upsBasicControlConserveBattery] Cause a UPS running on battery to turn off its outlets to conserve battery runtime and then wait in “sleep mode” until acceptable input power returns. • noTurnOffUps (1): The value always returned for a GET. Setting this value has no effect. • turnOffUpsToConserveBattery (2): The UPS, if running on battery, waits in “sleep mode” until acceptable input power returns. If the UPS is not on battery, a badValue error is returned.

There is also an advanced tree with 9 operations as of https://mibs.observium.org/mib/PowerNet-MIB/#upsAdvControl seen as nodes under .1.3.6.1.4.1.318.1.1.1.6.2 and many of those are seen in drivers/apc-mib.c also trailed with .0 (so maybe that is supposed to be a shortcut for "node itself"? and maybe it is not ubiquitous?)

This spelling stems from ancient history like commit 78bdf003ab so apparently this worked at some point?..

@nahez : can you please re-test the snmpset experiment without a trailing .0 in the OID? I suppose we can teach snmp-ups to fall back to chopping off such tail? I do not know OTOH if that would be a correct thing to do though.

CC @aquette : any ideas here, please? :-}

jimklimov avatar Dec 07 '25 12:12 jimklimov

Hello, thank you so much for the prompt reply. I am not familiar with how all this works but I tried the snmpset command for the OID without the trailing ".0" and a few other things. I am not too sure if they are useful but here they are.

snmpset -v2c -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6.1.1 i 2
Error in packet. Reason: notWritable (That object does not support modification) Failed object: iso.3.6.1.4.1.318.1.1.1.6.1.1

snmpwalk -v2c -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6.1.1 iso.3.6.1.4.1.318.1.1.1.6.1.1.0 = INTEGER: 1 snmpwalk -v2c -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6.1
iso.3.6.1.4.1.318.1.1.1.6.1.1.0 = INTEGER: 1 nmpwalk -v2c -c private 192.168.151.2 .1.3.6.1.4.1.318.1.1.1.6
iso.3.6.1.4.1.318.1.1.1.6.1.1.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.1.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.2.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.3.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.5.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.6.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.7.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.8.0 = INTEGER: 1 iso.3.6.1.4.1.318.1.1.1.6.2.9.0 = INTEGER: 1

Since you mentioned mib, I looked it up what that is. I also found a mib file listed named "powernet458.mib" under this cards support page. I wonder if this is the structure definitions for this card and if this is useful?

powernet458.txt

Here is the support page for this card.

https://www.se.com/ca/en/product/AP9631/ups-network-management-card-2-with-environmental-monitoring/

thanks again for looking into this.

nahez avatar Dec 07 '25 16:12 nahez

Yes, it is the formal definition of how different OID nodes in the SNMP data tree are named and related (as a further branch or leaf node contained in another). You can find the upsBasicControlConserveBattery definition in the text.

I googled around, and it seems the snmpset <OID>.0 is a commonly used form, and failures are usually due to either lack of support in the firmware, or lack of permission to use a certain command (and/or write a variable). Perhaps double-check the SNMP card configuration, if it allow to manage constraints like this (e.g. community private may be not all-powerful by default?)

Generally, in relatively newer devices there may be an inclination to frown upon SNMP v1/v2 (almost lack of) security model, and to allow access to juicy features only with cryptographically stronger SNMPv3 (with real user accounts or equivalent concept). So one more idea to test is to try that, whether with snmpset or NUT.

jimklimov avatar Dec 07 '25 21:12 jimklimov

Already tried updating permissions for community private. snmpset works for something like device location. That's why in my upsc output the device.location is "hello".

One of the output messages said "No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'!" So I took a guess that maybe because this card is not officially supported, iso.3.6.1.4.1.318.1.1.1.6.1.1.0 is just a fallback and is incorrect for this card. I didn't know exactly how to check if iso.3.6.1.4.1.318.1.1.1.6.1.1.0 is the correct value to set for shutdown, so I thought maybe I can come here to confirm. If someone can confirm this is indeed the correct OID to set for shutdown, then I believe you maybe right that this might be blocked on firmware level as I can set other values like location.

nahez avatar Dec 07 '25 22:12 nahez

just documenting here that using SNMPV3 triggered the same error.

upsc apc Init SSL without certificate database battery.charge: 53 battery.date: 12/15/2025 battery.runtime: 120 battery.runtime.low: 120 battery.voltage: 27 device.contact: Unknown device.description: APC Web/SNMP Management Card (MB:v4.1.0 PF:v7.2.2 PN:apc_hw05_aos_722.bin AF1:v7.2.2 AN1:apc_hw05_sumx_722.bin MN:AP9631 HR:05 device.location: home device.mfr: APC device.model: Smart-UPS 1500 device.serial: AS1327113887 device.type: ups driver.name: snmp-ups driver.parameter.authProtocol: SHA driver.parameter.pollinterval: 2 driver.parameter.port: 192.168.151.2 driver.parameter.privProtocol: AES driver.parameter.secLevel: authPriv driver.parameter.snmp_version: v3 driver.parameter.synchronous: auto driver.version: 2.8.0 driver.version.data: apcc MIB 1.6 driver.version.internal: 1.21 input.frequency: 60 input.sensitivity: high input.transfer.high: 127 input.transfer.low: 106 input.transfer.reason: smallMomentarySpike input.voltage: 121.60 input.voltage.maximum: 121.50 input.voltage.minimum: 120.80 output.current: 1.70 output.frequency: 60 output.voltage: 121.60 output.voltage.nominal: 120 ups.firmware: UPS 08.3 (ID18) ups.id: apc ups.load: 17.60 ups.mfr: APC ups.mfr.date: 07/04/2013 ups.model: Smart-UPS 1500 ups.power: 195 ups.realpower: 176 ups.serial: AS1327113887 ups.status: OL ups.temperature: 35.60 ups.test.date: 12/12/2025 ups.test.result: Ok

upsdrvctl shutdown Network UPS Tools - UPS driver controller 2.8.0 Network UPS Tools - Generic SNMP UPS driver 1.21 (2.8.0) No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'! Please report it to NUT developers, with an 'upsc' output for your device. Going back to the classic MIB detection method. No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'! Please report it to NUT developers, with an 'upsc' output for your device. Going back to the classic MIB detection method. No matching MIB found for sysOID '.1.3.6.1.4.1.318.1.3.27'! Please report it to NUT developers, with an 'upsc' output for your device. Going back to the classic MIB detection method. Detected Smart-UPS 1500 on host 192.168.151.2 (mib: apcc 1.6) Initiating UPS shutdown [apc] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: (genError) A general failure occured Shutdown failed! Driver failed to start (exit status=1)

nahez avatar Dec 18 '25 16:12 nahez

Failing with SNMPv3 is making me think that the driver is likely just using the wrong OID?

Did some more searches and I think I have found the correct OID for shutdown/reboot. It is this .1.3.6.1.4.1.318.1.1.1.6.2.2.0

This was suggested by google

Incorrect OID or Data Type: The most common OID for a graceful shutdown/reboot on APC units is .1.3.6.1.4.1.318.1.1.1.6.2.2.0 (or sometimes .1.3.6.1.4.1.318.1.1.1.6.1.1.0 depending on the exact firmware/model). The expected data type for this OID is typically an integer (i). A value of 3 should initiate a graceful shutdown and reboot.

Also kinda confirmed by chatgpt

Commonly seen command OIDs .6.1.1.0 → UPS Control (older / simpler models) .6.2.2.0 → UPS Control (newer firmware / SmartSlot path) Different firmware exposes one or both. You already saw both exist.

Confirmed with snmpset ... .1.3.6.1.4.1.318.1.1.1.6.2.2.0 i 3 The ups started to shutdown and proceeded to reboot immediately

Is it possible to use this OID instead for this specfic card with sysOID '.1.3.6.1.4.1.318.1.3.27'? I am not sure what this entails. Should the driver be updated or should i change this in my setup manually?

Thanks so much!

nahez avatar Dec 18 '25 23:12 nahez

Maybe, but it would need a rebuild of the driver you have. The OID is actually mentioned in the driver source, although its usage is commented away:

$ git grep -E 'CMD_SDRET|APCC_OID_REBOOT|1.3.6.1.4.1.318.1.1.1.6.2.2'
drivers/apc-mib.c:#define APCC_OID_REBOOT                       ".1.3.6.1.4.1.318.1.1.1.6.2.2"
drivers/apc-mib.c:/*    snmp_info_default(CMD_SDRET, 0, APCC_REBOOT_GRACEFUL, APCC_OID_REBOOT, "", SU_TYPE_CMD | SU_FLAG_OK, NULL), */

(note it mentions also CMD_SDRET which would probably be shutdown.return but is not defined anywhere).

jimklimov avatar Dec 19 '25 08:12 jimklimov

Sorry I meant would this be considered a bug in the driver that someone more experienced with this could consider updating for everyone or is the driver considered working as intended, no fix needed and I need to somehow make this work for myself. Thanks!

nahez avatar Dec 19 '25 19:12 nahez

Probably the driver needs an update by a dev...

jimklimov avatar Dec 21 '25 20:12 jimklimov

Ok thank you for the answer. I'll just leave this issue here and hopefully someone can find sometime to fix this whenever.

nahez avatar Dec 21 '25 22:12 nahez