Hi Arkadiusz,
On Mon, Aug 25, 2025 at 3:37 PM Arkadiusz Bokowy
<arkadiusz.bokowy@xxxxxxxxx> wrote:
>
> > 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).
Could we solve this by doing:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3595a8bad6bd..168b07041605 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1194,6 +1194,17 @@ static int btusb_recv_intr(struct btusb_data
*data, void *buffer, int count)
}
if (!hci_skb_expect(skb)) {
+ /* Each chunk should correct to at least 1 or
more events
+ * so if there are still bytes left that
doesn't constitute a new
+ * event this is likely a bug in the controller.
+ */
+ if (count && count < HCI_EVENT_HDR_SIZE) {
+ bt_dev_warn(data->hdev,
+ "Unexpected continuation: %d bytes",
+ count);
+ count = 0;
+ }
+
--
Luiz Augusto von Dentz
