Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
USB high speed EHCI-PCI Ownership Question?
USB high speed EHCI-PCI Ownership Question?
Hi all,
I have some linux experience and regularly use serial communication on Python for working with a wide set of instruments at work to build up the system I need.
However I have received a new spectrometer which comes with a proprietary library and a testing program "test" which has been added to my PATH and all appears to be working appropriately. Only problem is the test program will only work when I use "sudo" if I am not sudo, the program will run but will not find the spectrometer:
$ testavs
Avantes libavs test
USB spectrometers found: 0
Test Done
$ sudo testavs
Avantes libavs test
USB spectrometers found: 1
Test spectrometer: 1507193U1
Test Done
This appears to me to be a simple situation of not having the appropriate level to be able to access the instrument. When I plug in the device and run "sudo dmesg" I get the following result:
[97566.912233] usb 3-1.6: new high-speed USB device number 12 using ehci-pci
[97567.025682] usb 3-1.6: New USB device found, idVendor=1992, idProduct=0667, bcdDevice= 0.00
[97567.025686] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[97567.025688] usb 3-1.6: Product: AS5216
I am used to seeing an associated device placed under the "/dev" where I can alter its ownership to have access as a normal user but this is not the case for this "ehci-pci" type device. If anyone can help me and show where I need to go to change the ownership I would be very grateful.
I have some linux experience and regularly use serial communication on Python for working with a wide set of instruments at work to build up the system I need.
However I have received a new spectrometer which comes with a proprietary library and a testing program "test" which has been added to my PATH and all appears to be working appropriately. Only problem is the test program will only work when I use "sudo" if I am not sudo, the program will run but will not find the spectrometer:
$ testavs
Avantes libavs test
USB spectrometers found: 0
Test Done
$ sudo testavs
Avantes libavs test
USB spectrometers found: 1
Test spectrometer: 1507193U1
Test Done
This appears to me to be a simple situation of not having the appropriate level to be able to access the instrument. When I plug in the device and run "sudo dmesg" I get the following result:
[97566.912233] usb 3-1.6: new high-speed USB device number 12 using ehci-pci
[97567.025682] usb 3-1.6: New USB device found, idVendor=1992, idProduct=0667, bcdDevice= 0.00
[97567.025686] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[97567.025688] usb 3-1.6: Product: AS5216
I am used to seeing an associated device placed under the "/dev" where I can alter its ownership to have access as a normal user but this is not the case for this "ehci-pci" type device. If anyone can help me and show where I need to go to change the ownership I would be very grateful.
Re: USB high speed EHCI-PCI Ownership Question?
Well this is what I had in mind: usually when I want a serial connection like "/dev/ttyACM0" for instance it's a part of the group "dialout" so I add myself to that group and no more problems.
In this case however I have no idea which group ehci-pci devices belong to or even where to find such information as there appears to be no device node? At least not a dynamic device node as for serial devices.
In this case however I have no idea which group ehci-pci devices belong to or even where to find such information as there appears to be no device node? At least not a dynamic device node as for serial devices.
-
- Global Moderator
- Posts: 2669
- Joined: 2018-06-20 15:16
- Location: Colorado
- Has thanked: 41 times
- Been thanked: 196 times
Re: USB high speed EHCI-PCI Ownership Question?
Nothing yet?
You could maybe create a udev rule to place the pciid of the device into a common user group?
Or, take a look at usbview. Install it for the info it may give, and also an example of using pkexec to manage the permissions.
You could maybe create a udev rule to place the pciid of the device into a common user group?
Or, take a look at usbview. Install it for the info it may give, and also an example of using pkexec to manage the permissions.
Re: USB high speed EHCI-PCI Ownership Question?
Thank you for the suggestion, I tried udev but probably I wrote a bad rule as nothing came up:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="0667", ATTRS{idVendor}=="1992", SYMLINK+="avantes"
separately I also tried usbview: a great tool I did not know of. The device does show up on this program, where it does not on lsusb, coloured red which according to the documentation means "no kernel available". However the library I use for this instrument still works fine despite there being no kernel available so unfortunately I am no closer to finding how to access the instrument without needing admin privileges every time.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idProduct}=="0667", ATTRS{idVendor}=="1992", SYMLINK+="avantes"
separately I also tried usbview: a great tool I did not know of. The device does show up on this program, where it does not on lsusb, coloured red which according to the documentation means "no kernel available". However the library I use for this instrument still works fine despite there being no kernel available so unfortunately I am no closer to finding how to access the instrument without needing admin privileges every time.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: USB high speed EHCI-PCI Ownership Question?
If the spectrometer does not have a kernel driver which creates a device file in /dev, then trying to set permissions on an unexistent device file is pointless.
Maybe the proprietary library has a user-mode driver using libusb or the like to communicate with USB without a kernel driver, like SANE does with some USB scanners, which requires that the calling process has adequate privileges/capabilities.
Maybe the proprietary library has a user-mode driver using libusb or the like to communicate with USB without a kernel driver, like SANE does with some USB scanners, which requires that the calling process has adequate privileges/capabilities.
Re: USB high speed EHCI-PCI Ownership Question?
This is exactly what I am assuming p.H: that access to the library is not limited by any particular permission however access to the device itself, without which the library is useless, requires some additional privilege that I am unaware of and I came here trying to figure out how to find which privilege or group should be set. In the case of SANE with USB scanners was some work around found? I have not heard of it before and could not find any information online.
So far I have already begun running my experiments with the device, always as an administrator. Hardly good practice but the system itself works as advertised which is nice.
So far I have already begun running my experiments with the device, always as an administrator. Hardly good practice but the system itself works as advertised which is nice.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: USB high speed EHCI-PCI Ownership Question?
Looking better, it seems that the kernel actually creates a device node in /dev/bus/usb/, and libsane uses a udev rule to set an ACL granting R/W permission to the "scanner" group :
If you want to test first if setting the permission for your user would work,
while the device is unplugged, as root run
When you plug the device, it should print lines such as :
Press ctrl+c and run
Among the lines, you should see one like :
indicating that the device node is /dev/bus/usb/005/008.
Or maybe you could take the numbers from dmesg :
The device path should be /dev/bus/usb/003/012. (not sure).
You can try to change its permission/ownership and check whether the program can find the device when run without root privilege.
Code: Select all
ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"
while the device is unplugged, as root run
Code: Select all
udevadm monitor
Code: Select all
KERNEL[11208.253792] add /devices/pci0000:00/0000:00:1d.7/usb5/5-4 (usb)
Code: Select all
udevadm info --path=/devices/pci0000:00/0000:00:1d.7/usb5/5-4
Code: Select all
N: bus/usb/005/008
Or maybe you could take the numbers from dmesg :
Code: Select all
usb 3-1.6: new high-speed USB device number 12 using ehci-pci
You can try to change its permission/ownership and check whether the program can find the device when run without root privilege.
-
- Posts: 932
- Joined: 2020-05-03 14:16
- Has thanked: 7 times
- Been thanked: 65 times
Re: USB high speed EHCI-PCI Ownership Question?
(I've used professional spectrometers in the past)LostZimbo wrote:I have received a new spectrometer which comes with a proprietary library and a testing program "test" which has been added to my PATH and all appears to be working appropriately. Only problem is the test program will only work when I use "sudo" if I am not sudo, the program will run but will not find the spectrometer:
If We are not speaking here about useless toys, good spectrometers are quite expensive devices - if the manufacturer is claiming that the device is supported on Linux systems, then You should contact the manufacturer and report a bug/problem with the software. You should be aware of the fact, that spectrometers have to be calibrated before they can be used - the "test" program is useless without calibration.
Otherwise, it makes no sense to use tricks like suid flags - there is no guarantee that the software works correctly (f.e. it may silently skip some errors, leading to useless results obtained from non-calibrated device)
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed
The_full_story and Nothing_have_changed