[PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

Apparently, some Barrot based USB Bluetooth dongles erroneously sent one
extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
consequence of that is that the next HCI transfer is misaligned by one
byte causing undefined behavior. In most cases the response event for the
next command fails with random error code.

Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
controller initialization, the initialization fails rendering the USB
dongle not usable.

> [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110

This patch was not tested with the 33fa:0010 device, however, Internet
search suggest that the cause for the issue with this particular device
is exactly the same, e.g.: https://github.com/bluez/bluez/issues/1326

Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
---
 drivers/bluetooth/btusb.c   | 30 ++++++++++++++++++++++++++++++
 include/net/bluetooth/hci.h |  9 +++++++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8085fabad..b89efe482 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -66,6 +66,7 @@ static struct usb_driver btusb_driver;
 #define BTUSB_INTEL_BROKEN_INITIAL_NCMD BIT(25)
 #define BTUSB_INTEL_NO_WBS_SUPPORT	BIT(26)
 #define BTUSB_ACTIONS_SEMI		BIT(27)
+#define BTUSB_BARROT			BIT(28)
 
 static const struct usb_device_id btusb_table[] = {
 	/* Generic Bluetooth USB device */
@@ -810,6 +811,10 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x0cb5, 0xc547), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 
+	/* Barrot Technology Bluetooth devices */
+	{ USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
+	{ USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
+
 	/* Actions Semiconductor ATS2851 based devices */
 	{ USB_DEVICE(0x10d7, 0xb012), .driver_info = BTUSB_ACTIONS_SEMI },
 
@@ -1120,6 +1125,21 @@ static void btusb_qca_reset(struct hci_dev *hdev)
 	btusb_reset(hdev);
 }
 
+static int btusb_barrot_urb_quirk(struct btusb_data *data, struct sk_buff *skb)
+{
+	struct hci_dev *hdev = data->hdev;
+	struct hci_ev_cmd_complete *ev;
+
+	if (hci_test_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER) &&
+	    hci_event_hdr(skb)->evt == HCI_EV_CMD_COMPLETE) {
+		ev = (struct hci_ev_cmd_complete *)(hci_event_hdr(skb) + 1);
+		if (__le16_to_cpu(ev->opcode) == HCI_OP_READ_LOCAL_EXT_FEATURES)
+			return 1;
+	}
+
+	return 0;
+}
+
 static inline void btusb_free_frags(struct btusb_data *data)
 {
 	unsigned long flags;
@@ -1192,6 +1212,13 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
 		}
 
 		if (!hci_skb_expect(skb)) {
+			/* Discard one extra byte sent by some Barrot USB
+			 * controllers. Otherwise, the rest of the transfer
+			 * will be misaligned by one byte.
+			 */
+			if (btusb_barrot_urb_quirk(data, skb) && count == 1)
+				count = 0;
+
 			/* Complete frame */
 			btusb_recv_event(data, skb);
 			skb = NULL;
@@ -4218,6 +4245,9 @@ static int btusb_probe(struct usb_interface *intf,
 		hci_set_quirk(hdev, HCI_QUIRK_BROKEN_WRITE_AUTH_PAYLOAD_TIMEOUT);
 	}
 
+	if (id->driver_info & BTUSB_BARROT)
+		hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER);
+
 	if (!reset)
 		hci_set_quirk(hdev, HCI_QUIRK_RESET_ON_CLOSE);
 
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index df1847b74..ec9b47a39 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -351,6 +351,15 @@ enum {
 	 */
 	HCI_QUIRK_BROKEN_READ_ENC_KEY_SIZE,
 
+	/*
+	 * When this quirk is set, the URB buffer with response event for the
+	 * HCI_OP_READ_LOCAL_EXT_FEATURES command needs to be trimmed by one byte.
+	 * This is required for some Barrot controllers which erroneously transfer
+	 * an extra random byte at the end of the buffer which misaligns the rest
+	 * of the HCI communication.
+	 */
+	HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER,
+
 	/*
 	 * When this quirk is set, the reserved bits of Primary/Secondary_PHY
 	 * inside the LE Extended Advertising Report events are discarded.
-- 
2.47.2

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Paul Menzel]

Dear Arkadiusz,


Thank you for your patch. For the summary, just a small nit to use a 
statement: Add quirk to fix up reading ext features on some Barrot 
controllers

Am 25.08.25 um 19:25 schrieb Arkadiusz Bokowy:
> Apparently, some Barrot based USB Bluetooth dongles erroneously sent one

s/sent/send/

> extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
> consequence of that is that the next HCI transfer is misaligned by one
> byte causing undefined behavior. In most cases the response event for the
> next command fails with random error code.
> 
> Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
> controller initialization, the initialization fails rendering the USB
> dongle not usable.
> 
>> [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
>> [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
>> [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>> [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
>> [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
>> [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110

Although in the log, maybe mention, that you tested with the 33fa:0012 
device.

> This patch was not tested with the 33fa:0010 device, however, Internet
> search suggest that the cause for the issue with this particular device
> is exactly the same, e.g.: https://github.com/bluez/bluez/issues/1326

You could use:

Link: https://github.com/bluez/bluez/issues/1326

> Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> ---
>   drivers/bluetooth/btusb.c   | 30 ++++++++++++++++++++++++++++++
>   include/net/bluetooth/hci.h |  9 +++++++++
>   2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8085fabad..b89efe482 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -66,6 +66,7 @@ static struct usb_driver btusb_driver;
>   #define BTUSB_INTEL_BROKEN_INITIAL_NCMD BIT(25)
>   #define BTUSB_INTEL_NO_WBS_SUPPORT	BIT(26)
>   #define BTUSB_ACTIONS_SEMI		BIT(27)
> +#define BTUSB_BARROT			BIT(28)
>   
>   static const struct usb_device_id btusb_table[] = {
>   	/* Generic Bluetooth USB device */
> @@ -810,6 +811,10 @@ static const struct usb_device_id quirks_table[] = {
>   	{ USB_DEVICE(0x0cb5, 0xc547), .driver_info = BTUSB_REALTEK |
>   						     BTUSB_WIDEBAND_SPEECH },
>   
> +	/* Barrot Technology Bluetooth devices */
> +	{ USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
> +	{ USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
> +
>   	/* Actions Semiconductor ATS2851 based devices */
>   	{ USB_DEVICE(0x10d7, 0xb012), .driver_info = BTUSB_ACTIONS_SEMI },
>   
> @@ -1120,6 +1125,21 @@ static void btusb_qca_reset(struct hci_dev *hdev)
>   	btusb_reset(hdev);
>   }
>   
> +static int btusb_barrot_urb_quirk(struct btusb_data *data, struct sk_buff *skb)
> +{
> +	struct hci_dev *hdev = data->hdev;
> +	struct hci_ev_cmd_complete *ev;
> +
> +	if (hci_test_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER) &&
> +	    hci_event_hdr(skb)->evt == HCI_EV_CMD_COMPLETE) {
> +		ev = (struct hci_ev_cmd_complete *)(hci_event_hdr(skb) + 1);
> +		if (__le16_to_cpu(ev->opcode) == HCI_OP_READ_LOCAL_EXT_FEATURES)
> +			return 1;
> +	}
> +
> +	return 0;
> +}
> +
>   static inline void btusb_free_frags(struct btusb_data *data)
>   {
>   	unsigned long flags;
> @@ -1192,6 +1212,13 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
>   		}
>   
>   		if (!hci_skb_expect(skb)) {
> +			/* Discard one extra byte sent by some Barrot USB
> +			 * controllers. Otherwise, the rest of the transfer
> +			 * will be misaligned by one byte.
> +			 */
> +			if (btusb_barrot_urb_quirk(data, skb) && count == 1)
> +				count = 0;
> +
>   			/* Complete frame */
>   			btusb_recv_event(data, skb);
>   			skb = NULL;
> @@ -4218,6 +4245,9 @@ static int btusb_probe(struct usb_interface *intf,
>   		hci_set_quirk(hdev, HCI_QUIRK_BROKEN_WRITE_AUTH_PAYLOAD_TIMEOUT);
>   	}
>   
> +	if (id->driver_info & BTUSB_BARROT)
> +		hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER);
> +
>   	if (!reset)
>   		hci_set_quirk(hdev, HCI_QUIRK_RESET_ON_CLOSE);
>   
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index df1847b74..ec9b47a39 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -351,6 +351,15 @@ enum {
>   	 */
>   	HCI_QUIRK_BROKEN_READ_ENC_KEY_SIZE,
>   
> +	/*
> +	 * When this quirk is set, the URB buffer with response event for the
> +	 * HCI_OP_READ_LOCAL_EXT_FEATURES command needs to be trimmed by one byte.
> +	 * This is required for some Barrot controllers which erroneously transfer
> +	 * an extra random byte at the end of the buffer which misaligns the rest
> +	 * of the HCI communication.
> +	 */
> +	HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER,
> +
>   	/*
>   	 * When this quirk is set, the reserved bits of Primary/Secondary_PHY
>   	 * inside the LE Extended Advertising Report events are discarded.

Great patch.

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

RE: Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=995337

---Test result---

Test Summary:
CheckPatch                    PENDING   0.60 seconds
GitLint                       PENDING   0.34 seconds
SubjectPrefix                 PASS      0.07 seconds
BuildKernel                   PASS      23.90 seconds
CheckAllWarning               PASS      26.53 seconds
CheckSparse                   PASS      30.04 seconds
BuildKernel32                 PASS      23.87 seconds
TestRunnerSetup               PASS      477.43 seconds
TestRunner_l2cap-tester       PASS      24.95 seconds
TestRunner_iso-tester         PASS      40.75 seconds
TestRunner_bnep-tester        PASS      5.98 seconds
TestRunner_mgmt-tester        FAIL      125.99 seconds
TestRunner_rfcomm-tester      PASS      9.35 seconds
TestRunner_sco-tester         PASS      14.71 seconds
TestRunner_ioctl-tester       PASS      10.02 seconds
TestRunner_mesh-tester        FAIL      11.52 seconds
TestRunner_smp-tester         PASS      10.82 seconds
TestRunner_userchan-tester    PASS      6.25 seconds
IncrementalBuild              PENDING   0.67 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 485 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.104 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.102 seconds
Mesh - Send cancel - 2                               Timed out    1.993 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Mon, Aug 25, 2025 at 1:25 PM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> Apparently, some Barrot based USB Bluetooth dongles erroneously sent one
> extra random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
> consequence of that is that the next HCI transfer is misaligned by one
> byte causing undefined behavior. In most cases the response event for the
> next command fails with random error code.
>
> Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
> controller initialization, the initialization fails rendering the USB
> dongle not usable.
>
> > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110
>
> This patch was not tested with the 33fa:0010 device, however, Internet
> search suggest that the cause for the issue with this particular device
> is exactly the same, e.g.: https://github.com/bluez/bluez/issues/1326

This issue above seem to be something different though, it looks like
there is some fragmentation of the response but then in the meantime
we send another command (HCI_OP_READ_BUFFER_SIZE 0x1005) and that
times out, so the description and the code changes don't really seem
to match.

> Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> ---
>  drivers/bluetooth/btusb.c   | 30 ++++++++++++++++++++++++++++++
>  include/net/bluetooth/hci.h |  9 +++++++++
>  2 files changed, 39 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8085fabad..b89efe482 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -66,6 +66,7 @@ static struct usb_driver btusb_driver;
>  #define BTUSB_INTEL_BROKEN_INITIAL_NCMD BIT(25)
>  #define BTUSB_INTEL_NO_WBS_SUPPORT     BIT(26)
>  #define BTUSB_ACTIONS_SEMI             BIT(27)
> +#define BTUSB_BARROT                   BIT(28)
>
>  static const struct usb_device_id btusb_table[] = {
>         /* Generic Bluetooth USB device */
> @@ -810,6 +811,10 @@ static const struct usb_device_id quirks_table[] = {
>         { USB_DEVICE(0x0cb5, 0xc547), .driver_info = BTUSB_REALTEK |
>                                                      BTUSB_WIDEBAND_SPEECH },
>
> +       /* Barrot Technology Bluetooth devices */
> +       { USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
> +       { USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
> +
>         /* Actions Semiconductor ATS2851 based devices */
>         { USB_DEVICE(0x10d7, 0xb012), .driver_info = BTUSB_ACTIONS_SEMI },
>
> @@ -1120,6 +1125,21 @@ static void btusb_qca_reset(struct hci_dev *hdev)
>         btusb_reset(hdev);
>  }
>
> +static int btusb_barrot_urb_quirk(struct btusb_data *data, struct sk_buff *skb)
> +{
> +       struct hci_dev *hdev = data->hdev;
> +       struct hci_ev_cmd_complete *ev;
> +
> +       if (hci_test_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER) &&
> +           hci_event_hdr(skb)->evt == HCI_EV_CMD_COMPLETE) {
> +               ev = (struct hci_ev_cmd_complete *)(hci_event_hdr(skb) + 1);
> +               if (__le16_to_cpu(ev->opcode) == HCI_OP_READ_LOCAL_EXT_FEATURES)
> +                       return 1;
> +       }
> +
> +       return 0;
> +}
> +
>  static inline void btusb_free_frags(struct btusb_data *data)
>  {
>         unsigned long flags;
> @@ -1192,6 +1212,13 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
>                 }
>
>                 if (!hci_skb_expect(skb)) {
> +                       /* Discard one extra byte sent by some Barrot USB
> +                        * controllers. Otherwise, the rest of the transfer
> +                        * will be misaligned by one byte.
> +                        */
> +                       if (btusb_barrot_urb_quirk(data, skb) && count == 1)
> +                               count = 0;
> +
>                         /* Complete frame */
>                         btusb_recv_event(data, skb);
>                         skb = NULL;
> @@ -4218,6 +4245,9 @@ static int btusb_probe(struct usb_interface *intf,
>                 hci_set_quirk(hdev, HCI_QUIRK_BROKEN_WRITE_AUTH_PAYLOAD_TIMEOUT);
>         }
>
> +       if (id->driver_info & BTUSB_BARROT)
> +               hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER);
> +
>         if (!reset)
>                 hci_set_quirk(hdev, HCI_QUIRK_RESET_ON_CLOSE);
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index df1847b74..ec9b47a39 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -351,6 +351,15 @@ enum {
>          */
>         HCI_QUIRK_BROKEN_READ_ENC_KEY_SIZE,
>
> +       /*
> +        * When this quirk is set, the URB buffer with response event for the
> +        * HCI_OP_READ_LOCAL_EXT_FEATURES command needs to be trimmed by one byte.
> +        * This is required for some Barrot controllers which erroneously transfer
> +        * an extra random byte at the end of the buffer which misaligns the rest
> +        * of the HCI communication.
> +        */
> +       HCI_QUIRK_FIXUP_LOCAL_EXT_FEATURES_URB_BUFFER,
> +
>         /*
>          * When this quirk is set, the reserved bits of Primary/Secondary_PHY
>          * inside the LE Extended Advertising Report events are discarded.
> --
> 2.47.2
>
>


-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

> This issue above seem to be something different though, it looks like
> there is some fragmentation of the response but then in the meantime
> we send another command (HCI_OP_READ_BUFFER_SIZE 0x1005) and that
> times out, so the description and the code changes don't really seem
> to match.

This extra byte tripps wireshark as well. I have exactly the same
dissection in my case, and also I thought that the problem is with
fragmentation (which kind of is). If you look at raw bytes in
wireshark (not the reassembled packet), then you will see that the
0x1005 command response is correct on its own, however, it is
reassembled with this extra byte from 0x1004 command and then
everything goes sideways....

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Mon, Aug 25, 2025 at 2:49 PM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> > This issue above seem to be something different though, it looks like
> > there is some fragmentation of the response but then in the meantime
> > we send another command (HCI_OP_READ_BUFFER_SIZE 0x1005) and that
> > times out, so the description and the code changes don't really seem
> > to match.
>
> This extra byte tripps wireshark as well. I have exactly the same
> dissection in my case, and also I thought that the problem is with
> fragmentation (which kind of is). If you look at raw bytes in
> wireshark (not the reassembled packet), then you will see that the
> 0x1005 command response is correct on its own, however, it is
> reassembled with this extra byte from 0x1004 command and then
> everything goes sideways....

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, so Im afraid we are not
checking something in urb that tells there are more bytes, then we
must read that and only then call btusb_recv_event with the entire
response, then we can have a quirk to ignore the extra byte.


-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

> 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).

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Mon, Aug 25, 2025 at 3:37 PM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> 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

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

> 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;
> +                       }
> +

Yes, it should work. I was afraid that a simple patch like that, that
affects all other controllers, might break something. So, instead,
I've added a dedicated quirk only for affected controllers and only
for 0x1004 command. I can test it later, but it's simple enough that
even without testing one might tell that it will work as expected :)

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

> 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;
> +                       }
> +

I've just verified that this patch brings the Barrot dongle to live on
Linux. Here is the output from dmesg:

> [   43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> [   43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [   43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [   43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> [   43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [   43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [   43.750141] Bluetooth: MGMT ver 1.23

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Tue, Aug 26, 2025 at 12:44 AM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> > 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;
> > +                       }
> > +
>
> I've just verified that this patch brings the Barrot dongle to live on
> Linux. Here is the output from dmesg:
>
> > [   43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> > [   43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > [   43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > [   43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> > [   43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > [   43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > [   43.750141] Bluetooth: MGMT ver 1.23

Great, do you care to respin the patch with the above changes?

-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Arkadiusz Bokowy]

> Great, do you care to respin the patch with the above changes?

But, I'm not the author of these changes any more. It's not a minor
post-code review change but a different approach. If you really want I
can reupload it with your changes, but the proper way (from the
authorship point of view) is that you will submit this patch as yours
:)

Re: [PATCH] Bluetooth: btusb: Fixup quirk for reading ext features on some Barrot controllers

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Tue, Aug 26, 2025 at 12:23 PM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> > Great, do you care to respin the patch with the above changes?
>
> But, I'm not the author of these changes any more. It's not a minor
> post-code review change but a different approach. If you really want I
> can reupload it with your changes, but the proper way (from the
> authorship point of view) is that you will submit this patch as yours
> :)

Who develop it is not that important, and in the end I will have to
add my Signed-off-by anyway when applying these changes and you should
definitely appear on it, even if it is just with Tested-by, that said
now I realize we may want to rewrite the commit description as well
since with this we are now able to detect extra bytes sent by the
controller.



-- 
Luiz Augusto von Dentz

[PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Arkadiusz Bokowy]

Some Barrot based USB Bluetooth dongles erroneously send one extra
random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
consequence of that is that the next HCI transfer is misaligned by one
byte causing undefined behavior. In most cases the response event for
the next command fails with random error code.

Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
controller initialization, the initialization fails rendering the USB
dongle not usable.

> [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110

This patch was tested with the 33fa:0012 device. Now the device is
initialized properly:

> [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [43.750141] Bluetooth: MGMT ver 1.23

Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
---
 drivers/bluetooth/btusb.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8085fabad..24a249d1c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1192,6 +1192,18 @@ 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;
+			}
+
 			/* Complete frame */
 			btusb_recv_event(data, skb);
 			skb = NULL;
-- 
2.47.2

RE: [v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=995751

---Test result---

Test Summary:
CheckPatch                    PENDING   0.40 seconds
GitLint                       PENDING   0.32 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      24.21 seconds
CheckAllWarning               PASS      27.02 seconds
CheckSparse                   PASS      30.51 seconds
BuildKernel32                 PASS      26.64 seconds
TestRunnerSetup               PASS      476.15 seconds
TestRunner_l2cap-tester       PASS      25.01 seconds
TestRunner_iso-tester         PASS      39.20 seconds
TestRunner_bnep-tester        PASS      6.03 seconds
TestRunner_mgmt-tester        FAIL      128.12 seconds
TestRunner_rfcomm-tester      PASS      9.40 seconds
TestRunner_sco-tester         PASS      14.88 seconds
TestRunner_ioctl-tester       PASS      10.20 seconds
TestRunner_mesh-tester        FAIL      11.44 seconds
TestRunner_smp-tester         PASS      8.71 seconds
TestRunner_userchan-tester    PASS      6.29 seconds
IncrementalBuild              PENDING   0.90 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 484 (98.8%), Failed: 2, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.102 seconds
LL Privacy - Add Device 3 (AL is full)               Failed       0.222 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.032 seconds
Mesh - Send cancel - 2                               Timed out    1.997 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Tue, Aug 26, 2025 at 1:03 PM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> Some Barrot based USB Bluetooth dongles erroneously send one extra
> random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
> consequence of that is that the next HCI transfer is misaligned by one
> byte causing undefined behavior. In most cases the response event for
> the next command fails with random error code.
>
> Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
> controller initialization, the initialization fails rendering the USB
> dongle not usable.
>
> > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110
>
> This patch was tested with the 33fa:0012 device. Now the device is
> initialized properly:

I'm trying to find any entry with 0x33fa but I couldn't find any, we
probably want to include the Fixes tag to the commit that introduces
support for it.

>
> > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > [43.750141] Bluetooth: MGMT ver 1.23
>
> Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> ---
>  drivers/bluetooth/btusb.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8085fabad..24a249d1c 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -1192,6 +1192,18 @@ 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;
> +                       }
> +
>                         /* Complete frame */
>                         btusb_recv_event(data, skb);
>                         skb = NULL;
> --
> 2.47.2
>
>


-- 
Luiz Augusto von Dentz

Re: [PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Tue, Aug 26, 2025 at 3:31 PM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Arkadiusz,
>
> On Tue, Aug 26, 2025 at 1:03 PM Arkadiusz Bokowy
> <arkadiusz.bokowy@gmail.com> wrote:
> >
> > Some Barrot based USB Bluetooth dongles erroneously send one extra
> > random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
> > consequence of that is that the next HCI transfer is misaligned by one
> > byte causing undefined behavior. In most cases the response event for
> > the next command fails with random error code.
> >
> > Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
> > controller initialization, the initialization fails rendering the USB
> > dongle not usable.
> >
> > > [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> > > [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > > [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > > [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> > > [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> > > [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110
> >
> > This patch was tested with the 33fa:0012 device. Now the device is
> > initialized properly:
>
> I'm trying to find any entry with 0x33fa but I couldn't find any, we
> probably want to include the Fixes tag to the commit that introduces
> support for it.

Looks like we are missing:

+       /* Barrot Technology Bluetooth devices */
+       { USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
+       { USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },

We can probably add it together in the same patch, so we don't have to
rely on Fixes to inform the changes below needs to go together, but
then we should include the contents of /sys/kernel/debug/usb/devices
before the information why we need the changes to detect extra bytes
in order for it to work.

> >
> > > [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> > > [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> > > [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> > > [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> > > [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > > [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> > > [43.750141] Bluetooth: MGMT ver 1.23
> >
> > Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> > Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> > ---
> >  drivers/bluetooth/btusb.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 8085fabad..24a249d1c 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -1192,6 +1192,18 @@ 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;
> > +                       }
> > +
> >                         /* Complete frame */
> >                         btusb_recv_event(data, skb);
> >                         skb = NULL;
> > --
> > 2.47.2
> >
> >
>
>
> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: [PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Arkadiusz Bokowy]

> Looks like we are missing:
>
> +       /* Barrot Technology Bluetooth devices */
> +       { USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
> +       { USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
>
> We can probably add it together in the same patch, so we don't have to
> rely on Fixes to inform the changes below needs to go together, but
> then we should include the contents of /sys/kernel/debug/usb/devices
> before the information why we need the changes to detect extra bytes
> in order for it to work.

OK, so, should I restore the quirk (so this check is only for Barrot
devices)? Or add driver_info = BARROT without actually using it
anywhere?

Re: [PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Luiz Augusto von Dentz]

Hi Arkadiusz,

On Wed, Aug 27, 2025 at 11:02 AM Arkadiusz Bokowy
<arkadiusz.bokowy@gmail.com> wrote:
>
> > Looks like we are missing:
> >
> > +       /* Barrot Technology Bluetooth devices */
> > +       { USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
> > +       { USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
> >
> > We can probably add it together in the same patch, so we don't have to
> > rely on Fixes to inform the changes below needs to go together, but
> > then we should include the contents of /sys/kernel/debug/usb/devices
> > before the information why we need the changes to detect extra bytes
> > in order for it to work.
>
> OK, so, should I restore the quirk (so this check is only for Barrot
> devices)? Or add driver_info = BARROT without actually using it
> anywhere?

I don't think we need to quirk to acting on the extra bytes, but
perhaps we should leave the driver_info = BARROT in case we need some
special handling for it since I suspect it may be needed for setting
up things like firmware download, which in the event the driver is
ever fixed to not sent the extra bytes a new firmware will probably
going to be required.

-- 
Luiz Augusto von Dentz

[PATCH v3] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Arkadiusz Bokowy]

Some Barrot based USB Bluetooth dongles erroneously send one extra
random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
consequence of that is that the next HCI transfer is misaligned by one
byte causing undefined behavior. In most cases the response event for
the next command fails with random error code.

Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
controller initialization, the initialization fails rendering the USB
dongle not usable.

> [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
> [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
> [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
> [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110

This patch was tested with the 33fa:0012 device. The info from the
/sys/kernel/debug/usb/devices is shown below:

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 12 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=33fa ProdID=0012 Rev=88.91
S:  Product=UGREEN BT6.0 Adapter
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Now the device is initialized properly:

> [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
> [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
> [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
> [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
> [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes
> [43.750141] Bluetooth: MGMT ver 1.23

Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
---
 drivers/bluetooth/btusb.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 8085fabad..eaf88dda6 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -66,6 +66,7 @@ static struct usb_driver btusb_driver;
 #define BTUSB_INTEL_BROKEN_INITIAL_NCMD BIT(25)
 #define BTUSB_INTEL_NO_WBS_SUPPORT	BIT(26)
 #define BTUSB_ACTIONS_SEMI		BIT(27)
+#define BTUSB_BARROT			BIT(28)
 
 static const struct usb_device_id btusb_table[] = {
 	/* Generic Bluetooth USB device */
@@ -810,6 +811,10 @@ static const struct usb_device_id quirks_table[] = {
 	{ USB_DEVICE(0x0cb5, 0xc547), .driver_info = BTUSB_REALTEK |
 						     BTUSB_WIDEBAND_SPEECH },
 
+	/* Barrot Technology Bluetooth devices */
+	{ USB_DEVICE(0x33fa, 0x0010), .driver_info = BTUSB_BARROT },
+	{ USB_DEVICE(0x33fa, 0x0012), .driver_info = BTUSB_BARROT },
+
 	/* Actions Semiconductor ATS2851 based devices */
 	{ USB_DEVICE(0x10d7, 0xb012), .driver_info = BTUSB_ACTIONS_SEMI },
 
@@ -1192,6 +1197,18 @@ 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;
+			}
+
 			/* Complete frame */
 			btusb_recv_event(data, skb);
 			skb = NULL;
-- 
2.47.2

RE: [v3] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=996151

---Test result---

Test Summary:
CheckPatch                    PENDING   0.35 seconds
GitLint                       PENDING   0.21 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      24.18 seconds
CheckAllWarning               PASS      26.63 seconds
CheckSparse                   PASS      29.81 seconds
BuildKernel32                 PASS      24.09 seconds
TestRunnerSetup               PASS      473.91 seconds
TestRunner_l2cap-tester       PASS      24.67 seconds
TestRunner_iso-tester         PASS      36.71 seconds
TestRunner_bnep-tester        PASS      5.99 seconds
TestRunner_mgmt-tester        FAIL      127.25 seconds
TestRunner_rfcomm-tester      PASS      9.35 seconds
TestRunner_sco-tester         PASS      14.73 seconds
TestRunner_ioctl-tester       PASS      9.96 seconds
TestRunner_mesh-tester        FAIL      11.36 seconds
TestRunner_smp-tester         PASS      8.47 seconds
TestRunner_userchan-tester    PASS      6.20 seconds
IncrementalBuild              PENDING   0.88 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 490, Passed: 484 (98.8%), Failed: 2, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.109 seconds
LL Privacy - Set Flags 3 (2 Devices to RL)           Failed       0.184 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.104 seconds
Mesh - Send cancel - 2                               Timed out    1.997 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames

[Paul Menzel]

Dear Arkadiusz,


Thank you for the patch.

Am 26.08.25 um 19:03 schrieb Arkadiusz Bokowy:
> Some Barrot based USB Bluetooth dongles erroneously send one extra
> random byte for the HCI_OP_READ_LOCAL_EXT_FEATURES command. The
> consequence of that is that the next HCI transfer is misaligned by one
> byte causing undefined behavior. In most cases the response event for
> the next command fails with random error code.
> 
> Since the HCI_OP_READ_LOCAL_EXT_FEATURES command is used during HCI
> controller initialization, the initialization fails rendering the USB
> dongle not usable.
> 
>> [59.464099] usb 1-1.3: new full-speed USB device number 11 using xhci_hcd
>> [59.561617] usb 1-1.3: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
>> [59.561642] usb 1-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>> [59.561656] usb 1-1.3: Product: UGREEN BT6.0 Adapter
>> [61.720116] Bluetooth: hci1: command 0x1005 tx timeout
>> [61.720167] Bluetooth: hci1: Opcode 0x1005 failed: -110
> 
> This patch was tested with the 33fa:0012 device. Now the device is
> initialized properly:
> 
>> [43.329852] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
>> [43.446790] usb 1-1.4: New USB device found, idVendor=33fa, idProduct=0012, bcdDevice=88.91
>> [43.446813] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
>> [43.446821] usb 1-1.4: Product: UGREEN BT6.0 Adapter
>> [43.582024] Bluetooth: hci1: Unexpected continuation: 1 bytes
>> [43.703025] Bluetooth: hci1: Unexpected continuation: 1 bytes

As a normal user reading the logs and seeing the warning, I wouldn’t 
know what to do. So, I’d elaborate, that it’s probably a controller (of 
the dongle) issue, and, if at all, should be reported to the hardware 
vendor.

… Unexpected continuation: 1 bytes. This is likely a problem with the 
Bluetooth device and should be reported to the manufacturer.

>> [43.750141] Bluetooth: MGMT ver 1.23
> 
> Signed-off-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>
> Tested-by: Arkadiusz Bokowy <arkadiusz.bokowy@gmail.com>

I believe, the author does not need to add a dedicated Tested-by: tag, 
as it’s kind of expected. But I am not 100 % sure 
(`Documentation/process/5.Posting.rst` does not handle the case) and 
it’s not important.

> ---
>   drivers/bluetooth/btusb.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8085fabad..24a249d1c 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -1192,6 +1192,18 @@ 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;
> +			}
> +
>   			/* Complete frame */
>   			btusb_recv_event(data, skb);
>   			skb = NULL;


Kind regards,

Paul