Summary: CSR Bt dongle became unusable after upgrading from 3.9 (make oldconfig) 3.9: root@enkidu4:/home/enkidu# hciconfig hci0 hci0: Type: BR/EDR Bus: USB BD Address: 00:1B:10:00:23:9A ACL MTU: 1017:8 SCO MTU: 64:0 UP RUNNING PSCAN RX bytes:922 acl:0 sco:0 events:35 errors:0 TX bytes:404 acl:0 sco:0 commands:35 errors:0 3.11 root@enkidu4:/home/enkidu# hciconfig hci0 hci0: Type: BR/EDR Bus: USB BD Address: 00:1B:10:00:23:9A ACL MTU: 1017:8 SCO MTU: 64:0 DOWN RX bytes:922 acl:0 sco:0 events:35 errors:0 TX bytes:404 acl:0 sco:0 commands:35 errors:0 root@enkidu4:/home/enkidu# hciconfig hci0 up Can't init device hci0: Operation not supported (95)
Hi, Could please run btmon utility to collect HCI logs. You can find btmon in the bluez sources. Start the btmon and then in another shell run: $ hciconfig hci0 down $ hciconfig hci0 up And attach the logs here.
Hi, I don't have btmon atm, but I have attached log of `hcidump -X` while running `hciconfig hci0 up` on 3.11: HCI sniffer - Bluetooth packet analyzer ver 2.5 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Features (0x04|0x0003) ncmd 1 status 0x00 Features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80 < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 status 0x00 HCI Version: 2.0 (0x3) HCI Revision: 0x3000 LMP Version: 2.0 (0x3) LMP Subversion: 0x420b Manufacturer: Broadcom Corporation (15) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 > HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 1 status 0x00 bdaddr 00:1B:10:00:23:9A < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 > HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 1 status 0x00 ACL MTU 1017:8 SCO MTU 64:0 < HCI Command: Read Class of Device (0x03|0x0023) plen 0 > HCI Event: Command Complete (0x0e) plen 7 Read Class of Device (0x03|0x0023) ncmd 1 status 0x00 class 0x420100 < HCI Command: Read Local Name (0x03|0x0014) plen 0 > HCI Event: Command Complete (0x0e) plen 252 Read Local Name (0x03|0x0014) ncmd 1 status 0x00 name 'enkidu4-0' < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 > HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 1 status 0x00 voice setting 0x0060 < HCI Command: Set Event Filter (0x03|0x0005) plen 1 type 0 condition 0 Clear all filters > HCI Event: Command Complete (0x0e) plen 4 Set Event Filter (0x03|0x0005) ncmd 1 status 0x00 < HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2 timeout 32000 > HCI Event: Command Complete (0x0e) plen 4 Write Connection Accept Timeout (0x03|0x0016) ncmd 1 status 0x00 < HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 > HCI Event: Command Complete (0x0e) plen 8 Read Page Scan Activity (0x03|0x001b) ncmd 1 status 0x00 interval 2048 window 18 < HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 > HCI Event: Command Complete (0x0e) plen 5 Read Page Scan Type (0x03|0x0046) ncmd 1 0000: 00 00 .. < HCI Command: Set Event Mask (0x03|0x0001) plen 8 Mask: 0xfffffbff07180000 > HCI Event: Command Complete (0x0e) plen 4 Set Event Mask (0x03|0x0001) ncmd 1 status 0x00 < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0 > HCI Event: Command Complete (0x0e) plen 68 Read Local Supported Commands (0x04|0x0002) ncmd 1 status 0x00 Commands: ffffffffffffcfffffffffff0300ffff07 < HCI Command: Write Inquiry Mode (0x03|0x0045) plen 1 mode 1 > HCI Event: Command Complete (0x0e) plen 4 Write Inquiry Mode (0x03|0x0045) ncmd 1 status 0x00 < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1 page 1 > HCI Event: Command Complete (0x0e) plen 14 Read Local Extended Features (0x04|0x0004) ncmd 1 status 0x00 page 1 max 0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 bdaddr 00:00:00:00:00:00 all 1 > HCI Event: Command Complete (0x0e) plen 4 Delete Stored Link Key (0x03|0x0012) ncmd 1 status 0x11 deleted 0 Error: Unsupported Feature or Parameter Value If needed, I can also attach logs for 3.9 but it seems, that after applying patch to solve Delete Stored Link Key on broadcom devices, something went wrong on CSR. Also, binary dump is attached.
Created attachment 107378 [details] binary dump of hcidump
Yes, please add the logs from 3.9 where it works. Your Bluetooth controller reports that you actually support the Delete Stored Link Key, but then fail to run the command properly. Only the text logs are needed, no binaries.
here we go with 3.9: < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Features (0x04|0x0003) ncmd 1 status 0x00 Features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80 < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 status 0x00 HCI Version: 2.0 (0x3) HCI Revision: 0x3000 LMP Version: 2.0 (0x3) LMP Subversion: 0x420b Manufacturer: Broadcom Corporation (15) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 > HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 1 status 0x00 bdaddr 00:1B:10:00:23:9A < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 > HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 1 status 0x00 ACL MTU 1017:8 SCO MTU 64:0 < HCI Command: Read Class of Device (0x03|0x0023) plen 0 > HCI Event: Command Complete (0x0e) plen 7 Read Class of Device (0x03|0x0023) ncmd 1 status 0x00 class 0x000000 < HCI Command: Read Local Name (0x03|0x0014) plen 0 > HCI Event: Command Complete (0x0e) plen 252 Read Local Name (0x03|0x0014) ncmd 1 status 0x00 name 'enkidu4-0' < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 > HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 1 status 0x00 voice setting 0x0060 < HCI Command: Set Event Filter (0x03|0x0005) plen 1 type 0 condition 0 Clear all filters > HCI Event: Command Complete (0x0e) plen 4 Set Event Filter (0x03|0x0005) ncmd 1 status 0x00 < HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2 timeout 32000 > HCI Event: Command Complete (0x0e) plen 4 Write Connection Accept Timeout (0x03|0x0016) ncmd 1 status 0x00 < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 bdaddr 00:00:00:00:00:00 all 1 > HCI Event: Command Complete (0x0e) plen 4 Delete Stored Link Key (0x03|0x0012) ncmd 1 status 0x11 deleted 0 Error: Unsupported Feature or Parameter Value < HCI Command: Set Event Mask (0x03|0x0001) plen 8 Mask: 0xfffffbff07180000 > HCI Event: Command Complete (0x0e) plen 4 Set Event Mask (0x03|0x0001) ncmd 1 status 0x00 < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0 > HCI Event: Command Complete (0x0e) plen 68 Read Local Supported Commands (0x04|0x0002) ncmd 1 status 0x00 Commands: ffffffffffffcfffffffffff0300ffff07 < HCI Command: Write Inquiry Mode (0x03|0x0045) plen 1 mode 1 > HCI Event: Command Complete (0x0e) plen 4 Write Inquiry Mode (0x03|0x0045) ncmd 1 status 0x00 < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1 page 1 > HCI Event: Command Complete (0x0e) plen 14 Read Local Extended Features (0x04|0x0004) ncmd 1 status 0x00 page 1 max 0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 < HCI Command: Write Default Link Policy Settings (0x02|0x000f) plen 2 policy 0x0f Link policy: RSWITCH HOLD SNIFF PARK > HCI Event: Command Complete (0x0e) plen 4 Write Default Link Policy Settings (0x02|0x000f) ncmd 1 status 0x00 < HCI Command: Write Scan Enable (0x03|0x001a) plen 1 enable 2 > HCI Event: Command Complete (0x0e) plen 4 Write Scan Enable (0x03|0x001a) ncmd 1 status 0x00 < HCI Command: Write Class of Device (0x03|0x0024) plen 3 class 0x420100 > HCI Event: Command Complete (0x0e) plen 4 Write Class of Device (0x03|0x0024) ncmd 1 status 0x00 < HCI Command: Write Local Name (0x03|0x0013) plen 248 name 'enkidu4-0' > HCI Event: Command Complete (0x0e) plen 4 Write Local Name (0x03|0x0013) ncmd 1 status 0x00 < HCI Command: Write Scan Enable (0x03|0x001a) plen 1 enable 3 > HCI Event: Command Complete (0x0e) plen 4 Write Scan Enable (0x03|0x001a) ncmd 1 status 0x00 < HCI Command: Write Class of Device (0x03|0x0024) plen 3 class 0x520100 > HCI Event: Command Complete (0x0e) plen 4 Write Class of Device (0x03|0x0024) ncmd 1 status 0x00
Created attachment 107379 [details] mark Delete Stored Keys as non-critical failure Please apply this patch and check if it works. Also capture logs and send them here. This is a modified version of a patch Johan Hedberg did some time ago.
It seems to work: hciconfig hci0 up really brings dongle up an pairing is possible. Thank you for quick patch
This patch is not ready for upstream, could you please give more information. It would be good have a look on the output of /sys/kernel/debug/usb/devices for the bluetooth controller. Can you provide this?
of course I can: T: Bus=02 Lev=01 Prnt=01 Port=08 Cnt=03 Dev#= 9 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a12 ProdID=0001 Rev= 1.00 S: Manufacturer=Bluetooth v2.0 S: Product=Bluetooth V2.0 Dongle C:* #Ifs= 4 Cfg#= 1 Atr=a0 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=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) 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=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
I had the same problem. I have tested on ARM dove 3.11.0 - works fine.
I had the same problem too, but patch fixes it. Latest working kernel version: 3.9.11 Earliest failing kernel version: 3.10.1 (didn't test with rc versions) lsusb: Bus 006 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) /sys/kernel/debug/usb/devices: same as posted by M. Wisniewsk, except first line: T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
Also a problem on Fedora 18 Kernel 3.10 onwards. 3.9.11 is fine. From /sys/kernel/debug/usb/devices :- T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a12 ProdID=0001 Rev= 0.07 C:* #Ifs= 2 Cfg#= 1 Atr=00 MxPwr= 0mA 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=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) 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=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I have the same dongle with the same issue. It has CSR's USB vendor:product ID and Broadcom's HCI manufacturer ID, returns the same set of local commands, but doesn't actually support HCI_Delete_Stored_Link_Key. I worked around it with a quirk, but the above patch also works for me.
Hi I have the same issue with a pretty similar device and this patch fixed my issue too. Hope to see it merged soon. 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bug 60847 seems to be a duplicate of this bug. What is preventing the patch to be merged? Without this, the Bluetooth dongle doesn't work.
Hi, I have this issue with my bluetooth dongle and 3.10.25 kernel realease..I installed bluez bluez-utils and bluetooth on my raspbian. I see that the patch in attachment fix this issue but I don't find the files to modify bluetooth.h, hci_core.h, hci_core.c on my system. Where am I doing wrong? Thanks Andrea
This regression bug renders Raspberry Pi with Bluetooth devices unusable. Unless the patch makes it into Raspbian, many popular dongles won't work. Building a custom kernel on rPi is not an option for the most of us. Is there are a chance of the patch being accepted any time soon, please?
Bugzilla is just tracking its existence - if you want it fixed then I would raise it with linux-bluetooth@vger.kernel.org
I was writing under assumption that they have access to this information since the email address you provided is also in the "Assigned-To" field in the form above. So i thought they will be getting updates from this thread too. (In reply to Alan from comment #18) > Bugzilla is just tracking its existence - if you want it fixed then I would > raise it with linux-bluetooth@vger.kernel.org
Hi, Isn't that already fixed in bluetooth-next? https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f9f462faa02777f497eb25255683a94e0c054de6 br Szymon
I don't have these files in my kernel...Then the only solution is build a custom kernel? thanks Andrea
> andreap (Comment 21) Yes, at lest for now. > Szymon Janc (Comment 20) Judging from information i googled, attached patch is original one and patch in https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f9f462faa02777f497eb25255683a94e0c054de6 is modified "more elegant" one, however the elegant one does not work in all cases... at least not with Cambridge Silicon Radio chips.
I don't know since when, but with linux 3.14.1, the bluetooth dongle works again (at least for me). [ 19.181078] Bluetooth: Core ver 2.18 [ 19.181130] NET: Registered protocol family 31 [ 19.181133] Bluetooth: HCI device and connection manager initialized [ 19.181152] Bluetooth: HCI socket layer initialized [ 19.181156] Bluetooth: L2CAP socket layer initialized [ 19.181182] Bluetooth: SCO socket layer initialized [ 19.211473] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 19.211482] Bluetooth: BNEP filters: protocol multicast [ 19.211502] Bluetooth: BNEP socket layer initialized [33132.996728] usb 3-1: new full-speed USB device number 3 using uhci_hcd [33133.643196] usbcore: registered new interface driver btusb [33135.084957] Bluetooth: RFCOMM TTY layer initialized [33135.084982] Bluetooth: RFCOMM socket layer initialized [33135.084998] Bluetooth: RFCOMM ver 1.11
I have the same problem running kernel 3.16. `uname -a`: Linux deneb 3.16.0-25-generic #33-Ubuntu SMP Fri Nov 7 01:53:40 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux I am using Linux Mint 17 64 bits with the described Bluetooth adapter. `lsusb`: .... Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) .... As you have said, there are two different patches (elegant and non-elegant). I see that my kernel (3.16.0-25) has the elegant patch, but not the non-elegant and I can confirm that my bluetooth doesn't work. I see that this non-elegant change hasn't been added to the new kernel versions. Is there any reason for that? Thanks! Carlos
(In reply to Carlos from comment #24) > I have the same problem running kernel 3.16. `uname -a`: > > Linux deneb 3.16.0-25-generic #33-Ubuntu SMP Fri Nov 7 01:53:40 UTC 2014 > x86_64 x86_64 x86_64 GNU/Linux > > I am using Linux Mint 17 64 bits with the described Bluetooth adapter. > `lsusb`: > > .... > Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth > Dongle (HCI mode) Could you also provide the HCI log of the failure? If it's this same HCI command that's failing then we'd just need to find a way to set the new quirk flag for your device.
Created attachment 162171 [details] 'hcidump -X' while executing 'hciconfig hci0 up' for carlosgarciaq
Created attachment 162181 [details] contents of /sys/kernel/debug/usb/devices for carlosgarciaq
Yeap, this is the exit of 'hcidump -X' while I try to pair with a bluetooth headset using blueman-manager: HCI sniffer - Bluetooth packet analyzer ver 2.5 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 0 bdaddr 00:1E:3D:F1:4D:75 type ACL encrypt 0x00 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 0 Features: 0xbf 0x2f 0x83 0xfa 0x88 0x39 0x00 0x80 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 0 reason 0x08 Reason: Connection Timeout > HCI Event: Command Complete (0x0e) plen 4 Unknown (0x00|0x0020) ncmd 1 0000: 00 In my first attachement, you can find the 'hcidump -X' while doing: sudo hciconfig hci0 down sudo hciconfig hci0 up In my second attachment, you'll find the contents of /sys/kernel/debug/usb/devices Thanks! Let me know if this is not what you wanted. Regards, Carlos
I'm having the same problem here, kernel 4.20.17. btmon shows error at Delete Stored Link Key with hciconfig hci0 up, unsupported feature based on https://bugzilla.kernel.org/show_bug.cgi?id=103451 it seems that my dongle is also a fake (mismatch between bcdDevice and LMP subversion), but with bcdDevice 88.91, which isn't covered by the kernel (currently covers 1.00 and 1.34)
Well, I tried to build a custom kernel (4.19.55) with my bcdDevice and LMP subversion included in the btusb.c file. btmon shows promise, hcitool dev actually shows a device, but dmesg | grep tooth reveals that I'm stuck at HCI_OP_READ_LOCAL_VERSION, apparently it times out, reading hci0: command 0x1001 tx timeout and CSR: Local version failed (-110)
After resetting btusb driver with sudo modprobe -r btusb and sudo modprobe btusb, I can confirm that the bluetooth dongle is working What I had to do was add bcdDevice 0x8891 and lmp_subver 0x0811 to the quirk related functions. Inquiry command 0x1001 still timeouts, which necessitates the forced driver load, but once it loads it works
(In reply to raestloz from comment #31) > After resetting btusb driver with sudo modprobe -r btusb and sudo modprobe > btusb, I can confirm that the bluetooth dongle is working > > What I had to do was add bcdDevice 0x8891 and lmp_subver 0x0811 to the quirk > related functions. Inquiry command 0x1001 still timeouts, which necessitates > the forced driver load, but once it loads it works i have this problem in kernel 5.2.5 :(
Same here: 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode). But the product name is: JL AC69 A10 I tested in Linux 5.2.8-1-MANJARO, and the 4.19.57-1-MANJARO. The problems are: - After booting up the OS with the BT Dongle in, if I try to 'sudo bluetoothctl power on', it fails and 'btmon' returns this: @ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 34.681295 Powered: Enabled (0x01) = Open Index: 00:1A:7D:DA:71:10 [hci0] 34.743182 < HCI Command: Reset (0x03|0x0003) plen 0 #2 [hci0] 34.743412 = Close Index: 00:1A:7D:DA:71:10 [hci0] 44.768939 @ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0] 44.772086 Set Powered (0x0005) Status: Failed (0x03) = bluetoothd: Failed to set mode: Failed (0x03) [hci0] 44.790305 If I unplug and plug it back, the power on command will work fine. If it is set to AutoEnable on /etc/bluetooth/main.conf, it will also be powered up after plugin it back. If I power off, it will only work again if I unplug and plug it back. So it's not a big problem. The big deal is that I can't make it to scan: $ sudo bluetoothctl scan on bluetoothd[2358]: src/adapter.c:start_discovery() sender :1.268 bluetoothd[2358]: src/adapter.c:update_discovery_filter() bluetoothd[2358]: src/adapter.c:discovery_filter_to_mgmt_cp() bluetoothd[2358]: src/adapter.c:trigger_start_discovery() bluetoothd[2358]: src/adapter.c:cancel_passive_scanning() bluetoothd[2358]: src/adapter.c:start_discovery_timeout() bluetoothd[2358]: src/adapter.c:start_discovery_timeout() adapter->current_discovery_filter == 0 bluetoothd[2358]: src/adapter.c:start_discovery_complete() status 0x03 @ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0] 37.252439 Address type: 0x07 BR/EDR LE Public LE Random < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #81 [hci0] 37.252583 Address: 06:4D:6A:64:58:36 (Non-Resolvable) < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #82 [hci0] 39.423752 Type: Active (0x01) Interval: 22.500 msec (0x0024) Window: 11.250 msec (0x0012) Own address type: Random (0x01) Filter policy: Accept all advertisement (0x00) @ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 39.423747 Start Discovery (0x0023) plen 1 Status: Failed (0x03) Address type: 0x07 BR/EDR LE Public LE Random < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #83 [hci0] 41.557120 Scanning: Enabled (0x01) Filter duplicates: Enabled (0x01) < HCI Command: Inquiry (0x01|0x0001) plen 5 #84 [hci0] 43.690407 Access code: 0x9e8b33 (General Inquiry) Length: 10.24s (0x08) Num responses: 0 I will try to apply the patch and compile the kernel to see if I can get it to work. It's crazy to think this thread started in November 2013, and currently there are many of those CSR dongles being sold.
(In reply to Arthur Fragoso from comment #33) > Same here: > > 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode). > > But the product name is: JL AC69 A10 > > I tested in Linux 5.2.8-1-MANJARO, and the 4.19.57-1-MANJARO. > > The problems are: > > - After booting up the OS with the BT Dongle in, if I try to 'sudo > bluetoothctl power on', it fails and 'btmon' returns this: > ... > I will try to apply the patch and compile the kernel to see if I can get it > to work. It's crazy to think this thread started in November 2013, and > currently there are many of those CSR dongles being sold. At least it somehow works for you ! I just recently got one in attempt to "upgrade" from 2.1 to 4.0 (also 0a12:0001) and have a spare for my Sony DualShocks 3&4. It works under Windows but I don't actually remember if I managed to successfully test it under Linux. Under kernel 5.2.8 bluez acts if it wasn't there but in reality it fails with this ridiculous "Delete Stored Link Key: Unsupported Feature or Parameter Value". btusb does not have 'quirks' option and adding 'quirks=0a12:0001:HCI_QUIRK_BROKEN_STORED_LINK_KEY' to usbcore doesn't seem to be doing anything. But neither you or me are going to use that patch because BT stack was completely rewritten and its logic is completely different now. If developers don't want to ignore failures to initiate such "important" optional functions and enable quirks automatically on pre-init sanity check then at least someone could have said somewhere how to enable the damn things at runtime without hard-coding IDs of your random noname dongles into kernel's code… How the hell people are using those BT quirks ?
The code for these devices are bellow. You are right, the patch is way too old for this. I will probably buy a different device while we wait for someone with more knowledge to fix this. /linux/drivers/bluetooth/btusb.c kenel 5.2.8 static const struct usb_device_id blacklist_table[] = { /* CSR BlueCore devices */ { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_CSR }, static int btusb_setup_csr(struct hci_dev *hdev) { struct hci_rp_read_local_version *rp; struct sk_buff *skb; BT_DBG("%s", hdev->name); skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT); if (IS_ERR(skb)) { int err = PTR_ERR(skb); bt_dev_err(hdev, "CSR: Local version failed (%d)", err); return err; } if (skb->len != sizeof(struct hci_rp_read_local_version)) { bt_dev_err(hdev, "CSR: Local version length mismatch"); kfree_skb(skb); return -EIO; } rp = (struct hci_rp_read_local_version *)skb->data; /* Detect controllers which aren't real CSR ones. */ if (le16_to_cpu(rp->manufacturer) != 10 || le16_to_cpu(rp->lmp_subver) == 0x0c5c) { /* Clear the reset quirk since this is not an actual * early Bluetooth 1.1 device from CSR. */ clear_bit(HCI_QUIRK_RESET_ON_CLOSE, &hdev->quirks); /* These fake CSR controllers have all a broken * stored link key handling and so just disable it. */ set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks); } kfree_skb(skb); return 0; }
(In reply to Arthur Fragoso from comment #35) > The code for these devices are bellow. > > You are right, the patch is way too old for this. > > I will probably buy a different device while we wait for someone with more > knowledge to fix this. >... > /* Detect controllers which aren't real CSR ones. */ > if (le16_to_cpu(rp->manufacturer) != 10 || > le16_to_cpu(rp->lmp_subver) == 0x0c5c) { >... Luckily, I still have my old 2.1 dongle. It seems that this check is too specific, mine has 0x811 subversion but the real problem is idiotic notion of holding all BT devices to some imaginary standard of compliant vendor-approved behaviour and creating blacklists for actual devices only if someone from BT maintainers have heard something about some problems from someone. No normal user is going to write them letter with complains, let alone patches for hard-coded workarounds to artificial problems. They need to redo the whole initialization logic to be more generic or at least allow passing quirk-flags at runtime. There is and will be myriad of devices with random IDs and crappy firmwares, sometimes even circuitry, and kernel MUST make all that crap work at least partially, not backdown on smallest of mislabelings. It is saddening to see only recently created built-in Windows 10 BT stack to behave more sanely than bluez.
Created attachment 284525 [details] patches.hsf/btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch Made the patch based on raestloz's comments for our bcdDevice=88.91/LMP_sv=0x811 CSR 4.0 device to enable crutches that make the stack eat it up.
Hi, I merged a few fixes and quirks (including some from this thread) and sent them to linux-bluetooth@vger.kernel.org : https://www.spinics.net/lists/linux-bluetooth/msg81304.html Feel free to test it if you have a simillar CSR device (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", ATTRS{bcdDevice}=="8891"). It's not perfect, but it allows the use of the adapter and connect a headset (with some connect errors/retries now and then). Regards.
(In reply to Fernando Carvalho from comment #38) > Hi, > > I merged a few fixes and quirks (including some from this thread) and sent > them to linux-bluetooth@vger.kernel.org : > > https://www.spinics.net/lists/linux-bluetooth/msg81304.html > > Feel free to test it if you have a simillar CSR device > (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", > ATTRS{bcdDevice}=="8891"). > > It's not perfect, but it allows the use of the adapter and connect a headset > (with some connect errors/retries now and then). > > Regards. Great work ! Unlike the actual maintainers who don't even bother to read bug-tracker anymore or use ready fixes for their code that they themselves don't care about, it seems. However, I doubt that even a scrupulous maintainer would ever allow that many dedicated workaround options instead of one, in style of usbcore, usbhid and snd-hda-intel even though they all use inconsistent schemes of their own. A more reasonable approach would be passing model=vendorID:productID:<"model"> space-separated (to allow several dongles) override pairs with each having a bunch of quirk-hacks associated (as snd-hda-intel) on it, quirks=vendorID:productID:<comma separated list of all quirks> space-separated pairs (as usbcore/usbhid) or both. But that means doing even more work that can be ignored or offhandedly dismissed for code that was written without enough foresight for it in the first place.
Windows 10 doesn't exhibit the same issues with the exact same dongle, so I believe what they do is ignore the feature issues presented by dongles outright I personally don't think it's good to do that, there's a reason standards exist, so perhaps a better way is to move bluetooth driver out of kernel so fixing the driver to account for device quirks doesn't mean recompiling the entire kernel?
Created attachment 285489 [details] btusb.c: Module parameter to control multiple fixup (In reply to Sergey Kondakov from comment #39) > ... > their own. A more reasonable approach would be passing > model=vendorID:productID:<"model"> space-separated (to allow several > dongles) override pairs with each having a bunch of quirk-hacks associated > (as snd-hda-intel) on it, quirks=vendorID:productID:<comma separated list of > all quirks> space-separated pairs (as usbcore/usbhid) or both. > ... Hi, Yes, the feedback I had from the list was similar (my bad for following after the existing code :). Your suggestion was the most constructive though, so I implemented it that way. I'm uploading the patch that I'm using to play around with the fixups. I'm still trying to find out the best combination for my adapter and it may be useful to others in the same quest. PS: The syntax is a bit different from above: Syntax: fixups=<force_hex>[:<disable_hex>[:<vendor_hex>[:<model_hex>[:<bcdDevice>]]]]" PPS: Maybe I'll try a new upstream patch if/when I solve some instability it still has. Thanks.
I'm also having this problem with a generic chinese USB dongle. This specific model is the only BT 4.0 dongle available in my city, found at many stores. ``` @lsusb -v ... idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 25.20 ... ``` Everything works, execept that when I try to connect to the headset after pairing, bluetoothd hangs indefinitely, and I'm then unable to `modprobe -r btusb` because the device is now busy. Pulseaudio will never list that audio device. I applied both patches shown here and nothing changes, except btusb crashes into a neat coredump which I can see in dmesg. I would like to hardcode my `bcdDevice` to that patched `if` conditional but how to convert `bcdDevice=25.20` into something like `0x0000`? $uname -r 5.3.0-arch1-1-ARCH
(In reply to Fernando Carvalho from comment #38) > Hi, > > I merged a few fixes and quirks (including some from this thread) and sent > them to linux-bluetooth@vger.kernel.org : > > https://www.spinics.net/lists/linux-bluetooth/msg81304.html > > Feel free to test it if you have a simillar CSR device > (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", > ATTRS{bcdDevice}=="8891"). > > It's not perfect, but it allows the use of the adapter and connect a headset > (with some connect errors/retries now and then). > > Regards. I actually have two USB dongles with idVendor "0a12" and idProduct "0001". An old one purchased from webshop and a brand new one purchased in a local store with 5 years warranty. The old one does not work (as described by others), but the new one works fine with 5.3.8-arch1-1 kernel. The one that works has bcdDevice 88.91, the old one has 19.15. I don't know if your patch is already in the kernel, or I am just lucky.
(In reply to Fernando Carvalho from comment #41) > Created attachment 285489 [details] > btusb.c: Module parameter to control multiple fixup > > (In reply to Sergey Kondakov from comment #39) > > ... > > their own. A more reasonable approach would be passing > > model=vendorID:productID:<"model"> space-separated (to allow several > > dongles) override pairs with each having a bunch of quirk-hacks associated > > (as snd-hda-intel) on it, quirks=vendorID:productID:<comma separated list > of > > all quirks> space-separated pairs (as usbcore/usbhid) or both. > > ... > > Hi, > > Yes, the feedback I had from the list was similar (my bad for following > after the existing code :). > Your suggestion was the most constructive though, so I implemented it that > way. > I'm uploading the patch that I'm using to play around with the fixups. > I'm still trying to find out the best combination for my adapter and it may > be useful to others in the same quest. > > PS: The syntax is a bit different from above: > Syntax: > fixups=<force_hex>[:<disable_hex>[:<vendor_hex>[:<model_hex>[: > <bcdDevice>]]]]" > PPS: Maybe I'll try a new upstream patch if/when I solve some instability it > still has. > > Thanks. I've got the same fake csr device : ``` @lsusb -v ... idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 ... @uname -r 5.3.0-24-generic ``` Is there any newer patch available for this bug?
debian 10 (gnome) Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) - not work, how to fix?
same boat have not used my Bluetooth dongle for years and need them again and can not get working Ubuntu 19 hciconfig hci0: Type: Primary Bus: USB BD Address: 00:11:67:55:8F:C3 ACL MTU: 672:3 SCO MTU: 48:1 DOWN RX bytes:918 acl:0 sco:0 events:32 errors:0 TX bytes:112 acl:0 sco:0 commands:32 errors:2 usb 5-1: USB disconnect, device number 2 [176552.338881] usb 5-1: new full-speed USB device number 4 using xhci_hcd [176552.494463] usb 5-1: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping [176552.494466] usb 5-1: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping [176552.503454] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice= 1.34 [176552.503456] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [176552.503458] usb 5-1: Product: USB demo board [176552.503458] usb 5-1: Manufacturer: Conwise Technology [176847.054212] usb 5-1: USB disconnect, device number 4 [176849.007636] usb 5-1: new full-speed USB device number 5 using xhci_hcd [176849.167625] usb 5-1: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping [176849.167627] usb 5-1: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping [176849.176617] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice= 1.34 [176849.176618] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [176849.176619] usb 5-1: Product: USB demo board [176849.176620] usb 5-1: Manufacturer: Conwise Technology [177010.700332] NET: Registered protocol family 38 [177027.690747] debugfs: File 'dut_mode' in directory 'hci0' already present! [177111.033769] usbcore: deregistering interface driver btusb [177115.941071] usbcore: registered new interface driver btusb sudo btmon Bluetooth monitor ver 5.50 = Note: Linux version 5.4.11-050411-generic (x86_64) 0.303554 = Note: Bluetooth subsystem version 2.22 0.303557 = New Index: 00:11:67:55:8F:C3 (Primary,USB,hci0) [hci0] 0.303588 @ MGMT Open: bluetoothd (privileged) version 1.14 {0x0001} 0.303589 @ MGMT Open: btmon (privileged) version 1.14 {0x0002} 0.303655 @ RAW Open: hciconfig (privileged) version 2.22 {0x0003} 17.071322 = Open Index: 00:11:67:55:8F:C3 [hci0] 17.186259 = Index Info: 00:11:67:55:8F:C3 (Cambridge Silicon Radio) [hci0] 17.186268 < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #1 [hci0] 17.186284 > HCI Event: Command Complete (0x0e) plen 12 > #2 [hci0] 17.189217 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 2.0 (0x03) - Revision 500 (0x01f4) LMP version: Bluetooth 2.0 (0x03) - Subversion 500 (0x01f4) Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Reset (0x03|0x0003) plen 0 #3 [hci0] 17.189246 > HCI Event: Command Complete (0x0e) plen 4 > #4 [hci0] 17.265218 Reset (0x03|0x0003) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 #5 [hci0] 17.265235 > HCI Event: Command Complete (0x0e) plen 12 > #6 [hci0] 17.267216 Read Local Supported Features (0x04|0x0003) ncmd 1 Status: Success (0x00) Features: 0xff 0x3e 0x05 0x30 0x18 0x18 0x00 0x00 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets CVSD synchronous data Power control Interlaced inquiry scan Interlaced page scan AFH capable slave AFH classification slave AFH capable master AFH classification master < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #7 [hci0] 17.267230 > HCI Event: Command Complete (0x0e) plen 12 > #8 [hci0] 17.270215 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 2.0 (0x03) - Revision 500 (0x01f4) LMP version: Bluetooth 2.0 (0x03) - Subversion 500 (0x01f4) Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 #9 [hci0] 17.270232 > HCI Event: Command Complete (0x0e) plen 10 > #10 [hci0] 17.276215 Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: 00:11:67:55:8F:C3 (Integrated System Solution Corp.) < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 #11 [hci0] 17.276270 > HCI Event: Command Complete (0x0e) plen 11 > #12 [hci0] 17.278218 Read Buffer Size (0x04|0x0005) ncmd 1 Status: Success (0x00) ACL MTU: 672 ACL max packet: 3 SCO MTU: 48 SCO max packet: 1 < HCI Command: Read Class of Device (0x03|0x0023) plen 0 #13 [hci0] 17.278240 > HCI Event: Command Complete (0x0e) plen 7 > #14 [hci0] 17.282211 Read Class of Device (0x03|0x0023) ncmd 1 Status: Success (0x00) Class: 0x120104 Major class: Computer (desktop, notebook, PDA, organizers) Minor class: Desktop workstation Networking (LAN, Ad hoc) Object Transfer (v-Inbox, v-Folder) < HCI Command: Read Local Name (0x03|0x0014) plen 0 #15 [hci0] 17.282282 > HCI Event: Command Complete (0x0e) plen 252 > #16 [hci0] 17.305215 Read Local Name (0x03|0x0014) ncmd 1 Status: Success (0x00) Name: POV-ION < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 #17 [hci0] 17.305262 > HCI Event: Command Complete (0x0e) plen 6 > #18 [hci0] 17.307215 Read Voice Setting (0x03|0x0025) ncmd 1 Status: Success (0x00) Setting: 0x0060 Input Coding: Linear Input Data Format: 2's complement Input Sample Size: 16-bit # of bits padding at MSB: 0 Air Coding Format: CVSD < HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0 #19 [hci0] 17.307235 > HCI Event: Command Complete (0x0e) plen 5 > #20 [hci0] 17.311210 Read Number of Supported IAC (0x03|0x0038) ncmd 1 Status: Success (0x00) Number of IAC: 2 < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 #21 [hci0] 17.311230 > HCI Event: Command Complete (0x0e) plen 8 > #22 [hci0] 17.313214 Read Current IAC LAP (0x03|0x0039) ncmd 1 Status: Success (0x00) Number of IAC: 1 Access code: 0x9e8b33 (General Inquiry) < HCI Command: Set Event Filter (0x03|0x0005) plen 1 #23 [hci0] 17.313230 Type: Clear All Filters (0x00) > HCI Event: Command Complete (0x0e) plen 4 > #24 [hci0] 17.316211 Set Event Filter (0x03|0x0005) ncmd 1 Status: Success (0x00) < HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2 #25 [hci0] 17.316223 Timeout: 20000.000 msec (0x7d00) > HCI Event: Command Complete (0x0e) plen 4 > #26 [hci0] 17.319210 Write Connection Accept Timeout (0x03|0x0016) ncmd 1 Status: Success (0x00) < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0 #27 [hci0] 17.319221 > HCI Event: Command Complete (0x0e) plen 68 > #28 [hci0] 17.327209 Read Local Supported Commands (0x04|0x0002) ncmd 1 Status: Success (0x00) Commands: 109 entries Inquiry (Octet 0 - Bit 0) Inquiry Cancel (Octet 0 - Bit 1) Periodic Inquiry Mode (Octet 0 - Bit 2) Exit Periodic Inquiry Mode (Octet 0 - Bit 3) Create Connection (Octet 0 - Bit 4) Disconnect (Octet 0 - Bit 5) Add SCO Connection (Octet 0 - Bit 6) Accept Connection Request (Octet 1 - Bit 0) Reject Connection Request (Octet 1 - Bit 1) Link Key Request Reply (Octet 1 - Bit 2) Link Key Request Negative Reply (Octet 1 - Bit 3) PIN Code Request Reply (Octet 1 - Bit 4) PIN Code Request Negative Reply (Octet 1 - Bit 5) Change Connection Packet Type (Octet 1 - Bit 6) Authentication Requested (Octet 1 - Bit 7) Set Connection Encryption (Octet 2 - Bit 0) Change Connection Link Key (Octet 2 - Bit 1) Master Link Key (Octet 2 - Bit 2) Remote Name Request (Octet 2 - Bit 3) Read Remote Supported Features (Octet 2 - Bit 5) Read Remote Extended Features (Octet 2 - Bit 6) Read Remote Version Information (Octet 2 - Bit 7) Read Clock Offset (Octet 3 - Bit 0) Read LMP Handle (Octet 3 - Bit 1) Hold Mode (Octet 4 - Bit 1) Sniff Mode (Octet 4 - Bit 2) Exit Sniff Mode (Octet 4 - Bit 3) QoS Setup (Octet 4 - Bit 6) Role Discovery (Octet 4 - Bit 7) Switch Role (Octet 5 - Bit 0) Read Link Policy Settings (Octet 5 - Bit 1) Write Link Policy Settings (Octet 5 - Bit 2) Read Default Link Policy Settings (Octet 5 - Bit 3) Write Default Link Policy Settings (Octet 5 - Bit 4) Set Event Mask (Octet 5 - Bit 6) Reset (Octet 5 - Bit 7) Set Event Filter (Octet 6 - Bit 0) Flush (Octet 6 - Bit 1) Read PIN Type (Octet 6 - Bit 2) Write PIN Type (Octet 6 - Bit 3) Create New Unit Key (Octet 6 - Bit 4) Read Stored Link Key (Octet 6 - Bit 5) Write Stored Link Key (Octet 6 - Bit 6) Delete Stored Link Key (Octet 6 - Bit 7) Write Local Name (Octet 7 - Bit 0) Read Local Name (Octet 7 - Bit 1) Read Connection Accept Timeout (Octet 7 - Bit 2) Write Connection Accept Timeout (Octet 7 - Bit 3) Read Page Timeout (Octet 7 - Bit 4) Write Page Timeout (Octet 7 - Bit 5) Read Scan Enable (Octet 7 - Bit 6) Write Scan Enable (Octet 7 - Bit 7) Read Page Scan Activity (Octet 8 - Bit 0) Write Page Scan Activity (Octet 8 - Bit 1) Read Inquiry Scan Activity (Octet 8 - Bit 2) Write Inquiry Scan Activity (Octet 8 - Bit 3) Read Authentication Enable (Octet 8 - Bit 4) Write Authentication Enable (Octet 8 - Bit 5) Read Encryption Mode (Octet 8 - Bit 6) Write Encryption Mode (Octet 8 - Bit 7) Read Class of Device (Octet 9 - Bit 0) Write Class of Device (Octet 9 - Bit 1) Read Voice Setting (Octet 9 - Bit 2) Write Voice Setting (Octet 9 - Bit 3) Read Automatic Flush Timeout (Octet 9 - Bit 4) Write Automatic Flush Timeout (Octet 9 - Bit 5) Read Num Broadcast Retransmissions (Octet 9 - Bit 6) Write Num Broadcast Retransmissions (Octet 9 - Bit 7) Read Hold Mode Activity (Octet 10 - Bit 0) Write Hold Mode Activity (Octet 10 - Bit 1) Read Transmit Power Level (Octet 10 - Bit 2) Read Sync Flow Control Enable (Octet 10 - Bit 3) Write Sync Flow Control Enable (Octet 10 - Bit 4) Set Controller To Host Flow Control (Octet 10 - Bit 5) Host Buffer Size (Octet 10 - Bit 6) Host Number of Completed Packets (Octet 10 - Bit 7) Read Link Supervision Timeout (Octet 11 - Bit 0) Write Link Supervision Timeout (Octet 11 - Bit 1) Read Number of Supported IAC (Octet 11 - Bit 2) Read Current IAC LAP (Octet 11 - Bit 3) Write Current IAC LAP (Octet 11 - Bit 4) Set AFH Host Channel Classification (Octet 12 - Bit 1) Read Inquiry Scan Type (Octet 12 - Bit 4) Write Inquiry Scan Type (Octet 12 - Bit 5) Read Inquiry Mode (Octet 12 - Bit 6) Write Inquiry Mode (Octet 12 - Bit 7) Read Page Scan Type (Octet 13 - Bit 0) Write Page Scan Type (Octet 13 - Bit 1) Read AFH Channel Assessment Mode (Octet 13 - Bit 2) Write AFH Channel Assessment Mode (Octet 13 - Bit 3) Read Local Version Information (Octet 14 - Bit 3) Read Local Supported Commands (Octet 14 - Bit 4) Read Local Supported Features (Octet 14 - Bit 5) Read Local Extended Features (Octet 14 - Bit 6) Read Buffer Size (Octet 14 - Bit 7) Read Country Code (Octet 15 - Bit 0) Read BD ADDR (Octet 15 - Bit 1) Read Failed Contact Counter (Octet 15 - Bit 2) Reset Failed Contact Counter (Octet 15 - Bit 3) Read Link Quality (Octet 15 - Bit 4) Read RSSI (Octet 15 - Bit 5) Read AFH Channel Map (Octet 15 - Bit 6) Read Clock (Octet 15 - Bit 7) Read Loopback Mode (Octet 16 - Bit 0) Write Loopback Mode (Octet 16 - Bit 1) Enable Device Under Test Mode (Octet 16 - Bit 2) Setup Synchronous Connection (Octet 16 - Bit 3) Accept Synchronous Connection Request (Octet 16 - Bit 4) Reject Synchronous Connection Request (Octet 16 - Bit 5) < HCI Command: Set Event Mask (0x03|0x0001) plen 8 #29 [hci0] 17.327247 Mask: 0x00000001fffbffff Inquiry Complete Inquiry Result Connection Complete Connection Request Disconnection Complete Authentication Complete Remote Name Request Complete Encryption Change Change Connection Link Key Complete Master Link Key Complete Read Remote Supported Features Complete Read Remote Version Information Complete QoS Setup Complete Command Complete Command Status Hardware Error Flush Occurred Role Change Mode Change Return Link Keys PIN Code Request Link Key Request Link Key Notification Loopback Command Data Buffer Overflow Max Slots Change Read Clock Offset Complete Connection Packet Type Changed QoS Violation Page Scan Mode Change Page Scan Repetition Mode Change Flow Specification Complete > HCI Event: Command Complete (0x0e) plen 4 > #30 [hci0] 17.329211 Set Event Mask (0x03|0x0001) ncmd 1 Status: Success (0x00) < HCI Command: Read Stored Link Key (0x03|0x000d) plen 7 #31 [hci0] 17.329225 Address: 00:00:00:00:00:00 (OUI 00-00-00) Read all: 0x01 > HCI Event: Command Complete (0x0e) plen 8 > #32 [hci0] 17.332214 @lsusb -v Bus 005 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 16 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 1.34 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x006c bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Read Stored Link Key (0x03|0x000d) ncmd 1 Status: Unsupported Feature or Parameter Value (0x11) Max num keys: 0 Num keys: 0 = Close Index: 00:11:67:55:8F:C3 [hci0] 17.332241 @ RAW Close: hciconfig
dozen dongles later found one that worked Bus 005 Device 007: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 19.15 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 4 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 5 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1
Created attachment 286973 [details] Patch for CSR 0a12:0001 88.19 (kernel 5.4.14) I bumped the patch for bcdDevice == 88.91, this makes it work with 5.4.14 kernel with the device below (cheap Bluetooth 4 dongle from AliExpress: https://bit.ly/2uBDuX5 ). It seems something's still wrong (iProduct field shows error), but I managed to connect my phone and transfer data correctly (pictures). ---- Bus 001 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 iManufacturer 0 iProduct 2 (error) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0000 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0011 1x 17 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0019 1x 25 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 4 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0021 1x 33 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 5 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1
hi guys... i can confirm this with kernel 5.5.2, i applyed every patch attached here to kernel 5 and still not working.. uname -r 5.5.2 lsusb -v Bus 001 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 iManufacturer 0 iProduct 2 USB1.1-A iSerial 0 bNumConfigurations 1 hcitool dev Devices: dmesg [ 231.131312] usb 1-4: reset high-speed USB device number 2 using xhci_hcd [ 263.037922] usb 1-10: USB disconnect, device number 7 [ 283.813572] usb 1-10: new full-speed USB device number 8 using xhci_hcd [ 283.962915] usb 1-10: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 283.962916] usb 1-10: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 283.962917] usb 1-10: Product: USB1.1-A [ 283.985700] Bluetooth: hci0: urb 000000004a48b323 failed to resubmit (2) [ 285.993511] Bluetooth: hci0: command 0x0c14 tx timeout [ 288.009434] Bluetooth: hci0: command 0x0c25 tx timeout [ 290.025410] Bluetooth: hci0: command 0x0c38 tx timeout [ 292.041395] Bluetooth: hci0: command 0x0c39 tx timeout [ 294.057297] Bluetooth: hci0: command 0x0c05 tx timeout [ 758.040593] usb 1-4: reset high-speed USB device number 2 using xhci_hcd [ 1302.873156] usb 1-4: reset high-speed USB device number 2 using xhci_hcd [ 1375.723184] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
Hey guys, I can also confirm that the adapter is not getting recognized. uname -r 5.5.2-arch1-1 journalctl -f Feb 07 10:46:21 archlinux kernel: usb 1-5.3: new full-speed USB device number 9 using xhci_hcd Feb 07 10:46:21 archlinux kernel: usb 1-5.3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 Feb 07 10:46:21 archlinux kernel: usb 1-5.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0 Feb 07 10:46:21 archlinux kernel: usb 1-5.3: Product: CSR8510 A10 Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux systemd[794]: Reached target Bluetooth. Feb 07 10:46:21 archlinux systemd[1]: Reached target Bluetooth. Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action "bind" Feb 07 10:46:21 archlinux bluetooth-meshd[641]: Hci dev 0000 removed Feb 07 10:46:21 archlinux bluetooth-meshd[641]: Failed to initialize HCI Feb 07 10:46:26 archlinux systemd[1]: systemd-rfkill.service: Succeeded. bluetoothctl Agent registered [bluetooth]# devices No default controller available rfkill list 2: hci0: Bluetooth Soft blocked: no Hard blocked: no
Created attachment 287227 [details] attachment-31457-0.html Hi. Try addin the module flags: echo "options btusb fixups=0x0800000:0x000004:0x0a12:0x0001:0x8891" > /etc/modprobe.d/csr-bluetoothbongle.conf Syslog should show something like: btusb: New fixups. Device: 0x0a12:0x0001/0x8891. Rule 1/1 (5 terms): 0x0a12:0x0001/0x8891 btusb: driver flags: initial => 0x0000000000000004 btusb: driver flags: masked => 0x0000000000800000 Regards. # Fernando Pires de Carvalho # pires.carvalho@gmail.com On Fri, Feb 7, 2020 at 4:50 PM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=60824 > > Abhishekkumartux@gmail.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| | > Abhishekkumartux@gmail.com > > --- Comment #50 from Abhishekkumartux@gmail.com --- > Hey guys, > I can also confirm that the adapter is not getting recognized. > > uname -r > 5.5.2-arch1-1 > > journalctl -f > Feb 07 10:46:21 archlinux kernel: usb 1-5.3: new full-speed USB device > number 9 > using xhci_hcd > Feb 07 10:46:21 archlinux kernel: usb 1-5.3: New USB device found, > idVendor=0a12, idProduct=0001, bcdDevice=88.91 > Feb 07 10:46:21 archlinux kernel: usb 1-5.3: New USB device strings: Mfr=0, > Product=2, SerialNumber=0 > Feb 07 10:46:21 archlinux kernel: usb 1-5.3: Product: CSR8510 A10 > Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux systemd[794]: Reached target Bluetooth. > Feb 07 10:46:21 archlinux systemd[1]: Reached target Bluetooth. > Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" > Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" > Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux krunner[3104]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux baloo_file[901]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux plasmashell[903]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kded5[846]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux kmix[990]: UdevQt: unhandled device action "bind" > Feb 07 10:46:21 archlinux dolphin[971]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux dolphin[978]: UdevQt: unhandled device action > "bind" > Feb 07 10:46:21 archlinux bluetooth-meshd[641]: Hci dev 0000 removed > Feb 07 10:46:21 archlinux bluetooth-meshd[641]: Failed to initialize HCI > Feb 07 10:46:26 archlinux systemd[1]: systemd-rfkill.service: Succeeded. > > bluetoothctl > Agent registered > [bluetooth]# devices > No default controller available > > rfkill list > 2: hci0: Bluetooth > Soft blocked: no > Hard blocked: no > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Fernando Carvalho from comment #51) Fernando, You are a genius. Thanks for replying, I was struggling with this. Adding "options btusb fixups=0x0800000:0x000004:0x0a12:0x0001:0x8891" to /etc/modprobe.d/csr-bluetoothbongle.conf and regenerating the initramfs solved the problem for me. Cheers, Abhi. > Created attachment 287227 [details] > attachment-31457-0.html > > Hi. > > Try addin the module flags: > > echo "options btusb fixups=0x0800000:0x000004:0x0a12:0x0001:0x8891" > > /etc/modprobe.d/csr-bluetoothbongle.conf > > Syslog should show something like: > > btusb: New fixups. Device: 0x0a12:0x0001/0x8891. Rule 1/1 (5 terms): > 0x0a12:0x0001/0x8891 > btusb: driver flags: initial => 0x0000000000000004 > btusb: driver flags: masked => 0x0000000000800000 > > Regards. > > # Fernando Pires de Carvalho > # pires.carvalho@gmail.com
Hi, I've run into the same issue but adding the fixups option (from above) gives me this: "btusb: unknown parameter 'fixups' ignored" at boot. I'm running latest Manjaro kernel, any ideas? thanks.
(In reply to Ruthger Dijt from comment #53) > Hi, I've run into the same issue but adding the fixups option (from above) > gives me this: > "btusb: unknown parameter 'fixups' ignored" at boot. > > I'm running latest Manjaro kernel, > > any ideas? > > thanks. You need to apply the patch: https://bugzilla.kernel.org/attachment.cgi?id=285489 to btusb.c of kernel version 5.4 and load that kernel module. I wanted to say that using this fixups option, I was able to get my bluetooth adapter running as well. Bus 003 Device 012: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter The driver apparently didn't know the VID&PID, so I inserted it with VID&PID = 0: insmod btusb.ko "fixups=0x0800000:0x000004:0x0000:0x0000:0x0134" btusb: New fixups. Device: 0x0000:0x0000/0x0134. Rule 1/1 (5 terms): 0x0000:0x0000/0x0134
Hi, My issue with this device looks a little different, and after applying the latest patch from the thread I still have the issue. btmon shows the following (last lines, see Set Event Filter error): #20 [hci0] 9.289041 Read Number of Supported IAC (0x03|0x0038) ncmd 1 Status: Success (0x00) Number of IAC: 2 < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 #21 [hci0] 9.289050 > HCI Event: Command Complete (0x0e) plen 8 > #22 [hci0] 9.291043 Read Current IAC LAP (0x03|0x0039) ncmd 1 Status: Success (0x00) Number of IAC: 1 Access code: 0x9e8b33 (General Inquiry) < HCI Command: Set Event Filter (0x03|0x0005) plen 1 #23 [hci0] 9.291049 Type: Clear All Filters (0x00) > HCI Event: Command Complete (0x0e) plen 4 > #24 [hci0] 9.293040 Set Event Filter (0x03|0x0005) ncmd 1 Status: Invalid HCI Command Parameters (0x12) = Close Index: 00:1A:7D:DA:71:12 [hci0] 9.293052 and the device stays down and inaccessible Here is data from my system: hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:12 ACL MTU: 679:8 SCO MTU: 48:16 DOWN RX bytes:706 acl:0 sco:0 events:22 errors:0 TX bytes:68 acl:0 sco:0 commands:22 errors:0 Features: 0xbf 0x2e 0x4d 0xfa 0xd8 0x3d 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3 Link policy: Link mode: SLAVE ACCEPT hciconfig hci0 up Can't init device hci0: Invalid argument (22) [bluetooth]# list [bluetooth]# lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 14cd:125c Super Top SD card reader Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 018: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 003: ID 04b3:3025 IBM Corp. NetVista Full Width Keyboard Bus 001 Device 002: ID 0bda:b812 Realtek Semiconductor Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub dmesg (extract) [ 5284.357208] usbcore: deregistering interface driver btusb [ 5287.608129] usb 1-7: new full-speed USB device number 18 using xhci_hcd [ 5287.758895] usb 1-7: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping [ 5287.758904] usb 1-7: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping [ 5287.759639] usb 1-7: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 5287.759647] usb 1-7: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 5287.759651] usb 1-7: Product: BT DONGLE10 [ 5287.785780] btusb: New fixups. Device: 0x0a12:0x0001/0x8891. Rule 1/1 (5 terms): 0x0a12:0x0001/0x8891 [ 5287.785781] btusb: driver flags: initial => 0x0000000000000004 [ 5287.785783] btusb: driver flags: masked => 0x0000000000800000 [ 5287.785902] usbcore: registered new interface driver btusb [ 5395.553658] debugfs: File 'dut_mode' in directory 'hci0' already present! hcidump -X is attached Any suggestions/fixes are really appreciated. Please let me know if some info is missing. Thanks, Alex.
Created attachment 287411 [details] 'hcidump -X' while executing 'hciconfig hci0 up' for Alex (Set Event Filter error)
I confirm that the patch fixed the issue for me to my device: Bus 003 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Adopted patch to kernel version 5.5, confirmed that my device started working ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) That's my adoption: https://github.com/akushsky/kernel_patches/blob/master/UbiquitousEvil/bluetooth.patch
(In reply to Alex from comment #55) > Hi, > My issue with this device looks a little different, and after applying the > latest patch from the thread I still have the issue. > > btmon shows the following (last lines, see Set Event Filter error): > > #20 [hci0] 9.289041 > Read Number of Supported IAC (0x03|0x0038) ncmd 1 > Status: Success (0x00) > Number of IAC: 2 > < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 > #21 [hci0] 9.289050 > > HCI Event: Command Complete (0x0e) plen 8 > > #22 [hci0] > 9.291043 > Read Current IAC LAP (0x03|0x0039) ncmd 1 > Status: Success (0x00) > Number of IAC: 1 > Access code: 0x9e8b33 (General Inquiry) > < HCI Command: Set Event Filter (0x03|0x0005) plen 1 > #23 [hci0] 9.291049 > Type: Clear All Filters (0x00) > > HCI Event: Command Complete (0x0e) plen 4 > > #24 [hci0] > 9.293040 > Set Event Filter (0x03|0x0005) ncmd 1 > Status: Invalid HCI Command Parameters (0x12) > = Close Index: 00:1A:7D:DA:71:12 > [hci0] 9.293052 > > > and the device stays down and inaccessible > Here is data from my system: > > hciconfig -a > hci0: Type: Primary Bus: USB > BD Address: 00:1A:7D:DA:71:12 ACL MTU: 679:8 SCO MTU: 48:16 > DOWN > RX bytes:706 acl:0 sco:0 events:22 errors:0 > TX bytes:68 acl:0 sco:0 commands:22 errors:0 > Features: 0xbf 0x2e 0x4d 0xfa 0xd8 0x3d 0x7b 0x87 > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3 > Link policy: > Link mode: SLAVE ACCEPT > > hciconfig hci0 up > Can't init device hci0: Invalid argument (22) > > [bluetooth]# list > [bluetooth]# > > lsusb > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 001 Device 005: ID 14cd:125c Super Top SD card reader > Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver > Bus 001 Device 018: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth > Dongle (HCI mode) > Bus 001 Device 003: ID 04b3:3025 IBM Corp. NetVista Full Width Keyboard > Bus 001 Device 002: ID 0bda:b812 Realtek Semiconductor Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > dmesg (extract) > [ 5284.357208] usbcore: deregistering interface driver btusb > [ 5287.608129] usb 1-7: new full-speed USB device number 18 using xhci_hcd > [ 5287.758895] usb 1-7: config 1 interface 1 altsetting 0 endpoint 0x3 has > wMaxPacketSize 0, skipping > [ 5287.758904] usb 1-7: config 1 interface 1 altsetting 0 endpoint 0x83 has > wMaxPacketSize 0, skipping > [ 5287.759639] usb 1-7: New USB device found, idVendor=0a12, idProduct=0001, > bcdDevice=88.91 > [ 5287.759647] usb 1-7: New USB device strings: Mfr=0, Product=2, > SerialNumber=0 > [ 5287.759651] usb 1-7: Product: BT DONGLE10 > [ 5287.785780] btusb: New fixups. Device: 0x0a12:0x0001/0x8891. Rule 1/1 (5 > terms): 0x0a12:0x0001/0x8891 > [ 5287.785781] btusb: driver flags: initial => 0x0000000000000004 > [ 5287.785783] btusb: driver flags: masked => 0x0000000000800000 > [ 5287.785902] usbcore: registered new interface driver btusb > [ 5395.553658] debugfs: File 'dut_mode' in directory 'hci0' already present! > > hcidump -X is attached > Any suggestions/fixes are really appreciated. > Please let me know if some info is missing. > > Thanks, > Alex. I'm having the same issue on a raspberry with an aliexpress dongle, Set Event fails, looking at hci_core.c the set filter and previous calls are made only if device supports BREDR, is there any way to tell device doesn't support, or patch this ? I'm on latest raspberry pi 4, latest kernel 4.19.113-v7l+
I have same issue with this device. uname -a Linux reka-pc 5.6.5-050605-generic #202004171629 SMP Fri Apr 17 16:32:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux but my issue is a bit different, because I have another bcdDevice number. ** 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) ** my bcdDevice is 75.58 so I edit some condition in the patch, to this value 0x8891 I changed it to 0x7558 and apply this patch to my kernel. I can confirm that the bluetooth dongle is working.
(In reply to Michael Akushsky from comment #58) > Adopted patch to kernel version 5.5, confirmed that my device started working > > ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) > > That's my adoption: > https://github.com/akushsky/kernel_patches/blob/master/UbiquitousEvil/ > bluetooth.patch Same device ID here and while this patch gets the dongle functioning, I am unable to establish a successful connection with any device. < HCI Command: Create Connection (0x01|0x0005) plen 13 #299 [hci0] 192.046072 Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Packet type: 0xcc18 DM1 may be used DH1 may be used DM3 may be used DH3 may be used DM5 may be used DH5 may be used Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 Role switch: Allow slave (0x01) > HCI Event: Command Status (0x0f) plen 4 #300 [hci0] 192.048152 Create Connection (0x01|0x0005) ncmd 1 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 #301 [hci0] 192.508147 Status: Success (0x00) Handle: 128 Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Link type: ACL (0x01) Encryption: Disabled (0x00) < HCI Command: Read Remote Suppo.. (0x01|0x001b) plen 2 #302 [hci0] 192.508223 Handle: 128 > HCI Event: Command Status (0x0f) plen 4 #303 [hci0] 192.510138 Read Remote Supported Features (0x01|0x001b) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Supported Fea.. (0x0b) plen 11 #304 [hci0] 192.511139 Status: Success (0x00) Handle: 128 Features: 0xff 0xfe 0x8f 0xfe 0xdb 0xff 0x5b 0x87 3 slot packets 5 slot packets Encryption Slot offset Timing accuracy Role switch Hold mode Sniff mode Power control requests Channel quality driven data rate (CQDDR) SCO link HV2 packets HV3 packets u-law log synchronous data A-law log synchronous data CVSD synchronous data Paging parameter negotiation Power control Transparent synchronous data Broadcast Encryption Enhanced Data Rate ACL 2 Mbps mode Enhanced Data Rate ACL 3 Mbps mode Enhanced inquiry scan Interlaced inquiry scan Interlaced page scan RSSI with inquiry results Extended SCO link (EV3 packets) EV4 packets EV5 packets AFH capable slave AFH classification slave LE Supported (Controller) 3-slot Enhanced Data Rate ACL packets 5-slot Enhanced Data Rate ACL packets Sniff subrating Pause encryption AFH capable master AFH classification master Enhanced Data Rate eSCO 2 Mbps mode Enhanced Data Rate eSCO 3 Mbps mode 3-slot Enhanced Data Rate eSCO packets Extended Inquiry Response Simultaneous LE and BR/EDR (Controller) Secure Simple Pairing Encapsulated PDU Non-flushable Packet Boundary Flag Link Supervision Timeout Changed Event Inquiry TX Power Level Enhanced Power Control Extended features < HCI Command: Read Remote Exten.. (0x01|0x001c) plen 3 #305 [hci0] 192.511150 Handle: 128 Page: 1 > HCI Event: Command Status (0x0f) plen 4 #306 [hci0] 192.513135 Read Remote Extended Features (0x01|0x001c) ncmd 1 Status: Success (0x00) > HCI Event: Read Remote Extended Feat.. (0x23) plen 13 #307 [hci0] 192.514139 Status: Success (0x00) Handle: 128 Page: 1/1 Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) < HCI Command: Remote Name Requ.. (0x01|0x0019) plen 10 #308 [hci0] 192.514157 Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 < ACL Data TX: Handle 128 flags 0x00 dlen 10 #309 [hci0] 192.514167 L2CAP: Information Request (0x0a) ident 1 len 2 Type: Extended features supported (0x0002) > HCI Event: Command Status (0x0f) plen 4 #310 [hci0] 192.516133 Remote Name Request (0x01|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Max Slots Change (0x1b) plen 3 #311 [hci0] 192.517132 Handle: 128 Max slots: 5 > HCI Event: Number of Completed Packets (0x13) plen 5 #312 [hci0] 192.554140 Num handles: 1 Handle: 128 Count: 1 > HCI Event: Remote Name Req Complete (0x07) plen 255 #313 [hci0] 192.578126 Status: Success (0x00) Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Name: Tronsmart Spunky Beat @ MGMT Event: Device Connected (0x000b) plen 36 {0x0001} [hci0] 192.578141 BR/EDR Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Flags: 0x00000000 Data length: 23 Name (complete): Tronsmart Spunky Beat @ MGMT Event: Device Connected (0x000b) plen 36 {0x0002} [hci0] 192.578141 BR/EDR Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Flags: 0x00000000 Data length: 23 Name (complete): Tronsmart Spunky Beat < ACL Data TX: Handle 128 flags 0x00 dlen 12 #314 [hci0] 196.529160 L2CAP: Connection Request (0x02) ident 2 len 4 PSM: 1 (0x0001) Source CID: 64 > HCI Event: Number of Completed Packets (0x13) plen 5 #315 [hci0] 196.554157 Num handles: 1 Handle: 128 Count: 1 > HCI Event: Disconnect Complete (0x05) plen 4 #316 [hci0] 226.973306 Status: Success (0x00) Handle: 128 Reason: Remote User Terminated Connection (0x13) @ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 226.973325 BR/EDR Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Reason: Connection terminated by remote host (0x03) @ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0002} [hci0] 226.973325 BR/EDR Address: 5C:EB:68:74:50:AD (Cheerstar Technology Co., Ltd) Reason: Connection terminated by remote host (0x03)
Will this patch get back-ported to 5.4.0-XX for *ubuntu LTS 20.04 ? I have the same issue: "Patch for CSR 0a12:0001 88.19 (kernel 5.4.14)" "I bumped the patch for bcdDevice == 88.91, this makes it work with 5.4.14 kernel with the device below...." I've added the fixups option to crs-bluetoothbongle.conf "options btusb fixups=0x0800000:0x000004:0x0a12:0x0001:0x8891" which obviously reports unknown option without the patch. Currently using kubuntu 20.04 Linux server-2020 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux I was hoping that this would turn up with an Ubuntu update 🤔
Hi, I have the same problem in this computer with Mageia 7.1 with kernel 5.6.6: 4 x Intel Core 2 Quad CPU Q6600 @ 2400Ghz 4,8 Gb Ram The bluetooth no works. Greetings!
Hello everyone, Me too. I have the same problem on fedora 31 with kernel 5.6.7: uname -r 5.6.7-200.fc31.x86_64. If any further info or commands, I'm available to help with some of your assistance, guys. Greeting. Ouss.
Hello everyone. I have the same problem. "Bus 003 Device 004: ID 0a12: 0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" There is no way it matches with anything and I don't know how the patch is applied. AMD A10 - 8750K Debian Bullseye (testing) Linux debian 5.6.0-1-amd64 # 1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU / Linux. Thank you.
I have a different device. It's same vendor and id but bcdDevice is 25.20. First think I wanted to try is using the same patch and just change the fixups option. (In reply to Michael Akushsky from comment #58) > Adopted patch to kernel version 5.5, confirmed that my device started working > > ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) > > That's my adoption: > https://github.com/akushsky/kernel_patches/blob/master/UbiquitousEvil/ > bluetooth.patch Is it possible to use this in 5.6? I'm trying to build a kernel with this patch in Fedora 31, but although the resulting kernel is working, the btusb module still doesn't have the fixups parameter. Possible reasons include: - The patch doesn't work as is with 5.6. - I'm not applying the patch correctly. - I'm not compiling correctly. If anyone could help me with these I'd gladly test the patches. Even more, if someone could point me how to compile only the btusb module for a certain kernel version I'd be very happy, as compiling the full Fedora kernel in my computer takes more than 2 hours. Greetings!
Created attachment 289017 [details] lsusb for bcdDevice 25.20 Okay, managed to compiled the module with the fixups option and loaded. Unfortunately, although the module loads without problems, the BT adapter won't work. hciconfig hci0 up ends in connection timed out. I attach the full lsusb -v output for this device. Is there any other helpful info I can provide? Being able to solve this would be great, as in my country all the BT dongles I've seen online are CSR dongles.
(In reply to Sergey Kondakov from comment #39) > (In reply to Fernando Carvalho from comment #38) > > Hi, > > > > I merged a few fixes and quirks (including some from this thread) and sent > > them to linux-bluetooth@vger.kernel.org : > > > > https://www.spinics.net/lists/linux-bluetooth/msg81304.html > > > > Feel free to test it if you have a simillar CSR device > > (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", > > ATTRS{bcdDevice}=="8891"). > > > > It's not perfect, but it allows the use of the adapter and connect a > headset > > (with some connect errors/retries now and then). > > > > Regards. > > Great work ! Unlike the actual maintainers who don't even bother to read > bug-tracker anymore or use ready fixes for their code that they themselves > don't care about, it seems. > I have nothing in common with maintaining bluetooth stack in the kernel, but I'd like to comment on this a bit. That patch adds a device ID to the list of "Fake CSR devices with broken commands". And you write that it is a "workaround" of this bug, not a "fix". If I were a maintainer of BT stack in the kernel, I would try to avoid merging such patches unless I have this piece of hardware and a datasheet. So, here, I would not blame kernel maintainers for ignoring such bugs. Maybe I misunderstood something, feel free to correct me. Actually I did not understand from this bug report if this patch works or not. Does btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch make device just detectable or actually working?
(In reply to Mikhail Novosyolov from comment #68) > (In reply to Sergey Kondakov from comment #39) > > (In reply to Fernando Carvalho from comment #38) > > > Hi, > > > > > > I merged a few fixes and quirks (including some from this thread) and > sent > > > them to linux-bluetooth@vger.kernel.org : > > > > > > https://www.spinics.net/lists/linux-bluetooth/msg81304.html > > > > > > Feel free to test it if you have a simillar CSR device > > > (ATTRS{idVendor}=="0a12", ATTRS{idProduct}=="0001", > > > ATTRS{bcdDevice}=="8891"). > > > > > > It's not perfect, but it allows the use of the adapter and connect a > > headset > > > (with some connect errors/retries now and then). > > > > > > Regards. > > > > Great work ! Unlike the actual maintainers who don't even bother to read > > bug-tracker anymore or use ready fixes for their code that they themselves > > don't care about, it seems. > > > > I have nothing in common with maintaining bluetooth stack in the kernel, but > I'd like to comment on this a bit. > That patch adds a device ID to the list of "Fake CSR devices with broken > commands". > And you write that it is a "workaround" of this bug, not a "fix". > If I were a maintainer of BT stack in the kernel, I would try to avoid > merging such patches unless I have this piece of hardware and a datasheet. > So, here, I would not blame kernel maintainers for ignoring such bugs. > > Maybe I misunderstood something, feel free to correct me. > > Actually I did not understand from this bug report if this patch works or > not. Does btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch > make device just detectable or actually working? It's detectable but the only device I tested it was Sony DualShock 4 which acts as master that connects PC to itself which uses "sixaxis" hacks in bluez. And, in the end, it was a failure: DS4 does not want to pass input data and then promptly shuts itself off after "pairing". It does work under Windows® with that dongle but on Linux I had to resort to old BT 2.1 one. The more important thing is "fixup" parameter patches that allow to at select hacks per device and at least figure out what it needs without recompiling and rebooting kernel every time. But, apparently, BT maintainer is not interested in BT stack being as robust and easy to test as USB either. I'm pretty sure that the problem is not just that those CSR chips may require hacks by themselves but that "manufacturers" have flashed them with inappropriate/misconfigured firmwares without testing, other than trying something on Windows®, and then flooded Ebay and Aliexpress with those unlicensed fakes. It's pretty much all you can get in an adequate "simple dongle" price range. But Windows® manages to avoid those issues somehow, meaning that Linux's BT stack is too picky, pedantic and too hardcoded for unnecessary things. And that is something maintainers should care about. We shouldn't keep figuring out crutches for every model & revision for things that are not even required for device's purpose.
(In reply to Sergey Kondakov from comment #69) > It's detectable but the only device I tested it was Sony DualShock 4 which > acts as master that connects PC to itself which uses "sixaxis" hacks in > bluez. And, in the end, it was a failure: DS4 does not want to pass input > data and then promptly shuts itself off after "pairing". It does work under > Windows® with that dongle but on Linux I had to resort to old BT 2.1 one. Thanks for clearyfying. > The more important thing is "fixup" parameter patches that allow to at > select hacks per device and at least figure out what it needs without > recompiling and rebooting kernel every time. But, apparently, BT maintainer > is not interested in BT stack being as robust and easy to test as USB either. +1, it would be very good if users who do not know how to build kernels could easily participate in testing different hacks for hardware that they have. For example, I came to this bug because a user of the distro package of kernel which I am maintaining asked how he can build the kernel with that patch (https://forum.rosalinux.ru/viewtopic.php?t=10066) I had to read this bug and then just tell the user that I do not see sense in spending time to test this patch (include it into the package, build it, give him instructions how to install the build). Nobody benefits from the fact that an owner of hardware is not able to participate in hardware enablement in the kernel. On the other hand, opportunity to make such hacks in the kernel module config by the user may lead to that kernel will not have many needed hacks out of the box, users will just copy-paste device-specific solutions from the internet, then somebody will add them to e.g. systemd's hwdb. It is not good when some device-specific options are hard-coded in the driver and some are in other places like systemd's hwdb.
@Mikhail Just a little more details. Generally speaking the patch works. It allows detection of "different versions" of fake CSR-based chips. Unfortunately only part of devices actually work after detection. For example mine was detected, but I was not able to pair anything to it (my logs and traces were attached to this thread) Another issue I have since kernel 4.16 is that my old original Tekram BT also stopped pairing. In several kernels after 4.16 I had usb communication errors (known bug), then it was stated as fixed, usb errors disappeared but BT in my Debian still does not work. I'd say it may be usb errors, but USB storage and mouse/keyboard work fine. Still not sure if it's BT stack, or btusb
(In reply to Alex from comment #71) > Unfortunately only part of devices actually work after detection. For > example mine was detected, but I was not able to pair anything to it (my > logs and traces were attached to this thread) Do you mean that some devices with UDB device/vendor ID 0x0811/0x8891 do work and some do not?! Btw, some crappy USB dongles may have to be usb_modeswitch'ed. I once had to deal with a RTL8188GU-based USB WiFi dongle Tenda W311MI. It reported one model (USB device ID) before being usb_modeswitch'ed and another model after being usb_modeswitch'ed. https://www.raspberrypi.org/forums/viewtopic.php?t=215668 https://nixtux.ru/718 I mean that in some cases you may be trying to make an incorrect model work... Hope that this is not the case.
Yes, exactly. My 8891 does not work, but there were people here who stated their 8891 works. Of cause there are other variables (e.g. Motherboard/chipset, linux kernel/distro, BT client device, etc.), still if we take only CSR ID then yes. When I tested my CSR in Windows 10, it worked with quite an old generic usb driver. Still in info it had CSR 8891.
BTW, in this comment https://bugzilla.kernel.org/show_bug.cgi?id=60824#c59 there is some possible reason why certain dongles do not work: > I'm having the same issue on a raspberry with an aliexpress dongle, Set Event > fails, looking at hci_core.c the set filter and previous calls are made only > if device supports BREDR, is there any way to tell device doesn't support, or > patch this ?
I found patch for Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) https://www.reddit.com/r/AnnePro/comments/e76ij8/csr_40_bluetooth_dongle_on_linux/ Maybe someone could look on it deeply. Thank you!
(In reply to Marcin from comment #75) > I found patch for > Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI > mode) > > https://www.reddit.com/r/AnnePro/comments/e76ij8/ > csr_40_bluetooth_dongle_on_linux/ > > Maybe someone could look on it deeply. > Thank you! I 'looked on it deeply' and I was able to trace the patch you're talking about (btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch) back to this obscure little site: https://bugzilla.kernel.org/show_bug.cgi?id=60824