-
@Maltz said in NUT package:
I'm assuming this is an Intel build, since it (unsurprisingly) didn't work at all on my Netgate 2100.
Yes, it's an intel build. I don't have an ARM system. I have some free time coming up, and will look at building a cross compile environment.
-
@dennypage said in NUT package:
@Maltz said in NUT package:
I'm assuming this is an Intel build, since it (unsurprisingly) didn't work at all on my Netgate 2100.
Yes, it's an intel build. I don't have an ARM system. I have some free time coming up, and will look at building a cross compile environment.
I've got an RPi 4 running Ubuntu, if that'll work. I tried a few times to build it, but my Netgate didn't care for the results, so far. I'm probably configuring the build wrong somehow. If you have a ./configure command, I'd be happy to build 2.8.0 myself and post the result here.
-
@Maltz said in NUT package:
I've got an RPi 4 running Ubuntu, if that'll work. I tried a few times to build it, but my Netgate didn't care for the results, so far. I'm probably configuring the build wrong somehow. If you have a ./configure command, I'd be happy to build 2.8.0 myself and post the result here.
A Pi running Ubuntu will not work. pfSense is based on FreeBSD rather than Linux. You need to be running FreeBSD to build from the FreeBSD Ports collection.
The cross compile situation I was referring to was building FreeBSD ARM from a FreeBSD Intel system.
-
@dennypage said in NUT package:
A Pi running Ubuntu will not work. pfSense is based on FreeBSD rather than Linux. You need to be running FreeBSD to build from the FreeBSD Ports collection.
The cross compile situation I was referring to was building FreeBSD ARM from a FreeBSD Intel system.
I figured Linux vs FreeBSD was the other likely reason it didn't work. I'm quite unfamiliar with FreeBSD and it's package/ports system, but that post gave me enough info to google my way through compiling 2.8.0 on FreeBSD on my spare Pi4. (Interestingly, the RPi version of FreeBSD doesn't have nut in its package repository, I DID have to compile it from ports.) The replacement USB driver is running fine so far on my Netgate 2100. I'll post the binary here later today.
Thanks so much for sussing out the various issues in this thread - it's certainly helped me tremendously, and I'm sure many others as well!
-
@Maltz said in NUT package:
The replacement USB driver is running fine so far on my Netgate 2100. I'll post the binary here later today.
Thank you for this.
-
This post is deleted! -
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-ups -
Since upgrading to 2.7 nut keeps telling me "UPS is unavailable" and connection lost/unable to communicate. It's a cyberpower 1500pfclcd. It worked absolutely perfectly on 2.6. Not sure what might have changed? Using snmp to connect to the power panel software on a windows machine that hosts the UPS.
I've tried everything I can think of, removing, reinstalling, redoing config etc. It still pulls the stats so I know it's not actually a connection issue, the snmp portion and driver appear to be working properly.
I tried changing pollinterval to 12 and 15 and it still happened.
Edit: I am also noticing the "summary status" is blank. I think it used to say "online" and might explain what's going on
-
I can confirm through ssh that ups.status is blank which is why the nut package thinks it can't communicate.
On another server of mine (a Linux machine) ups.status shows the proper "OL" code.
So it seems something is broken with nut itself in this current release.
-
@incith said in NUT package:
Since upgrading to 2.7 nut keeps telling me "UPS is unavailable" and connection lost/unable to communicate. It's a cyberpower 1500pfclcd. It worked absolutely perfectly on 2.6. Not sure what might have changed? Using snmp to connect to the power panel software on a windows machine that hosts the UPS.
I've tried everything I can think of, removing, reinstalling, redoing config etc. It still pulls the stats so I know it's not actually a connection issue, the snmp portion and driver appear to be working properly.
Not much to go on here... Start with posting your config and status pages?
Services / UPS / Settings
Services / UPS / Status -
@dennypage my follow-up reply gave the cause.
uspc confirms that ups.status is blank after updating, and so pfSense does not know whether it's online or not. All other snmp data displays fine.
ups.firmware CR01802CBH11 ups.load 19 ups.mfr CYBERPOWER ups.model CP1500PFCLCDa ups.statusFrom Linux server:
ups.firmware: CR01802CBH11 ups.mfr: CYBERPOWER ups.model: CP1500PFCLCDa ups.status: OLSeem to be using a different driver, too -
pfSense:
driver.version.data cyberpower MIB 0.51Linux:
driver.version.data: cyberpower MIB 0.1 -
@incith Please post your (complete) config and status pages. I will look at them tomorrow. If you want, you can post the complete output of upsc on your pfSense system as well.
-
[2.7.0-RELEASE][admin@pfs1]/usr/local/etc/nut: cat ups.conf [CP1500PFC] driver=snmp-ups port=10.1.1.12 [2.7.0-RELEASE][admin@pfs1]/usr/local/etc/nut: cat upsd.users [admin] password=223556d47c38fb277211 actions=set instcmds=all [local-monitor] password=d15b36a67a98819c2117 upsmon master [2.7.0-RELEASE][admin@pfs1]/usr/local/etc/nut: cat upsmon.conf MONITOR CP1500PFC 1 local-monitor d15b36a67a98819c2117 master SHUTDOWNCMD "/sbin/shutdown -p +0" POWERDOWNFLAG /etc/killpower[2.7.0-RELEASE][admin@pfs1]/root: upsc CP1500PFC battery.charge: 100 battery.current: 1.50 battery.runtime: 3000 battery.runtime.elapsed: 0 battery.voltage: 27.60 battery.voltage.nominal: 24 device.contact: device.description: UPS Local device.location: device.mfr: CYBERPOWER device.model: CP1500PFCLCDa device.serial: CXXMZ7010229 device.type: ups driver.name: snmp-ups driver.parameter.pollinterval: 2 driver.parameter.port: 10.1.1.12 driver.parameter.synchronous: auto driver.version: 2.8.0 driver.version.data: cyberpower MIB 0.51 driver.version.internal: 1.21 input.frequency: 60 input.voltage: 122 output.current: 1.50 output.frequency: 60 output.voltage: 122 ups.delay.reboot: 0 ups.delay.shutdown: 120 ups.firmware: CR01802CBH11 ups.load: 16 ups.mfr: CYBERPOWER ups.model: CP1500PFCLCDa ups.serial: CXXMZ7010229 ups.status: -
@incith
I have the same thing happen lately. (23.05.1)
It works fine for a while but then says unavailable. I restart service and all works again. Sometimes for weeks, sometimes it quits the next day.
Also use a cyberpower 1500
Hardware is a Dell R210-II -
@DurUser My UPS.status is always blank. So it does not work even for a little bit for me. It thinks the ups is offline 100%.
-
@DurUser I think FreeBSD/pfSense/NUT has a somewhat general issue with USB based UPS’s.
IT’s well known Cyberpower UPS’es suffer very badly from this, but also several other units - fairly vendor agnostic - shows the same disconnect issues. I have two Eaton S5 UPS’s that suffer the same problem (and I have thoroughly tested its not the USB cable).
Common for all of them is that if you connect the same UPS to a Linux or Windows host they suffer no disconnect issues - so it’s likely something to do with either the USB UPS driver or the whole USB subsystem in pfSense.Up until 23.01 it was not a catastrophe because NUT would just reconnect to the UPS. But after 23.01 it no longer does that and a disconnect now means loss of UPS status/communication. I think work is being done on getting a never USB driver for NUT that attempts to reconnect again, but it will take a while - it will likely not cure the temporary disconnect issue though. That seems to be a deeper rooted issue.
-
@keyser agree with you observation. I have same problem with TrippLite disconnecting using usb driver. @dennypage (intel) and @Maltz (arm) have posted drivers to temporarily help with disconnects. @incith is using snmp driver and seems to never connect, which sounds like a different problem altogether.
-
@ghound yeah I literally had 0 problems at all on 2.6 pfSense using snmp. It always reported 100% correctly.
-
@keyser Sure, but it was working great before. Never had an issue until recent updates to pfsense. So something got screwed up that wasn't screwed up before. And yes, I did see those disconnects/reconnects happen before the update. That worked for me. Now it no longer reconnects I guess.
-
@incith Did you not have disconnects/reconnects ? Or never noticed it ?
