Date: Sat, 27 Jun 2020 16:12:45 +0200 From: Tomasz CEDRO <tomek@cedro.info> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: Hans Petter Selasky <hps@selasky.org>, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: USB reset fails when using a LimeSDR Mini on FreeBSD Message-ID: <CAM8r67DTKdj0%2BhkOegjBj-ywzWFq2CnS2sQed0mibSUeGp6HSQ@mail.gmail.com> In-Reply-To: <20200627144419.f14371695d9b62ea99106c4a@magnetkern.de> References: <20200625121052.e9f7e7cbeb68fad264ec80a9@magnetkern.de> <CAM8r67DFFeFCHMh6mAxw=x2LKYnFGwasOLgceo-EQSMOvMHbeg@mail.gmail.com> <20200625200849.6af81489a80c2f97d4f89ee6@magnetkern.de> <CAM8r67AE1K9AK%2BaL4RCn6_BWajvzKO7K99bYZMdH0mr-HQdyGw@mail.gmail.com> <20200625224522.44d6584465cb6e20d17be320@magnetkern.de> <0ec3e5a3-7f31-d1cd-6862-6066c431aa80@selasky.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 l= evel to 3, as suggested in the documentation > #endif > > Source: https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b= 6f3f576f7f8e74c7f1/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=E2=80=99s libusb should (and/or could) be fixed to e= nsure > 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=E2=80=99m not sure what=E2=80=99s right to do. Particular= ly, I don=E2=80=99t > know why the Lime Suite developers included that call, and I don=E2=80=99= 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 the= se > > kind of dirty hacks. This is the first difference. Second difference is > > that FreeBSD has its own implementation of LibUSB. There may be a probl= em > > 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. Cool.. seems very interesting exercise :-) > > What particular LimeSDR device do you have? Is it expensive? Can you sh= are > > 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 purposes > (general experimenting, trying to do ham radio satellite operation, > operation on different ham radio bands, etc.), the LimeSDR (Mini) seems > to be an awesome device, which is why I would really like if it was > supported by FreeBSD. I have HackRF-ONE SDR and did not observe such problems.. but also I did not use it for quite time. If LimeSDR vendor could provide three sample devices for HPS, you, and me, then we may offer a FreeBSD compatibility and testing in return.. or at least know what the problem is.. cannot tell anything for HPS though if he will have a free moment for such play :-) Can you please elaborate why this LimeSDR is better than HackRF-One? I may buy this one for testing if its worth the price :-) Mouser seems to have a good price for the bare metal version: https://pl.mouser.com/ProductDetail/Lime-Microsystems/cs-lime-05?qs=3DTiOZk= KH1s2RNd%252B0xy7toNQ%3D%3D Best regards :-) Tomek --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM8r67DTKdj0%2BhkOegjBj-ywzWFq2CnS2sQed0mibSUeGp6HSQ>