USB high speed EHCI-PCI Ownership Question?

[LostZimbo]

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.

[CwF]

I would look at 'groups' and not ownership.

[LostZimbo]

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.

[CwF]

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.

[LostZimbo]

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.

[p.H]

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.

[LostZimbo]

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.

[p.H]

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 :

Code: Select all

ENV{libsane_matched}=="yes", RUN+="/bin/setfacl -m g:scanner:rw $env{DEVNAME}"

If you want to test first if setting the permission for your user would work,
while the device is unplugged, as root run

Code: Select all

udevadm monitor

When you plug the device, it should print lines such as :

Code: Select all

KERNEL[11208.253792] add      /devices/pci0000:00/0000:00:1d.7/usb5/5-4 (usb)

Press ctrl+c and run

Code: Select all

udevadm info --path=/devices/pci0000:00/0000:00:1d.7/usb5/5-4

Among the lines, you should see one like :

Code: Select all

N: bus/usb/005/008

indicating that the device node is /dev/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

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.

[LE_746F6D617A7A69]

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:

(I've used professional spectrometers in the past)

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)