Question about RIELLO UPS

[Unoptanio]

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

[jimklimov]

Looking at screenshot, maybe the problem is with driver name: in NUT there are riello_ser and riello_usb respectively for different media, not one riello. I doubt that pfSense undertook an effort to merge them into one, although maybe they "hide" it behind selection of "UPS Type" (Local USB)? Even that would not be easy, as different drivers follow different naming patterns (and some are dual-capability). So the first thing to check would be typing riello_usb there.

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 debug_min = 6 to the "Extra arguments" while you are troubleshooting.

[Unoptanio]

Other UPS drivers in pfsense:

[Unoptanio]

Other UPS Type in pfsense

[Unoptanio]

From Pfsense manual:

Result in my system:

[jimklimov]

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 devd got configured with NUT list of known USB UPS VID:PID pairs and permissions tweaked to allow NUT run-time user to access them.

Assuming here that devd is what pfSense uses for dynamic device settings - at least there is a https://github.com/pfsense/pfsense/blob/master/src/etc/pfSense-devd.conf apparently :)

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 nut-usb.conf file is present anywhere? e.g. if something like this would find it:

:; find /usr* /lib* /etc* -name nut-usb.conf -ls

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

[Unoptanio]

[Unoptanio]

dennypage dennypage about a minute ago

@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.

[jimklimov]

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 dmesg (or some /var/log/syslog, or /var/log/messages, or /var/adm/...) says would reveal something to that effect faster, than trawling config files...

One more idea came up - since this setup is largely about permissions, you can try to add user = root to "Extra config" options for the driver. At least, if that gets traction, it would help differentiate permissions problems from something else (e.g. NUT or libusb just calling something not appropriate for that OS to hijack the device from kernel).

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)?

[Unoptanio]

you are the number one!

[jimklimov]

Thanks for the links, I'll add them to Wiki at least...

Starter kit: https://github.com/networkupstools/nut/wiki/NUT-on-pfSense

[Unoptanio]

[jimklimov]

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 root is generally frowned upon, if avoidable.

[Unoptanio]

Thanks for the links, I'll add them to Wiki at least...

it was enough to add "user = root" in the extra options.

[Unoptanio]

Thank you very much for your support, have a nice evening

[dennypage]

pfSense and/or NUT package integration there, than to NUT sources, probably.

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.

[jimklimov]

Looking at the thread's example like

hw.usb.quirk.0="0x09ae 0x2012 0x0000 0xffff UQ_HID_IGNORE"

I think this is something that half a dozen other rule files generated by NUT builds for devd, upower etc. achieve - just a yet another format of the same info (well, not sure what the 0x0000 0xffff bit is). As such, this seems like a packaging problem - to convert the NUT info during packaging into this format and append it to /boot/loader.conf.local during installation. PRs to get it generated by NUT are also an option - see https://github.com/networkupstools/nut/blob/master/tools/nut-usbinfo.pl

In-tree example of the info: https://github.com/networkupstools/nut/blob/master/scripts/upower/95-upower-hid.hwdb

Other than that, I think devd is a FreeBSD tech and is in pfSense, and that it is equivalent in regard to being an automation of OS reaction to hot-plug events (e.g. set certain permissions, run programs, etc.), so having it honour the actually delivered /usr/local/etc/devd/nut-usb.conf could be an easier solution.

[Unoptanio]

New upgrade in: https://forum.netgate.com/topic/183961/nut-package-2-8-1-and-above/15?_=1699613439488

[dennypage]

@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.

[jimklimov]

@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 apcupsd and need just the quirks for a few APC-related USB identifiers.

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).