OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: Andromeda on April 27, 2022, 06:16:17 pm
-
Hi all,
Hope that someone can help me out with the os-nut package.
It will not detect my UPS connected on a USB port.
Nut/Diagnostics just stays blank.
It looks like it has something to do with rights and user used, but I'm not sure where or how I could change/correct that.
Configuration:
OPNsense 22.1.6-amd64 with latest updates
os-nut v1.8.1
nut v2.7.4_20
Service Mode: standalone
Name: ups1
Listen Address: 127.0.0.1 & ::1
UPS Type: Enabled the BlazerUSB driver
Extra Arguments: port=auto
Troubleshooting:
NUT service shows as running in the GUI.
When logged in through ssh, you regularly see the message: UPS ups1 is unavailable
The content of the files in /usr/local/etc/nut seems to be correct, and line-up with what is shown in the OPNsense user interface.
When running the blazer usb driver from the command line, it will not detect the UPS.
But when running the blazer usb driver with user root, it will detect the ups.
$ sudo /usr/local/libexec/nut/blazer_usb -a ups1 -DDD
Password:
Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4)
0.000000 debug level is '3'
0.000661 No appropriate HID device found
0.000685 No supported devices found. Please check your device availability with 'lsusb'
and make sure you have an up-to-date version of NUT. If this does not help,
try running the driver with at least 'subdriver', 'vendorid' and 'productid'
options specified. Please refer to the man page for details about these options
(man 8 blazer_usb).
$
$ sudo /usr/local/libexec/nut/blazer_usb -a ups1 -DDD -u root
Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (2.7.4)
0.000000 debug level is '3'
0.000983 Checking device (06DA/0003) (/dev/usb//dev/ugen0.3)
0.017996 - VendorID: 06da
0.018020 - ProductID: 0003
0.018031 - Manufacturer: CTN
0.018040 - Product: USB UPS
0.018049 - Serial Number: unknown
0.018057 - Bus: /dev/usb
0.018066 - Device release number: 0501
0.018074 Trying to match device
0.018085 Device matches
0.018105 nut_usb_set_altinterface: skipped usb_set_altinterface(udev, 0)
0.018140 Trying megatec protocol...
0.019889 send: Q1
0.250438 read: (232.9 232.9 232.9 007 50.1 13.5 25.0 00001001
0.250576 Status read in 1 tries
0.250595 Supported UPS detected with megatec protocol
0.252378 send: F
0.394414 read: #220.0 003 12.00 50.0
$ sudo usbconfig
Password:
ugen0.1: <Intel EHCI root HUB> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.2: <vendor 0x8087 product 0x07e6> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.3: <CTN USB UPS> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
-
I never had to change anything internal for my UPS, it just worked.
Apologies if I missed something, but what model is your UPS?
-
Have you tried the USBHID driver with "port=auto" in the extra arguments field? I'm running a Tripp Lite UPS and this works for me.
-
Is your UPS on the list
https://networkupstools.org/stable-hcl.html
also
0.018140 Trying megatec protocol...
0.019889 send: Q1
0.250438 read: (232.9 232.9 232.9 007 50.1 13.5 25.0 00001001
0.250576 Status read in 1 tries
0.250595 Supported UPS detected with megatec protocol
Is this significant, its not on the drop down list of drivers in opnsense
Also
https://networkupstools.org/protocols/megatec.html
may be relavent
Finally
https://networkupstools.org/index.html
may help
and
searching
https://github.com/networkupstools/nut/search?q=megatec
may also through up some ideas.
-
The UPS is "Numeric Digital 800 plus"
It is on the list here: https://networkupstools.org/ddl/NUMERIC/Digital_800_Plus.html
I'm using the blazer_usb driver and that driver replaces the older/previous megatec driver, and it is using the megatec Q1 protocol.
As mentioned, the UPS is detected when I run the blazer_usb driver manually as the root user (with the -u root option).
I've also tried the newer QX driver (nutdrv_qx), with the same results.
-
Did you reboot? I have always had to install the NUT plugin, and then reboot. Then during boot it detects the USB UPS.
-
The UPS is "Numeric Digital 800 plus"
It is on the list here: https://networkupstools.org/ddl/NUMERIC/Digital_800_Plus.html
That page example shows:
ups.productid : 5161
ups.vendorid : 0665
What does your UPS actually use and tell you over USB? (If you don't know, and/or don't know how to find out , suggestions on how to find out posted below: I don't know your skill level. I'm not trying to be insulting. I try to write things to be consumable by a greater audience than an individual. Maybe people other than you can benefit. :-)
I'm using the blazer_usb driver and that driver replaces the older/previous megatec driver, and it is using the megatec Q1 protocol.
As mentioned, the UPS is detected when I run the blazer_usb driver manually as the root user (with the -u root option).
I've also tried the newer QX driver (nutdrv_qx), with the same results.
When working to diagnose other UPS serial (old fashioned RS232/DB9) and USB issues, I encountered a case like this...
Running debug options for a USB "driver" to UPS resulting in success/partial-success when running as root from the command line.
For me, the "problem" was with devd device permissions for the added USB device.
My device didn't match the devd DB for supported UPS, so it didn't change mode or permissions for the added USB device.
Using Linux "lsusb -vv |less" or FreeBSD "usbconfig dump_all_desc | less" , find the USB device for your UPS in the output, then locate that USB device's "idVendor" and "idProduct"
Take these hexadecimal values (after the 0x) you found when interrogating your UPS over USB and look in your OPNSense devd nut config file to compare/evaluate:
/usr/local/etc/devd/nut-usb.conf
See if you can find a supported device that uses those values for "idVendor" and "idProduct"
If there are none, even if your UPS is supported, devd is probably not altering the device permissions to allow non-root access to talk to the added USB , UPS device.
One route which I suggest not doing and relying upon long-term, if this is the problem, is adding an entry to the file similar to the others, but matching your vendorID and productID, then reloading devd or rebooting, then seeing if the "/dev/" device gets the desired ownership/permissions so that non-root can talk to it.
It might be a good step toward diagnosing the issue, but isn't really supportable, as the next update of the package that owns that file, and you will have to re-apply changes. Additionally, integrity checks for files owned by packages which have changes could issue alarms about the config file not matching the vendor installed file.
In my case, I was lucky: a firmware upgrade of my UPS having this problem (supported model, but vendorID and product/device ID not listed in the file) resolved the issue. After UPS Firmware upgrade and "reboot of the UPS with the new firmware" it appeared again on USB using a supported vendorID and product/device ID, allowing the default devd rules included with nut services to work with my UPS.
Assuming your UPS uses the samples from the URL provided:
ups.productid : 5161
ups.vendorid : 0665
Checking /usr/local/etc/devd/nut-usb.conf on my present 22.1.X (April 29, 2022) install shows me
# Belkin F6C1200-UNV - blazer_usb
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x0665";
match "product" "0x5161";
action "chgrp uucp /dev/$cdev; chmod g+rw /dev/$cdev";
};
If the text you have above is accurate, then check your nut devd config for:
0.017996 - VendorID: 06da
0.018020 - ProductID: 0003
Do you find this in your devd config?
# Mustek Powermust - blazer_usb
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x06da";
match "product" "0x0003";
action "chgrp uucp /dev/$cdev; chmod g+rw /dev/$cdev";
};
Is devd working for you on your system?
# /etc/rc.d/devd status
Try reloading devd:
# /etc/rc.d/devd reload
or maybe:
# /etc/rc.d/devd restart
or if not an option, a reboot will surely reload devd with the nut devd usb config.
Then unplug the USB cable to the UPS and plug it back in. Are the /dev/* device permissions and ownership now "right" for non-root access?
Does your USB device use these same VendorID and ProductID provided above in 2 examples?
Can you confirm the ownership (user:group) and mode match the expected settings from your file when detected?
From your text:
0.000983 Checking device (06DA/0003) (/dev/usb//dev/ugen0.3)
# ls -l /dev/usb//dev/ugen0.3
What are the ownership and permissions for that device (assuming same for your USB to UPS)?
Is more than one "/dev/*/ file added for your USB based UPS, and are you using one /dev/* file to talk to your UPS while the nut software is using another?
If your VendorID and ProductID do not match this, do they appear in this devd config file from nut anywhere else?
If your UPS is supported but has different VendorID/ProductID, it would probably be a good idea to see if the latest nut (source) includes your UPS in the devd rules, and if not, then submit it to the nut maintainers to get it added.
Other things to consider:
If you have been running tests as root, check to see if you have accidentally created directories, or files which the nut service running as non-root can no longer read from or write to.
Did the debug process accidentally remove a dedicated lockfile directory the non-root service needs to run correctly?
Were any changes made to the non-root user (/etc/passwd) or groups (/etc/group) that could break the non-root nut users access?
Are you trying to use special kernel hardening security features not supported by stock OPNSense such as MAC, or sysctl customizations for securelevel, etc.?
I hope this provides you with enough ideas to find a solution and then post what you did to solve this problem.
-
Thank you all for the replies. :)
I managed to get it working now.
UPS: Numeric Digital 800 Plus
Identified on USB as:
ugen0.3: <CTN USB 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 = 0x06da
idProduct = 0x0003
bcdDevice = 0x0501
iManufacturer = 0x0003 <CTN>
iProduct = 0x0001 <USB UPS>
iSerialNumber = 0x0000 <no string>
bNumConfigurations = 0x0001
The issues seems to have been a combination of things, and I've learned a few things along the way:
These are the settings that in the end worked for me:
Service Mode: standalone
Name: ups1
Listen Address: added local IPv4 address of OPNsense server (192.168.0.1)
UPS type: QX-Driver -> enabled
Extra Arguments: port=auto, novendor, protocol=megatec
With these settings (and a re-connect of USB cable) the Service status on the NUT configuration pages shows as running (Green).
On the Dashboard, the 2 services 'nut_deamon' and 'nut_upsmon' are now also green.
Learned:
UI process getting in the way of the commands given on the command line:
- Adding the settings via the UI, Apply, then stop the service, then troubleshoot/run commands on the command line. Or disable the NUT service in the UI and manually enter the details in the NUT config files.
- USB port of the UPS getting blocked (Permission denied) -> unplug USB cable and re-insert into other USB port.
- NUT package on FreeBSD is compiled with user uucp and group uucp, so use that when running the nut usb driver directly
(like: /usr/local/libexec/nut/blazer_usb -a ups1 -DDD -u uucp).
* The number of 'D's is the debug level (e.g 5 'D's is debug-lvel 5).
- NUT config files are in: /usr/local/etc/nut -> owned by: root:wheel
- NUT state path (PID file and status output file): /var/db/nut -> owned by: uucp:uucp
- NUT drivers are in : /usr/local/libexec/nut/ -> owned by: root:wheel
- NUT utils like upsd, upsdrvctl etc. are in: /usr/local/sbin/ -> owned by: root:wheel
- USB port is/gets correctly owned:
- sudo ls -l /dev/ugen0.3 -> shows link to usb/0.3.0 and is owned by root:wheel
- sudo ls -l /dev/usb/0.3.0 is owned by root:uucp