NUT Package (2.8.1 and above)

dennypage

@apremselaar said in NUT Package (2.8.1 and above):

Also, just to clarify, it was all working for me without issues with the packaged version 2.8.2, it only broke once I installed 2.8.2_1

This is puzzling.

The dependency that was used in pfSense-pkg-nut-2.8.2, was nut-devel-2023.10.07. For reference, the dependency used in pfSense-pkg-nut-2.8.2_1 is nut-devel-2024.01.03.

I would have expected the file I posted above, "tripplite_usb-2.8.1.zip", to work as that version is from the actual 2.8.1 release and should be almost identical to the version in nut-devel-2023.10.07.

I pulled the tripplite_usb executable from nut-devel-2023.10.07 and have attached it here. Can you please reconfirm that it works with the same test? Thanks!

tripplite_usb-from-nut-devel-2023.10.07_1.zip

apremselaar

@dennypage Sorry, I'm not seeing the attachment.

Is it possible that when I did the package update it (I assume) also updated the nut-devel package and perhaps the executable is linking to something in the dependency dynamically? or is the tripplite_usb part of the nut-devel package?

Thanks!

apremselaar

@dennypage sorry, it appears that for some reason the link to the attachment was delayed in its display. I've got it now and have downloaded it. will try it in a moment

dennypage

@apremselaar said in NUT Package (2.8.1 and above):

Sorry, I'm not seeing the attachment.

Well, isn't that embarrassing! My bad. I just edited the post to add the attachment.

Is it possible that when I did the package update it (I assume) also updated the nut-devel package and perhaps the executable is linking to something in the dependency dynamically? or is the tripplite_usb part of the nut-devel package?

NUT itself, including all executables, comes from the dependency which is currently nut-devel-2024.01.03. The pfSense package, pfSense-pkg-nut, only has the bits required to integrate with pfSense (mostly php). The pfSense package states a dependency on the specific version of the nut package that it wants.

apremselaar

@dennypage Yeah, this seems to work. I let it sit for about 30 seconds before hitting ^C to exit. here's the output:

[23.09.1-RELEASE][root@pfs.internal]/home/alan/2023.10.07: ./tripplite_usb -D -a RackTripp
Network UPS Tools - Tripp Lite OMNIVS / SMARTPRO driver 0.34 (2.8.0.1)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.000000	[D1] testval_reloadable: setting 'user' exists and differs: new value 'root' vs. 'nut'
   0.000018	[D1] Overriding previously specified user 'nut' with 'root' specified in global section
   0.000048	[D1] Network UPS Tools version 2.8.0.1 (release/snapshot of 2.8.0.1) built with FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152); Target: x86_64-unknown-freebsd14.0; Thread model: posix and configured with flags: --sysconfdir=/usr/local/etc/nut --program-transform-name= --localstatedir=/var/db/nut --datadir=/usr/local/etc/nut --with-devd-dir=/usr/local/etc/devd --with-drvpath=/usr/local/libexec/nut --with-statepath=/var/db/nut --with-altpidpath=/var/db/nut --with-pidpath=/var/db/nut --with-pkgconfig-dir=/usr/local/libdata/pkgconfig --with-user=nut --with-group=nut --with-python=/usr/local/bin/python3.11 --without-python2 --with-python3=/usr/local/bin/python3.11 --with-ltdl --with-nut-scanner --with-avahi --with-cgi --with-cgipath=/usr/local/www/cgi-bin/nut --with-htmlpath=/usr/local/www/nut --with-gd-includes=-I/usr/local/include --with-gd-libs='-L/usr/local/lib -lgd' --without-dev --with-freeipmi --without-ipmi --with-doc=no --with-modbus --with-neon --without-nss --with-openssl --with-powerman --with-serial --with-snmp --with-usb=auto --prefix=/usr/local --mandir=/usr/local/man --disable-silent-rules --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd14.0
   0.000064	[D1] debug level is '1'
   0.000501	[D1] Succeeded to become_user(root): now UID=0 GID=0
   0.000841	[D1] nut_libusb_open: invalid libusb bus number 0
   0.000860	[D1] nut_libusb_open: invalid libusb bus number 0
   0.000927	[D1] nut_libusb_open: invalid libusb bus number 0
   0.006914	Detected a UPS: Tripp Lite /TRIPP LITE SMART500RT1U
   0.058424	Using binary SMART protocol (3005)
   0.418455	Unit ID: 65535
Attached to Tripp Lite TRIPP LITE SMART500RT1U
   0.946800	[D1] Group and/or user account for this driver was customized ('root:nut') compared to built-in defaults. Fixing socket '/var/db/nut/tripplite_usb-RackTripp' ownership/access.
   0.946853	[D1] Group access for this driver successfully fixed
   0.946875	Running as foreground process, not saving a PID file
   0.946893	[D1] Driver initialization completed, beginning regular infinite loop
   0.946898	upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
^C  41.192535	[D1] set_exit_flag: raising exit flag due to signal 2
  41.192563	Signal 2: exiting
[23.09.1-RELEASE][root@pfs.internal]/home/alan/2023.10.07:

dennypage

@apremselaar I believe I found the tripplite issue.

Please try adding

upsid=65535

In the "Extra Arguments to driver" section.

You should not need the "user=root".

apremselaar

@dennypage yep! that did it.

Thank you!

dennypage

@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.

apremselaar

@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.

dennypage

@incith I haven't heard from you, but a fix for your issue with tripplite_usb is posted above.

4pack

@dennypage Was the original issue fixed in package version 2.8.2_1 or do I still need to replace UPSMON and USBHID-UPS?

dennypage

@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.

4pack

@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.

dennypage

@4pack Yes, that is addressed in nut-devel-2024.01.03.

hspindel

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.

dennypage

@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.

hspindel

@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.

dennypage

@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?

hspindel

@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.

dennypage

@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 3493

on 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.