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?