USB reset fails when using a LimeSDR Mini on FreeBSD

[Jan Behrens]

Hello Hans,

Thanks for your responses so far, all your work on FreeBSD's USB
support, and helping me to understand the nature of the problem. Also
thanks to Tomek, of course.

Your responses helped me a lot to track down the problem. I have a
couple more questions, see below.

On Thu, 2 Jul 2020 13:05:51 +0200
Hans Petter Selasky <hps at selasky.org> wrote:

> On 2020-07-02 12:37, Jan Behrens wrote:
> > On Thu, 2 Jul 2020 12:18:02 +0200
> > Hans Petter Selasky <hps at selasky.org> wrote:
> > 
> 
> Hi Jan,
> 
> >>> 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]
> > 
> > Are these devices there only for legacy reasons? 
> 
> Yes, and we have one or two firmware loading utilities in base still 
> using them.

Except that /dev/usb/X.Y.0 (which is linked by /dev/ugenX.Y) controls
access rights to the device through libusb, right?

> 
> > Or also for granting
> > access to devices via chown/chmod (or devfs.rules)? I see
> > that /dev/ugenX.Y are symlinks to /dev/usb/X.Y.0
> 
> For LibUSB you only need to chown/chmod /dev/ugenX.Y or /dev/usb/X.Y.0
> 
> The other utilities are usually run as root via devd scripts in base 
> (See /etc/devd) .
> 
> > 
> > I used chown user /dev/usb/2.2.* to get access through libusb (before I
> > set up devfs.rules).
> 
> Technically that is fine too, but you actually only need .0 for LibUSB.
> 
> > 
> >>
> >>> Is it correct that 2.2.0 identifies the device as a whole?
> >>
> >> Yes, this is correct.
> > 
> > Then I suppose if you have access to /dev/ugenX.Y (i.e. /dev/usb/X.Y.
> > 0), you should be allowed to reset a device.
> 
> Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers 
> are detached from this device.

Can/does a kernel device driver restrict what a user can do with the
device when the kernel driver is active? Or does access to the device
always enable a user to mess up things badly?

> 
> >>>>
> >>>> 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 means in order to reset the device itself, I need to claim an
> > interface, e.g. interface 0? But above you said, 2.2.0 identifies the
> > device as a whole (and I noted it is symlinked by /dev/ugen2.2). So I'm
> > a bit confused now. Is /dev/usb/2.2.0 the whole device? Or the
> > interface 0 of the device? Or both... haha
> 
> I think the following  will clear your confusion:
> 
> FreeBSD allows multiple drivers and user-space (LibUSB) to access the 
> same device and USB interface, using same endpoints, at the same time!
> 
> User-space drivers are requested to create a uniq PID file, to avoid 
> clashes with multiple drivers on the same interface and may use 
> libusb_claim_interface() to tell the kernel to detach any drivers on 
> that specific interface.

If the kernel refuses to give up control, is the user-space program
denied access? If yes, I can generally understand why you don't want a
USB reset to be initiated by a user-space program (at least as long
there are kernel drivers attached).

> 
> If you for example load the LimeSDR two times for the same ugenX.Y 
> device, then the interface communication might stop working, even though 
> no error is reported.

Thus the lock of user-space drivers is only advisory and not enforced?
How about if a kernel driver uses the device? Can/does the kernel block
out a user-space driver that would mess with the kernel's operation on
the device?

> 
> Was that clear?

It cleared a lot of questions for me, but some details I still don't
fully overlook, see my questions above.

> 
> --HPS
> 

I see three possible approaches currently:

1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might
   allow users to mess with kernel's operation on a device, unless the
   problem exists anyway, see my questions above).

2. Allowing a USB reset if the user has access to /dev/ugenX.Y and
   there are other prerequirements fulfilled (e.g. a sysctl setting to
   enable it globally, which might not be fine-graded enough, or the
   requirement that there is currently no kernel driver attached, or a
   combination thereof).

3. Providing a way to grant "reset permissions" on a per-device basis
   (might be overkill, and not really needed).


Regards,
Jan