NUT package (2.8.0 and below)

dennypage

That makes sense. For what it's worth, most people use a read-only SNMPv1 group for UPS monitoring. There isn't any sensitive information in the stream.

spambait

@dennypage:

That makes sense. For what it's worth, most people use a read-only SNMPv1 group for UPS monitoring. There isn't any sensitive information in the stream.

The docu said a write community is needed to facilitate shutdowns. I wanted the UPS and NUT to coordinate that NUT will shut down pfSense when there's not much runtime left and then tell the UPS to shut off the outlet in x minutes and come back up when AC power is restored and battery has at least y % charge.

Otherwise pfSense will just shut down and stay down until someone presses the power button or the BIOS power on time is reached.

dennypage

@spambait:

The docu said a write community is needed to facilitate shutdowns. I wanted the UPS and NUT to coordinate that NUT will shut down pfSense when there's not much runtime left and then tell the UPS to shut off the outlet in x minutes and come back up when AC power is restored and battery has at least y % charge.

Ah, yes. Needing write permission to kill power makes sense. Note that the pfSense NUT package version 2.7.4_5 does not support issuing the final power kill order. This will come with NUT package 2.7.4_6 which requires pfSense 2.4.3.

xx_robot_xx

Hello,

How do you configure power-kill after shutdown? I have pfsense 2.4.3 and latest version of nut..

dennypage

Power kill is enabled automatically with pfSense 2.4.3 and 2.7.4_6 of the NUT package. No configuration necessary.

kjstech

Hello,

I have a TrippLite Smart 1300VA unit connected via USB. dmesg does show it connected. This model is also one listed in NUT to use the USB driver (not the legacy TrippLite driver). I got readings from it very briefly last night when setting it up, but also a bunch of messages in the log about the data being stale. This was on pfSense 2.4.1.

Now it doesn't work at all. I upgraded to the latest NUT package. No dice. I upgraded pfSense to 2.4.3… no dice.

All I get is this in the status logs:
Apr 4 14:57:20 upsd 97125 User monuser@::1 logged into UPS [main]
Apr 4 14:57:20 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:20 upsmon 60509 Communications with UPS main lost
Apr 4 14:57:25 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:25 upsmon 60509 UPS main is unavailable
Apr 4 14:57:30 upsmon 60509 Poll UPS [main] failed - Driver not connected
Apr 4 14:57:35 upsmon 60509 Poll UPS [main] failed - Driver not connected

Like I said, system sees it, here's the USB stuff pulled from dmesg:
dmesg | grep usb
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <intel ehci="" root="" hub="">at usbus0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen0.3: <tripp lite="" tripp="" ups="">at usbus0
uhid0: <tripp 0="" 3="" lite="" tripp="" ups,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
ugen0.1: <intel ehci="" root="" hub="">at usbus0
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.3: <vendor 0x09ae="" product="" 0x3016="">at usbus0
uhid0: <vendor 0="" 3="" 0x09ae="" product="" 0x3016,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <intel ehci="" root="" hub="">at usbus1
ugen0.1: <intel ehci="" root="" hub="">at usbus0
uhub0: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus1
uhub1: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
ugen1.2: <vendor 0x8087="" product="" 0x0024="">at usbus1
uhub2: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus1
ugen0.2: <vendor 0x8087="" product="" 0x0024="">at usbus0
uhub3: <vendor 2="" 9="" 0x8087="" product="" 0x0024,="" class="" 0,="" rev="" 2.00="" 0.00,="" addr="">on usbus0
ugen0.3: <tripp lite="" tripp="" ups="">at usbus0
uhid0: <tripp 0="" 3="" lite="" tripp="" ups,="" class="" 0,="" rev="" 1.10="" 0.02,="" addr="">on usbus0

Anyone know how I can get this to work?
pfSense has been rebooted twice now. Once for the 2.4.3 upgrade. And another time after I removed NUT package and reinstalled NUT package. NUT is version 2.7.4_6.

Thanks!</tripp></tripp></vendor></vendor></vendor></vendor></intel></intel></intel></intel></vendor></vendor></vendor></vendor></vendor></vendor></intel></intel></intel></intel></tripp></tripp></vendor></vendor></vendor></vendor></intel></intel></intel></intel>

dennypage

@kjstech:

I have a TrippLite Smart 1300VA unit connected via USB. dmesg does show it connected. This model is also one listed in NUT to use the USB driver (not the legacy TrippLite driver).

Please run "usbconfig dump_device_desc" and post the output. Also, can you post the contents of /usr/local/etc/nut/ups.conf please? And lastly, the exact model number of the UPS.

Btw, where did you see the note about using the usbhid-ups vs. the tripplite_usb driver? I didn't find a Tripp Lite 1300VA model in the NUT HCL…

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.