-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about RIELLO UPS #2159
Comments
Looking at screenshot, maybe the problem is with driver name: in NUT there are Looking at source history, initial driver codebase was in fact contributed by a person from Riello, so at least as of ~2014 it should have "officially" supported the contemporary protocol. I do not know if their newer devices follow some unrelated protocol or are still compatible, though. You might try to bump driver debug verbosity, if you can see its logs - maybe that would expose how it tries to find the device and what exactly fails. With NUT v2.8.0+ it may suffice to add a |
Thanks! So at least it does start the correct driver program in the end, but apparently the OS does not let it claim the USB device filesystem node, or something of that sort. Reasons could vary, but typically it is either that some other program already holds it (potentially another instance of the NUT driver, though usually the new instance should detect the old one and signal it to quit so the new one can initialize), or the kernel holds it with some default OS driver/handler and no subsystem like Assuming here that NUT's file like that is generated in https://github.com/networkupstools/nut/tree/master/scripts/devd during build (if support is detected) but it may be up to packagers to write the recipes to integrate it in practice. Since you have SSH access, can you check if a
A pre-generated template (substitutions needed for runtime user/group) should be also present in a release tarball like https://www.networkupstools.org/source/2.8/nut-2.8.1.tar.gz as scripts/devd/nut-usb.conf.in |
dennypage @Unoptanio "failed to detach kernel driver" indicates that there is not a USB quirk registered to prevent the kernel from attaching a default driver. In other words, the kernel does not know that it is a UPS. You will either need to determine and register the correct quirk, or run as root. See this thread for a recent discussion about developing a quirk. |
That looks promising. Now you'd have to find some way to check if pfSense actually refers to that file (or directory with it) to make run-time decisions, but I can't directly help that far :} Maybe re-plugging the UPS and checking what One more idea came up - since this setup is largely about permissions, you can try to add By the way, haven't seen in screenshots: does it say anywhere which libusb version the driver was built against (0.1 or 1.x)? |
you are the number one! |
Thanks for the links, I'll add them to Wiki at least... Starter kit: https://github.com/networkupstools/nut/wiki/NUT-on-pfSense |
Well, at least the platform code works. The next question would be about getting the OS to let NUT handle the device with its own unprivileged account... but that is more of a question to pfSense and/or NUT package integration there, than to NUT sources, probably. Running as |
it was enough to add "user = root" in the extra options. |
Thank you very much for your support, have a nice evening |
Upstream FreeBSD manages USB quirks for the OS pfSense runs on. They can be added "in the field" but this is well beyond the scope of pfSense. I've given the user information on how to develop and test a quirk for their UPS. Following development of the quirk, a ticket can be opened in FreeBSD to add it to the default list. |
Looking at the thread's example like
I think this is something that half a dozen other rule files generated by NUT builds for In-tree example of the info: https://github.com/networkupstools/nut/blob/master/scripts/upower/95-upower-hid.hwdb Other than that, I think |
@jimklimov, To clarify, pfSense is not an operating system per se. pfSense is a configured collection of FreeBSD packages (akin to rpms) that run atop the FreeBSD operating system. Similar to a functioning Linux system, there are a large number of packages involved. Depending upon what optional things are installed, there will be 200-300 packages present in the system. NUT is one such package. Quirks in FreeBSD are owned by the OS. They can be added in the field as described in the thread that @Unoptanio linked to (see "Notes on USB quirks"), but they are expected to be registered upstream in FreeBSD rather than being distributed as part of a package. People may or may not agree with the approach FreeBSD has chosen, but it is their choice to make and we have to work with them accordingly. |
@dennypage : yeah, I understand that... just from the design side - at least this use-case shows that the set of quirks to apply can be something dependent on actual installed packages. Like, with USB-HID devices maybe there is a system-provided power daemon (HAL, dbus...) which handles the basics like online/onbatt/shutdown of the one host machine. In this case, maybe no quirks are needed. Or someone might have Or someone has NUT and needs many USB identifiers made available for its driver daemons that handle numerous protocols over USB. Overall, I believe this is not something to hard-code in the core OS (whether in C, like the linked source does for many Belkins and Tripplites and whatnot, or in default and immutable config files that users may touch but packages dare not). |
…orkupstools#2159] Signed-off-by: Jim Klimov <[email protected]>
Hello,
using pfsense 2.7.0 with package nut ver 2.8.0_2
UPS Riello VST1100 with USB cable
UPS Riello Sentinel PRO 2200 with USB cable
Tried various USB cables and different lengths
All riello UPS not working with USB cable
Problem descriprion:
https://forum.netgate.com/topic/162961/nut-with-riello-sentinel-pro-2200-usb-connection-cant-make-it-work/3?_=1699522441179
Can anyone help us?
Do you need any additional settings?
We couldn't find any documentation on how to fix the problem
The text was updated successfully, but these errors were encountered: