Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Thank you guys for trust and hints, I will be able to get into this around August, sorry, I am a bit overworked at the moment, I have some backlog waiting for FreeBSD already :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Fri, 3 Jul 2020 11:15:01 +0200 Hans Petter Selasky wrote: > Hi, > > On 2020-07-03 11:06, Tomasz CEDRO wrote: > > +1 for user enabled actions like usb reset and kernel driver detach:-) > > maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset > > and usb_allow_user_kernel_driver_detach..? > > > > One would allow user to reset a usb device. This is sometimes required to > > restore device or change its configration. > > > > Second would allow user for example to unload ucom driver that is attached > > to a device which does not seem possible right now and causes problem with > > i.e. pyOCD / some debug probes. > > Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets > PRIV_DRIVER rights. > With a few exceptions it looks like root permissions are required per default. The code is in /usr/src/sys/kern/kern_priv.c. > Tomasz: Feel free to suggest a patch for this after testing. > -- Gary Jennejohn ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 11:15 użytkownik Hans Petter Selasky napisał: > > Second would allow user for example to unload ucom driver that is > attached > > to a device which does not seem possible right now and causes problem > with > > i.e. pyOCD / some debug probes. > > Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets > PRIV_DRIVER rights. > > Tomasz: Feel free to suggest a patch for this after testing. > Thank You HPS :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi, On 2020-07-03 11:06, Tomasz CEDRO wrote: +1 for user enabled actions like usb reset and kernel driver detach:-) maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset and usb_allow_user_kernel_driver_detach..? One would allow user to reset a usb device. This is sometimes required to restore device or change its configration. Second would allow user for example to unload ucom driver that is attached to a device which does not seem possible right now and causes problem with i.e. pyOCD / some debug probes. Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets PRIV_DRIVER rights. Tomasz: Feel free to suggest a patch for this after testing. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 10:10 użytkownik Hans Petter Selasky napisał: > > 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). > > > > Maybe you're right we should allow this for non-root aswell. I need to > think about it! > +1 for user enabled actions like usb reset and kernel driver detach :-) maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset and usb_allow_user_kernel_driver_detach..? One would allow user to reset a usb device. This is sometimes required to restore device or change its configration. Second would allow user for example to unload ucom driver that is attached to a device which does not seem possible right now and causes problem with i.e. pyOCD / some debug probes. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi Jan, On 2020-07-03 09:51, Jan Behrens wrote: 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? Yes, that is correct. 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? The kernel device driver can not restrict what the user-space driver can do. Yes, user-space can mess up the device totally. 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). The FreeBSD USB stack has no concept of exclusive access to USB endpoints. Simply if both kernel and user-space attach to the same device, user-space will receive half of the USB packets and the kernel the other half. 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? Right, it is 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? No, it is all transparent. Kernel drivers cannot block user-space, but user-space can detach kernel-space. That's all. 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). Maybe you're right we should allow this for non-root aswell. I need to think about it! --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
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 wrote: > On 2020-07-02 12:37, Jan Behrens wrote: > > On Thu, 2 Jul 2020 12:18:02 +0200 > > Hans Petter Selasky 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
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-07-02 12:37, Jan Behrens wrote: On Thu, 2 Jul 2020 12:18:02 +0200 Hans Petter Selasky 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. 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. 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 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. Was that clear? --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 2 Jul 2020 12:18:02 +0200 Hans Petter Selasky wrote: > Hi Jan, > > On 2020-07-02 12:06, Jan Behrens wrote: > > On Thu, 2 Jul 2020 11:23:32 +0200 > > Hans Petter Selasky wrote: > > > >> On 2020-07-02 11:15, Jan Behrens wrote: > >>> On Thu, 2 Jul 2020 10:54:27 +0200 > >>> Hans Petter Selasky 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. > > [...] > > > 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? 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 I used chown user /dev/usb/2.2.* to get access through libusb (before I set up devfs.rules). > > > 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. > > >> > >> 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 > [...] Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi Jan, On 2020-07-02 12:06, Jan Behrens wrote: On Thu, 2 Jul 2020 11:23:32 +0200 Hans Petter Selasky wrote: On 2020-07-02 11:15, Jan Behrens wrote: On Thu, 2 Jul 2020 10:54:27 +0200 Hans Petter Selasky 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 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 2 Jul 2020 11:23:32 +0200 Hans Petter Selasky wrote: > On 2020-07-02 11:15, Jan Behrens wrote: > > On Thu, 2 Jul 2020 10:54:27 +0200 > > Hans Petter Selasky 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. Is it correct that 2.2.0 identifies the device as a whole? Or is this just the first/default interface? Is there any node in the /dev filesystem, which semantically refers to the whole hardware device? > > > Disregarding implementation complexity, I'd say that resetting a USB > > device should only be possible if a user has access to all sub-devices > > (or even better to a special device node that represents the device as > > a whole). > > Maybe we can check if any kernel side drivers are attached at the time > of reset device. It might be racy, because kernel drivers can be loaded > and attached at any time. But it will work. > > 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. > > > > > 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 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-07-02 11:15, Jan Behrens wrote: On Thu, 2 Jul 2020 10:54:27 +0200 Hans Petter Selasky 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. Disregarding implementation complexity, I'd say that resetting a USB device should only be possible if a user has access to all sub-devices (or even better to a special device node that represents the device as a whole). Maybe we can check if any kernel side drivers are attached at the time of reset device. It might be racy, because kernel drivers can be loaded and attached at any time. But it will work. What do you think? 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 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 2 Jul 2020 10:54:27 +0200 Hans Petter Selasky 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? Disregarding implementation complexity, I'd say that resetting a USB device should only be possible if a user has access to all sub-devices (or even better to a special device node that represents the device as a whole). That sounds better than adding a sysctl option to me. But I assume that would require a lot of changes in the code? Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
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 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 2 Jul 2020 10:41:42 +0200 Hans Petter Selasky wrote: > On 2020-07-02 10:35, Jan Behrens wrote: > > Thus Linux definitely behaves differently here. My question is: Can > > and/or should FreeBSD be fixed to allow libusb_reset_device() as a user > > or should a driver library be fixed to not use that call. > > This is an architectural problem. USB devices may have interfaces with > independent drivers attached. If one USB interface driver is running as > root and another USB interface driver is running as non-root, it doesn't > make sense that the non-root device driver should be able to affect the > root-one. But wouldn't both drivers require access to the entries in /dev ? Thus not every user could mess with any USB device, or do I get it wrong? > Your LimeSDR device appears to be very simple, having just one > USB device driver attaching to it. Just imagine some web-page trying to > reset your USB device, just because it can! Yes, USB is also exposed to > firefox nowadays :-) My webbrowser runs as different user than the programs that get access to emit radio emissions on my behalf. > > What we could do is to add a sysctl which controls the behaviour for > this specific case. Would that be of any use to you? You mean allowing users to reset USB devices? Only those which the users have access to on the /dev filesystem? Or all devices? > > --HPS > Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-07-02 10:35, Jan Behrens wrote: Thus Linux definitely behaves differently here. My question is: Can and/or should FreeBSD be fixed to allow libusb_reset_device() as a user or should a driver library be fixed to not use that call. This is an architectural problem. USB devices may have interfaces with independent drivers attached. If one USB interface driver is running as root and another USB interface driver is running as non-root, it doesn't make sense that the non-root device driver should be able to affect the root-one. Your LimeSDR device appears to be very simple, having just one USB device driver attaching to it. Just imagine some web-page trying to reset your USB device, just because it can! Yes, USB is also exposed to firefox nowadays :-) What we could do is to add a sysctl which controls the behaviour for this specific case. Would that be of any use to you? --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Sat, 27 Jun 2020 18:04:20 +0200 Gary Jennejohn wrote: > On Sat, 27 Jun 2020 17:53:01 +0200 > Tomasz CEDRO wrote: > > > [...] > > Lookig at the libusb code, libusb_reset_device() only returns an error if > resetting the device fails. Unfortunately it returns -99 (LIBUSB_ERROR_OTHER), which is not very verbose. > > Resetting the device requires making ioctl() calls into the kernel. > > ioctl() calls pretty much always require root permissions. > > -- > Gary Jennejohn I compared the behavior under FreeBSD to GNU/Linux. I could meanwhile confirm that under Linux, the device is reset, even if the executing user is not root. Kernel log using Linux is as follows: [1264819.538395] usb 2-1.1: reset high-speed USB device number 54 using ehci-pci UID was definitely not 0, as stated in my other e-mail: DEBUG: Executing libusb_reset_device() [UID=1000, effective UID=1000] DEBUG: libusb_reset_device() executed successfully. Thus Linux definitely behaves differently here. My question is: Can and/or should FreeBSD be fixed to allow libusb_reset_device() as a user or should a driver library be fixed to not use that call. This issue may also affect other device drivers that run in userspace and might not be limited to the issues with the LimeSDR Mini. The documentation (man page) and return value of libusb_reset_device() does not reflect its (deviant) behavior under FreeBSD (compared to Linux). Kind regards, Jan Behrens ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Sat, 27 Jun 2020 17:36:04 +0200
Jan Behrens wrote:
> On Sat, 27 Jun 2020 16:12:45 +0200
> Tomasz CEDRO wrote:
>
> > I guess the FreeBSD's LibUSB implementation should be one-to-one
> > compatible with the GNU LibUSB.
Unless GNU LibUSB behaves wrong, in which case there'd be a good reason
for FreeBSD's LibUSB to behave differently. But not sure if that's the
case.
> > I would try to test and compare it
> > with Linux and MacOS implementation and see the difference:
> >
> > 1. If the problem exists on FreeBSD, Linux, MacOS. If so/no then if
> > there are different error messages / codes. If there are more verbose
> > codes / messages on systems other than BSD then FreeBSD's
> > implementation may need an update. However, the difference here seems
> > to be the USB stack itself.
As I currently have no Linux installed on my machines, I tested with a
friend how the SoapySDR module for the LimeSDR Mini (SoapyLMS7 from
Lime Suite 20.01.0) behaves on Linux in regard to the
libusb_reset_device() call. This is our result:
We modified LimeSuite-20.01.0/src/ConnectionFTDI/ConnectionFT601.cpp
in the following way:
At the begin of the file:
#include
#include
And then below:
fprintf(stderr, "DEBUG: Executing libusb_reset_device() [UID=%i, effective
UID=%i]\n", getuid(), geteuid());
if (libusb_reset_device(dev_handle)!=0)
return ReportError(-1, "USB reset failed",
libusb_strerror(libusb_error(r)));
fprintf(stderr, "DEBUG: libusb_reset_device() executed successfully.\n");
This resulted in the following output:
$ SoapySDRUtil --make
##
## Soapy SDR -- the SDR abstraction library ##
##
Make device
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
[INFO] Make connection: 'LimeSDR Mini [USB 2.0] 1D3AC7FE409032'
DEBUG: Executing libusb_reset_device() [UID=1000, effective UID=1000]
DEBUG: libusb_reset_device() executed successfully.
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 40 MHz
[INFO] LMS7002M register cache: Disabled
driver=FT601
hardware=LimeSDR-Mini
boardSerialNumber=0x1d3ac7fe409032
firmwareVersion=6
gatewareVersion=1.30
hardwareVersion=1
protocolVersion=1
Thus libusb_reset_device() returns without an error on GNU/Linux,
despite being executed as user (UID and EUID = 1000).
This proves that on Linux there is no problem in executing the call as
non-root. The problem appears on FreeBSD only.
> >
> > 2. If that function blocks normal operations on FreeBSD while without
> > it everything works fine, then it may be wrapped around ifdef and
> > simply removed for FreeBSD.
Whether the libusb_reset_device() call is needed or not isn't clear to
me. It *appears* to work without the call, but I'm not sure if there
are side effects or corner cases.
The context of the call is as follows:
[...] libusb_open(devs[i], &dev_handle) [...];
if(libusb_kernel_driver_active(dev_handle, 1) == 1) //find out if kernel
driver is attached
{
lime::debug("Kernel Driver Active");
if(libusb_detach_kernel_driver(dev_handle, 1) == 0) //detach it
lime::debug("Kernel Driver Detached!");
}
int r = libusb_claim_interface(dev_handle, 0); //claim interface 0 (the
first) of device
if (r < 0)
return ReportError(-1, "Cannot claim interface - %s",
libusb_strerror(libusb_error(r)));
if ((r = libusb_claim_interface(dev_handle, 1))<0) //claim interface 1 of
device
return ReportError(-1, "Cannot claim interface - %s",
libusb_strerror(libusb_error(r)));
lime::debug("Claimed Interface");
if (libusb_reset_device(dev_handle)!=0)
return ReportError(-1, "USB reset failed",
libusb_strerror(libusb_error(r)));
FT_FlushPipe(ctrlRdEp); //clear ctrl ep rx buffer
FT_SetStreamPipe(ctrlRdEp,64);
FT_SetStreamPipe(ctrlWrEp,64);
isConnected = true;
return 0;
See:
https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b6f3f576f7f8e74c7f1/src/ConnectionFTDI/ConnectionFT601.cpp#L160
> >
> > 3. Make sure this is not a bug in the LimeSDR firmware that makes this
> > non-standard behaviour.
As shown above, no problem on Linux.
It might still be wrong to call libusb_reset_device(), but for that we'd
need to understand why it's called and if it's generally a bad practice
to call it as driver that runs as non-root (and if there are
alternatives or if it's just not necessary to do the call).
> >
> > 4. According to `man usbconfig` reset will perform "Reset the device.
> > This forces the USB stack to reenumerate the bus.". If LimeSDR uses
> > some dynamic USB interfaces configuration and re-organizes itself at
> > runtime then I would observe how the FreeBSD USB stack reacts to that
> > changes. Such reset may not be even necessary by hand (or from libusb)
> > if the OS re-enumerates the bus for you. Maybe on other OS it is
> >
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Sat, 27 Jun 2020 17:53:01 +0200 Tomasz CEDRO wrote: > Another idea: are you sure you are using valid usb cable and capable usb > port? Please try with another short length certified cable and use direct > usb 3.0 port with no usb hub. Cables and HUBs (even those built-in) are the > most common problem :-) > Lookig at the libusb code, libusb_reset_device() only returns an error if resetting the device fails. Resetting the device requires making ioctl() calls into the kernel. ioctl() calls pretty much always require root permissions. -- Gary Jennejohn ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Another idea: are you sure you are using valid usb cable and capable usb port? Please try with another short length certified cable and use direct usb 3.0 port with no usb hub. Cables and HUBs (even those built-in) are the most common problem :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Sat, 27 Jun 2020 16:12:45 +0200 Tomasz CEDRO wrote: > I guess the FreeBSD's LibUSB implementation should be one-to-one > compatible with the GNU LibUSB. I would try to test and compare it > with Linux and MacOS implementation and see the difference: > > 1. If the problem exists on FreeBSD, Linux, MacOS. If so/no then if > there are different error messages / codes. If there are more verbose > codes / messages on systems other than BSD then FreeBSD's > implementation may need an update. However, the difference here seems > to be the USB stack itself. > > 2. If that function blocks normal operations on FreeBSD while without > it everything works fine, then it may be wrapped around ifdef and > simply removed for FreeBSD. > > 3. Make sure this is not a bug in the LimeSDR firmware that makes this > non-standard behaviour. > > 4. According to `man usbconfig` reset will perform "Reset the device. > This forces the USB stack to reenumerate the bus.". If LimeSDR uses > some dynamic USB interfaces configuration and re-organizes itself at > runtime then I would observe how the FreeBSD USB stack reacts to that > changes. Such reset may not be even necessary by hand (or from libusb) > if the OS re-enumerates the bus for you. Maybe on other OS it is > important to call that libusb reset to make sure the bus is > re-enumerated. > > @HPS is the author of the USB stack so he could provide some hints.. > but without actually seeing the device it can be hard to achieve :-) > > > > > When in trouble always try to test at root especially when working with > > > hardware. That may pinpoint the permissions issuses (not only /dev/usb* > > > permissions). > > > > You are right, of course. As "chown user /dev/usb/2.2.*" made a > > difference (and there wasn't any hint about a privilege problem), I > > wrongly assumed that it was not a privilege problem. I'll know better > > next time. > > > > Another question that I still have no clear answer to is: Is it > > semantically correct to use libusb_reset_device() in the Lime Suite > > driver for SoapySDR. The driver runs in the context of user > > applications which likely have no root privileges (for a good reason). > > I also don't know yet why this library call is made in the driver, and > > which purpose it has. See also my most recent post on the myriadrf.org > > discussion forum: > > > > https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/8 > > > > I wrote: > > > > "I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure > > libusb_reset_device() can be run as non-root user, or if the Lime Suite > > should be fixed to not call libusb_reset_device() at all because it > > might be an administrative call that should never be used by a user of > > a USB device. I’m not sure what’s right to do. Particularly, I don’t > > know why the Lime Suite developers included that call, and I don’t even > > fully understand (yet) what it does." > > /dev/usb* are userland "access points" to the USB devices. They may be > accessed by the user according to the filesystem permissions. Some > stack level operations on the USB bus/port/hub may only be accessible > to the root user. > > Are you sure this is the problem? When run as root does the program > works fine? If so, there may be a systctl setting for the stack that > may allow user to reset / power-on-off the port (@HPS?)? You may want > to take a look at `sysctl -a | grep usb` to search for such sysctl > option. Maybe also `man usbconfig` and `man usb`. I haven't done a full analysis of the behavior with root privileges (or with a commented out libusb_reset_device call) yet. What I did is the following: 1. Comment out the libusb_reset_device(dev_handle) call in LimeSuite-20.01.0/src/ConnectionFTDI/ConnectionFT601.cpp 2. Compile and install the SoapyLMS7 module of Lime Suite (other parts of Lime Suite will fail to compile, which is a different issue but not required to fix to get the SoapySDR library to work) 3. Use a small C program to setup the LimeSDR Mini and record an I/Q stream to a file. (For those who are not familiar with the term "I/Q-Stream", it's raw sample data recording a radio band around a given center frequency, e.g. 145 MHz plus/minus 1 MHz using complex-valued samples representing in-phase and quadrature components.) I used a walkie talkie to do a test transmission in FM and I could later decode that FM transmission from the I/Q stream (using gqrx with that I/Q file as input). Unfortunately, the gqrx package in FreeBSD doesn't come with Soapy support, so I cannot use gqrx on FreeBSD to access the LimeSDR Mini directly (even with the SoapySDR driver working). Instead, I had to record the I/Q-Stream with my C program and later feed it into gqrx. Improving FreeBSD's packages to support SoapySDR and the Lime Suite is a different issue though, which I'd like to see solved and where I'd also be happy to help. However, I have no experiences in creating packages for FreeBSD yet
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Sat, Jun 27, 2020 at 2:44 PM Jan Behrens wrote: > The question is: Is it correct or wise to return an error status of -99 > (LIBUSB_ERROR_OTHER) when the function is called as non-root? Maybe > it's possible to return a more fitting error code? Also note that the > debug level was set to 3, and there was still no hint written to stderr > about any privilege problem: > > #if LIBUSBX_API_VERSION < 0x01000106 > libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the > documentation > #else > libusb_set_option(ctx, LIBUSB_OPTION_LOG_LEVEL, 3); //set verbosity level > to 3, as suggested in the documentation > #endif > > Source: > https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b6f3f576f7f8e74c7f1/src/ConnectionFTDI/ConnectionFT601Entry.cpp#L40 I guess the FreeBSD's LibUSB implementation should be one-to-one compatible with the GNU LibUSB. I would try to test and compare it with Linux and MacOS implementation and see the difference: 1. If the problem exists on FreeBSD, Linux, MacOS. If so/no then if there are different error messages / codes. If there are more verbose codes / messages on systems other than BSD then FreeBSD's implementation may need an update. However, the difference here seems to be the USB stack itself. 2. If that function blocks normal operations on FreeBSD while without it everything works fine, then it may be wrapped around ifdef and simply removed for FreeBSD. 3. Make sure this is not a bug in the LimeSDR firmware that makes this non-standard behaviour. 4. According to `man usbconfig` reset will perform "Reset the device. This forces the USB stack to reenumerate the bus.". If LimeSDR uses some dynamic USB interfaces configuration and re-organizes itself at runtime then I would observe how the FreeBSD USB stack reacts to that changes. Such reset may not be even necessary by hand (or from libusb) if the OS re-enumerates the bus for you. Maybe on other OS it is important to call that libusb reset to make sure the bus is re-enumerated. @HPS is the author of the USB stack so he could provide some hints.. but without actually seeing the device it can be hard to achieve :-) > > When in trouble always try to test at root especially when working with > > hardware. That may pinpoint the permissions issuses (not only /dev/usb* > > permissions). > > You are right, of course. As "chown user /dev/usb/2.2.*" made a > difference (and there wasn't any hint about a privilege problem), I > wrongly assumed that it was not a privilege problem. I'll know better > next time. > > Another question that I still have no clear answer to is: Is it > semantically correct to use libusb_reset_device() in the Lime Suite > driver for SoapySDR. The driver runs in the context of user > applications which likely have no root privileges (for a good reason). > I also don't know yet why this library call is made in the driver, and > which purpose it has. See also my most recent post on the myriadrf.org > discussion forum: > > https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/8 > > I wrote: > > "I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure > libusb_reset_device() can be run as non-root user, or if the Lime Suite > should be fixed to not call libusb_reset_device() at all because it > might be an administrative call that should never be used by a user of > a USB device. I’m not sure what’s right to do. Particularly, I don’t > know why the Lime Suite developers included that call, and I don’t even > fully understand (yet) what it does." /dev/usb* are userland "access points" to the USB devices. They may be accessed by the user according to the filesystem permissions. Some stack level operations on the USB bus/port/hub may only be accessible to the root user. Are you sure this is the problem? When run as root does the program works fine? If so, there may be a systctl setting for the stack that may allow user to reset / power-on-off the port (@HPS?)? You may want to take a look at `sysctl -a | grep usb` to search for such sysctl option. Maybe also `man usbconfig` and `man usb`. > > > What I don't understand is that the Lime Suite SoapySDR module seems to > > > work fine on Linux and other operating systems but makes trouble with > > > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > > > fails if called as non-root? Again, if you are sure that this is the problem, there may be a sysctl that could set USB stack to allow non-root users to reset / power-off-on the ports - @HPS can you give a hint please? :-) > > Linux as well as other operating systems usually uses dirty and quick > > hacks. FreeBSD treats standards seriously and usually does not have these > > kind of dirty hacks. This is the first difference. Second difference is > > that FreeBSD has its own implementation of LibUSB. There may be a problem > > here bu that would require detailed investigation and proofs. Very nice > > exercise to perform :- > > I also
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Fri, 26 Jun 2020 17:56:14 +0200 Tomasz CEDRO wrote: > pt., 26 cze 2020, 17:28 użytkownik Jan Behrens > napisał: > > > Does this mean that depending on the device, it will either be a > > no-operation or a re-enumeration, and in the latter case, root > > privileges are required, otherwise not? > > > > Or did you mean that if you are non-root, it will/should always be a > > no-operation? > > > > I guess that root is required for some administrative operations like port > reset etc that are not really possible to achieve even through /dev/usb* > permissions. The question is: Is it correct or wise to return an error status of -99 (LIBUSB_ERROR_OTHER) when the function is called as non-root? Maybe it's possible to return a more fitting error code? Also note that the debug level was set to 3, and there was still no hint written to stderr about any privilege problem: #if LIBUSBX_API_VERSION < 0x01000106 libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the documentation #else libusb_set_option(ctx, LIBUSB_OPTION_LOG_LEVEL, 3); //set verbosity level to 3, as suggested in the documentation #endif Source: https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b6f3f576f7f8e74c7f1/src/ConnectionFTDI/ConnectionFT601Entry.cpp#L40 > > When in trouble always try to test at root especially when working with > hardware. That may pinpoint the permissions issuses (not only /dev/usb* > permissions). You are right, of course. As "chown user /dev/usb/2.2.*" made a difference (and there wasn't any hint about a privilege problem), I wrongly assumed that it was not a privilege problem. I'll know better next time. Another question that I still have no clear answer to is: Is it semantically correct to use libusb_reset_device() in the Lime Suite driver for SoapySDR. The driver runs in the context of user applications which likely have no root privileges (for a good reason). I also don't know yet why this library call is made in the driver, and which purpose it has. See also my most recent post on the myriadrf.org discussion forum: https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/8 I wrote: "I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure libusb_reset_device() can be run as non-root user, or if the Lime Suite should be fixed to not call libusb_reset_device() at all because it might be an administrative call that should never be used by a user of a USB device. I’m not sure what’s right to do. Particularly, I don’t know why the Lime Suite developers included that call, and I don’t even fully understand (yet) what it does." > > > What I don't understand is that the Lime Suite SoapySDR module seems to > > work fine on Linux and other operating systems but makes trouble with > > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > > fails if called as non-root? > > > > Linux as well as other operating systems usually uses dirty and quick > hacks. FreeBSD treats standards seriously and usually does not have these > kind of dirty hacks. This is the first difference. Second difference is > that FreeBSD has its own implementation of LibUSB. There may be a problem > here bu that would require detailed investigation and proofs. Very nice > exercise to perform :- I also prefer to have things implemented cleanly instead of fixing problems in the wrong place with dirty methods. That is why I would like to understand if calling libusb_reset_device() is semantically correct or a wrong thing to do in the LimeSDR (Mini) driver. > > > I could give recommendation to the Lime Suite developers to remove the > > libusb_reset_device() call on FreeBSD systems if it is not neccessary. > > However, I would like to understand why it is called and what's its > > usual purpose, and if there are side effects when removing the call, or > > whether the call should/could be replaced by a different call that > > "only" requires device privileges. Also: Why does this work on Linux > > but fails on FreeBSD? Is the API differently defined? > > > Very good approach to understand what is the problem and fix it rarher than > using dirty hacks just to make things work :-) > > What particular LimeSDR device do you have? Is it expensive? Can you share > a spare one for testing? Can you acquire access to hardware USB sniffer? The device I have here for testing isn't mine, so it would be difficult to mail it. It is the "LimeSDR Mini". I asked on the myriadrf.org Forum if the manufacturer could provide a free sample for testing. If that doesn't work, I could also ask friends, but eventually I want to get one (or two) for myself anyway. The LimeSDR and LimeSDR Mini seem to have better electrical/radio characteristics than other available devices. Compared to the Pluto SDR, the LimeSDR (Mini) comes with better frequency stability out of the box, i.e. doesn't need to be modded. The LimeSDR also works on lower frequency bands while the Pluto SDR does not. For my pur
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 26 cze 2020, 17:28 użytkownik Jan Behrens napisał: > Does this mean that depending on the device, it will either be a > no-operation or a re-enumeration, and in the latter case, root > privileges are required, otherwise not? > > Or did you mean that if you are non-root, it will/should always be a > no-operation? > I guess that root is required for some administrative operations like port reset etc that are not really possible to achieve even through /dev/usb* permissions. When in trouble always try to test at root especially when working with hardware. That may pinpoint the permissions issuses (not only /dev/usb* permissions). What I don't understand is that the Lime Suite SoapySDR module seems to > work fine on Linux and other operating systems but makes trouble with > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > fails if called as non-root? > Linux as well as other operating systems usually uses dirty and quick hacks. FreeBSD treats standards seriously and usually does not have these kind of dirty hacks. This is the first difference. Second difference is that FreeBSD has its own implementation of LibUSB. There may be a problem here bu that would require detailed investigation and proofs. Very nice exercise to perform :- I could give recommendation to the Lime Suite developers to remove the > libusb_reset_device() call on FreeBSD systems if it is not neccessary. > However, I would like to understand why it is called and what's its > usual purpose, and if there are side effects when removing the call, or > whether the call should/could be replaced by a different call that > "only" requires device privileges. Also: Why does this work on Linux > but fails on FreeBSD? Is the API differently defined? Very good approach to understand what is the problem and fix it rarher than using dirty hacks just to make things work :-) What particular LimeSDR device do you have? Is it expensive? Can you share a spare one for testing? Can you acquire access to hardware USB sniffer? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Fri, 26 Jun 2020 14:47:13 +0200 Hans Petter Selasky wrote: > Hi, > > On 2020-06-26 13:51, Jan Behrens wrote: > > I made the discovery that running the library as root works just fine! > > The libusb_reset_device() function needs root permissions! This is > expected. There are specific checks in the kernel for this. I might have misunderstood your earlier post: On Thu, 25 Jun 2020 20:16:14 +0200 Hans Petter Selasky wrote: > Unless the device requires it, libusb_reset_device(), will only > re-enumerate the device. Beware that this only is allowed if you are > running the application as root. Else libusb_reset_device() will be a > no-operation. > > --HPS Does this mean that depending on the device, it will either be a no-operation or a re-enumeration, and in the latter case, root privileges are required, otherwise not? Or did you mean that if you are non-root, it will/should always be a no-operation? What I don't understand is that the Lime Suite SoapySDR module seems to work fine on Linux and other operating systems but makes trouble with FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() fails if called as non-root? > Can you run this app as root, and then change to non-root after > libusb_reset_device() has been executed? > > --HPS It's not really practical. I'd have to patch every program using the module. But maybe libusb_reset_device() isn't necessary to call? I could give recommendation to the Lime Suite developers to remove the libusb_reset_device() call on FreeBSD systems if it is not neccessary. However, I would like to understand why it is called and what's its usual purpose, and if there are side effects when removing the call, or whether the call should/could be replaced by a different call that "only" requires device privileges. Also: Why does this work on Linux but fails on FreeBSD? Is the API differently defined? Sorry for my confusion, I'm really not experienced with USB programming. Regards, Jan Behrens ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi, On 2020-06-26 13:51, Jan Behrens wrote: I made the discovery that running the library as root works just fine! The libusb_reset_device() function needs root permissions! This is expected. There are specific checks in the kernel for this. Can you run this app as root, and then change to non-root after libusb_reset_device() has been executed? --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Fri, 26 Jun 2020 10:58:20 +0200
Hans Petter Selasky wrote:
> USB_ERR_IOERROR:
Where did you get this error code from? I checked the error code
returned in my case by modifying the source of the Lime Suite:
{
int status = libusb_reset_device(dev_handle);
fprintf(stderr, "DEBUG status: %i\n", status);
if (libusb_reset_device(dev_handle)!=0)
return ReportError(-1, "USB reset failed",
libusb_strerror(libusb_error(r)));
}
I got:
DEBUG status: -99
Checking with libusb source, this seems to be LIBUSB_ERROR_OTHER:
https://github.com/libusb/libusb/blob/e782eeb2514266f6738e242cdcb18e3ae1ed06fa/libusb/libusb.h#L1098
I figured out this error might (amongst other reasons) also be raised
when there is an EACCES system error.
As my /dev/usb/2.2.* devices were all owned by my user (using chown)
and their ownership was not reset during testing, I tested what happens
if I run the library calls with root privileges.
I made the discovery that running the library as root works just fine!
So maybe the problem is that calling libusb_reset_device attempts to
recreate the /dev entries and has insufficient privileges? (Even though
access rights for the individual files are granted.)
Adding the entries Tomek (CeDeROM) proposed for granting privileges to
the operator group (and being member of the group) didn't help either.
>
> This error code is carefully chosen to indicate that the USB device did
> not respond at all to the USB set address command, which is mandatory to
> implement. Likely the USB firmware on the device is not up and running,
> or there is a timing issue or bug in the firmware.
>
> --HPS
Nonetheless, there might be timing issues. In addition to the error
returned by libusb_reset_device, I get a lot of:
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
[...]
See also my original post on the myriadrf.org Forum, with a full error
output:
https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230
Regards,
Jan Behrens
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
I have the USB sniffer hardware. If problem persists I can buy this LimeSDR and take some dumps from the wire. USB can also get sniffed in software on FreeBSD but this would not help here I guess. Just let me know when all other ways fail :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
USB_ERR_IOERROR: This error code is carefully chosen to indicate that the USB device did not respond at all to the USB set address command, which is mandatory to implement. Likely the USB firmware on the device is not up and running, or there is a timing issue or bug in the firmware. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-06-26 09:37, Jan Behrens wrote: 2. Does the bugfix below, which seemed to fix issues with LimeSDR on macOS, relate to a bug that is existent in FreeBSD's libusb as well? Is it just a coincidence and two unrelated issues? Or is there a problem with libusb that has been fixed for macOS but not for FreeBSD? From what I can see, the FreeBSD kernel already does set configuration (index 0) by default after a USB device reset, which the MacOS patch seems to be about. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi, On 2020-06-26 09:37, Jan Behrens wrote: 1. Are there (intended or accidental/unwanted) API and/or behaviour differences between Linux/macOS's libusb. Are there certain considerations when building apps that use libusb? Is it wrong to call libusb_reset_device() in a driver? If yes, why? If no, what is the function used for? Some devices are only tested using Windows, and I know that timing may affect how libusb_reset_device() works. My guess is that libusb_reset_device() should only be used in the case you've uploaded new firmware to the device, and that USB stack on the device has been rebooted. In FreeBSD there are a bunch of sysctl's which affect the libusb reset device behaviour: hw.usb.timings.extra_power_up_time: 20 hw.usb.timings.resume_recovery: 50 hw.usb.timings.resume_wait: 50 hw.usb.timings.resume_delay: 250 hw.usb.timings.set_address_settle: 10 hw.usb.timings.port_resume_delay: 40 hw.usb.timings.port_powerup_delay: 300 hw.usb.timings.port_reset_recovery: 250 hw.usb.timings.port_root_reset_delay: 200 hw.usb.timings.port_reset_delay: 50 In order to figure out exactly what is wrong, you need to have a USB analyzer, capturing all USB communications on the USB cable. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-06-26 09:37, Jan Behrens wrote: I am confused what libusb_reset_device() does, but whether I'm having root privileges or not, I doubt it should return an error for a device which runs well under Linux and/or macOS. Try using usbconfig, before loading the driver: usbconfig -d X.Y reset Also try using a 12-stable kernel. This issue might already be fixed! --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Dear all, I doubt that it is a coincidence that the LimeSDR Mini had the same problem with macOS's libusb, but I may be wrong. For macOS the problem has been solved, for FreeBSD it hasn't. I am confused what libusb_reset_device() does, but whether I'm having root privileges or not, I doubt it should return an error for a device which runs well under Linux and/or macOS. On the discussion forum on myriadrf.org, the question was rised if there are any special considerations to take when using FreeBSD's libusb. I would like to repeat that question here: 1. Are there (intended or accidental/unwanted) API and/or behaviour differences between Linux/macOS's libusb. Are there certain considerations when building apps that use libusb? Is it wrong to call libusb_reset_device() in a driver? If yes, why? If no, what is the function used for? See also: https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/2 I also would like to ask: 2. Does the bugfix below, which seemed to fix issues with LimeSDR on macOS, relate to a bug that is existent in FreeBSD's libusb as well? Is it just a coincidence and two unrelated issues? Or is there a problem with libusb that has been fixed for macOS but not for FreeBSD? https://github.com/libusb/libusb/commit/a0b5d27fa7f2bba11965e2b70533f925a5772808 See quoted message below for more links regarding this issue. Any help would appreciated. I understand far too little about libusb to solve the problem on my own. It would be really nice if either the Lime Suite or the libusb could be modified such that the LimeSDR Mini, which is an awesome radio device, works properly on FreeBSD (and I'm not forced to use Linux or Windows for it). Regards, Jan Behrens On Thu, 25 Jun 2020 19:59:43 +0200 Jan Behrens wrote: > On Thu, 25 Jun 2020 12:10:52 +0200 > Jan Behrens wrote: > > > I'd like to use a software defined radio "LimeSDR Mini" on FreeBSD > > utilizing the "SoapySDR library" with a driver from "Lime Suite", but I > > encounter errors, supposedly in libusb. > > Maybe the same problem occured in MacOS's libusb. Compare the following > posts: > > https://github.com/myriadrf/LimeSuite/issues/253 > > https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/7 > > In both cases there is an issue when calling the libusb_reset_device() > function. > > The problem on MacOS seems to have been fixed according to this post: > > https://github.com/myriadrf/LimeSuite/issues/253#issuecomment-480263517 > > Look at the following patch: > > https://github.com/libusb/libusb/commit/a0b5d27fa7f2bba11965e2b70533f925a5772808 > > The patch seems to be darwin-specific. Is the same bug affecting > FreeBSD or is this a different issue? Can the problem be solved for > FreeBSD as well? > > > Kind Regards, > Jan Behrens ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 25 Jun 2020 22:25:30 +0200 CeDeROM wrote: > How about usbconfig and power off then power on.. or reset via usbconfig? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info Do you mean I should test how the device behaves? Reset via usbconfig (as root) doesn't seem to have any effect, at least nothing shows up in dmesg. If I do usbconfig power_off, then the device stops blinking. When I executed usbconfig power_on, I got this: usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR It didn't seem to be always reproducible though. Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
How about usbconfig and power off then power on.. or reset via usbconfig? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 25 Jun 2020 20:16:14 +0200 Hans Petter Selasky wrote: > Hi, > > > On 2020-06-25 19:59, Jan Behrens wrote: > > In both cases there is an issue when calling the libusb_reset_device() > > function. > > Unless the device requires it, libusb_reset_device(), will only > re-enumerate the device. Beware that this only is allowed if you are > running the application as root. Else libusb_reset_device() will be a > no-operation. But in my case, the call causes the program to abort (due to returning an error status, I assume). This is the context where the SoapySDR driver calls libusb_reset_device(): https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b6f3f576f7f8e74c7f1/src/ConnectionFTDI/ConnectionFT601.cpp#L212 > > --HPS > Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-06-25 20:08, Jan Behrens wrote: Yes, I manually gave me access by using chown after plugging the device in. libusb_reset may reset-these permissions ! --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hi, On 2020-06-25 19:59, Jan Behrens wrote: In both cases there is an issue when calling the libusb_reset_device() function. Unless the device requires it, libusb_reset_device(), will only re-enumerate the device. Beware that this only is allowed if you are running the application as root. Else libusb_reset_device() will be a no-operation. --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 25 Jun 2020 14:31:21 +0200 CeDeROM wrote: > Hello Jan :-) > > Are you sure you have the correct permissions to read/write /dev/usb* devices? Yes, I manually gave me access by using chown after plugging the device in. > > Assuming you are already in the operator group: > > ***/etc/devfs.rules: > [localrules=10] > add path 'ugen*' mode 0660 group operator > add path 'usb/*' mode 0660 group operator > add path 'usb' mode 0770 group operator > > ***/etc/rc.conf: > devfs_system_ruleset="localrules" Thank you for these explanations, that will be better than always calling chown manually :-) The problem with resetting the device via libusb still persists, see my other mails. > > > Best regards :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 25 Jun 2020 12:23:37 +0200 Hans Petter Selasky wrote: > On 2020-06-25 12:10, Jan Behrens wrote: > > Any help on this would be appreciated. Is there any way to increase > > verbosity of libusb or figure out why the USB initialization fails? > > What is printed in dmesg? > > --HPS > % dmesg [...] ugen2.2: at usbus2 I also made sure I got proper access rights (like Tomek mentioned). Meanwhile I have tracked down the problem further. See my other e-mail. I got the LimeSDR Mini running on FreeBSD (successfully received a radio transmission), but I had to comment out the libusb_reset_device() call, see: https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/7 This is just a quick-and-dirty hack, and no idea if there are any side-effects. It would be better to figure out what's causing the bug in the first place. Regards, Jan ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On Thu, 25 Jun 2020 12:10:52 +0200 Jan Behrens wrote: > I'd like to use a software defined radio "LimeSDR Mini" on FreeBSD > utilizing the "SoapySDR library" with a driver from "Lime Suite", but I > encounter errors, supposedly in libusb. Maybe the same problem occured in MacOS's libusb. Compare the following posts: https://github.com/myriadrf/LimeSuite/issues/253 https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/7 In both cases there is an issue when calling the libusb_reset_device() function. The problem on MacOS seems to have been fixed according to this post: https://github.com/myriadrf/LimeSuite/issues/253#issuecomment-480263517 Look at the following patch: https://github.com/libusb/libusb/commit/a0b5d27fa7f2bba11965e2b70533f925a5772808 The patch seems to be darwin-specific. Is the same bug affecting FreeBSD or is this a different issue? Can the problem be solved for FreeBSD as well? Kind Regards, Jan Behrens ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
Hello Jan :-) Are you sure you have the correct permissions to read/write /dev/usb* devices? Assuming you are already in the operator group: ***/etc/devfs.rules: [localrules=10] add path 'ugen*' mode 0660 group operator add path 'usb/*' mode 0660 group operator add path 'usb' mode 0770 group operator ***/etc/rc.conf: devfs_system_ruleset="localrules" Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
On 2020-06-25 12:10, Jan Behrens wrote: Any help on this would be appreciated. Is there any way to increase verbosity of libusb or figure out why the USB initialization fails? What is printed in dmesg? --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
