hackrf_sweep occasionally detaches driver instead of claiming interface

[metayan]

Steps to reproduce

1. LIBUSB_DEBUG=4 hackrf_sweep -f 1000:1020 -w 333333 -l 16 -g 24 -N 1

Expected behaviour

Sweep should always work.

Actual behaviour

Between three and nine times for every 10000 runs, hackrf_sweep reports hackrf_open() failed: Access denied (insufficient permissions) (-1000)

Version information

Operating system: macOS 10.15.7

hackrf_info output: hackrf_info version: git-49481cf2 libhackrf version: git-49481cf2 (0.7) Found HackRF Index: 0 Serial number: 000000000000000087c867dc2919845f Board ID Number: 2 (HackRF One) Firmware Version: git-49481cf2 (API:1.06) Part ID Number: 0xa000cb3c 0x00644f56

Using https://github.com/metayan/hackrf/commits/verify-clear which incorporates https://github.com/martinling/hackrf/commits/concurrency-cleanup .

Output

Failing run:

libusb: debug [process_new_device] found device with address 20 port = 1 parent = 0x0 at 0x7fc013e046da
libusb: debug [darwin_event_thread_main] creating hotplug event source
libusb: debug [darwin_event_thread_main] darwin event thread ready to receive events
libusb: warning [libusb_init] installing new context as implicit default
libusb: debug [libusb_get_device_list]  
libusb: debug [libusb_get_device_descriptor]  
libusb: debug [libusb_open] open 20.20
libusb: debug [darwin_open] device open for access
libusb: debug [libusb_get_configuration]  
libusb: debug [libusb_get_configuration] active config 1

libusb: debug [libusb_kernel_driver_active] interface 0

libusb: debug [libusb_detach_kernel_driver] interface 0
libusb: debug [darwin_detach_kernel_driver] attempting to detach kernel driver from device
libusb: info [darwin_detach_kernel_driver] no capture entitlements. may not be able to detach the kernel driver for this device
libusb: warning [darwin_detach_kernel_driver] USB device capture requires either an entitlement (com.apple.vm.device-access) or root privilege
libusb: debug [libusb_close]  
hackrf_open() failed: Access denied (insufficient permissions) (-1000)

libusb_detach_kernel_driver is called instead of libusb_claim_interface.

Successful run:

libusb: debug [libusb_kernel_driver_active] interface 0
[... same as above until here ...]

libusb: debug [libusb_claim_interface] interface 0
libusb: debug [get_endpoints] building table of endpoints.
libusb: debug [get_endpoints] interface: 0 pipe 1: dir: 1 number: 1
libusb: debug [get_endpoints] interface: 0 pipe 2: dir: 0 number: 2
libusb: debug [darwin_claim_interface] interface opened
call hackrf_sample_rate_set(20.000 MHz)

[straithe]

Thank you for mentioning this. We don't have a Mac available at the moment to test this. We'll let you know once we have an update.

[martinling]

I don't have a macOS 10.15 system available to reproduce this.

However, I am closing this because I'm pretty sure it's not a bug on our side. What happens here from libhackrf's point of view is:

1. We check whether there's a kernel driver attached to the device by calling libusb_kernel_driver_active.
2. The answer from libusb is that yes, there is a kernel driver active.
3. We therefore call libusb_detach_kernel_driver to detach the kernel driver.
4. The response from libusb is that the process doesn't have permission to detach the kernel driver.

We're only calling libusb_detach_kernel_driver because libusb told us we need to. We can't proceed to use a HackRF that has a kernel driver attached, unless the OS lets us detach it. We've been told that there's a kernel driver attached and that we're not allowed to detach it. So all we can do is return an error.

I don't know what the actual problem is. I don't see why macOS should ever be attaching its own driver to a HackRF, so there may be a macOS bug here. Or perhaps libusb_kernel_driver_active returns a false positive, which would be a libusb bug. Given the intermittent reproduction while looping the test, I'm guessing there may be a narrow timing window between closing and reopening the device, in which the kernel is still doing something with the device, and libusb somehow reports there's a kernel driver attached. But that's something that really ought to be solved in either the OS or libusb - and having not seen it come up elsewhere, I'm guessing it may already have been fixed in newer macOS versions.