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.