Duplicate USB devices don't connect in 2.8.0

[ProjectInitiative]

OS: Fresh installed raspberry pi OS 64 bit
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye

Build commands used

Built from source with provided instructions. All commands used below:

sudo apt-get install -y make g++ gcc build-essential autoconf gettext m4 libtool libudev-dev automake pkg-config libusb-0.1-4 libusb-1.0-0-dev libsnmp-dev libgd-dev

groupadd nut
useradd -ms /bin/bash ups
usermod -aG nut ups
usermod -aG nut root

mkdir -p /var/run/nut
chown root:nut /var/run/nut
mkdir -p /var/state/ups
chown root:nut /var/state/ups
chmod 0770 /var/state/ups

git clone https://github.com/networkupstools/nut.git
/nut
./autogen.sh
./configure --with-user=ups --with-group=nut --with-usb --with-snmp --with-cgi
make -j $(nproc)
make install

nut-scanner output

sudo /usr/local/ups/bin/nut-scanner
Scanning USB bus.
No start IP, skipping SNMP
No start IP, skipping NUT bus (old connect method)
[nutdev1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0764"
        productid = "0601"
        product = "OR1500LCDRM1U"
        vendor = "CPS"
        bus = "001"
[nutdev2]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0764"
        productid = "0601"
        product = "OR1500LCDRM1U"
        vendor = "CPS"
        bus = "001"

Adding this info to /usr/local/ups/etc/ups.conf and running sudo /usr/local/ups/sbin/upsdrvctl -u root start worked in previous versions, connected to both devices.

Presently upsdrvctl returns the following:

Network UPS Tools - UPS driver controller 2.8.0-18-gaaa72bebd
Network UPS Tools - Generic HID driver 0.47 (2.8.0-18-gaaa72bebd)
USB communication driver (libusb 1.0) 0.43
Using subdriver: CyberPower HID 0.6
Network UPS Tools - Generic HID driver 0.47 (2.8.0-18-gaaa72bebd)
USB communication driver (libusb 1.0) 0.43
Can't claim USB device [0764:0601]@0/0: Entity not found
Driver failed to start (exit status=1)

NOTE: only having one UPS plugged in works just fine, the problem only comes up when 2 or more are connected.

[ProjectInitiative]

I would like to also note that I have tried this in a x86 installation of Debian as well. Same behavior.

[jimklimov]

Can some other metadata be unique to the device? Serial number? (there are also issues about trying to monitor several devices without unique serials) I think it boils down to libusb giving us a set of device descriptors (AFAIK no devfs path there, so "port" value is ignored), and a driver picking one and binding to it. So if you find a way to specify how one of otherwise identical devices is different from another - great! Note that connection path details should not be "it" (at worst as non-recommended fallback), to allow re-enumeration of buses and re-plugging of cables.

…

On Wed, May 4, 2022, 17:41 Kyle Petryszak ***@***.***> wrote: I would like to also note that I have tried this in a x86 installation of Debian as well. Same behavior. — Reply to this email directly, view it on GitHub <#1414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPTFAR3CNQUSBDERNF663VIKLENANCNFSM5VCMDHZA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ProjectInitiative]

So I went down the rabbit hole a bit. There are no unique identifying bits of meta data for these two devices (the ups does not return a serial number).

I have found two ways to differentiate the two: using the devnum outputted by lsusb, or by the physical bus port.

Making the problem worse: the upses (cyberpower) constantly disconnect and reconnect themselves until a driver binds to them. Therefore the devnum gets increased frequently.

I wrote a python script to read /sys/bus/usb/devices/1-1.1/devnum for instance, and add that to ups.conf as "device=000", and restart the driver's if the cables were ever unplugged or the kernel re-numbered things.

The problem is, the "device=000" parameter seems to be ignored by upsdrvctl and usbhid-ups.

[ProjectInitiative]

I was poking through the code, and trying to figure out where to add a new ups.conf parameter to use a dev path or bus port to the usbhid-ups driver.

[jimklimov]

Regarding regular disconnects, that rings a bell. Please trawl issues (possibly closed, maybe labeled for Cyberpower/CPS), I read that somewhere. Could be on a distro site recommendations on NUT though (maybe Arch Linux then, they had a useful troubleshooting page).

...read /sys/bus/usb/devices/1-1.1/devnum for instance, and add that to

ups.conf as "device=000" Is something similar achievable with libusb API? Looking into these paths is very systems-dependent and the world is not only Linux :\ Not saying '"no" outright, on platforms that can detect the value in some manner it can be useful, and others would have a blank and ignore. As for driver code, look for "vendorid" as it is a criterion for all usb driver matchers; then for other fields it varies. I raised an issue recently to compare nutdrv_qx matcher with usbhid-ups one, they seem to be advanced in different ways so could be a good idea to reconcile the approaches or even refactor them out to e.g. usb-common.c/.h code for all drivers to use the same featured matcher eventually. Also some part of equation could be in libusb0.c and libusb1.c with API-variant dependent pieces...

…

On Thu, May 5, 2022, 00:04 Kyle Petryszak ***@***.***> wrote: I was poking through the code, and trying to figure out where to add a new ups.conf parameter to use a dev path or bus port to the usbhid-ups driver. — Reply to this email directly, view it on GitHub <#1414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPTFCAW325GJDQB6FFPETVILX7XANCNFSM5VCMDHZA> . You are receiving this because you commented.Message ID: ***@***.***>

[jimklimov]

UPDATES:

• Another ticket on duplicate USB: Proper solution for UPSes without unique serials #1273 (I think there were more, but that's a start...)
• CPS reconnects: https://wiki.archlinux.org/title/Network_UPS_Tools#CyberPower_UPS_keeps_disconnecting/reconnecting

[ProjectInitiative]

The cross referenced issue is the same issue, different UPS. I'm still looking at libusb functions that could help bind to the correct HID device

[jimklimov]

Someone mentioned on the mailing list recently that libusb-0.1 API did not allow to connect to devices by path; however libusb-1.0 should have a way to do so (and this honor the port setting which is now ignored) => #1565

[jimklimov]

Interesting, I don't remember seeing Can't claim USB device [0764:0601]@0/0: Entity not found earlier. Googling points "Entity not found" to possibly "not claiming an interface first".

[jimklimov]

Regarding "device=000": how is it reported by OS? In a Linux system I have, there are no 000s in lsusb output, seems it is 001 based for each bus.

Note that the argument is a regex (in trivial case a fixed string), not a numeric comparison.

If you run the driver with debug verbosity 2 (or higher) it should report the mismatches in detail.