NUT Package (2.8.1 and above)
-
@apremselaar I believe I found the tripplite issue.
Please try adding
upsid=65535In the "Extra Arguments to driver" section.
You should not need the "user=root".
-
@dennypage yep! that did it.
Thank you!
-
@apremselaar Excellent. It is a tripplite_usb specific bug, introduced 2023.10.11, right after our first devel snapshot. The fix went in on 2024.01.31, right after our most recent devel snapshot.
I expect the fix to be in the next NUT version, after which you may remove the upsid entry from your configuration. Having it in there will not hurt anything if you should forget.
FWIW, upsid is a new optional feature that allows you to select among multiple Tripplite UPSs attached to the same system. The bug was that the feature wasn't quite optional enough.
-
@dennypage I see. Well I'm glad that you were able to identify the problem and a fix for it.
Thanks again for all of your effort and quick responses.
-
@incith I haven't heard from you, but a fix for your issue with tripplite_usb is posted above.
-
@dennypage Was the original issue fixed in package version 2.8.2_1 or do I still need to replace UPSMON and USBHID-UPS?
-
@4pack said in NUT Package (2.8.1 and above):
Was the original issue fixed in package version 2.8.2_1 or do I still need to replace UPSMON and USBHID-UPS?
Apologies... I don't remember your specific issue. Which issue(s) you are referring to?
FWIW, I don't currently know of outstanding issues with pfSense-pkg-nut 2.8.2_1 / nut-devel-2024.01.03 other than the tripplite_usb and nutdrv_qx issues discussed over the last week. I'm not currently aware of anything affecting usbhid-ups or upsmon.
-
@dennypage Sorry, it was the issue with the APC BackUPS models causing a shutdown during the selftest.
https://github.com/networkupstools/nut/issues/2104
I know the fix has been applied to upstream NUT, I just wanted to make sure the fix is present in the package, because this was happening in the 2.8.2 version of the package on pfSense 2.7.2. I did just upgrade to 2.8.2_1.
-
@4pack Yes, that is addressed in nut-devel-2024.01.03.
-
I have four Synologies. Three out of four (ds412, two ds120j) connect to my NUT server (running on pfSense) just fine.
My ds1522 cannot connect to the NUT server.
telnet <NUT server> works fine and lets me login. So telnetd is responding correctly on the NUT server.
telnet <NUT server> 3493 says "Unable to connnect to the remote host: Connection refused." The same command on any other Synology connects to the NUT server no problem.
I can't find anything in the firewall on the NUT server that would block the DS1522. I have even tried putting a special firewall rule to allow the DS1522.
-
@hspindel said in NUT Package (2.8.1 and above):
telnet <NUT server> works fine and lets me login. So telnetd is responding correctly on the NUT server.
telnet <NUT server> 3493 says "Unable to connnect to the remote host: Connection refused."
These are two totally different things.
In the first case, you are attempting to connect to whatever process is listening on port 23, which would be telnetd. As an aside, having telnetd enabled on your firewall is very bad practice--you should use ssh instead.
In the second case, you are attempting to connect to whatever process is listening on port 3493, which would be upsd. Telnetd would not be involved in any way.
You are correct to be looking at your firewall rules, however you should also double check the configuration on the Synology: Make sure you are using the IP address rather than a hostname, and If you have the firewall enabled on the Synology, check that as well.
-
@dennypage said in NUT Package (2.8.1 and above):
@hspindel said in NUT Package (2.8.1 and above):
telnet <NUT server> works fine and lets me login. So telnetd is responding correctly on the NUT server.
telnet <NUT server> 3493 says "Unable to connnect to the remote host: Connection refused."
These are two totally different things.
In the first case, you are attempting to connect to whatever process is listening on port 23, which would be telnetd. As an aside, having telnetd enabled on your firewall is very bad practice--you should use ssh instead.
In the second case, you are attempting to connect to whatever process is listening on port 3493, which would be upsd. Telnetd would not be involved in any way.
You are correct to be looking at your firewall rules, however you should also double check the configuration on the Synology: Make sure you are using the IP address rather than a hostname, and If you have the firewall enabled on the Synology, check that as well.
Yes, I understand they are different things. Sorry for confusing things.
All four of my Synologies are using an IP address, not a hostname. telnet <NUT Server IP> 3493 works fine on three of the four Synologies.
I have tried using tcpdump to see how the Synology is talking to the NUT server. Unless I'm using tcpdump wrong, the Synology isn't even trying to connect. tcpdump port 3493 doesn't show a thing on the problem Synology, while it shows traffic on the other Synologies.
I have tried disabling the Synology firewall completely, without effect.
-
@hspindel said in NUT Package (2.8.1 and above):
I have tried using tcpdump to see how the Synology is talking to the NUT server. Unless I'm using tcpdump wrong, the Synology isn't even trying to connect. tcpdump port 3493 doesn't show a thing on the problem Synology, while it shows traffic on the other Synologies.
Just to be clear, tcpdump on the Synology shows no outbound packets? Do you have multiple ethernet interfaces on the Synology?
-
@dennypage said in NUT Package (2.8.1 and above):
@hspindel said in NUT Package (2.8.1 and above):
I have tried using tcpdump to see how the Synology is talking to the NUT server. Unless I'm using tcpdump wrong, the Synology isn't even trying to connect. tcpdump port 3493 doesn't show a thing on the problem Synology, while it shows traffic on the other Synologies.
Just to be clear, tcpdump on the Synology shows no outbound packets? Do you have multiple ethernet interfaces on the Synology?
tcpdump by itself on the questionable Synology shows plenty of packets. tcpdump port 3493 shows nothing.
-
@hspindel said in NUT Package (2.8.1 and above):
tcpdump port 3493 shows nothing.
Port 3493 was implied.
You see no outbound packets even when you do
telnet firewall 3493on the Synology?
You said that you received a connection refused error when doing the telnet. If there are no outbound packets on the interface, then the issue would have to be the Synology itself. Synology's firewall would be my guess. I've never used Synology's firewall, so I really can't help much there.
-
@dennypage Yes, I have further narrowed this down to be a problem on the Synology.
I have not yet been able to figure out why, but when the Synology attempts to contact pfsense (even by using numeric IP instead of DNS) it actually contacts itself (localhost). Since NUT doesn't exist on localhost, that's why I get a connection refused response.
Just FYI, arp cache looks correct and even flushing the arp cache on the Synology didn't help.
-
@dennypage said in NUT Package (2.8.1 and above):
FWIW, I don't currently know of outstanding issues with pfSense-pkg-nut 2.8.2_1 / nut-devel-2024.01.03 other than the tripplite_usb and nutdrv_qx issues discussed over the last week. I'm not currently aware of anything affecting usbhid-ups or upsmon.
I have a Tripp Lite ECO850LCD using the usbhid-ups driver. I am running 2.8.2_1 nut-devel-2024.01.03. I still have the problem that every few days the hid driver looses connection to the Tripp Lite and I have to physically disconnect the USB and restart Nut. Is this problem supposed to be fixed now?
-
@hspindel said in NUT Package (2.8.1 and above):
I have not yet been able to figure out why, but when the Synology attempts to contact pfsense (even by using numeric IP instead of DNS) it actually contacts itself (localhost).
The actual localhost (logical) interface? Or an ethernet (physical) interface? Btw, you didn't answer the question regarding multiple interfaces being present on the Synology.
What do you have in
Control Panel -> Network -> General -> Network Interfaceand
Control Panel -> Network -> General -> Advanced Settings?
If you want me to look at the tcpdump output from the Synology during the connection attempt, please send it via PM.
-
@ghound said in NUT Package (2.8.1 and above):
I still have the problem that every few days the hid driver looses connection to the Tripp Lite and I have to physically disconnect the USB and restart Nut.
I don't know about this issue. What do you see in the logs for kernel USB and usbhid-ups?
When the unit disappears, does it still show up when you do
usbconfig -v?
-
I recently reloaded the driver, so I may have to wait a few days for the problem to show up. In the mean time this post is the problem I thought I was having (even though I have a Tripp Lite not a CyberPower, others reported your devel packaged helped Tripp Lite UPS):
From your Feb 22, 2023 post...
For those of you affected by the CyberPower issue (and those that will be in the future):
First, I want to thank all of you for your help in tracking this down. Particularly @shaffergr, who was kind enough, and trusting enough, to run test builds for me against his CyberPower.
1 tracked this down to a double free by the ush code in nut. FWIW, I don't believe that this issue is completely limited to CyberPower UPSs, but it is probably pretty difficult to encounter with other units as hitting the issue requires a reconnect of the UPS on the bus. CyberPower units are well known to randomly disconnect and reconnect seemingly at random.
For those wondering why this issue did not happen in prior to 23.01: 22.05 and below used nut version 2.7.4. In 2.7.4, nut did not actually close the device when a disconnect happened. Presumably, this may have resulted in a memory leak at shutdown, but I didn't explore enough to confirm. In 2.8.0, when a device disconnects nut actually closes the device when it disconnects. In fact, it closes it twice on all systems other than Linux. There is even a comment in the code noting how the double close would cause corruption on Linux systems. Unfortunately contrary to the code comments it also causes corruption in FreeBSD.
Having traced this down in the 2.8.0 release code, when I went to the current development version I surprised to find that someone had beat me to it, and fixed the issue back in August. It's just not been release yet. :)
To resolve this will require a new version of nut. Either a new release from the nut team, or for the pfSense team to move from the 2.8.0 release version to the current development version of nut. The nut team is looking toward 2.8.1, but it appears that they have a few things they still want to address before putting that out. I will explore the concept of moving to nut-devel with the pfSense team as time permits (I think they are pretty busy right now). But no matter which way it goes, it's going to take some time.
In the interim, the only known work-around using the release code (discovered by @tman222) is to add the line "interruptonly"
to the Extra Arguments to driver section. This will cut down some of the information you can see about your UPS, but the important stuff needed to monitor and shutdown should still be there.
Alternatively, if brave souls are interested, I have a build of usbhid-ups made from the FreeBSD nut-devel package. I do not have a CyberPower available so I haven't been able to directly test it, but I expect that it will work.
If you you decide you would like a copy, reach out to me and I will see about getting it to you. For reference, the shasum and sha256sum checksums are:
49ce9131502bb86789ee97b7fb3fc81fc9f8fff usbhid-ups
999a2653559dbc50ecc8ba592a67587ble307a1495f6e8ebbd3d8e90e3967133 usbhid-ups
