Hello William,
> > 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;>
> Thank you, this seems to be the primary problem. I learned enough about
udev to find that the first UPS I was testing with had 'root nut'
ownership. The second UPS used for testing had 'root root' ownership.
When
I manually changed the second UPS to 'root nut' ownership the driver
behaved as expected with the second UPS.>
> The question I have now is: Why did the second UPS need manual ownership
change and the first one did not? I know that I didn't do anything down the
/dev/bus/usb/xxx path until today.>
> I have been running the driver in the foreground for the second UPS but I
know I had run the driver "normally" on the first UPS. Would the
ownership
have been changed due to the "normal" driver run versus the
"foreground"
driver run? Perhaps something that gets done using 'upsdrvctl' that
doesn't
get done just running the driver by itself?
Looking at your original post...
> 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)
In the main NUT codebase I see no drivers proclaiming support for
`USB_DEVICE(0x1234, <anything>)` (in your case, your driver needs two such
separate lines, with 0x0001 and 0x0002 respectively).
These lines lead to generation of NUT's `udev.rules` and similar files when
you `autogen.sh` (or via `make` rules, possibly explicitly called, in some
build scenarios).
Only when such an `udev.rules` file is installed into the location the OS
looks at, and activated (`systemctl restart udev` or reboot), and possibly
after the device is re-plugged (or system rebooted, or USB port reset if
conforming) to update the devfs nodes, will the `nut`-oriented permissions
get applied.
At least, that's my best educated guess about the situation at the moment :)
Hope this helps,
Jim Klimov
On Mon, Dec 2, 2024 at 7:02?PM William R. Elliot <bill at wreassoc.com>
wrote:
> Jim, see two comments/questions below...
>
> 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;
>
>
> Thank you, this seems to be the primary problem. I learned enough about
> udev to find that the first UPS I was testing with had 'root nut'
> ownership. The second UPS used for testing had 'root root'
ownership. When
> I manually changed the second UPS to 'root nut' ownership the
driver
> behaved as expected with the second UPS.
>
> The question I have now is: Why did the second UPS need manual ownership
> change and the first one did not? I know that I didn't do anything down
the
> /dev/bus/usb/xxx path until today.
>
> I have been running the driver in the foreground for the second UPS but I
> know I had run the driver "normally" on the first UPS. Would the
ownership
> have been changed due to the "normal" driver run versus the
"foreground"
> driver run? Perhaps something that gets done using 'upsdrvctl' that
doesn't
> get done just running the driver by itself?
>
>
> 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).
>
>
> Didn't go here as I made progress with udev above. Plus I am the only
one
> running the driver on this machine.
>
>
> 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_6439276482505671098_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/20241202/c59f68fd/attachment-0001.htm>