CSR8510 A10 fake clone Bluetooth fix for Linux

Patched btusb driver for fake CSR8510 A10 / Barrot 8041a02 USB Bluetooth dongles (0a12:0001), packaged as DKMS. Kernels 5.15 – 7.1+. Ubuntu, Debian, Fedora, Arch, CachyOS, SteamOS.

View on GitHub →

Is this your device?

You are in the right place if lsusb and dmesg show:

ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
usb: Product: CSR8510 A10, idVendor=0a12, idProduct=0001, bcdDevice=25.20
Bluetooth: hci0: CSR: Setting up dongle with HCI ver=9 rev=3120
Bluetooth: hci0: LMP ver=9 subver=22bb; manufacturer=10

and Bluetooth fails with any of these errors

Bluetooth: hci0: Opcode 0x0c03 failed: -110
Bluetooth: hci0: command 0x1001 tx timeout
Bluetooth: hci0: CSR: Local version failed (-32)
Bluetooth: hci0: Opcode 0x0c25 failed: -110
Can't init device hci0: Connection timed out (110)

Typical symptoms: the dongle works on Windows but not on Linux, bluetoothctl show prints “No default controller available”, the adapter disappears from GNOME/KDE settings, or hciconfig hci0 up times out.

There is also a quieter failure with no error in the usual places: the adapter comes up looking perfectly healthy, but the Bluetooth panel of your desktop never finds a single device — while bluetoothctl scan on in a terminal finds them straight away. See LE that only looked broken.

Why it happens

These are cheap clone chips (Barrot 8041a02 and similar) sold as “Bluetooth 5.0/5.1/5.3 USB adapter” — ORICO BTA-403, Орбита OT-PCB13 and countless no-name AliExpress dongles. They squat the VID/PID of a real Cambridge Silicon Radio chip but return malformed HCI responses.

Known fake bcdDevice values: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891.

The stock kernel already detects them (“Unbranded CSR clone detected”), but its workarounds are not enough for this hardware. This patch additionally:

• stops Read Page Scan Type 0x0c46 — which these clones answer with a truncated payload — from ever being sent, by clearing its bit in the Supported Commands bitmap the clone advertises;
• pads the undersized Command Complete payloads returned for Read Voice Setting 0x0c25, Read Transmit Power Level 0x0c2d and 0x0c46. 0x0c25 is left advertised on purpose: since v6.15 the core reads an unsupported Read Voice Setting as “no SCO” and zeroes the SCO buffer count, disabling HFP audio;
• fixes the fragile USB runtime-PM force-suspend workaround;
• auto-recovers with a USB reset from init failures and command timeouts, including a dongle that answers nothing at all — not even the very first Reset (0x0c03) — instead of leaving the controller stuck.

Only detected fake devices are affected. Real CSR hardware is untouched.

Install

Ubuntu / Debian

sudo apt install git dkms linux-headers-$(uname -r)
git clone https://github.com/hhsnake/csr8510-fix.git
cd csr8510-fix
sudo ./install.sh

Fedora

sudo dnf install git dkms kernel-devel-$(uname -r)
git clone https://github.com/hhsnake/csr8510-fix.git
cd csr8510-fix
sudo ./install.sh

Arch Linux

sudo pacman -S git dkms linux-headers bluez-utils
sudo systemctl enable --now bluetooth
git clone https://github.com/hhsnake/csr8510-fix.git
cd csr8510-fix
sudo ./install.sh

CachyOS

sudo pacman -S --needed git dkms bluez bluez-utils \
  "$(pacman -Qoq /usr/lib/modules/$(uname -r)/vmlinuz)-headers"
sudo systemctl enable --now bluetooth
git clone https://github.com/hhsnake/csr8510-fix.git
cd csr8510-fix
sudo ./install.sh

SteamOS

The root filesystem is read-only and ships without a package database, so it has to be opened up first. The kernel is taken along with its headers on purpose: SteamOS images usually run one revision behind the only headers the repository carries, and DKMS refuses to build until the two match.

sudo steamos-readonly disable
sudo pacman-key --init
sudo pacman-key --populate
sudo pacman -Sy

K=$(pacman -Qoq /usr/lib/modules/$(uname -r)/vmlinuz)
sudo pacman -S --needed git dkms gcc make bc bluez bluez-utils "$K" "$K-headers"
sudo systemctl enable --now bluetooth
sudo reboot

After the reboot:

git clone https://github.com/hhsnake/csr8510-fix.git
cd csr8510-fix
sudo ./install.sh

SteamOS updates remove the module. The system updates by replacing the whole root image (A/B slots), so /usr/lib/modules, /usr/src and the steamos-readonly disable state are all reset. Re-run install.sh after each system update, or keep the built .ko on /home — that partition survives updates — and load it from a systemd unit.

The module is installed to /lib/modules/<ver>/updates/dkms/, which takes precedence over the stock module — nothing in the kernel is overwritten — and DKMS rebuilds it automatically on every kernel update.

Verify

dkms status csr8510-fix                      # -> installed
modinfo -F filename btusb                    # -> .../updates/dkms/btusb.ko(.zst)
journalctl -kf | grep -iE 'bluetooth|csr'    # then plug in the dongle

Uninstall

sudo ./uninstall.sh

Supported kernels

Variant	Used for kernels	Tested on
src/5.15	< 5.19	5.15.0-185-generic (Ubuntu 22.04)
src/5.19	5.19 – 6.1	5.19.0-50-generic (Ubuntu 22.04)
src/6.2	6.2 – 6.4	6.2.0-39-generic (Ubuntu 22.04)
src/6.5	6.5 – 6.7	6.5.0-45-generic (Ubuntu 22.04)
src/6.8	6.8 – 6.10	6.8.0-94, 6.8.0-134-generic (Ubuntu 22.04)
src/6.11	6.11 – 6.13	6.11.0-29-generic (Ubuntu 24.04); 6.11.4-301.fc41
src/6.14	6.14 – 6.16	6.14.0-37-generic (Ubuntu 24.04); 6.16.12-valve24.5-1-neptune-616 (SteamOS 3.8.14)
src/6.17	≥ 6.17	6.17.0-35, 7.0.0-14-generic (Ubuntu 24.04); 6.17.10-100.fc41; 6.19.10-300.fc44, 7.1.4-200.fc44; 7.1.4-arch1-1, 6.18.39-1-lts, 7.1.4-zen1-1 (Arch); 7.1.8-1-cachyos

The right variant is picked automatically at build time.

Building your own kernel instead?

Apply the matching diff from patches/:

cd linux-<version>
patch -p1 < .../patches/csr8510-fix-6.17.patch

LE that only looked broken

These clones report Bluetooth LE in their local features, and early on that looked like a lie: LE commands came back as failures and desktop discovery died on the LE half.

Bluetooth: hci0: Opcode 0x2005 failed: -32     # LE Set Random Address
Bluetooth: hci0: Opcode 0x200b failed: -32     # LE Set Scan Parameters

Desktop Bluetooth stacks start discovery in dual mode, so a failing LE half aborts the whole scan and nothing is ever found — while bluetoothctl scan on still works, because it falls back to BR/EDR. Nothing looks broken: hciconfig shows UP RUNNING with a valid BD address, and the controller answers everything else. That combination makes the fault read as a desktop bug rather than a controller one.

Already-paired devices keep connecting normally, because that path does not involve discovery — which is why this is easy to miss until you try to add a new device.

The controller answers LE commands correctly. The real fault is two BR/EDR replies that come back a byte short, and the driver stops the core from asking for them — so LE is left alone and simply works.

Only devices matching 0a12:0001 and detected as fake are affected. Other adapters in the same machine are untouched.

To rule the workaround out while debugging:

# /etc/modprobe.d/csr8510-fix.conf
options btusb csr_mask_commands=0

If LE still misbehaves on your clone. Firmware varies between these dongles. Forcing bluetoothd to BR/EDR is the fallback — note it is a global setting that disables LE for every controller on the host, including a working built-in one.

# /etc/bluetooth/main.conf
[General]
ControllerMode = bredr

sudo systemctl restart bluetooth

Troubleshooting

• Nothing is found after installing, although the adapter looks fine — reloading the module (which install.sh does at the end) rebinds the driver without re-enumerating the device, so the receive-issue workaround is skipped. Unplug the dongle and plug it back in. A USB reset or systemctl restart bluetooth is not enough: the controller ignores an in-band Reset (0x0c03).
• Secure Boot — the module is signed automatically if DKMS MOK signing is set up; otherwise enroll a key (man mokutil) or disable Secure Boot.
• Two Bluetooth adapters — a built-in controller may interfere. Disable it for testing: rfkill list, then rfkill block <id>.
• module verification failed ... tainting kernel in dmesg is harmless on machines without Secure Boot — it only means the module is unsigned.

По-русски

Не работает Bluetooth-адаптер 0a12:0001 «CSR8510 A10» в Linux — Ubuntu, Debian, Fedora, Arch, CachyOS, SteamOS? Это дешёвый клон на чипе Barrot 8041a02, который продаётся как «Bluetooth 5.0 USB адаптер» (ORICO BTA-403, Орбита OT-PCB13 и безымянные донглы с AliExpress). В Windows он работает, в Linux — нет: bluetoothctl пишет «No default controller available», а в dmesg видно Opcode 0x0c03 failed: -110 или command 0x1001 tx timeout.

Бывает и тише: адаптер поднимается как ни в чём не бывало, но поиск устройств из настроек рабочего стола не находит ничего, хотя bluetoothctl scan on в терминале находит сразу. Это тот же клон — он заявляет поддержку LE, которой у него нет. Подробности в разделе LE that only looked broken.

Решение — исправленный драйвер btusb, собираемый через DKMS (пересобирается сам при обновлении ядра, штатный модуль не затирается). Команды установки — в разделе Install выше; исходники и баг-репорты — на GitHub.

Questions & feedback

Bug reports, questions and suggestions are welcome in GitHub Issues. When reporting, please attach the output of uname -r, lsusb | grep 0a12 and journalctl -k | grep -iE 'bluetooth|csr'.