-
(connection refused?)
(Unavailable) -
Changing it off of port = auto and setting it to what the sockets was showing seemed to resolve this. I always wanted to see the GUI monitor like the website has, has anyone set that up where you can just go to for example https://192.168.1.1:3493 and access a login prompt and monitor the ups?
-
@jonathanlee did you check the contents of ups.conf after reboot? if the contents are being lost, you might be able to use the Filer plugin to work around it
-
@jonathanlee In the Advanced settings -> Additional configuration lines for ups.conf, you have entries that are not allowed there. That section is for global directives only. What you have there are UPS Fields (driver configuration).
All entries in that section should be removed. If you wish, the "desc" line can be moved into the Extra Arguments to driver section, but all the others should be removed. Those entries are in conflict with the driver configuration.
-
@dennypage the stuff he has in the "additional configuration lines for ups.conf" should be in the "extra arguements to driver" section no?
-
@gwaitsi said in NUT package:
@dennypage the stuff he has in the "additional configuration lines for ups.conf" should be in the "extra arguements to driver" section no?
No. See the post immediately above. The lines should be not be present in either section.
-
Hi @dennypage - I ran into the same issue as @JonathanLee after upgrading to 23.01. I have a CyperPower UPS hooked up via USB using the usbhid NUT driver that worked fine up to now (i.e. in 22.05). After the upgrade, the NUT driver can't seem to keep a connection to the UPS. If I reload the NUT service / restart NUT, it will work anywhere from 5-20 minutes before disconnecting again. I have tried reinstalling the package and also manually setting the port line in "Extra Arguments to driver" section to the actual USB port/device the UPS is attached to, but no dice. The only left to try is a different USB port on the system to see if that fixes it. Is there anything else can you think of that is worth checking into to try to resolve this? Thanks in advance.
-
Hello,
I am experiencing the same issue with my Tripp Lite rack mount UPS; NUT not able to connect after upgrading pfSense to 23.01. Re-installing NUT package did not help. -
Dang I said 'seemed' to resolve this issue to soon.:( it is now doing the disconnect again so because of this I have now normalized my config and removed the old settings now as it is doing the same thing, and everyone is recommending removing it.
-
-
Does Squid need NUT's port to be listed on the acl page if you are also running the proxy on the loopback?
-
@jonathanlee said in NUT package:
Dang I said 'seemed' to resolve this issue to soon.:( it is now doing the disconnect again so because of this I have now normalized my config and removed the old settings now as it is doing the same thing, and everyone is recommending removing it.
There are multiple uses of the term "port" in nut, the port setting for the driver and the port setting for upsd. The port setting you had was for upsd (default 3493), but it was in the driver section. It was being ignored.
The other lines you had created a duplicate entry for what the package configurator was already doing, so if you looked in ups.conf you would have seen [CyberPower] twice.
-
@tman222 said in NUT package:
I have a CyperPower UPS hooked up via USB using the usbhid NUT driver that worked fine up to now (i.e. in 22.05). After the upgrade, the NUT driver can't seem to keep a connection to the UPS. If I reload the NUT service / restart NUT, it will work anywhere from 5-20 minutes before disconnecting again.
What shows in the system log? Anything containing the strings "ups" or "usb" please.
-
@dennypage yes that was only done to test, I did check the actual path to the config files and they are listed with duplicates. Thanks the system logs just fill up because of this similar to the post before with the screenshot of the logs.
-
@jonathanlee Please post the log entries surrounding the disconnect. I don't care about the upsmon entries, just the usbusps-hid and kernel usb entries.
So what specifically I would like you to do, is to re-save the config (so nut starts), wait for the disconnect, and then post everything from the system log from just before you did the re-save to just after the disconnect. Redact anything that is a privacy issue before you post.
-
@dennypage I currently have the package removed as the logs generated are overwhelming everything else for the firewall. I did a search this is what I found so far.
(Image: HID showing connection refused)
(Image: Error on disconnect)I can reinstall nut package and check the logs again for you, thanks for looking into this. It was working perfectly prior to the update to 23.01
-
@jonathanlee Not looking for upsd or upsmon messages. I'm looking for the messages from the driver (usbhid-hid) and from the kernel (usb).
Yes, please re-install the package. A log message or two every min isn't going to hurt. I need information in order to try and help.
Please do the following, in order:
- open a console window (ssh into pfSense)
- note the time (begin time)
- unplug the usb connection to the ups
- wait 10 seconds
- replug the usb connection to the ups
- run "usbconfig -v" in the console window
- go into the ui and resave the nut configuration (this will restart the nut service)
- confirm that the service is started and that you see device information on the status page
- wait for the disconnect to happen
- run "usbconfig -v" in the console window
- note the time (end time)
Please post the entire system log from begin time to end time, and the output of both usbconfig commands. Redact anything you need to for privacy reasons.
-
Can you also run through the instructions immediately above please? Thanks
[Edit: You can skip the above instructions. Please check your system logs for a usbhid-ups error similar to that reported by @shaffergr shown in post 972.]
-
-
-
In another thread, @shaffergr posted important log info:
kernel: pid 38678 (usbhid-ups), jid 0, uid 66: exited on signal 10
This is a bus error, generally indicative of a pointer problem. Unfortunately this indicates a serious problem in NUT itself. Tracking this with the nut maintainers is going to be a bit of work. Are any of you affected by this experienced C developers?