-
@dennypage ...ok?
-
@incith Your prior post referred to an adjustment in polling interval. FWIW, I do not see any polling interval in the configuration you posted.
As to your actual problem, it is discussed here. Assuming that you are on an Intel or AMD based platform, you use the updated snmp-ups driver posted in that thread.
-
@incith huh ? So your master is a windows machine ?
We're talking about the pfsense machine being the master. It does show disconnects. Windows likely does not.
I have a completely seperate workstation running windows with a different cyberpower 1500 ups and it never notifies me of disconnects... ever. That could mean 2 things. It has a better driver OR it doesn't show any disconnects if it's quickly reconnected.
The pfsense machine is a whole different story. I would repeatedly see disconnects in the console output. -
@DurUser cyberpower ups USB cable -> Windows server -> PowerPanel business software -> enable SNMP.
pfSense -> remote-snmp driver -> IP of windows server.
pfSense is not the master in my setup. It is an SNMP client.
-
@dennypage Thanks, I'll give that a shot here shortly!
I did a completely clean install and wiped my config from /conf for <nut> and rm /temp/config.cache etc etc. And removed the /usr/local/etc/nut folder to give you a clean configuration. That is why you are noticing discrepancies. I had tried poll interval as it was mentioned somewhere else this helped but I assumed this was going to be driver related from the start.
-
@incith said in NUT package:
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.
-
@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?
-
@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.
-
@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.
-
@incith Yeah, what we're talking about (THE issue) is on pfsense connected to a UPS directly. Your setup is different.
-
@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
-
Ah. Yeah, all good now, driver works. Thanks!
-
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.
-
@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
sha256sum of uncompressed file:
cdeb8d4400e0c721c878c0af084f48356323c29b7f9ef4fc526b4d9a3ff339a5 usbhid-upsHi 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).
-
@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.
-
@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.
Love the no fuss of using the official appliances :-)
-
@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.
-
@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.
-
@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 -
@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.
