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
Still having the same problem on Linux 5.7.4. 75.58, in my case it's one of these super common, round, unmarked dongles: https://web.archive.org/web/https://pl.aliexpress.com/item/33058605031.html Here's what running `hcidump -X` while doing `hciconfig hci0 up` shows; it errors out while trying to delete the stored link key. So, same problem and different bcdDevice; 75.58, sounds like someone needs to add a bunch of extra quirks: HCI sniffer - Bluetooth packet analyzer ver 5.54 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff > HCI Event: Command Complete (0x0e) plen 4 Reset (0x03|0x0003) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 12 Read Local Supported Features (0x04|0x0003) ncmd 5 status 0x00 Features: 0xff 0xff 0xcd 0xfa 0xdb 0xbf 0x7b 0x87 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 5 status 0x00 HCI Version: 4.0 (0x6) HCI Revision: 0x709 LMP Version: 4.0 (0x6) LMP Subversion: 0x709 Manufacturer: Cambridge Silicon Radio (10) > HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 5 status 0x00 bdaddr 00:15:83:EA:<censored>:<censored> > HCI Event: Command Complete (0x0e) plen 11 Read Buffer Size (0x04|0x0005) ncmd 5 status 0x00 ACL MTU 360:4 SCO MTU 0:0 > HCI Event: Command Complete (0x0e) plen 7 Read Class of Device (0x03|0x0023) ncmd 5 status 0x00 class 0x000000 > HCI Event: Command Complete (0x0e) plen 252 Read Local Name (0x03|0x0014) ncmd 5 status 0x00 name '' > HCI Event: Command Complete (0x0e) plen 6 Read Voice Setting (0x03|0x0025) ncmd 5 status 0x00 voice setting 0x0000 > HCI Event: Command Complete (0x0e) plen 5 Read Number of Supported IAC (0x03|0x0038) ncmd 5 0000: 00 01 .. > HCI Event: Command Complete (0x0e) plen 8 Read Current IAC LAP (0x03|0x0039) ncmd 5 IAC 0x9e8b33 (General Inquiry Access Code) > HCI Event: Command Complete (0x0e) plen 4 Set Event Filter (0x03|0x0005) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 4 Write Connection Accept Timeout (0x03|0x0016) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 7 LE Read Buffer Size (0x08|0x0002) ncmd 5 status 0x00 pktlen 0x001b maxpkt 0x12 > HCI Event: Command Complete (0x0e) plen 12 LE Read Supported States (0x08|0x001c) ncmd 5 0000: 00 ff 00 3c 1f 00 00 00 00 ...<..... > HCI Event: Command Complete (0x0e) plen 68 Read Local Supported Commands (0x04|0x0002) ncmd 5 status 0x00 Commands: bfffff03feffffff0fffff1ff20fe8fe3ff78fff1c00000061f7ffff7f18 > HCI Event: Command Complete (0x0e) plen 4 Write Extended Inquiry Response (0x03|0x0052) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 4 Write Inquiry Mode (0x03|0x0045) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 5 Read Inquiry Response Transmit Power Level (0x03|0x0058) ncmd 5 status 0x00 level 8 > HCI Event: Command Complete (0x0e) plen 14 Read Local Extended Features (0x04|0x0004) ncmd 5 status 0x00 page 1 max 0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > HCI Event: Command Complete (0x0e) plen 4 Set Event Mask (0x03|0x0001) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 8 Read Stored Link Key (0x03|0x000d) ncmd 5 status 0x00 max 0 num 0 > HCI Event: Command Complete (0x0e) plen 4 Write Default Link Policy Settings (0x02|0x000f) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 8 Read Page Scan Activity (0x03|0x001b) ncmd 5 status 0x00 interval 512 window 18 > HCI Event: Command Complete (0x0e) plen 5 Read Default Erroneous Data Reporting (0x03|0x005a) ncmd 5 status 0x00 reporting 0 > HCI Event: Command Complete (0x0e) plen 5 Read Page Scan Type (0x03|0x0046) ncmd 5 0000: 00 00 .. > HCI Event: Command Complete (0x0e) plen 4 LE Set Event Mask (0x08|0x0001) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 5 LE Read White List Size (0x08|0x000f) ncmd 5 0000: 00 08 .. > HCI Event: Command Complete (0x0e) plen 4 LE Clear White List (0x08|0x0010) ncmd 5 status 0x00 > HCI Event: Command Complete (0x0e) plen 6 Delete Stored Link Key (0x03|0x0012) ncmd 5 status 0x11 deleted 0 Error: Unsupported Feature or Parameter Value -- This is my `uname -a` shows. I'm just running the normal Arch Linux kernel: Linux fenix 5.7.4-arch1-1 #1 SMP PREEMPT Thu, 18 Jun 2020 16:01:07 +0000 x86_64 GNU/Linux -- This is what `lsusb -v` shows for this device. As you can see in my case it has bcdDevice 75.58: Bus 008 Device 003: 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 75.58 iManufacturer 0 iProduct 0 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 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 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 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 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered) -- This is what `dmesg` shows at startup with the thingie connected: [ 293.350687] usb 8-1: new full-speed USB device number 3 using ohci-pci [ 293.528946] usb 8-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=75.58 [ 293.528953] usb 8-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 295.680774] Bluetooth: hci0: command 0x2003 tx timeout [ 298.027478] Bluetooth: hci0: command 0x2007 tx timeout -- Seems like they have stolen bdaddr space from 00:15:83 IVT corporation. Anyway, hope that helps, let me know if anyone needs something else to diagnose to test a proper Kernel patch that gets mainlined. I'm all ears. :)
Okay, so after investigating the problem in-depth (and doing a bunch of heavy testing) I made what I think is a leaner and meaner +20/-8 line patch, and submitted it for kernel review. It would be great if you guys could test it and let me know if everything works correctly on your end, too: https://patchwork.kernel.org/patch/11619143/ I'm fairly happy with the compactness of it all, the idea is that it should work universally, and be generic and future-proof. Because new cloned dongles are coming up all the time and they will eventually squat all the remaining ID space. For those that want to show their real name and e-mail, feel free to drop a line in your message so that it can be added at the end of the commit message like this; the more testing the better: Tested-by: Your Name <real@email.address> I already credited M. Wisniewski for opening the issue back in 2013. That's it, let me know what you think!
(In reply to Swyter from comment #78) > Okay, so after investigating the problem in-depth (and doing a bunch of > heavy testing) I made what I think is a leaner and meaner +20/-8 line patch, > and submitted it for kernel review. It would be great if you guys could test > it and let me know if everything works correctly on your end, too: > > https://patchwork.kernel.org/patch/11619143/ I was unable to get a bcdDevice 2520 to work with this patch, even though it seems to apply the quirks: --- lsusb -v: Bus 005 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 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 25.20 iManufacturer 0 iProduct 2 CSR8510 A10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus 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 0x83 EP 3 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 0x01 EP 1 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 0x81 EP 1 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 --- dmesg | grep CSR [ 3.449503] usb 5-1: Product: CSR8510 A10 [ 12.619478] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workaround --- Let me know if I can help.
Hi, Andrés. Thanks for testing v1! I just submitted a revised v2 after following the recommendations of Marcel Holtmann and finding a better way of classifying them by type: https://patchwork.kernel.org/patch/11622161/ In your case, and as it says after iProduct in your lsusb -v dump, yours should be a legit Cambridge Silicon Radio CSR8510 A10 chip and detected as such. Those have the HCI_QUIRK_BROKEN_STORED_LINK_KEY bug. Same as my dongle. Give v2 a go. :)
Hi Swyter, unfortunately I'm still unable to list the device. Blueman found no adapters and neither does bluetoothctl list. dmesg info messages say it's still being recognized and given the bcdDevice I assume the quirk is being applied but seemingly is not enough: [ 67.847429] Bluetooth: hci0: CSR: New controller detected; bcdDevice=0x2520, HCI manufacturer=10, HCI rev=0x3120, LMP subver=0x22bb [ 67.847432] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workaround This is a cheap chinese dongle that says "CSR 4.0" on the side, I took a (crappy) photo of the PCB: https://i.imgur.com/3I5aKMZ.jpg and here's a stock one from the vendor showing the box and the dongle: https://i.imgur.com/wyjJTU6.jpg The super small nigh-unreadable text in the main chip says "AP1P181" Let me know if you want me to try anything else.
Hmm. That's interesting, so HCI reports that the chip manufacturer is fine; Cambridge Silicon Radio (10), but then the following check fails and treats it as counterfeit... Which (if I've done my research correctly) *isn't true*, your dongle should be legit and suffering from the Stored Link Key bug, like mine, which also never showed up in `bluetoothctl` before this. ¯\_(ツ)_/¯ If you could try changing this part: > + if (le16_to_cpu(rp->manufacturer) == 10 && > + le16_to_cpu(rp->hci_rev) == le16_to_cpu(rp->lmp_subver)) { ...to this: > + if (le16_to_cpu(rp->manufacturer) == 10) { ...and find that it works for you, then we may be onto something. Until now all the CSR chips I've found put the same little version numbers in both fields, but it may not be as constant as I thought. Back to basics. In any case doing `while true; do sudo hcidump -X; done` in a terminal window that keeps running (you can stop it with Ctrl + C) even when your thingie is disconnected, then trying to plug it in, and then copying the interesting parts of that to GitHub Gist or some other paste place to link here may be useful. If you are on Arch there's a handy bluez-utils-compat AUR package with these utilities. Some interesting keywords to look for in the logs, any errors are probably useful, given some context: - Error: Unsupported Feature or Parameter Value - Stored Link Key Thanks again for testing!
Before removing hci_rev check (patch 2.0 as-is) hcidump -X https://gist.github.com/mixedCase/67bfaa752050aa4a705e538f9d478ec3 dmesg: [14225.389482] usb 1-2: new full-speed USB device number 6 using xhci_hcd [14225.549112] usb 1-2: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=25.20 [14225.549115] usb 1-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [14225.549117] usb 1-2: Product: CSR8510 A10 [14225.557143] Bluetooth: hci0: CSR: New controller detected; bcdDevice=0x2520, HCI manufacturer=10, HCI rev=0x3120, LMP subver=0x22bb [14225.557144] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workaround --- After removing hci_rev check hcidump -X https://gist.github.com/mixedCase/2e1c670e5d4ff414558b35db37472058 dmesg: [13938.833774] usb 1-2: new full-speed USB device number 4 using xhci_hcd [13938.996271] usb 1-2: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=25.20 [13938.996274] usb 1-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [13938.996276] usb 1-2: Product: CSR8510 A10 [13939.004322] Bluetooth: hci0: CSR: New controller detected; bcdDevice=0x2520, HCI manufacturer=10, HCI rev=0x3120, LMP subver=0x22bb [13939.004324] Bluetooth: hci0: CSR: Modern CSR controller type detected
Interesting. Sounds like another quirk for that specific model that was hidden until now; they don't support the Read Default Erroneous Data Reporting command. Let's try something, continuing with the same patches as before, change this in net/bluetooth/hci_core.c: > if (hdev->commands[18] & 0x04) > hci_req_add(req, HCI_OP_READ_DEF_ERR_DATA_REPORTING, 0, NULL); ...to this: > if (false) > hci_req_add(req, HCI_OP_READ_DEF_ERR_DATA_REPORTING, 0, NULL); ...and see if the log moves a bit, maybe that fixes it. Who knows? Save the log somewhere. Chances are that the last change wasn't enough. So additionally, after that change this in net/bluetooth/hci_core.c: > /* Set erroneous data reporting if supported to the wideband speech > * setting value > */ > if (hdev->commands[18] & 0x08) { ...to this: > /* Set erroneous data reporting if supported to the wideband speech > * setting value > */ > if (false) { Technically with that Linux should ignore the wideband error thingy altogether. Sounds like we need a HCI_QUIRK_WIDEBAND_SPEECH_NOT_SUPPORTED. The opposite of the HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED that already exists. Anyway, good progress. This is a different bug. ¯\_(ツ)_/¯
Created attachment 289871 [details] CSR_ds4_fail.btsnoop (In reply to Swyter from comment #80) > Hi, Andrés. Thanks for testing v1! I just submitted a revised v2 after > following the recommendations of Marcel Holtmann and finding a better way of > classifying them by type: > > https://patchwork.kernel.org/patch/11622161/ > > > In your case, and as it says after iProduct in your lsusb -v dump, yours > should be a legit Cambridge Silicon Radio CSR8510 A10 chip and detected as > such. > > Those have the HCI_QUIRK_BROKEN_STORED_LINK_KEY bug. > > Same as my dongle. Give v2 a go. :) Tried it for my DS4. Unfortunately the result is the same as when I tried to hardcode my ID: gamepad thinks that it's paired but system does not register it. I've fiddled about with `btmon` and it seems that everything goes wrong at: HCI Event: Role Change (0x12) plen 8 Status: Role Switch Failed (0x35) Role: Slave (0x01) You may read full dump with `btmon -r <file>` `dmesg --color=always | grep -i CSR` says: [ 11.516062] Bluetooth: hci0: CSR: New controller detected; bcdDevice=0x8891, HCI manufacturer=10, HCI rev=0x811, LMP subver=0x811 [ 11.516065] Bluetooth: hci0: CSR: Modern CSR controller type detected
Hi Swyter, I also tried your patch v2 and actually in my case see no difference with the previous ones I tried (see my comments 55/56 https://bugzilla.kernel.org/show_bug.cgi?id=60824#c55 ) Linux recognizes the controller, but it's unusable: Can't init device hci0: Invalid argument (22) > HCI Event: Command Complete (0x0e) plen 4 > #22 [hci0] > 11.191461 Set Event Filter (0x03|0x0005) ncmd 1 Status: Invalid HCI Command Parameters (0x12) = Close Index: 00:1A:7D:DA:71:12 [hci0] 11.191493 I've seen several people here have this issue, and I believe that comment 59 may be quite relevant here: > 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 ?
Hi, guys. Keep in mind that this patch basically uncovers other problems in your respective dongles, so at the bare minimum it stays as-is. And that's a good thing; it's a good start point so that other fixes can be implemented on top. In any case the errors need to appear in context. It's a conversation flow, we need to know more than the last few words to see what went wrong. That's why `while true; do sudo hcidump -X; done` and your log is very useful. Also, please use `lsusb -v -d 0a12:0001` instead of a standard one, the bcdDevice is the most important part. The main bug here is that every single dongle in this thread has the same 0A12:0001 VID/PID. We need to compare and see what's different between them to apply different behaviors. Every bit helps.
@Swyter I'm happy to report some progress! After patching the bitwise 0x04 comparison, the controller can finally be detected, but is unable to find any devices (tested against a Wiimote and an Android phone). This is the hcidump -X: https://gist.github.com/mixedCase/d6962b3d24e13cf4443e8193c1451c5d These are the relevant dmesg lines: [ 50.227320] Bluetooth: hci0: CSR: New controller detected; bcdDevice=0x2520, HCI manufacturer=10, HCI rev=0x3120, LMP subver=0x22bb [ 50.227330] Bluetooth: hci0: CSR: Modern CSR controller type detected [ 50.251489] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 50.251490] Bluetooth: BNEP filters: protocol multicast [ 50.251493] Bluetooth: BNEP socket layer initialized [ 50.340205] NET: Registered protocol family 38 [ 50.362740] Bluetooth: RFCOMM TTY layer initialized [ 50.362745] Bluetooth: RFCOMM socket layer initialized [ 50.362756] Bluetooth: RFCOMM ver 1.11 After trying to find devices with Blueman: [ 107.543868] Bluetooth: hci0: command 0x2005 tx timeout [ 109.677220] Bluetooth: hci0: command 0x200b tx timeout [ 111.810719] Bluetooth: hci0: command 0x200c tx timeout --- After patching out both comparisons, the hcidump -X changes a little bit: https://gist.github.com/mixedCase/e286bbc5f43807bd04c59c2c75cfb88f I notice in there my machine's hostname (Enterprise) which is the default bluez identifier. Thanks for all the help so far! Hope we can find a pattern here.
Created attachment 289879 [details] lsusb -vvd 0a12:0001 (In reply to Swyter from comment #87) > Hi, guys. Keep in mind that this patch basically uncovers other problems in > your respective dongles, so at the bare minimum it stays as-is. And that's a > good thing; it's a good start point so that other fixes can be implemented > on top. > > In any case the errors need to appear in context. It's a conversation flow, > we need to know more than the last few words to see what went wrong. > > That's why `while true; do sudo hcidump -X; done` and your log is very > useful. Also, please use `lsusb -v -d 0a12:0001` instead of a standard one, > the bcdDevice is the most important part. The main bug here is that every > single dongle in this thread has the same 0A12:0001 VID/PID. > > We need to compare and see what's different between them to apply different > behaviors. Every bit helps. Sure. But why do you insist on using `hcidump`, a thing that was deprecated years ago, unmaintained and not build by default to dissuade from packaging it, instead of `btmon` that is necessary part of bluez ?
Because it's what I know, plain and simple. It's what I have been using and it's what I've been comfortable recommending. As long as they are HCI logs and *they exist* it doesn't matter the format, doing `btmon -w my.log` is much nicer than `hcidump -X`, that's for sure, so thanks for that. I'm learning as I go, I figured that if no one was stepping up I might as well give it a try. Seems like a good way of submitting a first patch and learning a few things. ¯\_(ツ)_/¯ I took a look at your DS4 logs. I would take similar captures on Windows to compare, maybe the role switch isn't really needed. If you could link your Windows drivers here it may also be useful, maybe the dongle needs to be configured with vendor commands before using it. **Update**: Tested DS4 pairing myself with BlueZ and no, the `Accept Connection Request` packet doesn't show up and it connects normally, the spec says that this isn't non-fatal, and in this case the one erroring out due to timeout and disconnecting is the DS4, so that's something to keep in mind. From what I see, HCI_OP_ACCEPT_CONN_REQ seems to be called by the SCO layer in sco_conn_defer_accept(): https://github.com/torvalds/linux/blob/cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/sco.c#L741 Or alternatively from here, I believe: https://github.com/torvalds/linux/blob/cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/hci_event.c#L2742 It's a wild guess, but it may be sound-related. -- Another thing to keep in mind is that the bluez-utils package has a nifty `bccmd` tool for CSR devices (a clone of a proprietary tool, actually) that is able to get and set most of the internal firmware properties and detect the chip type, in theory. It doesn't work for me, though. I'm guessing there's an alternative way of accessing the vendor commands via USB, or the interface has changed since then. But at least worth a shot on your end. Maybe you guys have more luck doing `bccmd chiprev`.
Created attachment 289883 [details] ISSC_ds4_pass.btsnoop (In reply to Swyter from comment #90) > Because it's what I know, plain and simple. It's what I have been using and > it's what I've been comfortable recommending. As long as they are HCI logs > and *they exist* it doesn't matter the format, doing `btmon -w my.log` is > much nicer than `hcidump -X`, that's for sure, so thanks for that. I'm > learning as I go, I figured that if no one was stepping up I might as well > give it a try. Seems like a good way of submitting a first patch and > learning a few things. ¯\_(ツ)_/¯ Sure, it's just that not only hcidump likely to not be installed by default or even packaged, the fact that it's long time obsoleted means that it can also be incorrect and no one is going to debug it. btmon's file dumps are binary though, so you would need to use `tee` to dump text as it scrolls or use `btmon -r`. > I took a look at your DS4 logs. I would take similar captures on Windows to > compare, maybe the role switch isn't really needed. If you could link your > Windows drivers here it may also be useful, maybe the dongle needs to be > configured with vendor commands before using it. **Update**: Tested DS4 > pairing myself with BlueZ and no, the `Accept Connection Request` packet > doesn't show up and it connects normally, the spec says that this isn't > non-fatal, and in this case the one erroring out due to timeout and > disconnecting is the DS4, so that's something to keep in mind. > > From what I see, HCI_OP_ACCEPT_CONN_REQ seems to be called by the SCO layer > in sco_conn_defer_accept(): > https://github.com/torvalds/linux/blob/ > cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/sco.c#L741 > Or alternatively from here, I believe: > https://github.com/torvalds/linux/blob/ > cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2/net/bluetooth/hci_event.c#L2742 > > It's a wild guess, but it may be sound-related. > I might have made that dump with '-S' option which adds SCO messages that otherwise might be ignored, just for completeness. DualShocks 3 and 4 are fiddly to connect, when connecting to "new" dongle you need to: 1) Remove any OS entries of it. 2) Force DS4 into pairing mode by holding SELECT+PS until light flashes rapidly, for DS3 you need to connect it to USB. It will write dongle's MAC/UID into itself. 3) Now you can switch it on normally. I'm pretty sure DS wants to be the master in that connection. It works fine on my old 2.x ISSC dongle which I tried to replace with fancier 4.x dongles twice while having 2.x as backup. First 4.x dongle killed itself for no reason a minute after plugging in, bastards didn't even refund me for its corpse. And second one is this CSR. But timeouts seem irrelevant, sometimes they just don't react properly fast enough during pairing and they also refuse to connect to a dongle that's not in their memory. On Windows I just use Windows' stock drivers and DS4Windows https://github.com/Ryochan7/DS4Windows for polling rate / latency, lights controls, battery state tracking and xinput emulation. On Linux there is no control (polling/latency would be really nice for battery/responsiveness balancing and parity with new generation of consoles that advertise 1ms wireless latency which DS4 should be well capable of) but I'm trying out https://github.com/TheDrHax/ds4drv-cemuhook now. I think that Windows' BT stack just not as picky. There is no way they would do per-device workarounds for garbage bin dongles like that. They JUST recently (like last year or something) added USB audio driver after years of relying on crappy, often licensed separately, third-party per-device implementations. > > Another thing to keep in mind is that the bluez-utils package has a nifty > `bccmd` tool for CSR devices (a clone of a proprietary tool, actually) that > is able to get and set most of the internal firmware properties and detect > the chip type, in theory. It doesn't work for me, though. I'm guessing > there's an alternative way of accessing the vendor commands via USB, or the > interface has changed since then. > > But at least worth a shot on your end. Maybe you guys have more luck doing > `bccmd chiprev`. Fails for me with "Can't execute command: No such device or address (6)"
@Swyter: I have exactly the same dongle as Andrés Rodríguez , lsusb identical. Exactly the same symptoms, recognized by usb, not by bluetooth anything (except hciconfig -a hci0 did show it). After doing the v2 patch, then the suggested edits in comments 82 & 84, I am paired and functioning to my stereo A2DP. I can't be mistaken unless my ears are too. Very happy here. I'll keep an eye on this bug, happy to assist in any way I can. Thank you!
Alright, I have submitted another patch for kernel review: https://patchwork.kernel.org/patch/11644615/ This v3 should cover Mike Johnson's test and take all the other reviewer feedback into account. The checks may still need some fine-tuning in the future. But again, it's a good start point for counterfeit dongles. Better than nothing, which is what we have now. Small, progressive improvements are the way forward. So yeah, no panacea Bluetooth fix here. Let me know how it goes. :)
I just rebuilt a kernel with the v3 patch and it works fine, though I still need to pass reset=1 and enable_autosuspend=0 to btusb (it needs both).
Forgot to say I bought exactly the same dongle as Mike Johnson and Andrés Rodríguez, if you need more info I can help you as well.
I'm sorry for the flood but now I have this warning spamming my dmesg: [ 8901.594641] Bluetooth: hci0: SCO packet for unknown connection handle 0
I have no errors here Real Name. Working fine for days.
Ok, it seems that the easiest way to trigger that error is if I try to configure my headset as a HSP/HFP device, but I've seen it on other occasions as well. Which is to say I have absolutely no idea what's going on. The patch does work very well though. When I tried to pair devices under Windows it threw a BSOD at me, but on Linux I can modprobe/rmmod, change ports and it's up and running just the same.
(In reply to Swyter from comment #93) > Alright, I have submitted another patch for kernel review: > https://patchwork.kernel.org/patch/11644615/ > > This v3 should cover Mike Johnson's test and take all the other reviewer > feedback into account. The checks may still need some fine-tuning in the > future. > > But again, it's a good start point for counterfeit dongles. Better than > nothing, which is what we have now. Small, progressive improvements are the > way forward. > > So yeah, no panacea Bluetooth fix here. Let me know how it goes. :) Your patch V3 works great, I'm using this cheap dongle https://en.aliexpress.com/i/4000517165819.html?spm=a2g03.12057483.0.0.54aa146b5xe42n with kernel 5.7.7 without problems, great job!
It is my honor to be the #100th comment in this thread and to also confirm that the patch v3 worked like a charm here. (With reset=1 and enable_autosuspend=0 added to btusb too). Thank you for saving my money and time.
(In reply to M.Hanny Sabbagh from comment #100) > It is my honor to be the #100th comment in this thread and to also confirm > that the patch v3 worked like a charm here. (With reset=1 and > enable_autosuspend=0 added to btusb too). > > Thank you for saving my money and time. Unfortunately I can not say the same. Using Arch Linux here and tried a lot of patches on kernel 5.7.7 and 5.7.8 as showed on my forum post here https://bbs.archlinux.org/viewtopic.php?pid=1915544#p1915544
(In reply to AndreyTarkovsky from comment #101) > Unfortunately I can not say the same. Using Arch Linux here and tried a lot > of patches on kernel 5.7.7 and 5.7.8 as showed on my forum post here > https://bbs.archlinux.org/viewtopic.php?pid=1915544#p1915544 Did you try running 'sudo hciconfig hci0 up'? Unless Arch does something different to their kernels. I patched a stock Fedora kernel (built from source RPM).
(In reply to Real Name from comment #102) > (In reply to AndreyTarkovsky from comment #101) > > Unfortunately I can not say the same. Using Arch Linux here and tried a lot > > of patches on kernel 5.7.7 and 5.7.8 as showed on my forum post here > > https://bbs.archlinux.org/viewtopic.php?pid=1915544#p1915544 > > Did you try running 'sudo hciconfig hci0 up'? Unless Arch does something > different to their kernels. I patched a stock Fedora kernel (built from > source RPM). hciconfig dev hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:10 ACL MTU: 640:4 SCO MTU: 64:8 DOWN RX bytes:1084 acl:0 sco:0 events:50 errors:0 TX bytes:662 acl:0 sco:0 commands:50 errors:0 sudo hciconfig hci0 up Can't init device hci0: Invalid request code (56) Looks like there is something special on my dongle. dmesg showed it was recognized as a CSR clone: [ 194.023832] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds... [ 194.032848] debugfs: File 'dut_mode' in directory 'hci0' already present! [ 194.077761] audit: type=1106 audit(1595108086.134:91): pid=1605 uid=0 auid=1000 ses=3 msg='op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' [ 194.077970] audit: type=1104 audit(1595108086.134:92): pid=1605 uid=0 auid=1000 ses=3 msg='op=PAM:setcred grantors=pam_unix,pam_permit,pam_env acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Maybe this can help. Tried Knoppix(kernel 5.3.5-64) distro on Virtual Box and dmesg said this about my usb bluetooth dongle: [ 307.982384] usb 1-2: new full-speed USB device number 3 using ohci-pci [ 308.475005] usb 1-2: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=25.20 [ 308.475008] usb 1-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 308.475010] usb 1-2: Product: CSR8510 A10 [ 308.575313] Bluetooth: Core ver 2.22 [ 308.575416] NET: Registered protocol family 31 [ 308.575417] Bluetooth: HCI device and connection manager initialized [ 308.575423] Bluetooth: HCI socket layer initialized [ 308.575425] Bluetooth: L2CAP socket layer initialized [ 308.575429] Bluetooth: SCO socket layer initialized [ 308.582531] usbcore: registered new interface driver btusb [ 308.732775] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 308.732777] Bluetooth: BNEP filters: protocol multicast [ 308.732781] Bluetooth: BNEP socket layer initialized
(In reply to AndreyTarkovsky from comment #104) > [ 307.982384] usb 1-2: new full-speed USB device number 3 using ohci-pci > [ 308.475005] usb 1-2: New USB device found, idVendor=0a12, idProduct=0001, > bcdDevice=25.20 > [ 308.475008] usb 1-2: New USB device strings: Mfr=0, Product=2, > SerialNumber=0 > [ 308.475010] usb 1-2: Product: CSR8510 A10 Looks exactly like mine. Post the output of 'sudo lsusb -vd 0a12:0001'.
(In reply to Real Name from comment #105) > (In reply to AndreyTarkovsky from comment #104) > > [ 307.982384] usb 1-2: new full-speed USB device number 3 using ohci-pci > > [ 308.475005] usb 1-2: New USB device found, idVendor=0a12, > idProduct=0001, > > bcdDevice=25.20 > > [ 308.475008] usb 1-2: New USB device strings: Mfr=0, Product=2, > > SerialNumber=0 > > [ 308.475010] usb 1-2: Product: CSR8510 A10 > > Looks exactly like mine. Post the output of 'sudo lsusb -vd 0a12:0001'. Here: sudo lsusb -vd 0a12:0001 Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 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 25.20 iManufacturer 0 iProduct 2 CSR8510 A10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus 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 0x83 EP 3 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 0x01 EP 1 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 0x81 EP 1 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
(In reply to AndreyTarkovsky from comment #106) >... Still looks like mine, maybe a slightly different chip that needs more quirks. Someone more knowledgeable about those quirks might be able to help you.
many thanks @Swyter.It works like a charm. This is my first time patching and building a custom kernel. It's quite fancy experience. this is lsusb output if it can help. #lsusb -vd 0a12:0001 Bus 003 Device 007: 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 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
Hi, Like Andrey, with patch v3 and reset=0 + enable_autosuspend=0, I can't make my Bluetooth adapter work :-/ I am also using an ArchLinux kernel (patched). Here is my lsusb, if it can help: sudo lsusb -vd 0a12:0001 Bus 001 Device 014: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 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 88.91 iManufacturer 0 iProduct 2 BT DONGLE10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 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 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 can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered) Many thanks!
Oh, I should have added that btmon gives me the following error when plugging the USB dongle: < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 #21 [hci0] 39.239547 > HCI Event: Command Complete (0x0e) plen 8 > > #22 [hci0] > 39.241502 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] 39.241510 Type: Clear All Filters (0x00) > HCI Event: Command Complete (0x0e) plen 4 > > #24 [hci0] > 39.243501 Set Event Filter (0x03|0x0005) ncmd 1 Status: Invalid HCI Command Parameters (0x12) = Close Index: 00:1A:7D:DA:71:12
Just submitted v4 for kernel review. Its behavior should be identical to v3, it only contains a few minor technical changes and logic flow tweaks, to appease the BlueZ gods. Nothing new. We'll see if they like this one. If it needs to be trimmed down and submitted as a tiny patch series then I can also do that. As long as it gets mainlined in some shape or form: https://patchwork.kernel.org/patch/11686157/ Thanks again for your comments and reports. I have credited some of you with a Tested-By line, hope you guys don't mind. Just let me know. ¯\_(ツ)_/¯
SCO routing seems less broken, now it cycles between several handles instead of being stuck in handle 0. It also stops eventually, so no more endless dmesg spam. I'll attach it, maybe it can help figuring out a fix (couldn't find anything on Google for those counterfeit controllers). Switching between headset mode and A2DP doesn't crash my session anymore. So, nice improvement.
Created attachment 290593 [details] SCO packets dmesg bcdDevice=25.20
it still does not work here on Arch Linux, kernel 5.7.9. Interesting that on Linux Mint 20, trying it in a VM, Mint recognized my dongle on bluetoothctl as showed here http://ix.io/2sq3 (this output was catched when I unplugged and plugged again the dongle)but didn't work either.
Thanks for the patch! I tested with v3 in kernel 5.7.10-1-MANJARO. It works for me with following issues: - connecting worked not so well until I enabled USB port over sysfs completely with setting power/control to "on" (enable_autosuspend=0 seems not to be sufficient in my case) - dongle doesn't support more as one simultan connection. But I think this is a firmware problem and not a driver one My lsusb output: Bus 004 Device 017: 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 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 0x003f 1x 63 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 0x003f 1x 63 bytes bInterval 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
Well, good news. Marcel seemed happy with v4 and the patch has been accepted: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cde1a8a992875a7479c4321b2a4a190c2e92ec2a Thanks for testing, hopefully we'll get to enjoy our slightly less broken dongles soon-ish. This was my first kernel patch stint, and all in all I think that after the first submission (oof!) things seemed surprisingly accessible and formative, I barely knew anything about Bluetooth or mailing lists before this. So don't get discouraged, the information is there. ¯\_(ツ)_/¯
Great. Now to make Fedora backport it. Yeah I will eventually tackle the SCO routing issue, though it not working even on Windows (i.e. nowhere to reverse-engineer from) doesn't give me high hopes of making it work anywhere else.
Tested with kernel 5.8.0-050800-generic x86_64 on Ubunutu 20.04 Works for bcdDevice 88.91 Broken for bcdDevice 25.20 is this patch included in newest kernel? lsusb -v log for 88.91 Bus 001 Device 013: 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 88.91 iManufacturer 0 iProduct 2 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 lsusb -v log for 25.20 Bus 001 Device 012: 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 25.20 iManufacturer 0 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus 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 0x83 EP 3 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 0x01 EP 1 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 0x81 EP 1 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 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 0x02 EP 2 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 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0031 1x 49 bytes bInterval 1
By the way, guys. While knowing the bcdDevice/lsusb is interesting, the important part to narrow down these dongles is knowing their HCI version, HCI Revision, LMP version, LMP Subversion and Manufacturer fields. So please include some kind of `hciconfig -a` output or the 'Read Local Version Information' packet from your `btmon -w my.log` session that should show up at the start of your capture. That's what actually allows us to add specific workarounds.
Created attachment 290729 [details] btmon -w for working bt dongle 4.0 hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:11 ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN ISCAN RX bytes:622 acl:0 sco:0 events:38 errors:0 TX bytes:952 acl:0 sco:0 commands:38 errors:0 Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'ardom' Class: 0x1c0104 Service Classes: Rendering, Capturing, Object Transfer Device Class: Computer, Desktop workstation HCI Version: 4.0 (0x6) Revision: 0x22bb LMP Version: 4.0 (0x6) Subversion: 0x22bb Manufacturer: Cambridge Silicon Radio (10)
Created attachment 290731 [details] btmon -w for broken bt dongle 4.0 hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:10 ACL MTU: 640:4 SCO MTU: 64:8 DOWN RX bytes:501 acl:0 sco:0 events:22 errors:0 TX bytes:326 acl:0 sco:0 commands:22 errors:1 Features: 0xff 0xff 0x8f 0xfa 0x9b 0xff 0x59 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT
Created attachment 290733 [details] btmon -w for broken bt dongle 5.0 hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:10 ACL MTU: 640:4 SCO MTU: 64:8 DOWN RX bytes:501 acl:0 sco:0 events:22 errors:0 TX bytes:326 acl:0 sco:0 commands:22 errors:1 Features: 0xff 0xff 0x8f 0xfa 0x9b 0xff 0x59 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT
Looks like the last two are fake CSR (i.e. the interesting ones), but because they don't initialize properly we can't actually see HCI/LMP/Manufacturer stuff we are interested in. Sounds like a packet capture is the only way of finding these values. So please use `btmon -w my.log` (or alternatively `hcidump -X`) to capture the Bluetooth traffic as shown in previous comments. The good thing is that they should get stuck early on, so I don't expect a lot of traffic once you plug that in. Search for 'Read Local Version Information' in this thread to see examples. So yeah, if possible, please include the bcdDevice + hciconfig -a + 'Read Local Version Information' packet in your tests. The bigger the corpus of counterfeit dongles, the more we can extrapolate and make better workarounds that work for everyone.
Created attachment 290735 [details] 'hcidump -X' while executing 'hciconfig hci0 up'
Created attachment 290737 [details] `btmon -w` while executing `hciconfig hci0 up` for fake BT dongle 4.0
Created attachment 290739 [details] `btmon -w` while executing `hciconfig hci0 up` for fake BT dongle 5.0
Created attachment 290745 [details] (btmon -w) while executing `hciconfig hci0 up` for fake BT dongle 4.0 Plugged the dongle and did the command as showed in the last comments.
Created attachment 290829 [details] Relevant info (In reply to Swyter from comment #111) > Just submitted v4 for kernel review. Its behavior should be identical to v3, > it only contains a few minor technical changes and logic flow tweaks, to > appease the BlueZ gods. Nothing new. > ... > https://patchwork.kernel.org/patch/11686157/ Tried your patch on my current in use kernel 5.7.12 but unfortunately can't get my fake CSR to initiate properly. Hcidump and other relevant info in attachment.
Created attachment 290889 [details] hcdump_acr_5.0
Created attachment 290891 [details] btmon_acr_5.0
Created attachment 290893 [details] lspci_acr_5.0
Hi, Encoutering issue with a new bluetooth dongle (hci1) acquired from Gearbest site. hciconfig hci0 up Can't init device hci0: Invalid request code (56) I tried on 5.4 kernel and moved to 5.8.1-050801-generic the same behaviour. hci1: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:10 ACL MTU: 640:4 SCO MTU: 64:8 DOWN RX bytes:501 acl:0 sco:0 events:22 errors:0 TX bytes:329 acl:0 sco:0 commands:22 errors:0 Features: 0xff 0xff 0x8f 0xfa 0x9b 0xff 0x59 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT hci0: Type: Primary Bus: USB BD Address: 4C:1D:96:6D:CB:48 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING RX bytes:19359 acl:0 sco:0 events:3062 errors:0 TX bytes:748521 acl:0 sco:0 commands:3061 errors:0 Features: 0xbf 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'VivoBook' Class: 0x1c010c Service Classes: Rendering, Capturing, Object Transfer Device Class: Computer, Laptop HCI Version: 5.1 (0xa) Revision: 0x100 LMP Version: 5.1 (0xa) Subversion: 0x100 Manufacturer: Intel Corp. (2) Any help wil be appreciated. Regards
Hi , Sorry , forgot about it , i patched my kernel as described on this link https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3415350 and it works like a charm rgds
(In reply to Swyter from comment #111) > Just submitted v4 for kernel review. Its behavior should be identical to v3, > it only contains a few minor technical changes and logic flow tweaks, to > appease the BlueZ gods. Nothing new. > ... > https://patchwork.kernel.org/patch/11686157/ Just to correct my last comment #128. The patch indeed work. First time I tried I didn't pay attention to the patch, I just applied the patch. Then I built only the module (btusb) for my in use kernel version. For obvious reasons it didn't work. Today with more time I realized the stupidity I did, then I built the entire kernel. Now after load the btusb module with the options "reset=1 enable_autosuspend=0" the dongle initiates and apparently works correctly. I'm sorry for the misinformation on my last comment. Thank you Swyter for your time on fixing this. Hope to see the patch in mainline kernel soon.
Well, then I have good news for you. Because I have just received two e-mails from Sasha Levin saying that my Bluetooth patch has been added to the 5.8-stable and 5.7-stable trees. So hopefully we'll see it running in mainstream distros soon™ without having to wait for 5.9 to land. :)
(In reply to Swyter from comment #116) > Well, good news. Marcel seemed happy with v4 and the patch has been accepted: > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/ > ?id=cde1a8a992875a7479c4321b2a4a190c2e92ec2a > > Thanks for testing, hopefully we'll get to enjoy our slightly less broken > dongles soon-ish. This was my first kernel patch stint, and all in all I > think that after the first submission (oof!) things seemed surprisingly > accessible and formative, I barely knew anything about Bluetooth or mailing > lists before this. So don't get discouraged, the information is there. > ¯\_(ツ)_/¯ Dear Swyter, Thanks for this patch. Can you please give step by step details to apply this patch on Ubuntu 20.04 Kernel version is 4.5.0-42-generic Will be very helpful for novice like me. Thanks
Hi! There's actually a script that should help with this, at least as reference: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 It's for newer kernels, though. So while the btusb.c part should more or less apply cleanly (because the existing/original CSR workaround stuff has been there for a while) the ERR_DATA_REPORTING stuff (on hci_core.c) is new and will need to be stripped out when back-porting the patch. Who knows, maybe it's a good idea to ask someone from Canonical to add it to Ubuntu, once it's been more battle-tested. Hopefully (as it officially gets into stable kernels) distros downstream will pick this up, even on super old Linux versions. Hope that helps. :)
Just compiled the 5.8.2 vanilla kernel in Gentoo, yep, v4 is there, no more patches!
Created attachment 292041 [details] lsusb -v && Local Version Information While trying to scan for BLE devices with 'sudo hcitool -i hci0 lescan' I got the following error: 'Set scan parameters failed: Input/output error' Capturing with btmon while trying to scan gave me this: < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 Type: Active (0x01) Interval: 10.000 msec (0x0010) Window: 10.000 msec (0x0010) Own address type: Public (0x00) Filter policy: Accept all advertisement (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Unknown HCI Command (0x01)
(In reply to Swyter from comment #137) > Hi! There's actually a script that should help with this, at least as > reference: > https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 > > It's for newer kernels, though. So while the btusb.c part should more or > less apply cleanly (because the existing/original CSR workaround stuff has > been there for a while) the ERR_DATA_REPORTING stuff (on hci_core.c) is new > and will need to be stripped out when back-porting the patch. > > Who knows, maybe it's a good idea to ask someone from Canonical to add it to > Ubuntu, once it's been more battle-tested. Hopefully (as it officially gets > into stable kernels) distros downstream will pick this up, even on super old > Linux versions. > > Hope that helps. :) Hi tried this script, but it gives below error cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No such file or director I checked there is no such directory and file. I have Ubuntu 20.04 LTS with Kernel 5.4.0-42-generic. Then updated kernel to hoping that 5.8.2-050802-generic hoping by Bluetooth device will work with this .(As you mentioned this script is accepted in 5.7 and 5.8 version of kernel) With new kernel 5.8.2-050802-generic, it detects logitech M337 mouse , but not able to configure. Then I tried above script and got error cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No such file or director
(In reply to MMD from comment #140) > (In reply to Swyter from comment #137) > > Hi! There's actually a script that should help with this, at least as > > reference: > > https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 > > > > It's for newer kernels, though. So while the btusb.c part should more or > > less apply cleanly (because the existing/original CSR workaround stuff has > > been there for a while) the ERR_DATA_REPORTING stuff (on hci_core.c) is new > > and will need to be stripped out when back-porting the patch. > > > > Who knows, maybe it's a good idea to ask someone from Canonical to add it > to > > Ubuntu, once it's been more battle-tested. Hopefully (as it officially gets > > into stable kernels) distros downstream will pick this up, even on super > old > > Linux versions. > > > > Hope that helps. :) > > Hi tried this script, but it gives below error > cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No > such file or director > > I checked there is no such directory and file. > > I have Ubuntu 20.04 LTS with Kernel 5.4.0-42-generic. Then updated kernel to > hoping that 5.8.2-050802-generic hoping by Bluetooth device will work with > this .(As you mentioned this script is accepted in 5.7 and 5.8 version of > kernel) > With new kernel 5.8.2-050802-generic, it detects logitech M337 mouse , but > not able to configure. Then I tried above script and got error > cp: cannot stat '/usr/lib/modules/5.8.2-050802-generic/build/.config': No > such file or director I tried some command as suggested by you on https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 Here is the output of its lsusb -vvd 0a12:0001... gives bcdDevice 25.20 dmesg |grep 'CSR clone detected' [ 75.420911] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds... [ 4880.814947] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds... [22664.573526] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds... [23268.855461] Bluetooth: hci0: CSR: Unbranded CSR clone detected; adding workarounds... btmon -w my.log Bluetooth monitor ver 5.54 = Note: Linux version 5.8.2-050802-generic (x86_64) 0.574027 = Note: Bluetooth subsystem version 2.22 0.574029 = New Index: 00:1A:7D:DA:71:10 (Primary,USB,hci0) [hci0] 0.574030 @ MGMT Open: bluetoothd (privileged) version 1.17 {0x0001} 0.574031 @ MGMT Open: btmon (privileged) version 1.17 hcidump -X HCI sniffer - Bluetooth packet analyzer ver 5.53 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
(In reply to Swyter from comment #137) > Hi! There's actually a script that should help with this, at least as > reference: > https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07 > > It's for newer kernels, though. So while the btusb.c part should more or > less apply cleanly (because the existing/original CSR workaround stuff has > been there for a while) the ERR_DATA_REPORTING stuff (on hci_core.c) is new > and will need to be stripped out when back-porting the patch. > > Who knows, maybe it's a good idea to ask someone from Canonical to add it to > Ubuntu, once it's been more battle-tested. Hopefully (as it officially gets > into stable kernels) distros downstream will pick this up, even on super old > Linux versions. > > Hope that helps. :) Yes...finally it is working... I installed kernel 5.8.3 and ran script at.. And it is working... Thank you very much....
Created attachment 292177 [details] repeatedly calling hcidump -X
Created attachment 292179 [details] btmon -w dump
Created attachment 292181 [details] lsusb for CSR 4.0 dongle
Hi everyone, I have bought a dongle just like Andres's in https://bugzilla.kernel.org/show_bug.cgi?id=60824#c81 and my system has problems activating it. This is my system: Linux localhost.localdomain 5.7.9-200.fc32.x86_64 #1 SMP Fri Jul 17 16:23:37 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux These are result of running commands recommended here: $ hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:1A:7D:DA:71:10 ACL MTU: 640:2 SCO MTU: 64:8 DOWN RX bytes:538 acl:0 sco:0 events:25 errors:0 TX bytes:338 acl:0 sco:0 commands:25 errors:0 Features: 0xff 0xff 0x8f 0xfa 0xdb 0xff 0x5b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Local Version Information from btmon output: < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 #5 [hci0] 3.570144 > HCI Event: Command Complete (0x0e) plen 12 > #6 [hci0] 3.572090 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 4.0 (0x06) - Revision 12576 (0x3120) LMP version: Bluetooth 4.0 (0x06) - Subversion 8891 (0x22bb) Manufacturer: Cambridge Silicon Radio (10) hcidump -X resulted in this : https://bugzilla.kernel.org/attachment.cgi?id=292177 btmon -w : https://bugzilla.kernel.org/attachment.cgi?id=292179 lsusb : https://bugzilla.kernel.org/attachment.cgi?id=292181 thanks for the great work
My dongle worked fine with kernel 5.7, broken with 5.8.0 (problems connecting with headphones) and seems to be fixed again in 5.8.5. Same device as comment 118.
Yeah, I tested 5.8.2-arch when it came out and it was a bit disappointing, to be honest. Something in that timespan caused a regression. It was still an improvement, because the counterfeit detection worked fine and the dongle talked back and forth, but it suffered from weird connection problems, so it probably didn't play well with some of the Bluetooth stack changes introduced recently. As you said, my patch on kernel 5.7 worked more or less fine. I haven't had time to properly track down the issue or see what happens in newer kernel versions with the patch included (from 5.8.2 onwards, I think). https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/bluetooth/btusb.c?id=v5.8.2&id2=v5.8.1 But maybe it has ironed out itself. ¯\_(ツ)_/¯ If anyone has time to do some regression testing to narrow down the issue and better document what's going on, it would probably help a lot.
What about BLE, anyone can get this dongles work with BLE devices? I tried without success like I said in my last comment #139. I don't even know if this dongles work with BLE or not I just know they are advertised as Bluetooth 4.0. And HCI version during a packet capture is reporting 0x6 (Bluetooth Core Specification 4.0) so unless they are faking that too it should support BLE. Does anyone here know if it supports BLE on Microsoft Windows? During my tests trying to scan for BLE devices I got this on my packet capture log: LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Unknown HCI Command (0x01) It clearly doesn't recognize the LE scan command.
(In reply to vic from comment #149) > Does anyone here know if it supports BLE on Microsoft Windows? Mine at least doesn't. Trying to pair a device as BLE device doesn't do anything. I was assessing if there was anything to get from the Windows driver but it seemingly doesn't have anything new to offer. But I'm far from an expert, so anyone with more knowledge is invited to chime in.
(In reply to Real Name from comment #150) > (In reply to vic from comment #149) > > Does anyone here know if it supports BLE on Microsoft Windows? > > Mine at least doesn't. Trying to pair a device as BLE device doesn't do > anything. > > I was assessing if there was anything to get from the Windows driver but it > seemingly doesn't have anything new to offer. But I'm far from an expert, so > anyone with more knowledge is invited to chime in. I have tried with my own fake CSR Bluetooth 5.0 adapter on Windows 10 and that works fine after i manually override the default plug and play driver with the generic bluetooth dongle driver in Device Manager. I could connect and use BLE devices without issues but on Linux it can see other devices but not connect regardless of bluetooth version. Details on the dongle from Linux Kernel 5.8.3 > Bus 001 Device 020: 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 64 idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 iManufacturer 0 iProduct 2 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 >
I am using Kernel 5.8.5. Bluetooth mouse is working fine, but some times it starts lagging and becomes very slow.Especially, when I start downloading files on Telegram, mouse becomes very slow. I tried some solutions , but problem is not solved. Anybody know solution for this ?
As a complete newbie in kernel space I wanted to pitch in and say that there are many types of cheap Chinese USB-Bluetooth chips in market that are just a tinsy bit different: Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) 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 25.20 iManufacturer 0 iProduct 2 CSR8510 A10 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x00b1 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA The device gets detected but doesn't respond to any commands including 'power up'. I am thinking if it will be possible to have a proper support of such device in Linux. They do ship with drivers for Windows. If anyone would be so kind to point me to start pointing I would be very interested in hacking some support for it.
(In reply to Alex from comment #86) > Hi Swyter, > > I also tried your patch v2 and actually in my case see no difference with > the previous ones I tried (see my comments 55/56 > https://bugzilla.kernel.org/show_bug.cgi?id=60824#c55 ) > > Linux recognizes the controller, but it's unusable: > > Can't init device hci0: Invalid argument (22) > > > HCI Event: Command Complete (0x0e) plen 4 > > #22 [hci0] > > 11.191461 > Set Event Filter (0x03|0x0005) ncmd 1 > Status: Invalid HCI Command Parameters (0x12) > = Close Index: 00:1A:7D:DA:71:12 > [hci0] 11.191493 > > > I've seen several people here have this issue, and I believe that comment 59 > may be quite relevant here: > > > 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 have the same device, and my fix was simply changing the #define that checks if a device supports BREDR to "false" (aka disabling BREDR support completely) and that solved it.
(In reply to Flole from comment #154) > (In reply to Alex from comment #86) > > Hi Swyter, > > > > I also tried your patch v2 and actually in my case see no difference with > > the previous ones I tried (see my comments 55/56 > > https://bugzilla.kernel.org/show_bug.cgi?id=60824#c55 ) > > > > Linux recognizes the controller, but it's unusable: > > > > Can't init device hci0: Invalid argument (22) > > > > > HCI Event: Command Complete (0x0e) plen 4 > > > #22 > [hci0] > > > 11.191461 > > Set Event Filter (0x03|0x0005) ncmd 1 > > Status: Invalid HCI Command Parameters (0x12) > > = Close Index: 00:1A:7D:DA:71:12 > > [hci0] 11.191493 > > > > > > I've seen several people here have this issue, and I believe that comment > 59 > > may be quite relevant here: > > > > > 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 have the same device, and my fix was simply changing the #define that > checks if a device supports BREDR to "false" (aka disabling BREDR support > completely) and that solved it. Thanks so much. Same device and same issue on Pi Zero. Changing the "#define lmp_bredr_capable(dev)" in hci_core.h to return false did the trick.
It seems like this patch is fake CSRs of up to Bluetooth 4.0? I have the 5.0 one and I can't get it to work. I can't run: hciconfig hci0 up and also btmon.
I'm using v5.9.0 and my device is no more no being detectable. It was when using v5.4.0 and I was able to use it with my readmi airdots but not with my dualshock 4 btmon -w my.log Bluetooth monitor ver 5.54 = Note: Linux version 5.9.0 (armv7l) 0.389794 = Note: Bluetooth subsystem version 2.22 0.389809 @ MGMT Open: bluetoothd (privileged) version 1.18 {0x0001} 0.389816 @ MGMT Open: btmon (privileged) version 1.18 {0x0002} 0.389977 @ RAW Open: hcitool (privileged) version 2.22 {0x0003} 29.538239 @ RAW Close: hcitool {0x0003} 29.538398 @ RAW Open: hcitool (privileged) version 2.22 {0x0003} 29.538529 @ RAW Close: hcitool {0x0003} 29.538556 lsusb -vvd 0a12:0001...| grep bcdDevice bcdDevice 25.20 dmesg |grep 'CSR clone detected' <nothing> hcidump -X HCI sniffer - Bluetooth packet analyzer ver 5.54 Can't attach to device hci0. No such device(19)
Created attachment 293615 [details] hciconfig -a
Created attachment 293617 [details] btmon -w mylog.txt Mine btmon log of my broken dongle My kernel is 5.9.6-arch1-1
Created attachment 293619 [details] lsusb log of my broken dongle
(In reply to Dani from comment #156) > It seems like this patch is fake CSRs of up to Bluetooth 4.0? I have the 5.0 > one and I can't get it to work. I can't run: hciconfig hci0 up and also > btmon. Me too
(In reply to vinodmishra from comment #155) > (In reply to Flole from comment #154) > > (In reply to Alex from comment #86) > > > Hi Swyter, > > > > > > I also tried your patch v2 and actually in my case see no difference with > > > the previous ones I tried (see my comments 55/56 > > > https://bugzilla.kernel.org/show_bug.cgi?id=60824#c55 ) > > > > > > Linux recognizes the controller, but it's unusable: > > > > > > Can't init device hci0: Invalid argument (22) > > > > > > > HCI Event: Command Complete (0x0e) plen 4 > > > > #22 > > [hci0] > > > > 11.191461 > > > Set Event Filter (0x03|0x0005) ncmd 1 > > > Status: Invalid HCI Command Parameters (0x12) > > > = Close Index: 00:1A:7D:DA:71:12 > > > [hci0] 11.191493 > > > > > > > > > I've seen several people here have this issue, and I believe that comment > > 59 > > > may be quite relevant here: > > > > > > > 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 have the same device, and my fix was simply changing the #define that > > checks if a device supports BREDR to "false" (aka disabling BREDR support > > completely) and that solved it. > Thanks so much. > Same device and same issue on Pi Zero. Changing the "#define > lmp_bredr_capable(dev)" in hci_core.h to return false did the trick. Could you provide more detailed information about how to do this? I'm trying to do the same thing but not sure which drivers i have to compile to apply this change.
After seeing the: "[v3] Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers" https://patchwork.kernel.org/project/bluetooth/patch/6bce2c08-48f0-f49c-d70c-280475220550@gmail.com/ Patch land, I decided to give my own fake CSR dongles marked with "V5.0" on the outside another try. After much experimenting I have managed to get muy variant, which uses a "Barrot 8041a02" chip to work, the patches for this are pending upstream here: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=d74e0ae7e03032b47b8631cc1e52a7ae1ce988c0 https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=0671c0662383eefc272e107364cba7fe229dee44 The second patch contains the fix for the "Barrot 8041a02" chip, but if you want to try this, you need to apply both since the first patch introduces a new local variable which is used in the second. Note this only fixes "v5.0" dongles with the Barrot chip. Also important to note here is that frankly these clones are of very poor quality. I guess most of you are getting these from aliexpress. If you look for CSR8510 at aliexpress and then for offers saying "original csr8510" chip (and the dongle will be marked csr 4.0, then you should be getting a dongle with a real CSR chip for almost the same price and those work so much better it just is not funny!
(In reply to vinodmishra from comment #155) > (In reply to Flole from comment #154) > > (In reply to Alex from comment #86) > > > Hi Swyter, > > > > > > I also tried your patch v2 and actually in my case see no difference with > > > the previous ones I tried (see my comments 55/56 > > > https://bugzilla.kernel.org/show_bug.cgi?id=60824#c55 ) > > > > > > Linux recognizes the controller, but it's unusable: > > > > > > Can't init device hci0: Invalid argument (22) > > > > > > > HCI Event: Command Complete (0x0e) plen 4 > > > > #22 > > [hci0] > > > > 11.191461 > > > Set Event Filter (0x03|0x0005) ncmd 1 > > > Status: Invalid HCI Command Parameters (0x12) > > > = Close Index: 00:1A:7D:DA:71:12 > > > [hci0] 11.191493 > > > > > > > > > I've seen several people here have this issue, and I believe that comment > > 59 > > > may be quite relevant here: > > > > > > > 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 have the same device, and my fix was simply changing the #define that > > checks if a device supports BREDR to "false" (aka disabling BREDR support > > completely) and that solved it. > Thanks so much. > Same device and same issue on Pi Zero. Changing the "#define > lmp_bredr_capable(dev)" in hci_core.h to return false did the trick. Thanks, i did that. Seems to have a advance, but still not working as expected. Info and logs: https://gist.github.com/Yrds/5c2d610c86facc9b1f0522a6509e9e23
(In reply to Yuri Santos from comment #164) > (In reply to vinodmishra from comment #155) > > (In reply to Flole from comment #154) [snip] > > Thanks so much. > > Same device and same issue on Pi Zero. Changing the "#define > > lmp_bredr_capable(dev)" in hci_core.h to return false did the trick. > > Thanks, i did that. Seems to have a advance, but still not working as > expected. > > > Info and logs: > > https://gist.github.com/Yrds/5c2d610c86facc9b1f0522a6509e9e23 I can report some success here using the solution proposed here: https://askubuntu.com/a/1304723 IOW, disabling the "clear event filter" step altogether in hci_core.c (lines around 296-297). Perhaps this could be added as another quirk, but that's sadly beyond my ability. For reference, here's the data of my model (Bluetooth 5.0, bcdDevice 8891) : Features: 0xbf 0x3e 0x4d 0xfa 0xdb 0x3d 0x7b 0xc7 HCI Version: 5.0 (0x9) HCI Revision: 0x810 LMP Version: 5.0 (0x9) LMP Subversion: 0x2312 Manufacturer: Cambridge Silicon Radio (10) idVendor 0x0a12 Cambridge Silicon Radio, Ltd idProduct 0x0001 Bluetooth Dongle (HCI mode) bcdDevice 88.91 iManufacturer 0 iProduct 2 BT DONGLE10 I have tried pairing a couple of devices and it has worked so far. Hopefully a cleaner version of this hack will be able to get into the official kernel.
So.. I hate to bring yet another variable (and probably yet another scenario) to the equation, but have people in here tried to also consider electrical interference? I had been using my fake CSR (lsusb is identical to comment 77, except bcdUSB=2.00 and MaxPower=0mA) for months on my old Core 2 Quad PC with WH-1000XM2. Arguably I was getting even a better run with A2DP and LDAC than windows itself, which is quite the achievement considering how infamous the linux wireless audio stack is. I changed to a more modern Z97 system, and lo and behold I was getting all kinds of crazy errors, disconnections, stuttering, failures to connect.. you name it. After bisecting all my software I eventually turned to the hardware, and see yourself: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/usb3-frequency-interference-papers.pdf Now, with an USB extension cord (or the USB 2.0 port on my laptop *very* far from all the others), I can get a rock solid signal.. at least up to the distance of literally a finger from the antenna inside the headphones. More than that, and anything goes. Sometimes I can listen to an entire album with a normal posture and position, others I have almost to touch the bluetooth receiver. A long cry from when I could even go to the bathroom meters, a wall, and a wooden door away (which is more or less what the AR3012 built-in in my laptop can still score instead). Something is rotten here electromagnetically but I cannot figure out anything more (reported RSSI in btmgmt looks indeed like shit). I tried to disable some of the usb power saving stuff, to no avail. And I wonder if the "hci0: unexpected event for opcode 0x0000" error that I'm only getting on the the first connect on the new Intel southbridges is in any way related.
mirh, hi, interesting comment. I wonder if this perhaps is a USB packet timing issue, rather then a signal strength issue, esp. the " "hci0: unexpected event for opcode 0x0000" error that I'm only getting..." bit makes me wonder this. Your old PC was likely using an EHCI controller. Where as your new PC is using a xHCI controller, or a mix of EHCI + xHCI. There is a subtle problem with USB1/2 compatibility and xHCI controllers. the UHCI/EHCI USB1/2 controllers have a frameclock of 1 ms and when sending a new USB packet to a device just after the frame clock-tick, it will get delayed until the next frame. The xHCI controller however will send any new USB control/bulk transfers *immediately* if there is room for it on the BUs schedule (IOW if the bus is otherwise idle). I've recently helped fix support for some old USB scanners by inserting a 1 ms delay for some requests during the initialization of the scanner since the new xHCI behavior made the time between 2 requests too short for the firmware of the scanner to handle. I wonder if something similar is going on here.
Uh. Actually, now that you make me check my journal logs (unfortunately the old computer is no longer with me).. It was using uhci_hcd indeed. https://www.intel.com/content/dam/doc/datasheet/i-o-controller-hub-7-datasheet.pdf#page=46 Not sure if due to some advanced switcheroo logic, or just out of luckily plugging it in inside the right port. That could also explain why the damn adapter is still glitchy even when I plug it in my other A50M netbook with all USB 2.0 ports.
Ah, so your old PC was that old, ok. So there are basically 4 generations of USB controllers which are relevant here: 1. The first USB-2 capable Intel PCs use UHCI for USB-1, and EHCI for USB-2. Ports directly on the motherboard are automatically muxed to the UHCI/EHCI controller depending on device speed (and some BT dongles are USB1). When a USB-2 hub is plugged into this generation and then an USB-1 device plugged into the HUB, then the USB-1 device will be handled by the EHCI controller. If you still have your old PC you can check if the BT USB adapter you are using perhaps dislikes being routed through the TT (transaction translator) of a hub, but putting an USB-2.0 hub in between. 2. Later USB-2 capable Intel PCs dropped the UHCI controllers (and the muxing of ports) instead integrating a USB-2 hub with the EHCI controller(s) 3. The first USB-3 capable motherboards had a combinationn of USB-3 ports connected to a XHCI controller and also had some EHCI controllers. Also the USB-3 ports could be muxed to the EHCI controller (loosing USB-3 support) for use with operating systems which do not support the XHCI controller. With the 1st gen the ports were actually muxed to the EHCI by default IIRC. 4. Current PCs often only have a XHCI controller which serves both the USB-3 and USB-2 ports of the PC.
Hi ! Not sure it helps but this is the one I bought: https://ebay.us/Om8h1k Of course, before I discovered this thread... Should I get another stick or is there any chance that this will ever work ? Anything I can do to help ? Thanks for your efforts all ! Cheers, FL
(In reply to fredleb from comment #170) > Hi ! > > Not sure it helps but this is the one I bought: https://ebay.us/Om8h1k > > Of course, before I discovered this thread... > > Should I get another stick or is there any chance that this will ever work ? > Anything I can do to help ? > > Thanks for your efforts all ! > > Cheers, > FL Likely. After all fiddling about, I gave up on that thing. Instead I bought Orico BTA-508 (on BT5 RTL8761B chip) from https://www.aliexpress.com/item/1005001273586697.html They also have previous BT4 version of a dongle based on real CSR8510 chip and proper firmware: https://www.aliexpress.com/item/32734449020.html - I've seen reports that this one actually works too. For BT5 RTL8761B I had to manually extract firmware file from its Windows driver, current release kernel does not have any and one known from Github did not work for me: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/572#note_776534
I have a CSR Dongle with the exact same problem on Debian 10. I am a new linux user, so my question is how to apply the patch suggested this comment (In reply to Gustavo Padovan from comment #6) > 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. Thanks
(In reply to Diego Morais from comment #174) > I have a CSR Dongle with the exact same problem on Debian 10. I am a new > linux user, so my question is how to apply the patch suggested this comment > (In reply to Gustavo Padovan from comment #6) > > 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. > > > > Thanks Probably best to ask for debian advice in a debian forum. I'm not a debian user but I'd try updating the kernel, found this on google, https://www.osradar.com/how-to-install-linux-kernel-5-10-debian-10/
(In reply to Steeve McCauley from comment #175) > (In reply to Diego Morais from comment #174) > > I have a CSR Dongle with the exact same problem on Debian 10. I am a new > > linux user, so my question is how to apply the patch suggested this comment > > (In reply to Gustavo Padovan from comment #6) > > > 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. > > > > > > > > Thanks > > Probably best to ask for debian advice in a debian forum. I'm not a debian > user but I'd try updating the kernel, found this on google, > > https://www.osradar.com/how-to-install-linux-kernel-5-10-debian-10/ Thanks for your response. Installed the kernel mentioned with no success. uname -r 5.10.0-0.bpo.4-amd64 I would like to try applying the patch mentioned in my last post, is it complicated? Thanks again!
(In reply to Hans de Goede from comment #169) > When a USB-2 hub is plugged into this generation and then an USB-1 device > plugged into the HUB, then the USB-1 device will be handled by the EHCI > controller. If you still have your old PC you can check if the BT USB > adapter you are using perhaps dislikes being routed through the TT > (transaction translator) of a hub, but putting an USB-2.0 hub in between. I could only test this now with the Windows 7 default CSR drivers, but indeed this is what happens. I tried directly all the row of ports on the P5QPL-AM, and not a single hitch. I plugged in my "Techole UH411" USB hub (technically it's USB 3, but I'd hope it doesn't matter much on this motherboard), and boom. Basically same behaviour I was getting on the newer PC with connection and disconnection cycles all over the place.
(In reply to mirh from comment #177) > I could only test this now with the Windows 7 default CSR drivers, but > indeed this is what happens. > > I tried directly all the row of ports on the P5QPL-AM, and not a single > hitch. I plugged in my "Techole UH411" USB hub (technically it's USB 3, but > I'd hope it doesn't matter much on this motherboard), and boom. Basically > same behaviour I was getting on the newer PC with connection and > disconnection cycles all over the place. Ok, so it misbehaves with the Windows drivers too once a USB-2 hub (with its TT) gets into play. So other then only using the dongle directly plugged into really old (by now) motherboars there really is not much which you can do here I'm afraid. I suggest you buy a new dongle. If you search on say aliexpress (*) for csr8510 then you will find several dongles which are advertised as "original csr8510 chip" in my experience these indeed contain a real CSR8510 chip and they work a lot better then the clones. So the best advice which I have is just to order one of those. This advice goes for everyone in this thread who is still having issues. Trying to get these clone to work with Linux is a good thing to do, since this will also help other users with such clones. But if you just want something which works then just buying a dongle with a real CSR8510 chip is the way to go (these things are pretty affordable). *) Not my favorite source because of the environmental impact of shipping, but ...
(In reply to Hans de Goede from comment #178) > I suggest you buy a new dongle. If you search on say aliexpress (*) for > csr8510 then you will find several dongles which are advertised as "original > csr8510 chip" in my experience these indeed contain a real CSR8510 chip and > they work a lot better then the clones. So the best advice which I have is > just to order one of those. Is there a way the kernel could identify those as a fake/clone, and advertise this in dmesg? It would make debugging user reports much easier as we could just say "get an original instead of a fake/clone". This chipset (and clones) seems to be very common, almost any USB dongle I can find has this chipset (or a clone) inside (according to lsusb), and some work, others don't. This chip is even in dongles of manufactures who somewhat claim that the Bluetooth dongle is completely made by themselves (with no mention of the CSR chip inside), or maybe these are just fake dongles with a brand name on it, I'm not sure. It's difficult to get something else even if you're not looking explicitly for CSR.
Newer versions of the kernel should detect (most) fake CSR dongles and warn via dmesg, check this out: https://github.com/torvalds/linux/commit/cde1a8a992875a7479c4321b2a4a190c2e92ec2a#diff-82175cb30d8f0e6fd9fb8b83571c33aac5db6db4d5f79dd97d4255116a79c79eR1813 My mainlined patch also adds a few known workarounds, which with the latest bluez changes seem insufficient. But when I originally submitted the patch it made my dongle work just fine. So in theory using an older patched kernel should work. Improvements are welcome, while getting a new dongle is a decent solution ideally we'd fix the counterfeit ones enough to work as well as on Windows. The problem is that bluez is a moving target, with new modes being introduced all the time, regressing these fickle chips.
(In reply to Swyter from comment #180) > Newer versions of the kernel should detect (most) fake CSR dongles and warn > via dmesg Oh nice, thanks for the info. If I see this correctly, it's submitted for 5.13: Is that what you mean by "newer kernels"? Will it be backported to stable?
Nevermind, I found out that it's in 5.10 already. My git foo didn't work as I expected, seems it appeared in 5.9.
It ended up being included starting with Linux v5.9-rc1 in July last year, I think I originally tested it with a late v5.7 or v5.8 kernel. Then it regressed shortly afterwards. ¯\_(ツ)_/¯ That's why I said a few months ago that trying to find what broke it is a good start point. Solving it seems like a matter of finding the culprit by narrowing down the range of changes between a known working point and now. Then it should be a matter of testing and sending a small patch that builds onto what's already there in less than ten lines, adding one or more missing quirks. If I were to start working on another fix now I would also compare the packet flow between the Windows and Linux Bluetooth stacks and see what's up and why it locks up after receiving very trivial stuff. Linux is probably doing something extra. :) Comment #165 here and above (testing getting rid of the event filter thingie) seems also like a good candidate to expand the quirk list: https://bugzilla.kernel.org/show_bug.cgi?id=60824#c165 Food for thought.
(In reply to Mauro Fontana from comment #67) > 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. Same here. I managed to compile the module on kernel 5.4.6 with the patch that has the fixups made by Fernando Carvalho, but the symptoms are the same as without it; no bluetooth adapter found with bluetoothctl or any other front end. Dmesg shows the patch and the fixups are indeed applied. lsusb -v -> https://pastebin.com/HDc9z10e /etc/modprobe.d/csr-bluetoothbongle.conf: <code>options btusb fixups=0x0800000:0x000004:0x0a12:0x0001:0x8891</code> dmesg: <code> [ 2080.767176] usbcore: registered new interface driver btusb [ 2086.045608] usb 2-4: new full-speed USB device number 11 using xhci_hcd [ 2086.187920] usb 2-4: config 1 interface 1 altsetting 0 endpoint 0x3 has wMaxPacketSize 0, skipping [ 2086.187922] usb 2-4: config 1 interface 1 altsetting 0 endpoint 0x83 has wMaxPacketSize 0, skipping [ 2086.188519] usb 2-4: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91 [ 2086.188520] usb 2-4: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 2086.188522] usb 2-4: Product: BT DONGLE10 [ 2086.190717] btusb: New fixups. Device: 0x0a12:0x0001/0x8891. Rule 1/1 (5 terms): 0x0a12:0x0001/0x8891 [ 2086.190718] btusb: driver flags: initial => 0x0000000000000004 [ 2086.190719] btusb: driver flags: masked => 0x0000000000800000</code>
Hey everyone! I'm currently running 5.12.12-arch1-1 and I'm having the same issues with the CRS bluetooth dongle. I've found that it begins to work if I suspend my computer and then wake it up. This has worked every time I've tried it so far. I'm not sure what this means for figuring out a fix, but I believe it should be helpful. Let me know if you need more info regarding my setup.
Turns out Hans de Goede completed the work I started last year trying to improve Chinese-clone detection of CSR controller chips. And seems like it all points to the same power reset issue *and* workaround. The workaround was already present in the kernel since December 2020: https://github.com/torvalds/linux/commit/0671c0662383eefc272e107364cba7fe229dee44 Here's my submitted patch, give it a go. In theory you don't need anything else, no `reset=1 enable_autosuspend=0`, just relaxing the check: https://patchwork.kernel.org/project/bluetooth/patch/906e95ce-b0e5-239e-f544-f34d8424c8da@gmail.com/ PS: For more information and some discussion take a look here: https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07#gistcomment-3815490