In hci_transport_usb, handle_completed_transfer calls the packet_handler and resubmits the transfer when needed. But if the packet handler has caused usb_close to be called (by calling hci_power_control for example), usb processing should be stopped.

What steps will reproduce the problem? 1. Run the daemon. 2. Connect and disconnect a client. 3. Wait for for the daemon_no_connections_timeout timer to run (and call hci_power_control). 4. If on the next run loop iteration a libusb fd is set, handle_completed_transfer will get called and call the packet_handler. 5. The hci packet handler callback will call usb_close (in HCI_STATE_HALTING handling). 6. Calling libusb_submit_transfer in this state, or later iterating the handle_packet in usb_process_ds, is invalid.

What is the expected output? What do you see instead? - usb_close should set libusb_state back to LIB_USB_CLOSED, and set handle to NULL; - Before calling libusb_submit_transfer in handle_completed_transfer, check that the state is still valid. - In usb_process_ds, after calling handle_completed_transfer, a similar check should be done (since the handle_packet is invalid after usb_close is called).

What version of the product are you using? On what operating system? Present in the latest r2599.

Thanks again. I've only used the daemon on iOS and Android, where there was an H4_UART.

I've added the state checks as suggested. Please check if you miss another one.