Text only | Text with Images

OPNsense Forum

English Forums => 26.1, 26,4 Series => Topic started by: mrzaz on May 24, 2026, 05:12:04 AM

Title: Previously working os-apcupsd plugin has stopped working.
Post by: mrzaz on May 24, 2026, 05:12:04 AM
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"

Best regards
Dan Lundqvist
Stockholm, Sweden
Title: Re: Previously working os-apcupsd plugin has stopped working.
Post by: viragomann on May 24, 2026, 02:21:05 PM
Quote from: mrzaz on May 24, 2026, 05:12:04 AMI 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.
Title: Re: Previously working os-apcupsd plugin has stopped working.
Post by: mrzaz on May 24, 2026, 06:52:35 PM
Quote from: viragomann on May 24, 2026, 02:21:05 PM
Quote from: mrzaz on May 24, 2026, 05:12:04 AMI 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
Title: Re: Previously working os-apcupsd plugin has stopped working.
Post by: mrzaz on July 12, 2026, 05:18:31 PM
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
Text only | Text with Images