NUT package (2.8.0 and below)

kjstech

Ok the model number is SMART1300LCDT. I was at work when I posted and I forgot the exact model number. I was told I can use usbhid-ups from here: http://networkupstools.org/ddl/Tripp_Lite/SMART1300LCDT.html

Here is the output of usbconfig dump_device_desc
ugen1.1: <intel ehci="" root="" hub="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x0000
idProduct = 0x0000
bcdDevice = 0x0100
iManufacturer = 0x0001 <intel>iProduct = 0x0002 <ehci root="" hub="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.1: <intel ehci="" root="" hub="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x0000
idProduct = 0x0000
bcdDevice = 0x0100
iManufacturer = 0x0001 <intel>iProduct = 0x0002 <ehci root="" hub="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x8087
idProduct = 0x0024
bcdDevice = 0x0000
iManufacturer = 0x0000 <no string="">iProduct = 0x0000 <no string="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <hub>bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0001
bMaxPacketSize0 = 0x0040
idVendor = 0x8087
idProduct = 0x0024
bcdDevice = 0x0000
iManufacturer = 0x0000 <no string="">iProduct = 0x0000 <no string="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

ugen0.3: <tripp lite="" tripp="" ups="">at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x09ae
idProduct = 0x3016
bcdDevice = 0x0002
iManufacturer = 0x0003 <retrieving string="" failed="">iProduct = 0x0001 <retrieving string="" failed="">iSerialNumber = 0x0005 <retrieving string="" failed="">bNumConfigurations = 0x0001

cat /usr/local/etc/nut/ups.conf
[main]
driver=usbhid-ups
port=auto

It worked for about a minute last night when I initially tried it, but then it stopped working and hasn't worked since. Now on the SSH console I randomly see these UPS main is unavailable messages.</retrieving></retrieving></retrieving></probed></tripp></no></no></no></hub></vendor></no></no></no></hub></vendor></no></ehci></intel></hub></intel></no></ehci></intel></hub></intel>

kjstech

I also wanted to add, I tried specifying more detail in the ups.conf like the port and description, and also change the poll interval.

[main]
driver=usbhid-ups
port=/dev/ugen0.3
desc="Tripp Lite TRIPP LITE UPS"
pollinterval=20

Still nothing.

It almost seems to be maybe a permissions problem? But even if I try to run it as root it shows this:
[2.4.3-RELEASE][root@pfSense.local]/usr/local/etc/nut: upsd -DDDD
Network UPS Tools upsd 2.7.4
0.000000 fopen /var/db/nut/upsd.pid: No such file or directory
0.000235 listen_add: added 127.0.0.1:3493
0.000376 listen_add: added ::1:3493
0.000393 setuptcp: try to bind to ::1 port 3493
0.000427 listening on ::1 port 3493
0.000439 setuptcp: try to bind to 127.0.0.1 port 3493
0.000457 listening on 127.0.0.1 port 3493
0.000580 Can't open /usr/local/etc/nut/ups.conf: Can't open /usr/local/etc/nut/ups.conf: Permission denied

[2.4.3-RELEASE][root@pfSense.local]/usr/local/etc/nut: ls -lah
total 164
drwxr-xr-x 2 root wheel 512B Apr 4 14:49 .
drwxr-xr-x 23 root wheel 2.0K Apr 4 14:56 ..
-rw-r–r-- 1 root wheel 14K Mar 16 13:16 cmdvartab
-rw-r--r-- 1 root wheel 76K Mar 16 13:16 driver.list
-rw-r--r-- 1 root wheel 15B Apr 4 12:28 nut.conf
-rw-r--r-- 1 root wheel 1.5K Mar 16 13:16 nut.conf.sample
-rw-r----- 1 root wheel 92B Apr 4 21:44 ups.conf
-rw-r--r-- 1 root wheel 4.5K Mar 16 13:16 ups.conf.sample
-rw-r----- 1 root wheel 28B Apr 4 21:42 upsd.conf
-rw-r--r-- 1 root wheel 4.5K Mar 16 13:16 upsd.conf.sample
-rw-r----- 1 root wheel 117B Apr 4 21:42 upsd.users
-rw-r--r-- 1 root wheel 2.1K Mar 16 13:16 upsd.users.sample
-rw-r----- 1 root wheel 115B Apr 4 21:42 upsmon.conf
-rw-r--r-- 1 root wheel 15K Mar 16 13:16 upsmon.conf.sample
-rw-r--r-- 1 root wheel 3.8K Mar 16 13:16 upssched.conf.sample

just for the hell of it, I did chmod 777 ups.conf since it seemed to be complaining about permissions reading that file.

Then it complained about upsd.users, so again for testing I did chmod 777 upsd.users

-rwxrwxrwx 1 root wheel 92B Apr 4 21:44 ups.conf
-rwxrwxrwx 1 root wheel 117B Apr 4 21:42 upsd.users

It kept looping no data available so I killed it.
upsd -DDDD
Network UPS Tools upsd 2.7.4
0.000000 fopen /var/db/nut/upsd.pid: No such file or directory
0.000255 listen_add: added 127.0.0.1:3493
0.000403 listen_add: added ::1:3493
0.000424 setuptcp: try to bind to ::1 port 3493
0.000483 listening on ::1 port 3493
0.000505 setuptcp: try to bind to 127.0.0.1 port 3493
0.000533 listening on 127.0.0.1 port 3493
0.000751 Can't connect to UPS [main] (usbhid-ups-main): No such file or directory
0.001695 /usr/local/etc/nut/upsd.users is world readable
0.001731 user_add_action: adding 'set' for admin
0.001747 user_add_instcmd: adding 'all' for admin
0.001764 user_add_action: adding 'login' for monuser
0.001776 user_add_action: adding 'master' for monuser
0.001789 user_add_action: adding 'fsd' for monuser
0.001824 mainloop: polling 2 filedescriptors
2.015622 mainloop: no data available
2.015697 mainloop: polling 2 filedescriptors
4.027074 mainloop: no data available
4.027150 mainloop: polling 2 filedescriptors
6.056806 mainloop: no data available
6.056881 mainloop: polling 2 filedescriptors
8.059687 mainloop: no data available
8.059757 mainloop: polling 2 filedescriptors
10.068805 mainloop: no data available
10.068882 mainloop: polling 2 filedescriptors
12.084621 mainloop: no data available
12.084699 mainloop: polling 2 filedescriptors
14.085689 mainloop: no data available
14.085777 mainloop: polling 2 filedescriptors
16.106784 mainloop: no data available
16.106835 mainloop: polling 2 filedescriptors
^C 17.722668 mainloop: Interrupted system call
17.722703 Signal 2: exiting

Does this help at all?

dennypage

@kjstech:

ugen0.3: <tripp lite="" tripp="" ups="">at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x09ae
idProduct = 0x3016
bcdDevice = 0x0002
iManufacturer = 0x0003 <retrieving string="" failed="">iProduct = 0x0001 <retrieving string="" failed="">iSerialNumber = 0x0005 <retrieving string="" failed="">bNumConfigurations = 0x0001</retrieving></retrieving></retrieving></probed></tripp>

The "retrieving string failed" is something I haven't seen before and would seem problematic. First thing I would suggest is trying a USB port on the other bridge chip. I would also test a different cable.

kjstech

Ok I did try another USB port and its the same results.

I'm at work now, I can try a new USB A to B cable. There's 6 ports on the back, 2 on the front. Its a Dell Optiplex 390. It doesn't appear to have USB 3.0 - at least none of the ports are blue. I could also throw in a USB 3.0 PCIe card if none of the onboard ports work. TrippLite's website does not appear to have any firmware for this model. If it did I would plug into my Windows laptop temporally and update it.

dennypage

@kjstech:

It almost seems to be maybe a permissions problem? But even if I try to run it as root it shows this:
[2.4.3-RELEASE][root@pfSense.local]/usr/local/etc/nut: upsd -DDDD

NUT is a multi-process architecture. See /usr/local/etc/rc.d/nut.sh.

dennypage

@kjstech:

There's 6 ports on the back, 2 on the front. Its a Dell Optiplex 390. It doesn't appear to have USB 3.0 - at least none of the ports are blue. I could also throw in a USB 3.0 PCIe card if none of the onboard ports work.

It looks like all the ports are USB 2.0. The UPS itself is a low speed USB device, so you are using the internal compatibility bridge anyway.

Btw, if you have any other USB devices connected, you might want to disconnect them while you diagnose your UPS issue.

kjstech

Fortunately, I have no other USB devices connected, as its running headless. Just a mini-tower with two ethernet cables, power, and now as of this week, a USB cable to a UPS.

kjstech

I tried another port and cable. It still seems to think it’s in the same port 0.3.
Still see the retrieving string failed. Still not able to monitor UPS in pfSense GUI.

I’m not sure what the issue is.

ugen0.3: <tripp lite="" tripp="" ups="">at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0110
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0008
idVendor = 0x09ae
idProduct = 0x3016
bcdDevice = 0x0002
iManufacturer = 0x0003 <tripp lite="">iProduct = 0x0001 <tripp lite="" ups="">iSerialNumber = 0x0005 <retrieving string="" failed="">bNumConfigurations = 0x0001</retrieving></tripp></tripp></probed></tripp>

dennypage

@kjstech:

I tried another port and cable. It still seems to think it’s in the same port 0.3.
Still see the retrieving string failed. Still not able to monitor UPS in pfSense GUI.

Until you have the USB issue figured, I would disable the NUT service in pfSense.

On the USB bus, the second bus may the front connectors. It's worth a shot. Normally, I recommend against USB hubs, but it's also worth a try to put a (high quality) hub between the host and the UPS to see if that helps.

Btw, did you ever try the tripplite driver?

kjstech

Yes I tried the tripplite driver and I get the same result.

I tried the back USB ports. I did't try the front because I was trying to keep it a clean install without cables coming out of the front. I could try that though.

I have some usb hubs I could try, it would be strange solution but I'm willing to try it.

The only thing I haven't tried is connecting a monitor and keyboard up to it and booting into the BIOS to see if there's anything specific to USB in there.

I have an APC BackUPS 550 I could also try. I wanted the TrippLite on this unit though because it's a higher capacity, but for experimentation purposes I can switch it.

Jacopx

After a reboot of one of my miniPC over the home this problem has raised up again, during SSH session:

Broadcast message from nut@minix.orbax (Wed Apr 25 09:33:59 2018):

UPS SaveLife@172.16.0.1:3439 is unavailable

I don't remember how i have solved this problem in past! Someone can help me? The UPS is link to the pfSense box via USB and the miniPC is in the same LAN of the pfSense. The sfotware work perfectly, is something related to the pool time i think! :/

bulldog5

dennypage-

I had NUT working on a pfsense 2.4.1RELEASE package. Just did a full reinstall on 2 new drives for ZFS to the latest 2.4.3. Restored my config and see my UPS not connecting. I figure no biggie i need to update my port = /dev/ugen0.6 to what usbconfig dump_device_desc is now showing as ugen0.4. Still no go. Did some reading and find that
chmod 777 /dev/ugen0.4 ended up getting it working again. Wondering what changed to cause what seems to be a permissions issue for that USB ugen path?

ugen0.4: <cps or1500pfcrt2u="">at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (2mA)

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0000 <probed by="" interface="" class="">bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x0764
idProduct = 0x0601
bcdDevice = 0x0200
iManufacturer = 0x0003 <cps>iProduct = 0x0001 <or1500pfcrt2u>iSerialNumber = 0x0002 <retrieving string="" failed="">bNumConfigurations = 0x0001</retrieving></or1500pfcrt2u></cps></probed></cps>

dennypage

@bulldog5:

Just did a full reinstall on 2 new drives for ZFS to the latest 2.4.3. Restored my config and see my UPS not connecting.
…
Did some reading and find that chmod 777 /dev/ugen0.4 ended up getting it working again. Wondering what changed to cause what seems to be a permissions issue for that USB ugen path?

It’s generally an issue when you first install the base nut package on FreeBSD. The nut package puts a config script in place to set ownership of the usb device to the user nut runs as. Unfortunately, the script does not execute until you reboot or unplug and replug the usb device.

Cortexian

Complete noob to NUT. I have a supported UPS, have the package installed and configured with a base configuration. pfSense is returning information about my UPS.

My hardware configuration is as follows:

1x UPS
1x pfSense Machine configured with a Port Forward rule to allow NUT access.
1x File Server running Windows Server 2012 R2 with WinNUT installed.

Both the pfSense machine and File Server are connected to the UPS.

I would like pfSense / NUT to send a shutdown command to my File Server if NUT detects that the UPS has dropped to 80% battery capacity. I would then like pfSense to remain online for as long as possible before shutting itself down.

Could someone help me accomplish this? I've read through some of the documentation and attempted a configuration, but I'm running into a few issues. ~~Specifically, I have a [user] entry with password and set to slave in upsd.users on pfSense, but WinNUT logs are returning a "Can't login to UPS [UPS-Name@192.168.1.1:3493]: Access denied" message.~~

Edit: Solved my first issue of the "Access denied" thing. I guess installing the NUT package creates some hidden information inside of upsd.users that wasn't shown in the Advanced Settings of the pfSense NUT GUI. My NUT user I added was named [monuser] which is a default created when installing the package. Changed it to something else and now WinNUT can connect just fine.

Any tips on creating a configuration to do what I mentioned above though? Shut down File Server at 80% of battery life, then preserve pfSense as long as possible (10% battery remaining or so)?

dennypage

@cortexian said in NUT package:

Any tips on creating a configuration to do what I mentioned above though? Shut down File Server at 80% of battery life, then preserve pfSense as long as possible (10% battery remaining or so)?

To my knowledge, NUT has no provision for initiating shutdown of slaves separate from the master.

letarch

I use pfsense 2.2.6-RELEASE (amd64) (it's need for asterisk). NUT v.2.1.2 . And I connected UPS Ippon Back comfo pro 800 via usb cable. Driver is set "Geneneric USB UPS (Blazer)", port "Auto".
In "System logs" error: "Data scale!"
What's it? How-to fix it?

dennypage

This thread covers the current NUT package which does not support 2.2. 2.3 is the first version supported by the package.

I strongly recommend you upgrade pfSense. 2.2.6 is quite old at this point. Many vulnerabilities have been addressed since then.

letarch

@dennypage said in NUT package:

This thread covers the current NUT package which does not support 2.2. 2.3 is the first version supported by the package.

I strongly recommend you upgrade pfSense. 2.2.6 is quite old at this point. Many vulnerabilities have been addressed since then.

It's true. But last pfsense not have asterisk package.

stompro

Hello Denny Page, You mentioned that the current version of Nut tries to shut down the UPS. I'm discovering that the UPS that I'm using (Cyberpower OR500LCD) seems to have a faulty implementation, and blips the power (turns off load and then immediately turns it back on). This seems to have the side effect of corrupting something on my SG-2220 devices, which puts them in a boot loop with a kernel panic.

I'm running 2.4.3 P1 with the latest Nut package available.

A reinstall is required to get the system running again after this event.

After further reading, I'm finding that it doesn't seem to possible to do a safe instant shutdown of a UPS in FreeBSD, because the filesystem doesn't finish syncing until after the shutdown scripts finish. And if the nut shutdown script turns off the UPS, then disk corruption can occur.

So would it be accurate to say that it is only safe to use nut to shutdown pfsense firewalls when the UPS supports a shutdown delay, to allow enough time for the system to fully halt before the load power is pulled?

Josh

dennypage

@stompro said in NUT package:

You mentioned that the current version of Nut tries to shut down the UPS. I'm discovering that the UPS that I'm using (Cyberpower OR500LCD) seems to have a faulty implementation, and blips the power (turns off load and then immediately turns it back on).

I don't have a Cyberpower on hand to double check, but most all UPSs offer some form of shutdown delay. You can check this in the UPS by looking at the ups.delay.shutdown variable using the upsrw command.