Messages

Thank you for your swift reply. I'm a bit ashamed I didn't find your solution on my own 🫣�

Code Select Expand

opnsense-revert -r 26.1.7 nut
pkg lock nut


Thank you!

[NUT 2.8.5_1: upsc, upscmd, and upsrw segfault after successful query; NUT Diagnostics page remains empty]

NUT 2.8.5_1: upsc, upscmd, and upsrw segfault after successful query; NUT Diagnostics page remains empty

Environment

• OPNsense 26.1.9-amd64
• NUT package: nut-2.8.5_1
• os-nut package: os-nut-1.9_1
• Platform: FreeBSD 14.3 (OPNsense)
• UPS: Generic USB UPS
• Vendor ID: 0001
• Product ID: 0000
• USB Product String: MEC0003
• Manufacturer String: MEC

Problem Summary

NUT successfully communicates with the UPS and returns valid telemetry, but the NUT client utilities ([tt]upsc[/tt], [tt]upscmd[/tt], and [tt]upsrw[/tt]) consistently segfault after completing their output.

Additionally, the OPNsense NUT Diagnostics page remains empty even though the UPS is operational and data can be queried.

Current Working Configuration

Code Select Expand

[SKE850]
driver=nutdrv_qx
port=auto
vendorid=0001
productid=0000

Evidence that the Driver Works

The following command successfully retrieves live UPS data:

Code Select Expand

upsc SKE850

Example output:

Code Select Expand

battery.charge: 100
battery.voltage: 13.4
device.mfr: Ippon
driver.name: nutdrv_qx
driver.version: 2.8.5
driver.version.data: INNOVATAE 0.01
input.frequency: 60.2
input.voltage: 121.5
output.voltage: 121.8
ups.load: 27
ups.status: OL
ups.type: offline / line interactive

Immediately after printing all values:

Code Select Expand

Segmentation fault

The same occurs with:

Code Select Expand

upsc SKE850@localhost
upsc SKE850@127.0.0.1

Other Affected Commands

Code Select Expand

upscmd -l SKE850

Lists all supported commands successfully and then segfaults.

Code Select Expand

upsrw SKE850

Lists writable variables successfully and then segfaults.

Even querying a single variable reproduces the issue:

Code Select Expand

upsc SKE850 battery.charge

Output:

Code Select Expand

100
Segmentation fault


Code Select Expand

upsc SKE850 ups.status

Output:

Code Select Expand

OL
Segmentation fault

Daemon Status

Code Select Expand

service nut status

Output:

Code Select Expand

nut is running as pid XXXXX

upsd is listening normally:

Code Select Expand

sockstat -4 -6 | grep upsd

and shows listeners on TCP/3493.

Kernel Messages

Code Select Expand

pid XXXXX (upsc), jid 0, uid 0: exited on signal 11 (no core dump - bad address)

This occurs every time [tt]upsc[/tt] is run.

LLDB Backtrace

The crash occurs after all data has already been printed.

Code Select Expand

frame #0: libthr.so.3
frame #1: libcrypto.so.12`CRYPTO_THREAD_read_lock
frame #2: libcrypto.so.12
frame #3: libcrypto.so.12
frame #4: legacy.so
frame #5: libcrypto.so.12
frame #6: libcrypto.so.12
frame #7: libssl.so.12`SSL_CTX_free
frame #8: libupsclient.so.7`upscli_cleanup
frame #9: upsc

The crash appears to occur during cleanup/freeing of SSL/OpenSSL resources rather than during UPS communication.

Impact

• UPS communication is functional.
• Telemetry is available.
• nutdrv_qx appears healthy.
• NUT client utilities crash on exit.
• OPNsense NUT Diagnostics page remains empty, likely because the helper process exits with SIGSEGV.

Additional Note

The UPS was initially detected as USB device MEC0003 (vendor 0001, product 0000).

After simplifying the generated configuration to only:

Code Select Expand

[SKE850]
driver=nutdrv_qx
port=auto
vendorid=0001
productid=0000

communication with the UPS became fully functional. The remaining issue appears limited to client-side crashes and the empty Diagnostics page.

Question

Has anyone else observed upsc, upsrw, or upscmd segfaulting under NUT 2.8.5_1 on OPNsense/FreeBSD 14.3, particularly in libupsclient cleanup paths involving SSL_CTX_free() and OpenSSL 3 libraries?

Thanks, I had none 😯

root@OPNsense:~ # less /etc/resolv.conf
domain pihole
search pihole

I followed this guide using method 1: https://docs.pi-hole.net/routers/opnsense/#method-1-distribute-pi-hole-as-dns-server-via-dhcp

I got it working again by entering my pihole IPv4 and IPv6 address here as well: System: Settings: General: [Networking/DNS Servers]

Now my resolv.conf file looks like this:
You cannot view this attachment.

I hope that's the right OPNsense way to do it.

Thanks Franco, I checked my DNS (little Pihole server) and I can access http://pkg.opnsense.org/ and any other sites that aren't on a blocklist.

But when I ssh into OPNsense and ping I get errors:


root@OPNsense:~ # ping bing.com
ping: cannot resolve bing.com: Name does not resolve
root@OPNsense:~ # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=15.700 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=25.244 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=13.440 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=17.130 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=11.652 ms
^C
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.652/16.633/25.244/4.696 ms
root@OPNsense:~ # ping http://pkg.opnsense.org/FreeBSD:14:amd64/
ping: cannot resolve http://pkg.opnsense.org/FreeBSD:14:amd64/: Name does not resolve


I wonder how to fix that. I want the Pihole DNS served to all clients in the LAN.

I get this error when I initiate an update:

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 25.7.4 (amd64) at Mon Oct 13 00:44:11 EDT 2025
Fetching changelog information, please wait... fetch: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/changelog.txz: Host does not resolve
Updating OPNsense repository catalogue...
pkg: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/meta.txz: No address record
repository OPNsense has no meta file, using default settings
pkg: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/packagesite.pkg: No address record
pkg: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/packagesite.txz: No address record
Unable to update repository OPNsense
Error updating repositories!
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***