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
___
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
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
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
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,
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
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
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
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
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
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 ?
>
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,
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,
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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:
>
>
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
>
%
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.
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
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
Dear all,
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.
As I didn't find a FreeBSD package for a LimeSDR Mini driver for
SoapySDR, I compiled it from source,
43 matches
Mail list logo
