Stack can get into state of refusing to send commands or packets.

[GoogleCodeExporter]

I experienced this problem when testing with something based on the 
'ble_peripheral' example from examples/libusb.  I was testing on a MIPS router 
running OpenWrt, and I had enabled HCI dumps.  This router was fairly slow, in 
terms of I/O and CPU speed.

In both cases, I was using a Plugable Bluetooth 4.0 dongle.

I would see two symptoms:
 - If I sent a notification or indication, the first one would go through.  As soon as I sent this, att_server_can_send() would return false for as long as the connection is up - and so no further packets can be sent.
 - If I disconnect, it would disconnect successfully, but then it never resumes advertising.

When I would try identical code and the same dongle on a faster (x86) machine, 
neither issue would occur.

I looked further into the code and the logs and saw that the reason for this is 
in two functions, usb_send_cmd_packet() and usb_send_acl_packet(), in 
'hci_transport_usb.c'. These functions call libusb_submit_transfer(), call 
hci_dump_packet(), and set 'usb_command_active' or 'usb_acl_out_active' to 1 - 
and in that order. What I was observing is that handle_completed_transfer() was 
then being called and setting 'usb_command_active' or 'usb_act_out_active' to 0 
- sometime right after libusb_submit_transfer(), but before usb_send_*() had 
set the respective flag to 1 - perhaps because hci_dump_packet() was running 
too slowly. The flag would then be set back to 1, even though the transfer was 
complete. Thus, the stack would refuse to send any other packets.

Patch is attached which sets the flags before hci_dump_packet(), rather than 
after it.

Original issue reported on code.google.com by hodap...@gmail.com on 4 Jul 2014 at 5:58

Attachments:

• hci_transport_usb.diff

[GoogleCodeExporter]

hi. thanks for reporting and debugging. looking at your patch, that's perfectly 
fine. however, if there's a race condition, then the ..._active need to go 
before the libusb_submit_transfer (and I didn't expect that they already call 
handlers.

I've update the code in r2692. Could you try the current version on your router?

Original comment by matthias.ringwald@gmail.com on 8 Jul 2014 at 12:26

• Changed state: Fixed