USB reset fails when using a LimeSDR Mini on FreeBSD

Hans Petter Selasky hps at selasky.org
Thu Jul 2 10:18:32 UTC 2020


Hi Jan,

On 2020-07-02 12:06, Jan Behrens wrote:
> On Thu, 2 Jul 2020 11:23:32 +0200
> Hans Petter Selasky <hps at selasky.org> wrote:
> 
>> On 2020-07-02 11:15, Jan Behrens wrote:
>>> On Thu, 2 Jul 2020 10:54:27 +0200
>>> Hans Petter Selasky <hps at selasky.org> wrote:
>>>
>>>> On 2020-07-02 10:47, Jan Behrens wrote:
>>>>> But wouldn't both drivers require access to the entries in /dev ?
>>>>
>>>> Yes, user-space drivers would require access to /dev, yes, but kernel
>>>> drivers not, like mouse, keyboard, storage, network.
>>>>
>>>>> Thus not every user could mess with any USB device, or do I get it
>>>>> wrong?
>>>>
>>>> A so-called composite USB device may appear like a USB storage device
>>>> (kernel driver) and a security token (firefox). Firefox can only grab
>>>> the device if you set the proper permissions for /dev of course, but the
>>>> reset device IOCTL then also becomes possible, which is why we currently
>>>> block it for non-root.
>>>>
>>>> --HPS
>>>
>>> Okay, so if I understand it right, the problem is due to devices that
>>> shall be partly accessible by root, and partly by users. Some device
>>> nodes (e.g. /dev/usb/2.2.1 ) while others (e.g. /dev/usr/2.2.2 ) are
>>> limited to root access only. An USB reset always affects all devices
>>> (e.g. also /dev/usb/2.2.2, 2.2.3, etc.), right?
>>
>> Yes, correct.
> 
> Does /dev/usb/2.2.0 (in the given example) represent the device as a
> whole, or is it just another subdevice? (What's the correct term for
> "subdevice" in this context by the way? I assume "interface"?)
> 


> I experienced that /dev/usb/2.2.0 and /dev/usb/2.2.1, 2.2.2, 2.2.3,
> etc. get treated differently when I reset the LimeSDR Mini with
> "usbconfig -u 2 -a 2 reset". The devices 2.2.1 and up are supposingly
> re-created (and have their access rights reset), while the device 2.2.0
> maintains any manually changed access rights.
> 

Let me explain, now you are getting me into dirty details :-)

This device is used for all of LibUSB interfaces and gives access to all 
endpoints:

/dev/usb/X.Y.0

These devices are legacy devices, which allow direct access to the 
endpoint via the shell. They are there to support the old user-space 
model FreeBSD had. And they are re-created when you reset/reconfigure a 
USB device. Actually you can "echo > /dev/usb/X.Y.N" to write directly 
to an endpoint from user-space. But don't do that unless it is a modem 
endpoint which support AT commands for example.

/dev/usb/X.Y.[1..15]

> Is it correct that 2.2.0 identifies the device as a whole?

Yes, this is correct.

>>
>> What do you think?
> 
> I'm not sure if this is (from a semantic point of view) the best thing
> to do. I would say you should only be able to reset a device if you
> have been granted access to the device as a whole (including all
> interfaces/subdevices/whatever), as the reset seems to affect all of
> those.
> 

In FreeBSD and LibUSB there is no such concept. Everything is oriented 
around interfaces. There is a function to claim an interface, but not 
the device itself. (man libusb_claim_interface)

>>
>>>
>>> That sounds better than adding a sysctl option to me. But I assume that
>>> would require a lot of changes in the code?
>>
>> If a simple rule can be formulated, I could implement it in the generic
>> USB kernel code.
>>
>> --HPS
> 
> Regards,
> Jan
> 

--HPS


More information about the freebsd-usb mailing list