NUT package (2.8.0 and below)

dennypage

Found the fix? Not sure why this hasn't been merged into pfSense 2.7. this is old it seems. pfSense using mib v0.51 and this is 0.52 to fix the issue

https://github.com/networkupstools/nut/commit/6a6888e9b5fd995e79e3db335ff4c9c524f31b51

It's not a question of being merged into pfSense. A version of NUT with that fix has not actually been released yet. The most recent release of NUT is 2.8.0, in April 2022. We have been waiting for 2.8.1 for some time. I'm sure that when 2.8.1 is released, it will be in FreeBSD Ports, and the pfSense repo, shortly thereafter.

As it sits, the only way to get a fully functional build for the various Cyberpower UPS units is to build against NUT's development (master) branch. Unfortunately, this is a moving target.

incith

@dennypage Hmm, that sucks! Thanks for the information.

Unfortunately the linked snmp-ups driver will not load. It's an Intel xeon e3 v3 so should be compatible I'd have thought. Perhaps it needs rebuilt for pfSense 2.7?

dennypage

@incith said in NUT package:

Unfortunately the linked snmp-ups driver will not load.

Need more information. Please start the driver by hand as described in the other thread. and report the actual errors encountered.

FWIW, this description:

pfSense -> remote-snmp driver -> IP of windows server.

Doesn't make sense. You are using the snmp driver, so you should be talking directly to the UPS using the IP address of the UPS rather than a Windows server.

incith

@dennypage The ups does not have a network card.

PowerPanel software communicate with the ups over USB. PowerPanel software provides the SNMP server.

It's honestly very straightforward.

DurUser

@incith Yeah, what we're talking about (THE issue) is on pfsense connected to a UPS directly. Your setup is different.

incith

@DurUser My issue is not your issue. We are discussing the SNMP driver. I was simply proffering up how my setup is configured since you seemed confused about it

incith

@dennypage

Ah. Yeah, all good now, driver works. Thanks!

Druidblack

Hello everyone. After upgrading to 2.7, the UPS IPPON_Back_Basic_650S_Euro stopped being determined. Is there a solution to this problem.
P.S. I have tried all versions of connections that are available in the NUT menu.

Adding user=root to ups.conf helped. I use the driver and blazer.

keyser

@Maltz said in NUT package:

I have realized that all I did was re-compile the problematic v2.8.0 instead of the devel version. Oops. Here's the ARM verson of usbhid-ups from nut-devel-2023.06.06

usbhid-ups.gz

sha256sum of uncompressed file:
cdeb8d4400e0c721c878c0af084f48356323c29b7f9ef4fc526b4d9a3ff339a5 usbhid-ups

Hi Maltz. Thank you for your work. I have been running your compiled ARM64 usbhid.ups on my SG-2100 for about a week now, and I can confirm it at least solves the problem of loosing the UPS status at the random disconnects. It is now able to reconnect without addtional config on 23.05 (no run as root fx).
Here is a extract from my log when the disconnect happes, and it then reconnects successfully:

Jul 5 01:01:02 php-cgi 61460 rc.dyndns.update: phpDynDNS (): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
Jul 4 23:36:29 upsmon 4478 Communications with UPS eaton5sc established
Jul 4 23:36:29 upsd 6047 UPS [eaton5sc] data is no longer stale
Jul 4 23:36:24 upsmon 4478 Communications with UPS eaton5sc lost
Jul 4 23:36:24 upsmon 4478 Poll UPS [eaton5sc] failed - Data stale
Jul 4 23:36:24 kernel ugen1.2: <EATON 5S> at usbus1
Jul 4 23:36:22 usbhid-ups 13495 libusb1: Could not open any HID devices: no USB buses found
Jul 4 23:36:21 kernel ugen1.2: <EATON 5S> at usbus1 (disconnected)
Jul 4 23:36:21 upsd 6047 Data for UPS [eaton5sc] is stale - check driver
Jul 4 23:36:21 usbhid-ups 13495 libusb1: Could not open any HID devices: insufficient permissions on everything
Jul 4 12:30:26 php-cgi 78812 rc.update_urltables: /etc/rc.update_urltables: pfB_Blocked_Countries_v4 does not need updating.

Any idea if the disconnect issue could be a voltage problem or some USB settings thing i pfSense? It seems strange driver says there is no USB buses found at disconnect time. I have never had issues on this SG-2100 with another UPS I have, so it could be a driver issue when something unforseen happens. The same UPS that shows issues here never disconnects on a Windows machine I have (or my Raspberry Pi).

dennypage

@keyser said in NUT package:

Any idea if the disconnect issue could be a voltage problem or some USB settings thing i pfSense? It seems strange driver says there is no USB buses found at disconnect time.

Some UPS brands, Notably Cyberpower, are well known to randomly disconnect on USB. I don't know why, but it's a fact of life with some manufactures.

I wouldn't read anything into the "no USB buses found" message. That's just a generic hard coded error that NUT reports when it has exhausted its attempts to open a USB HID device.

keyser

@dennypage I guess it’s something I have to live with. I just find it curious that the very same UPS with the same cable shows no such behaviour on Windows Installs or my Rasberry Pi (Rasberry Pi OS). So my logic says that indicates it something with the USB/USB Driver on pfSense.

dennypage

@keyser said in NUT package:

I just find it curious that the very same UPS with the same cable shows no such behaviour on Windows Installs or my Rasberry Pi (Rasberry Pi OS). The same UPS that shows issues here never disconnects on a Windows machine I have (or my Raspberry Pi).

There are a lot of things different among the three systems you list. USB chips, hub implementations, base drivers for both the USB chip and the hub, drivers for HID, etc. Too many differences to draw conclusions.

It could also be that it's happening on those systems as well but is just not reported. You would have to put a USB analyzer on it to know for sure. As this behavior is well known for some UPSs, I tend to put that as the highest likelihood.

Maltz

@keyser Maybe try googling the UPS model number and "NUT" or "Network UPS Tools", and/or the error from your logs and see what pops up. It's much more likely that the root cause is in upstream FreeBSD or NUT, like the other two recent issues have been, than in pfSense or this NUT wrapper package. (Assuming the UPS itself isn't being weird, a la CyberPower)

But dennypage is right - there are too many variables to do much troubleshooting without being hands-on with the specific gear.

lcbbcl

@dennypage i come back after a 2.7 clean install with the same error like before.
upsmon 85035 UPS [APC]: connect failed: Connection failure: Connection refused
I add user=root in ups.conf and also hw.usb.quirk.0="0x051d 0x0003 0x0000 0xffff UQ_HID_IGNORE" on loader.conf.local and it is not working anymore

dennypage

@lcbbcl You didn't give detail as to what "not working" means (permission failure, bus error, etc.), but the usual caveats about disconnect/reconnect or reboot following install still apply. The quirk definitely requires a reboot.

I would suggest that you install the updated usbhid-ups and reboot. If that doesn't work, then please post some detail about what you are seeing.

lcbbcl

@dennypage Done is fixed , i deleted and redo the loader.cond.local

Nuggets 0

@dennypage

Unfortunately this did not work for me. Even worse it seems to have broken it more. I would be able to restart the NUT service and it would work for a while and then crap out, but with the dev usbhid-ups, it won't connect at all.

pfSense+ 23.05.1-RELEASE (amd64)
NUT 2.8.0_2. UPS Type: Local USB. Driver: usbhid
Cyperpower CP1500AVRLCD connected over USB.
Was working fine prior to upgrading from pfsense CE 2.6.0. Already tried reinstalling the NUT package.

Tried the below to resolve:

interruptonly by itself
user=root by itself
Use the dev usbhid-ups by itself
Didn't try any combination of the above together.

Steps taken to use the dev usbhid_ups

Stopped NUT
Backed up original usbhid-ups from /usr/local/libexec/nut/
Removed and uploaded the dev usbhid-ups you provided.
chmod 755 (the permissions didn't match)
Ran "logger beforerestart" to have a clear spot in the logs to reference (you'll see that in the log snip below)
Started NUT. Failed to connect
Rebooted. Still failed to connect.
Stopped NUT, removed dev usbhid-ups, and restored original. Fixed permissions
Started NUT. Successfully connects on startup but disconnects after some time.

Logs from using the dev usbhid-ups

Sep  7 16:01:02 pfbox root[96703]: beforerestart
Sep  7 16:01:02 pfbox php-fpm[396]: /nut_settings.php: Configuration Change: admin@10.10.10.123 (Local Database): Updated UPS settings
Sep  7 16:01:02 pfbox check_reload_status[435]: Syncing firewall
Sep  7 16:01:02 pfbox php-fpm[396]: /nut_settings.php: Stopping service nut
Sep  7 16:01:02 pfbox upsmon[21097]: Signal 15: exiting
Sep  7 16:01:02 pfbox upsd[22142]: User local-monitor@::1 logged out from UPS [CP1500AVRLCD]
Sep  7 16:01:02 pfbox upsd[22142]: mainloop: Interrupted system call
Sep  7 16:01:02 pfbox upsd[22142]: Signal 15: exiting
Sep  7 16:01:02 pfbox php-fpm[396]: /nut_settings.php: Starting service nut
Sep  7 16:01:02 pfbox upsmon[1506]: Startup successful
Sep  7 16:01:02 pfbox upsmon[2025]: UPS [CP1500AVRLCD]: connect failed: Connection failure: Connection refused
Sep  7 16:01:02 pfbox upsmon[2025]: Communications with UPS CP1500AVRLCD lost
Sep  7 16:01:03 pfbox upsd[14606]: listening on ::1 port 3493
Sep  7 16:01:03 pfbox upsd[14606]: listening on 127.0.0.1 port 3493
Sep  7 16:01:03 pfbox upsd[14606]: Can't connect to UPS [CP1500AVRLCD] (usbhid-ups-CP1500AVRLCD): Connection refused
Sep  7 16:01:03 pfbox upsd[14784]: Startup successful

On the original usbhid-ups, it starts up fine, and then later starts to have the same issue. This is with no additional options configured.

Sep  7 16:05:26 pfbox upsmon[86229]: Startup successful
Sep  7 16:05:26 pfbox upsmon[86705]: UPS [CP1500AVRLCD]: connect failed: Connection failure: Connection refused
Sep  7 16:05:26 pfbox upsmon[86705]: Communications with UPS CP1500AVRLCD lost
Sep  7 16:05:26 pfbox usbhid-ups[87908]: Startup successful
Sep  7 16:05:27 pfbox upsd[88031]: listening on ::1 port 3493
Sep  7 16:05:27 pfbox upsd[88031]: listening on 127.0.0.1 port 3493
Sep  7 16:05:27 pfbox upsd[88031]: Connected to UPS [CP1500AVRLCD]: usbhid-ups-CP1500AVRLCD
Sep  7 16:05:27 pfbox upsd[88080]: Startup successful
Sep  7 16:05:31 pfbox upsd[88080]: User local-monitor@::1 logged into UPS [CP1500AVRLCD]
Sep  7 16:05:31 pfbox upsmon[86705]: Communications with UPS CP1500AVRLCD established
###Gap in time where it was working###
Sep  7 17:52:08 pfbox upsd[88080]: Can't connect to UPS [CP1500AVRLCD] (usbhid-ups-CP1500AVRLCD): Connection refused
**Sep  7 17:52:08 pfbox kernel: pid 87908 (usbhid-ups), jid 0, uid 316: exited on signal 10**
Sep  7 17:52:13 pfbox upsmon[86705]: Poll UPS [CP1500AVRLCD] failed - Driver not connected
Sep  7 17:52:13 pfbox upsmon[86705]: Communications with UPS CP1500AVRLCD lost
Sep  7 17:52:18 pfbox upsmon[86705]: Poll UPS [CP1500AVRLCD] failed - Driver not connected
Sep  7 17:52:23 pfbox upsmon[86705]: Poll UPS [CP1500AVRLCD] failed - Driver not connected

I tried enabling debug in the additional options for NUT based on the NUT documentation but didn't see any debug messaging being output anywhere.

Any wisdom or guidance for me? My telegram bot is annoying the hell out of me

dennypage

@Nuggets-0 said in NUT package:

kernel: pid 87908 (usbhid-ups), jid 0, uid 316: exited on signal 10

I would suggest double checking the file checksums against the alternate usbhid-ups checksums posted back on March 12th.

Nuggets 0

@dennypage

Thanks for the quick response (and for all that you've done). I did do that when I originally did it but I did it again so I could get you the command output below. I use openhashtab which does it for you in the properties tab and confirms if it's a match if you paste in a value to compare it to. I copied the sha1 and sha256 values you provided and confirmed them when I downloaded and extracted. Then when I copied them to the system, I ran sha1 and sha256 on the file and compared it to the confirmed downloaded copy which also match the values you provided.

/usr/local/libexec/nut: sha1 usbhid-ups; sha256 usbhid-ups
SHA1 (usbhid-ups) = 49ce9131502bfb8b789ee97b7fb3fc81fc9f8fff
SHA256 (usbhid-ups) = 999a2653559dbc50ecc8ba592a67587b1e307a1495f6e8ebbd3d8e90e3967133

I'm using the usbhid-ups you provided on that post from ~~July 7th~~ March 12th (the one I replied to). Is that the right one or is there an updated one?

EDIT: ~~Just realized you said there was one on March 12th. I'll try that one and report back.~~
Not sure where I got July 7th, but the March 12th one is indeed the one I tried. SHA1 and SHA256 above match it and I even have it in my notes that it's the one I tried. Just mixed up a date when typing this post.

dennypage

@Nuggets-0 Sorry, I mixed up which was dev and which was original. Looking at your logs, the original version is the one that is core dumping (as you would expect).

The logs with the dev version do not show any output from usbhid-ups. You are on an x86_64 system, yes? If so, can you try starting the executable by hand please?

If you are on a ARM instead of an x86_64, you need to use a different executable. I believe that someone else posted an ARM executable. [Edit: On Jul 7, 2023]