NUT Package (2.8.1 and above)

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.

hspindel

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

ghound

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

dennypage

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

and

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.

dennypage

@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

?