> Yeah, but that is just working around the extra byte, but it seems > there is some way to detect that not all data has been read, which is > why wireshard is only considering the Read Local Extended Features as > received on frame 127 not on frame 123 I have not checked how the wireshark logic works, but I guess that it works like this: 1) read URB and parse it's header to get the size of the buffer 2) reads HCI header which tells how long the HCI packet is 3) diccesst entire HCI packet 4) return dissection with the number of processed bytes 5) URB_packet_len - dissected_len == 1 which triggers fragmentation logic USB capture from my controller: > 109 7.586834 host 1.7.1 USB 64 URB_INTERRUPT in > 110 7.586985 host controller HCI_CMD 68 Sent Read Local Extended Features > 111 7.596062 1.7.0 host HCI_USB 64 Rcvd > 112 7.604809 1.7.1 host HCI_USB 81 Rcvd Fragment > 113 7.604830 host 1.7.1 USB 64 URB_INTERRUPT in > 114 7.604980 host controller HCI_CMD 67 Sent Read Buffer Size > 115 7.610312 1.7.0 host HCI_USB 64 Rcvd > 116 7.610814 controller host HCI_EVT 77 Rcvd Command Complete (Read Local Extended Features) > 117 7.610823 host 1.7.1 USB 64 URB_INTERRUPT in But this INFO column is not correct. The frame 112 contains: 0000 40 5e d7 04 80 ff ff ff 43 01 81 07 01 00 2d 00 0010 b8 73 a8 68 00 00 00 00 9e 80 05 00 00 00 00 00 0020 11 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00 0030 01 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 -- HCI payload starts here 0040 0e 0e 01 04 10 00 01 02 00 00 00 00 00 00 00 00 0050 00 First byte in the HCI payload is event type, the second byte is length 0x0e == 14. However, the USB buffer has 17 bytes, which is one more than the event header size (2 bytes) + 14 bytes of data. The frame 116 contains: 0000 40 5e d7 04 80 ff ff ff 43 01 81 07 01 00 2d 00 0010 b8 73 a8 68 00 00 00 00 13 98 05 00 00 00 00 00 0020 0d 00 00 00 0d 00 00 00 00 00 00 00 00 00 00 00 0030 01 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 -- HCI payload starts here 0040 0e 0b 01 05 10 00 a7 02 ff 09 00 04 00 And it is a correct event for the 0x1005 opcode on its own. But wireshark tries to defragment it with frame 112 and displays frame 116 as "Rcvd Command Complete (Read Local Extended Features)" which is not true. So, here is the full diagnostic for what is going on. However, I'm not sure that the patch is the right remedy for this issue... It works, so at least it is a good PoC that these USB dongles can work with Linux as well. I have not tested all HCI commands, so I do not know whether there are any other quirks in this dongle. All I can tell is that I've tested it with A2DP audio and it works but it is not very stable... sometimes it hangs (unplug/plug is required), but most likely due to undervoltage on my RPi... (undervoltage does not jam the on-board BT chip or other dongles that I have, though). This extra byte in the 0x1004 response event seems to be random - garbage most likely. I've tested it with libusb. There is also another thing with this dongle which was not mentioned earlier. Dedicated Barrot Windows driver sends a few vendor HCI commands before standard initialization. Most likely queries version of firmware or something. Also, Windows driver does not use "Read Local Extended Features", so maybe it was not tested... Anyway, without these vendor commands the controller seems to work properly (as far as I tested it).
