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

[Jim Klimov]

Thinking of it, we can't conjure a libusb descriptor from thin air because
the library can have internal state associated with it (allocated buffers,
open-close count, etc.)

On Tue, Nov 26, 2024, 21:06 Jim Klimov <jimklimov+nut at gmail.com> wrote:

> 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_-887649569300041980_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/102d949d/attachment.htm>