-
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 -DDDDNUT is a multi-process architecture. See /usr/local/etc/rc.d/nut.sh.
-
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.
-
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.
-
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> -
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?
-
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.
-
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 unavailableI 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! :/
-
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> -
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.
-
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)?
-
@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.
-
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? -
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.
-
@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.
-
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
-
@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.
-
@dennypage Hello, the ups does report ups.delay.shutdown = 20 by default, but 'upsdrvctrl -k' doesn't seem to make use of it at all. The ups immediately powers off at "Initiating UPS shutdown" and then turns back on immediately.
I tried setting ondelay and offdelay in the driver config and that had no effect.
This UPS also doesn't seem to store variables set by upsrw.
I'm testing by setting the lowbatt setting to 90%, so I don't need to wait so long... I wonder if that is causing problems? Maybe this UPS is hard coded to the 10% lowbatt, so it is immediately turning back on since when it shuts down it sees that the battery is over 10% and turns back on? I'll test that next.
The key thing though is that it doesn't seem to actually support the shutdown delay. The Cyberpower control software doesn't let me set any settings related to a shutdown delay/startup delay, so I think this device just doesn't support it, even though the UPS_HID interface has a variable for it.
Josh
-
It may not be persistent in the UPS. You might also try explicitly setting offdelay and ondelay in the extra arguments section.
-
@dennypage Ohh, I just figured out that CyberPower UPS's take shutdown delays in 60 second increments, and round down. So I was telling it 45 seconds, which was rounded down to 0, so instant shutoff.
I wonder if that is what "ups.timer.shutdown=-60" is supposed to tell me?
So setting "offdelay=60" in the extra driver arguments does seem to work.
Now I just need to figure out the ondelay, since it seems to start back up after that delay no matter if the power is restored or not.... Now I see that there is a note in the usbhid-ups man page about some UPS's starting back up even when mains power isn't present. It says I should set "ondelay=-1" so I'll give that a try.
Next time I'll purchase a model that supports waiting for a certain battery level before restart.
I've been trying to find out where the 60 second interval thing is documented but I haven't found it yet.
Josh
-
@stompro "ondelay=-1" sets the UPS to never restart after the power returns, "ondelay=0" seems to say return once power has returned.
I thought there may be a power race condition, but with "ondelay=0" it seems to work. If the power returns right after the system starts shutting down, the UPS will still turn off after the offdelay period, and then it will power back on shortly afterwards(10 seconds) so everything comes back up correctly.
Josh
