[pyusb-users] pyusb and root permissions "ValueError: The device has no langid"

Permissions deal with your Linux configuration.

Here is a general answer for Linux.
http://unix.stackexchange.com/questions/44308/understanding-udev-rules-and-permissions-in-libusb

You can google for libusb permissions for your distribution if this doesn't lead to a solution.

Post by Jay Aurabind
Hi,
I am a user of pyOCD, and I am having an issue related to pyusb which
is what the former uses for talking to the USB device. The situation
is that I need to use pyOCD through an eclipse plugin. Eclipse
launches pyocd-gdbserver and normal user. But it will only work if
launched as root.
My question is, how can I make pysb do its job without requiring root
permissions? Here is the error I get when launching pyocd-gdbserver as
uncaught exception: The device has no langid
File "build/bdist.linux-x86_64/egg/pyOCD/tools/gdb_server.py", line
262, in run
frequency=self.args.frequency)
File "build/bdist.linux-x86_64/egg/pyOCD/board/mbed_board.py", line
210, in chooseBoard
target_override, frequency)
File "build/bdist.linux-x86_64/egg/pyOCD/board/mbed_board.py", line
182, in getAllConnectedBoards
connected_daps = dap_class.get_connected_devices()
File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py",
line 352, in get_connected_devices
all_interfaces = _get_interfaces()
File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/dap_access_cmsis_dap.py",
line 44, in _get_interfaces
return INTERFACE[usb_backend].getAllConnectedInterface()
File "build/bdist.linux-x86_64/egg/pyOCD/pyDAPAccess/interface/pyusb_backend.py",
line 88, in getAllConnectedInterface
product = board.product
File "/usr/lib/python2.7/site-packages/usb/core.py", line 841, in product
self._product = util.get_string(self, self.iProduct)
File "/usr/lib/python2.7/site-packages/usb/util.py", line 314, in get_string
raise ValueError("The device has no langid")
ValueError: The device has no langid
Please let me know if there are any workarounds to make pyusb work
without requiring root privilege.
--
Thanks and Regards,
Aurabindo J
------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users

------------------------------------------------------------------------------

Tormod Volden

2016-08-20 16:23:52 UTC

Post by Steven Michalske
Here is a general answer for Linux.
http://unix.stackexchange.com/questions/44308/understanding-udev-rules-and-permissions-in-libusb

IMHO that link doesn't have the greatest answer (or question).
Probably the asking user failed to use group permission because he
didn't log out and in again after adding the user to the groups. I
think group permissions are superior to just letting any user (or
process) full access to the device. I'd recommend something like this:

# Example udev rules (usually placed in /etc/udev/rules.d)
# Makes given device writeable for the "plugdev" group
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0483",
ATTRS{idProduct}=="df11", MODE="664", GROUP="plugdev"

Post by Steven Michalske

Post by Jay Aurabind
I am a user of pyOCD, and I am having an issue related to pyusb which
is what the former uses for talking to the USB device. The situation
is that I need to use pyOCD through an eclipse plugin. Eclipse
launches pyocd-gdbserver and normal user. But it will only work if
launched as root.
ValueError: The device has no langid

The missing langid here looks like https://github.com/walac/pyusb/issues/139

I don't know if this is something wrong about langid (in the device or
software) or if it is just that requesting langid is the first
operation requiring full access to the device. The last comment there
about specifying langid hints to the former option.

Regards,
Tormod

------------------------------------------------------------------------------

Jay Aurabind

2016-08-22 06:19:53 UTC

Post by Steven Michalske
Here is a general answer for Linux.
http://unix.stackexchange.com/questions/44308/understanding-udev-rules-and-permissions-in-libusb

IMHO that link doesn't have the greatest answer (or question).
Probably the asking user failed to use group permission because he
didn't log out and in again after adding the user to the groups. I
think group permissions are superior to just letting any user (or
# Example udev rules (usually placed in /etc/udev/rules.d)
# Makes given device writeable for the "plugdev" group
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0483",
ATTRS{idProduct}=="df11", MODE="664", GROUP="plugdev"

Post by Steven Michalske

The missing langid here looks like https://github.com/walac/pyusb/issues/139
I don't know if this is something wrong about langid (in the device or
software) or if it is just that requesting langid is the first
operation requiring full access to the device. The last comment there
about specifying langid hints to the former option.
Regards,
Tormod
------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users

Hi Tormod and Steve,

Thanks for your responses. I tried running the pyocd-gdbserver with
LIBUSB_DEBUG=9, and got the following[snipped]:

libusb: debug [libusb_open] open 2.1
libusb: error [_get_usbfs_fd] libusb couldn't open USB device
/dev/bus/usb/002/001: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
libusb: debug [libusb_open] open 2.1 returns -3
uncaught exception: The device has no langid
Traceback (most recent call last):

The device 1 on bus 2, is actually the root hub - the output of lsusb
-v -s2:1 is:

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.06
iManufacturer 3 Linux 4.6.6-300.fc24.x86_64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1

But even after adding the following rule to udev, I am still getting
the permission error:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1d6b",
ATTRS{idProduct}=="0003", MODE="0666", GROUP="plugdev"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0d28",
ATTRS{idProduct}=="0204", MODE="0666", GROUP="plugdev"

I tried with both with and without GROUP="plugdev" because the group
didnt really exist in my (Fedora 24) distro. Although I created the
group and added myself to it, and rebooted.

--
Thanks and Regards,
Aurabindo J

------------------------------------------------------------------------------

Tormod Volden

2016-08-22 20:48:28 UTC

Post by Jay Aurabind
Hi Tormod and Steve,
Thanks for your responses. I tried running the pyocd-gdbserver with
libusb: debug [libusb_open] open 2.1
libusb: error [_get_usbfs_fd] libusb couldn't open USB device
/dev/bus/usb/002/001: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
libusb: debug [libusb_open] open 2.1 returns -3
uncaught exception: The device has no langid
The device 1 on bus 2, is actually the root hub - the output of lsusb

I am a bit confused here, did you really want to manipulate the root
hub with pyusb, or did something go wrong here?

Post by Jay Aurabind
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.06
iManufacturer 3 Linux 4.6.6-300.fc24.x86_64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1

(Obviously the underlying hardware was not made by the Linux
Foundation, the kernel usb stack just presents the root hub like it
would be yet another USB device.)

A "device" like this will be grabbed by the kernel (ehci_hcd driver).
More generally it can happen per USB interface of the device and each
can be claimed by its own driver.

The same would be the case for e.g. a USB mass storage device. The
relevant kernel driver will grab it exclusively, and you won't get
permissions to write to it, whatever the file permissions on the
corresponding USB device node.

Some devices can be released from the kernel, and then be available
for you to manipulate it through the device node (and thus via e.g
libusb and pyusb). See for instance the libusb_detach_kernel_driver()
function in libusb. However, in most cases people use libusb and pyusb
to access devices that have no kernel driver.

Post by Jay Aurabind
But even after adding the following rule to udev, I am still getting
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="1d6b",
ATTRS{idProduct}=="0003", MODE="0666", GROUP="plugdev"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0d28",
ATTRS{idProduct}=="0204", MODE="0666", GROUP="plugdev"
I tried with both with and without GROUP="plugdev" because the group
didnt really exist in my (Fedora 24) distro. Although I created the
group and added myself to it, and rebooted.

(You can of course use any group that you are member of.)

Regards,
Tormod

------------------------------------------------------------------------------

Jay Aurabind

2016-08-23 06:31:33 UTC

I am a bit confused here, did you really want to manipulate the root
hub with pyusb, or did something go wrong here?

Absolutely not, only reason I wanted to try giving write permission to
that device, which happens to be the root hub was because that's the
only permission error I see in the LIBUSB debug messages, as you can
see from the logs I showed. If I run pyusb as root, I do not see those
permission errors.

I suspect that pyusb reads certain data commonly for all available
devices, may to figure out whether that is really the device it needs
to work on ?

(Obviously the underlying hardware was not made by the Linux
Foundation, the kernel usb stack just presents the root hub like it
would be yet another USB device.)
A "device" like this will be grabbed by the kernel (ehci_hcd driver).
More generally it can happen per USB interface of the device and each
can be claimed by its own driver.
The same would be the case for e.g. a USB mass storage device. The
relevant kernel driver will grab it exclusively, and you won't get
permissions to write to it, whatever the file permissions on the
corresponding USB device node.
Some devices can be released from the kernel, and then be available
for you to manipulate it through the device node (and thus via e.g
libusb and pyusb). See for instance the libusb_detach_kernel_driver()
function in libusb. However, in most cases people use libusb and pyusb
to access devices that have no kernel driver.

In that case, even the root should not be able to write to those
devices, since its exclusively managed by kernel. Then how come I get
no errors when I run pyocd with root permissions ?

(You can of course use any group that you are member of.)
Regards,
Tormod
------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users

--
Thanks and Regards,
Aurabindo J

------------------------------------------------------------------------------

Tormod Volden

2016-08-23 11:10:44 UTC

Post by Tormod Volden
I am a bit confused here, did you really want to manipulate the root
hub with pyusb, or did something go wrong here?

OK, I see.

Post by Jay Aurabind
I suspect that pyusb reads certain data commonly for all available
devices, may to figure out whether that is really the device it needs
to work on ?

It usually shouldn't try to retrieve descriptor strings from other
devices than the ones targeted. The device descriptor (retrieved and
cached by the OS) is usually enough to filter out the right devices
(e.g. filtering on vid/pid). How are the devices filtered in your
program?

Post by Tormod Volden
Some devices can be released from the kernel, and then be available
for you to manipulate it through the device node (and thus via e.g
libusb and pyusb). See for instance the libusb_detach_kernel_driver()
function in libusb. However, in most cases people use libusb and pyusb
to access devices that have no kernel driver.

In that case, even the root should not be able to write to those
devices, since its exclusively managed by kernel. Then how come I get
no errors when I run pyocd with root permissions ?

You won't be able to claim any of its interfaces, but I suppose some
control transfers are still allowed.

Tormod

------------------------------------------------------------------------------

Jay Aurabind

2016-08-23 13:02:08 UTC

Post by Tormod Volden
I am a bit confused here, did you really want to manipulate the root
hub with pyusb, or did something go wrong here?

OK, I see.

Post by Jay Aurabind
I suspect that pyusb reads certain data commonly for all available
devices, may to figure out whether that is really the device it needs
to work on ?

Here is the code which creates the error:

all_devices = usb.core.find(find_all=True)

if not all_devices:
logging.debug("No device connected")
return []

boards = []

# iterate on all devices found
for board in all_devices:
interface_number = -1
try:
# The product string is read over USB when accessed.
# This can cause an exception to be thrown if the device
# is malfunctioning.
product = board.product

This is how pyusb is used. The program doesn't go beyond the last line
shown above, if run as normal user. See full source github[1].

[1]:https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/pyDAPAccess/interface/pyusb_backend.py#L88

In that case, even the root should not be able to write to those
devices, since its exclusively managed by kernel. Then how come I get
no errors when I run pyocd with root permissions ?

You won't be able to claim any of its interfaces, but I suppose some
control transfers are still allowed.
Tormod
------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
https://lists.sourceforge.net/lists/listinfo/pyusb-users

--
Thanks and Regards,
Aurabindo J

------------------------------------------------------------------------------

Jay Aurabind

2016-08-23 13:05:26 UTC

Post by Tormod Volden
I am a bit confused here, did you really want to manipulate the root
hub with pyusb, or did something go wrong here?

OK, I see.

Post by Jay Aurabind
I suspect that pyusb reads certain data commonly for all available
devices, may to figure out whether that is really the device it needs
to work on ?

all_devices = usb.core.find(find_all=True)
logging.debug("No device connected")
return []
boards = []
# iterate on all devices found
interface_number = -1
# The product string is read over USB when accessed.
# This can cause an exception to be thrown if the device
# is malfunctioning.
product = board.product
This is how pyusb is used. The program doesn't go beyond the last line
shown above, if run as normal user. See full source github[1].
[1]:https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/pyDAPAccess/interface/pyusb_backend.py#L88

I just managed to get it working. Simply added an exception for the
try block for ValueError: continue

Is this an acceptable solution generally? Is there a point in asking
pyOCD to take it ?

In that case, even the root should not be able to write to those
devices, since its exclusively managed by kernel. Then how come I get
no errors when I run pyocd with root permissions ?

--
Thanks and Regards,
Aurabindo J

--
Thanks and Regards,
Aurabindo J

------------------------------------------------------------------------------

Tormod Volden

2016-08-23 15:38:45 UTC

Post by Jay Aurabind
I just managed to get it working. Simply added an exception for the
try block for ValueError: continue
Is this an acceptable solution generally? Is there a point in asking
pyOCD to take it ?

I would try to filter on vid/pid first. Are there many different
vid/pids possible, but they all have "CMSIS-DAP" in the product
string?

IMO manually filtering through the product string is a bad idea, but
if it cannot be avoided, yes, you should an exception for devices
where you can't retrieve the product string.

Try for instance "lsusb -v" versus "sudo lsusb -v" - a normal user
will often not see the product strings listed, whereas the superuser
does.

Regards,
Tormod

------------------------------------------------------------------------------

Jay Aurabind

2016-08-23 16:17:19 UTC

This post might be inappropriate. Click to display it.

Karl Palsson

2016-08-23 17:09:11 UTC

yeah, well, would be good to tell ARM that. A device class or
interface class or anything, but no, by definition, a CMSIS-DAP
device is identified _only_ by the product string containing
"CMSIS-DAP"

Thanks ARM!

Tormod Volden

2016-08-23 15:32:11 UTC

Post by Tormod Volden
It usually shouldn't try to retrieve descriptor strings from other
devices than the ones targeted. The device descriptor (retrieved and
cached by the OS) is usually enough to filter out the right devices
(e.g. filtering on vid/pid). How are the devices filtered in your
program?

There is a grave mismatch between comment and code here:

# find all devices matching the vid/pid specified
all_devices = usb.core.find(find_all=True)

There is nothing in the code that filters on vid/pid.
usb.core.find(find_all=True) will return all devices the OS know of.
Then the code goes on to request the product string from all these
devices... It can be expected that this goes wrong on devices for
which the user has no permissions.

Post by Jay Aurabind
[1]:https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/pyDAPAccess/interface/pyusb_backend.py#L88