[Nut-upsdev] NUT, Linux and libusb

[Jim Klimov]

Cheers,

  Trying to wrap my head around an issue discussed in
https://github.com/networkupstools/nut/issues/1925

  The gist of it is that despite the usbhid-ups driver running as `root`
and seeing most of the regular run-time info, in the initial device search
it fails to find basic matching info points - the device vendor, product
and sernum strings:

````
   0.289953 [D2] Device does not match - skipping
   0.289960 [D2] Checking device 8 of 9 (0463/FFFF)
   0.311147 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.332348 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.353600 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.374780 [D1] nut_libusb_open get iProduct failed, retrying...
   0.395962 [D1] nut_libusb_open get iProduct failed, retrying...
   0.417222 [D1] nut_libusb_open get iProduct failed, retrying...
   0.438631 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.460000 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481267 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481286 [D2] - VendorID: 0463
   0.481291 [D2] - ProductID: ffff
   0.481296 [D2] - Manufacturer: unknown
   0.481301 [D2] - Product: unknown
   0.481306 [D2] - Serial Number: unknown
   0.481311 [D2] - Bus: 003
   0.481316 [D2] - Device: unknown
   0.481321 [D2] - Device release number: 0202
   0.481344 [D2] Trying to match device
   0.481350 [D2] match_function_subdriver (non-SHUT mode): matching a
device...
   0.481358 [D3] match_function_regex: matching a device...
   0.481364 [D2] Device matches
````

...which does not preclude it from being queried and accepted thanks to
numeric IDs and dialog with the device. Later on the lack of iProduct name
however creeps into "unknown 2000" (per mge-hid.c logic).

  Has anyone please got clues, hints, gut feelings and trench anecdotes to
share? Why could these basics be "invisible" to NUT (as root) while lsusb
and udevadm have no problem reporting them. Apparently a different
APC-oriented daemon also reported the name well.

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230629/52492d75/attachment.htm>