[ARCHIVED] Fix for CSR Dongle 0a12:0001 ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

archived.md

This gist is currenctly archived.

Please refer to previous revisions if you know what to do.

The patch proposed was merged into kernel in 5.8 release, but no longer working as of linux 5.11

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

The CSR's barely work on Windows even. Maybe for very basic stuff. But, if it says that it has Bluetooth LE and advanced features, it definitely does not, or if it does, it's extremely broken.

well the one i have is tp-link ub400, thought they were a reputable brand

These CSR clones are not one device. They use the same case, but there may be different chips inside. They simply use the API from an existing driver so as not to write their own. But they only test it on Windows. Since different chips are used, their firmware has a variety of bugs, so workarounds for one clone will not help for another.

The CSR's barely work on Windows even. Maybe for very basic stuff. But, if it says that it has Bluetooth LE and advanced features, it definitely does not, or if it does, it's extremely broken.

well the one i have is tp-link ub400, thought they were a reputable brand

TP-Link should be a good one. But, the generic no-name ones like one I posted pictures to above is awful even on Windows.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

Chinese manufacturers produce identical looking Bluetooth dongles with different chips. They use new chips over time. So you can't have one firmware to fix them all.

I wonder if it's possible to rewrite and reflash the firmware of the CSR Clones. They could be an interesting thing for a common open-source firmware. The device is awful, but it's extremely common and cheap.

Chinese manufacturers produce identical looking Bluetooth dongles with different chips. They use new chips over time. So you can't have one firmware to fix them all.

Ah, that's unfortunate.

Not sure if this is mentioned or no since this gist is too long...
Plugging the cheap USB Bluetooth adapter in the USB 2.0 port was the fix for me (prev. was in USB 3.0 [the blue one])

Yes, that was also my biggest take home message
https://bugzilla.kernel.org/show_bug.cgi?id=60824#c167

Found this patch, but it's for a newer kernel:

--- a/net/bluetooth/hci_sync.c	2025-07-28 20:25:38.718355109 -0300
+++ b/net/bluetooth/hci_sync.c	2025-07-28 20:30:02.004160831 -0300
@@ -3960,8 +3960,6 @@
 	HCI_INIT(hci_write_inquiry_mode_sync),
 	/* HCI_OP_READ_INQ_RSP_TX_POWER */
 	HCI_INIT(hci_read_inq_rsp_tx_power_sync),
-	/* HCI_OP_READ_LOCAL_EXT_FEATURES */
-	HCI_INIT(hci_read_local_ext_features_1_sync),
 	/* HCI_OP_WRITE_AUTH_ENABLE */
 	HCI_INIT(hci_write_auth_enable_sync),
 	{}
@@ -4252,8 +4250,6 @@
 	HCI_INIT(hci_read_def_err_data_reporting_sync),
 	/* HCI_OP_READ_PAGE_SCAN_TYPE */
 	HCI_INIT(hci_read_page_scan_type_sync),
-	/* HCI_OP_READ_LOCAL_EXT_FEATURES */
-	HCI_INIT(hci_read_local_ext_features_all_sync),
 	{}
 };

There's no net/bluetooth/hci_sync.c in 5.15.

I made additional patch for 5.15, now all my adapters work more or less. Even with the other IDs, 33fa:0010, 33fa:0012 from UGREEN.

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 7ed5d6e..0f16d88 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -482,6 +482,7 @@ static int hci_init2_req(struct hci_request *req, unsigned long opt)
 	if (lmp_inq_tx_pwr_capable(hdev))
 		hci_req_add(req, HCI_OP_READ_INQ_RSP_TX_POWER, 0, NULL);
 
+	if (0) // FIX
 	if (lmp_ext_feat_capable(hdev)) {
 		struct hci_cp_read_local_ext_features cp;
 
@@ -797,6 +798,7 @@ static int hci_init3_req(struct hci_request *req, unsigned long opt)
 	}
 
 	/* Read features beyond page 1 if available */
+	if (0) // FIX
 	for (p = 2; p < HCI_MAX_PAGES && p <= hdev->max_page; p++) {
 		struct hci_cp_read_local_ext_features cp;
 

If anyone still needs a fix — I've packaged the btusb patch as a DKMS module, so there's nothing to apply by hand and it rebuilds itself on kernel updates: https://github.com/hhsnake/csr8510-fix

It targets the fake CSR8510 A10 / "Bluetooth 5.x" dongles (0a12:0001, Barrot 8041a02 and similar) that fail with CSR: Local version failed (-32), command 0x1001 tx timeout or Opcode 0x0c03/0x0c25 failed: -110.

On top of the stock kernel workarounds it:

• pads the undersized HCI Command Complete responses (0x0c25, 0x0c2d, 0x0c46) so HCI init survives;
• fixes the fragile USB runtime-PM workaround;
• auto-recovers via USB reset on init failures and command timeouts — including a dongle that answers nothing at all;
• hides the LE support these clones advertise but don't implement (that's why desktop Bluetooth panels find no devices while bluetoothctl scan on works fine).

Real CSR hardware is untouched — only devices detected as clones are affected.

Patches for 5.15 through 6.17 (kernels 5.15 – 7.1+), with install instructions for Ubuntu/Debian, Fedora, RED OS 7/8, Arch, CachyOS and SteamOS.

So your LLM stripped out all the credits, refactored the workaround and mixed their own stuff on top. While using some of our detection research here and comments almost verbatim in the ReadMe, selling it as novel work.

You know that the original patches have been merged even by linux-stable and most dongles already work out of the box, right?

Please don't let your LLM answer for you.

To Swyter: (old-style mailing ;) This patch was originally created by analyzing the transmission protocol used by the proprietary dongle drivers on Windows, and implementing similar behavior in the Linux kernel code. What I did use was comparing it afterwards with solutions from other places — bugzilla, other repositories. I didn't compare it to this gist.

As for the verbatim text — I took it from the kernel code in drivers/bluetooth/btusb.c, you can take a look there yourself.

Of course, after reading it, I now understand that those changes in the kernel came from this thread. Okay — I don't mind if someone submits my changes to the kernel as well. I just wanted a patch that works right here and now, because I couldn't find a single working version for this dongle.