Closed m4ver1cks closed 9 years ago
If you put the libusb into the debug mode you can see the following message
[ 0.001477] [000035ab] libusbx: debug [libusb_set_configuration] configuration 1 [ 0.089620] [000035ab] libusbx: error [op_set_configuration] failed, error -1 errno 32 [ 0.089681] [000035ab] libusbx: debug [libusb_close] [ 0.089706] [000035ab] libusbx: debug [usbi_remove_pollfd] remove fd 11
@m4ver1cks Which distribution are you running in the VM? Which kernel version?
This sounds very much like the problem with the (unofficial) HackRF kernel module taking control of the hardware. This has been showing up as a problem on recent Kali installs (as they use kernel 3.18+)
I found the problem and it is VMware. When I try the same distro (Kali 1.0.7) in virtualbox , the hackrf go well but very very very slow.
I have the same error on Debian:
# uname -a
Linux handy 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux
# modinfo hackrf
filename: /lib/modules/4.0.0-1-amd64/kernel/drivers/media/usb/hackrf/hackrf.ko
license: GPL
description: HackRF
author: Antti Palosaari <crope@iki.fi>
alias: usb:v1D50p6089d*dc*dsc*dp*ic*isc*ip*in*
depends: videobuf2-core,videodev,usbcore,videobuf2-vmalloc,v4l2-common
intree: Y
vermagic: 4.0.0-1-amd64 SMP mod_unload modversions
# hackrf_info
hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000)
@sanpii Your kernel version is > 3.18.0, which is where the kernel driver was added. This is also being tracked as issue #163 and a patch is coming soon.
As a short term solution you can write "blacklist hackrf" to /etc/modprobe.d/blacklist-hackrf.conf
to stop the driver from being loaded.
@dominicgs Thank you :smiley:
The obvious question is why we're still suffering from a useless rx-only kernel driver that is not and will probably never be supported by any software because even if it was useful and would provide the libhackrf features it would still be a mess to upgrade and provide no benefit over using libhackrf.
https://gist.github.com/jocover/5a29e225ee7460d5f228
the patch hackrf can work on vmware configure 1 is transceiver mode, 2 is CPLD update mode
The HackRF kernel module unloading was fixed in PR #185
I believe that this issue was related to that, so I am closing it. Please let me know if I am wrong.
Hmm, i have this error popping up on an older kernel, blacklisting the module (obviously) didn't help. I'll probably best try upgrading my system first..
@ri0t The error message appears any time that we cannot access the HackRF hardware. This issue was specifically about the kernel module causing the problem.
You may find that contacting the mailing list or asking in the IRC channel (#hackrf on Freenode) will allow us to diagnose the cause more quickly.
Solved. I didn't add the udev rules (seemed unnecessary):
SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="cc15", MODE="0600", OWNER="YOURUSER", GROUP="YOURUSER"
SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", MODE="0600", OWNER="YOURUSER", GROUP="YOURUSER"
(Those are for the rad1o, not sure if the HackRF sports the same ;)
@ri0t Thanks. I had this error as well (libusb -1000) even though I had blacklisted the hackrf kernel module as I'm running Ubuntu 15.04 with kernel 3.19.0-25-generic. As it turns out PyBOMBS doesn't install udev rules...it says so in the FAQ as well...last paragraph in the first question: https://github.com/mossmann/hackrf/wiki/FAQ
Anyway if anyone else ends up here I just cloned this repository (hackrf) and copied "
Thank you @christofferholmstedt. Had the same problem and your solution fixed this.
I am having the same issue on kernel 4.2.0-23. Blacklisted kernel module and udev.rules, but still no luck. Any idea why this could be?
➜ ~ uname -a
Linux blackbox 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
➜ ~ head /etc/modprobe.d/blacklist.conf
# for rad1o
blacklist hackrf
➜ ~ cat /etc/udev/rules.d/51-rad1o.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="cc15", MODE="0600", OWNER="regular", GROUP="regular"
SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", MODE="0600", OWNER="regular", GROUP="regular"
➜ ~ dmesg|tail
[ 37.921072] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 37.921075] usb 1-3: Product: HackRF
[ 37.921077] usb 1-3: Manufacturer: Great Scott Gadgets
[ 221.560018] usb 1-3: reset high-speed USB device number 3 using ehci-pci
[ 221.693580] usb 1-3: USB disconnect, device number 3
[ 221.804020] usb 1-3: new high-speed USB device number 4 using ehci-pci
[ 221.937092] usb 1-3: New USB device found, idVendor=1d50, idProduct=cc15
[ 221.937096] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 221.937098] usb 1-3: Product: HackRF
[ 221.937101] usb 1-3: Manufacturer: Great Scott Gadgets
➜ ~ hackrf_info
Found HackRF board 0:
hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000)
➜ ~
Could you do the following command?
Rmmod hackrf
I did that and sometimes worked. Anyway i'm using the branch 4.4 of the kernel and works well El 9/1/2016 22:44, "Jan Bölsche" notifications@github.com escribió:
I am having the same issue on kernel 4.2.0-23. Blacklisted kernel module and udev.rules, but still no luck. Any idea why this could be?
➜ ~ uname -a Linux blackbox 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27 17:47:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
➜ ~ head /etc/modprobe.d/blacklist.conf
for rad1o
blacklist hackrf
➜ ~ cat /etc/udev/rules.d/51-rad1o.rules SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="cc15", MODE="0600", OWNER="regular", GROUP="regular" SUBSYSTEM=="usb", ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", MODE="0600", OWNER="regular", GROUP="regular"
➜ ~ dmesg|tail [ 37.921072] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 37.921075] usb 1-3: Product: HackRF [ 37.921077] usb 1-3: Manufacturer: Great Scott Gadgets [ 221.560018] usb 1-3: reset high-speed USB device number 3 using ehci-pci [ 221.693580] usb 1-3: USB disconnect, device number 3 [ 221.804020] usb 1-3: new high-speed USB device number 4 using ehci-pci [ 221.937092] usb 1-3: New USB device found, idVendor=1d50, idProduct=cc15 [ 221.937096] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [ 221.937098] usb 1-3: Product: HackRF [ 221.937101] usb 1-3: Manufacturer: Great Scott Gadgets ➜ ~ hackrf_info Found HackRF board 0: hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000) ➜ ~
— Reply to this email directly or view it on GitHub https://github.com/mossmann/hackrf/issues/165#issuecomment-170284972.
Thanks, it works now. I had to follow this advise: http://unix.stackexchange.com/questions/91027/how-to-disable-usb-autosuspend-on-kernel-3-7-10-or-above
I'm trying to resolve some issues with the hackrf that runs into a vmware machine but i can't.
When we execute hackrf_info, the program throws the following error.
hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000)
I've tried with compiled packages (ubuntu (14.04, 14.10 and 15.04) and mint) and with source code (compiled on my own).
I did some debug stuff and I found that the error is produced in the following line in the hackrf.c file "result = libusb_set_configuration(usb_device, 1);"
That function throws a -99 code error (LIBUSB_ERROR_OTHER)
It seems that the configuration "1" don't like to the libusb