Date: Thu, 2 Jul 2020 12:18:02 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: USB reset fails when using a LimeSDR Mini on FreeBSD Message-ID: <8ac365f3-3d33-4730-622e-e66f29dd5938@selasky.org> In-Reply-To: <20200702120655.73d1111e2de81c626be78139@magnetkern.de> References: <20200625121052.e9f7e7cbeb68fad264ec80a9@magnetkern.de> <20200626135151.e5542cf97fad213c4ad661f2@magnetkern.de> <5c0729f9-9e98-52f7-a5cb-6c5dfd2287a3@selasky.org> <20200626172851.872f3a08fa6e632666683230@magnetkern.de> <CAM8r67AF%2BfGiqBr9A0863Za_zR-fG1FxGfNAqEvvafW=wTRmyQ@mail.gmail.com> <20200627144419.f14371695d9b62ea99106c4a@magnetkern.de> <CAM8r67DTKdj0%2BhkOegjBj-ywzWFq2CnS2sQed0mibSUeGp6HSQ@mail.gmail.com> <20200627173604.7f7b7777140e66dbad812fc7@magnetkern.de> <CAM8r67DqZzje=JnrT_R3d6Uo_NxjvGsvpydd1NOTrJHU2jHzQA@mail.gmail.com> <20200627180420.4b8012fb@ernst.home> <20200702103523.adb0566bcc7b6e354905a8a5@magnetkern.de> <97c8fd11-9200-dff7-4c68-b0b80cc44871@selasky.org> <20200702104743.223e98c325806025704703f2@magnetkern.de> <e3bd0417-c89c-5598-448e-33ec1e505a3f@selasky.org> <20200702111538.e7edf0ae8d10ec7ede9acebb@magnetkern.de> <9e14575a-5c8b-28c8-6593-22019a21e7e7@selasky.org> <20200702120655.73d1111e2de81c626be78139@magnetkern.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Jan, On 2020-07-02 12:06, Jan Behrens wrote: > On Thu, 2 Jul 2020 11:23:32 +0200 > Hans Petter Selasky <hps@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8ac365f3-3d33-4730-622e-e66f29dd5938>