CLOSED: Previously working os-apcupsd plugin has stopped working.

[mrzaz]

Hello,
I have a APC UPS SMT750IC but uses "APC PowerShute Serial Shutdown" in my server
to handle shutdown of the server (as my old standalone SNMP card was to old for the new UPS)
but also act as a NIS for other devices like Synology DS920+ and OpnSense via the "os-apcupsd"
plugin and it has been working fine for a couple of years.
Both from Synology but also from OpnSense.

I have relied on that it was working good for a very long time so i forgot to check it in more
details in OpnSense but tonight I realised that it was broken.  No info in the dashboard widget,
no info in the apcupsd plugin status screen. Found one problem that was related to NIS port 3551
being used but changed to 3552 to test but still not resolved.

I use "Ether, snmp, 192.168.x.x:161:APC:private" as config which has been working for years but now stopped working.

Log shows
2026-05-24T03:11:37 Notice apcupsd apcupsd 3.14.14 (31 May 2016) freebsd startup succeeded

I have traced the port 161 signalling out of OpnSense on LAN going out OK.
I then traced the port 161 signalling in to server with "PowerShute Serial Shutdown" application and it is comming in.
But still nothing.

I then checked Synology UPS settings and it is working fine, both on SNMP v2c (using private) and also v3 with username/psw.

I tried to start it manually to get startup log entries but nothing found really apart from
Selected community: "private"
Selected MIB: "APC"
But there are NO successful SNMP reads afterward.

Have no clue why this started happening, especially as it works totally fine from Synology NAS and also from OpnSense for a long time.

Does anyone else use "os-apsupsd" plugin that also experience the same issue ?

I am running on latest version of OpnSense/Apsupsd.

BR,
Dan Lundqvist
Stockholm, Sweden


UPDATE:  I draw conclusion to fast.  Still has the issue and have, after some debugging,
most likely found some incompatibility between os-apcupsd and its use of 10+ year old snmplite.

I installed Net-SNMP which is much later and have used snmpwalk to communicate perfect
with the APC Serial Shutdown but when used with snmpwalk it does not get any response.

I will send an email to the assigned support for it through email or shared ChatGPT link.

I have installed the Net-SNMP plugin in OpnSense to be able to do a lot of testing to compare
what happens with communication and works OK with Net-SNMP where I used snmp

My suggestion is to replace the built-in (very old 10+ snmplite) with the "Net-SNMP" plugin
that is available in plugins. Or possible add functionality to configure which snmp to use
(Internal snmplite or plugin Net-SNMP.)

https://chatgpt.com/share/6a5359b4-95fc-83ed-8bbe-5db0933cbf56

Through tracings I could see that it uses snmp-v1 and when I use:
snmpwalk -v1 -c private 192.168.<x>.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

root@OPNsense:~ # snmpwalk -v1 -c private 192.168.<x>.4 PowerNet-MIB::upsBasicBatteryStatus
PowerNet-MIB::upsBasicBatteryStatus.0 = INTEGER: batteryNormal(2)

root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"
SNMPv2-SMI::enterprises.318.1.1.1.1.1.2.0 = STRING: "APC UPS"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.1.0 = STRING: "UPS 18.0 / COM 18.0 (1027 - 45)"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.2.0 = STRING: "11/7/23"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.3.0 = STRING: "3S2344X14916"
SNMPv2-SMI::enterprises.318.1.1.1.2.1.1.0 = INTEGER: 2
SNMPv2-SMI::enterprises.318.1.1.1.2.1.2.0 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::enterprises.318.1.1.1.2.1.3.0 = STRING: "3/12/26"
SNMPv2-SMI::enterprises.318.1.1.1.2.2.1.0 = Gauge32: 100
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 38
SNMPv2-SMI::enterprises.318.1.1.1.2.2.3.0 = Timeticks: (192800) 0:32:08.00
.
.
root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

root@OPNsense:~ # snmpgetnext -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

UPDATE 2026-07-15:
I think we need to close this thread as it, for an unexplained reason started to work.
I could now see that packets sent, that earlier never got a reply now suddenly started to respond.

I did one thing though.  I uninstalled the apcupsd plugin and re-installed and now it works.

Best regards
Dan Lundqvist
Stockholm, Sweden

[viragomann]

I have traced the port 161 signalling out of OpnSense on LAN going out OK.
I then traced the port 161 signalling in to server with "PowerShute Serial Shutdown" application and it is comming in.
But still nothing.

So OPNsense doesn't get a response from the server?
If so you should rather look for the reason on the server.

Was the OPNsense interface address changed by any chance?
In this case you might have to update the access control list of the SNMP server.

[mrzaz]

I have traced the port 161 signalling out of OpnSense on LAN going out OK.
I then traced the port 161 signalling in to server with "PowerShute Serial Shutdown" application and it is comming in.
But still nothing.

So OPNsense doesn't get a response from the server?
If so you should rather look for the reason on the server.

Was the OPNsense interface address changed by any chance?
In this case you might have to update the access control list of the SNMP server.

I have enabled some debugging in the PowerShute and I could see the following:

OpnSense
2026-05-24 18:13:23,492 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] got Request from:[B@3611beffCommandResponderEvent[securityModel=1, securityLevel=1, maxSizeResponsePDU=2147483647, pduHandle=PduHandle[476310], stateReference=StateReference[msgID=0,pduHandle=PduHandle[476310],securityEngineID=null,securityModel=null,securityName=private,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=GETNEXT[requestID=476310, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.318.1.1.1.1.1.2 = Null]], messageProcessingModel=0, securityName=private, processed=true, peerAddress=192.168.120.20/37256, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@16a362a3, tmStateReference=null]
2026-05-24 18:13:23,492 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] Successfull Connection

Synology
2026-05-24 18:29:35,601 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] got Request from:[B@b420132CommandResponderEvent[securityModel=1, securityLevel=1, maxSizeResponsePDU=2147483647, pduHandle=PduHandle[1113222366], stateReference=StateReference[msgID=0,pduHandle=PduHandle[1113222366],securityEngineID=null,securityModel=null,securityName=private,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=GET[requestID=1113222366, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.1.2.0 = Null]], messageProcessingModel=0, securityName=private, processed=true, peerAddress=192.168.120.64/44555, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@16a362a3, tmStateReference=null]
2026-05-24 18:29:35,601 [DefaultUDPTransportMapping_0.0.0.0/161] DEBUG - [Util.ExtendedCommandProcessor.()] Successfull Connection

However, Synology gets more connections and readout that looks more OK than OpnSense.
I have saved 2 logs. One for OpnsSense NON-working and one from Synology workign.

Will try to investigate some more with debugging in Apcupsd.

I changed from private to public to separate some other SNMP that was going from Opn to Synology about disks and could see that it sends
the following but never gets any response (and could not find anything in the other logs to why:

1   0.000000   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.2.2.6
2   2.007897   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.3.2.3
9   4.019971   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.3.2.2
10   6.030553   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.4.1.1
15   8.037828   192.168.120.20   192.168.120.4   SNMP   89   161   get-next-request 1.3.6.1.4.1.318.1.1.1.2.2.4

Frame 1: Packet, 89 bytes on wire (712 bits), 89 bytes captured (712 bits)
Ethernet II, Src: 52:54:00:74:c0:6c (52:54:00:74:c0:6c), Dst: Intel_d5:60:9f (a0:36:9f:d5:60:9f)
Internet Protocol Version 4, Src: 192.168.120.20, Dst: 192.168.120.4
User Datagram Protocol, Src Port: 37743, Dst Port: 161
Simple Network Management Protocol
    version: version-1 (0)
    community: public
    data: get-next-request (1)
        get-next-request
            request-id: 514747
            error-status: noError (0)
            error-index: 0
            variable-bindings: 1 item
                1.3.6.1.4.1.318.1.1.1.2.2.6: Value (Null)
                    Object Name: 1.3.6.1.4.1.318.1.1.1.2.2.6 (iso.3.6.1.4.1.318.1.1.1.2.2.6)
                    Value (Null)

I have not changed the version on PowerShute. Only the OpnSense/plugins.

Also -d 99 did not give anything either. :-/
/usr/local/sbin/apcupsd -f /usr/local/etc/apcupsd/apcupsd.conf -d 99

I have checked some traces between Synology och PowerShute and there it looks OK. It gets response/reply on each request.

//Dan Lundqvist

[mrzaz]

Please see the updated "UPDATE" in main post for more information.

UPDATE:  I draw conclusion to fast.  Still has the issue and have, after some debugging,
most likely found some incompatibility between os-apcupsd and its use of 10+ year old snmplite.

I installed Net-SNMP which is much later and have used snmpwalk to communicate perfect
with the APC Serial Shutdown but when used with snmpwalk it does not get any response.

I will send an email to the assigned support for it through email or shared ChatGPT link.

I have installed the Net-SNMP plugin in OpnSense to be able to do a lot of testing to compare
what happens with communication and works OK with Net-SNMP where I used snmp

My suggestion is to replace the built-in (very old 10+ snmplite) with the "Net-SNMP" plugin
that is available in plugins. Or possible add functionality to configure which snmp to use
(Internal snmplite or plugin Net-SNMP.)

https://chatgpt.com/share/6a5359b4-95fc-83ed-8bbe-5db0933cbf56

Through tracings I could see that it uses snmp-v1 and when I use:
snmpwalk -v1 -c private 192.168.<x>.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

root@OPNsense:~ # snmpwalk -v1 -c private 192.168.<x>.4 PowerNet-MIB::upsBasicBatteryStatus
PowerNet-MIB::upsBasicBatteryStatus.0 = INTEGER: batteryNormal(2)

root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"
SNMPv2-SMI::enterprises.318.1.1.1.1.1.2.0 = STRING: "APC UPS"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.1.0 = STRING: "UPS 18.0 / COM 18.0 (1027 - 45)"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.2.0 = STRING: "11/7/23"
SNMPv2-SMI::enterprises.318.1.1.1.1.2.3.0 = STRING: "3S2344X14916"
SNMPv2-SMI::enterprises.318.1.1.1.2.1.1.0 = INTEGER: 2
SNMPv2-SMI::enterprises.318.1.1.1.2.1.2.0 = Timeticks: (0) 0:00:00.00
SNMPv2-SMI::enterprises.318.1.1.1.2.1.3.0 = STRING: "3/12/26"
SNMPv2-SMI::enterprises.318.1.1.1.2.2.1.0 = Gauge32: 100
SNMPv2-SMI::enterprises.318.1.1.1.2.2.2.0 = Gauge32: 38
SNMPv2-SMI::enterprises.318.1.1.1.2.2.3.0 = Timeticks: (192800) 0:32:08.00
.
.
root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

root@OPNsense:~ # snmpgetnext -v1 -c private 192.168.x.4 .1.3.6.1.4.1.318.1.1.1.1.1.1
SNMPv2-SMI::enterprises.318.1.1.1.1.1.1.0 = STRING: "Smart-UPS 750"

Best regards
Dan Lundqvist
Stockholm, Sweden

//Dan Lundqvist

[mrzaz]

I think we need to close this thread as it, for an unexplained reason started to work.
I could now see that packets sent, that earlier never got a reply now suddenly started to respond.

I did one thing though.  I uninstalled the apcupsd plugin and re-installed and now it works.

/Dan

[mrzaz]

Hello,

I have managed to figure out what the culprit was for this problem.

Explanation:
When I enabled tailscale client on the server the PowerShute is running, in the tcpdump traces
from opnsense shows that it only sends but never receives on LAN net.

From tcpdump in opnsense could see this behaviour.

But when I disable the tailscale app in .4 server then all comes through OK.

I even saw this when testing with net-snmp snmpwalker. (packets leaving but no response on LAN .20 from 192.168.x.4.
Client however handled it because I got output)

Code Select Expand

root@OPNsense:~ # snmpwalk -v1 -c private 192.168.x.4 .1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: PowerChute Business Edition
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.318.1.3.33.1
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (60296) 0:10:02.96
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: PowerChute UPS
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 10
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
I suspect that the server gets the the command from LAN 192.168.x.20 but
then (because tailscale is also enabled in opnsense) it sends
the response back on the tailscale interface.

Synology (which also has tailscale) seems to handle it.
Net-SNMP plugin in opnsense seems to handle it.
apcupsd in opnsense, NOT so much.  :-/

Not sure when in time they swapped from net-snmp in apcupsd to other snmp client ?

So in the past it is most likely working because 1 - I hadn't enabled tailscale on server yet.
OR 2. they changed from net-snmp to other and then it broke.

Seems like Net-SNMP handles it better though.

Net-SNMP tailscale on in server  (also look similar with apcupsd with only outgoing on LAN net.)

Code Select Expand

root@OPNsense:~ # tcpdump -i em1 host 192.168.x.4 and udp port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on em1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:59:54.947059 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(26)  system
21:59:54.948212 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysDescr.0
21:59:54.948706 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysObjectID.0
21:59:54.949247 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysUpTime.0
21:59:54.949683 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysContact.0
21:59:54.950191 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysName.0
21:59:54.950629 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysLocation.0
21:59:54.951030 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysServices.0
21:59:54.951481 IP OPNsense.57487 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.8.0

Net-SNMP tailscale off in server

Code Select Expand

root@OPNsense:~ # tcpdump -i em1 host 192.168.x.4 and udp port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on em1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:01:08.907568 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(26)  system
22:01:08.908316 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(55)  system.sysDescr.0="PowerChute Business Edition"
22:01:08.908388 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysDescr.0
22:01:08.908763 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(39)  system.sysObjectID.0=E:318.1.3.33.1
22:01:08.908788 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysObjectID.0
22:01:08.909213 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(31)  system.sysUpTime.0=60296
22:01:08.909235 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysUpTime.0
22:01:08.909562 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(28)  system.sysContact.0=""
22:01:08.909580 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysContact.0
22:01:08.909861 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(42)  system.sysName.0="PowerChute UPS"
22:01:08.909879 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysName.0
22:01:08.910161 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(28)  system.sysLocation.0=""
22:01:08.910177 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysLocation.0
22:01:08.910461 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(29)  system.sysServices.0=10
22:01:08.910479 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.sysServices.0
22:01:08.910810 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(29)  system.8.0=0
22:01:08.910827 IP OPNsense.50746 > 192.168.x.4.snmp:  C="private" GetNextRequest(28)  system.8.0
22:01:08.911209 IP 192.168.x.4.snmp > OPNsense.50746:  C="private" GetResponse(30)  snmp.snmpInPkts.0=499

I will test a bit with some settings in server tailscale client.

But now I have found the main reason at least.

Interesting is that Net-SNMP for sure handles it even if the response came back on tailscale interface. (as seen further up)

I tested to use the tailscale IP to the server instead of the LAN net and then it works with apcupsd with tailscale enabled in server. 😊

Best regards
Dan Lundqvist
Stockholm, Sweden