[Nut-upsdev] USB match but cannot open??

[Jim Klimov]

Regarding the follow-up, IIRC `open` walks a device list returned by
libusb, checks each entry against the matcher, and tells libusb if it wants
to claim the device described by a particular entry. I don't think it walks
further entries after a successful match and claim?

We can't use the matcher directly, because its fields can be a regex
geberally (e.g. `vendor=A*` instead of `APC` or `Aardwark` specifically),
and because libusb device descriptors are a black box for us (FD, struct,
blob - whatever the token we pass to library methods is on a platform and
lib version).

Also matching can involve callbacks, so a driver can probe the device in
more detail (okay, you're APC - but do you talk USB HID or Modbus or
microsol?)

Hope this helps,
Jim Klimov

On Tue, Nov 26, 2024, 15:53 William R. Elliot <bill at wreassoc.com> wrote:

> Jim,
>
> Thanks for the quick reply.
>
> I'll try number 1 below but I don't have the understanding as to why that
> would be for this UPS and not the other UPS in the family.
>
> For number 2, kind of the same comment. Why would someone else hold this
> device and not the other vendor ups that is working. I am running the
> driver in the foreground and not through a debugger.
>
> A follow up question that hit me this morning even though I have seen the
> evidence for weeks: If there is a successful Regex Match, why does the
> "open" command walk through the five or so available USB devices? Why is
> "open" not just opening what is in the matcher structure? I'm clearly
> missing something here about how all the USB stuff works.
>
> Thanks,
>
> Bill
>
> At 01:50 AM 11/26/2024, Jim Klimov wrote:
>
> Cheers,
>
>   This error message usually deals with a couple of situations:
>
> 1) Actual lack of permissions (POSIX bits in devfs) - usually solved by
> `udev` or similar subsystem that handles hotplug HW for the OS. Or by
> running the driver as root and not losing the privileges (user=root in
> ups.conf) as a temporary fix and check that this is the case at all;
>
> 2) Someone else has hold of the device and libusb can't take it as
> exclusively as NUT needs (lsof/fuser/... to check if any other programs
> hold it - maybe another copy of your driver program in debugger etc).
>
> Happy Thanksgiving,
> Jim
>
> On Tue, Nov 26, 2024 at 4:37 AM William R. Elliot <bill at wreassoc.com>
> wrote:
>
> Hello again.
>
> The USB device table in the driver I am working on has two entries for the
> particular vendor ID I am working with, one for each of two product
> IDs...0x0001 and 0x0002. The driver properly matches and can open the
> device with the 0x0002 product ID. However, running the same driver with
> the 0x0001 ups attached matches but fails to open.
>
> This is the relevent output following a successful match and trying to
> open the device:
>
>    0.002511     [D2] Checking device 2 of 5 (1234/0001)
>    0.002564     [D1] Failed to open device (1234/0001), skipping: Access
> denied (insufficient permissions)
>
> My expectation would be that either device, once matched, would be able to
> be opened and then further steps can be taken to confirm that the driver is
> communicating with an expected device.
>
> I would appreciate any pointers toward something I may have missed.
>
> Thank you,
>
> Bill
>
> Happy Thanksgiving to the U.S. folks!
>
> Virus-free. www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> <#m_-5248667457445858416_m_-6725320979215136950_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241126/3e360b30/attachment-0001.htm>