Bug 60824

Summary: [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable
Product: Drivers Reporter: M. Wisniewski (brylozketrzyn)
Component: BluetoothAssignee: linux-bluetooth (linux-bluetooth)
Status: REOPENED ---    
Severity: normal CC: alan, alexandre, andreapedra91, arthur, barfin, carlosgarciaq, cJ-kernel, gabriel_scf, gustavo, johan.hedberg, oliver.frolovs, pires.carvalho, raestloz, rafaeln.dev, remche, s.rasnikov, ssharunas, szymon.janc, takacsk2004, virtuousfox, yonseca, younes.m
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 3.11 rc6 git Tree: Mainline
Regression: Yes
Attachments: binary dump of hcidump
mark Delete Stored Keys as non-critical failure
'hcidump -X' while executing 'hciconfig hci0 up' for carlosgarciaq
contents of /sys/kernel/debug/usb/devices for carlosgarciaq
patches.hsf/btusb-Enablement-of-HCI_QUIRK_BROKEN_STORED_LINK_KEY-quirk.patch
btusb.c: Module parameter to control multiple fixup

Description M. Wisniewski 2013-09-01 01:29:54 UTC
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)
Comment 1 Gustavo Padovan 2013-09-01 15:07:39 UTC
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.
Comment 2 M. Wisniewski 2013-09-01 15:36:17 UTC
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.
Comment 3 M. Wisniewski 2013-09-01 15:37:05 UTC
Created attachment 107378 [details]
binary dump of hcidump
Comment 4 Gustavo Padovan 2013-09-01 16:14:51 UTC
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.
Comment 5 M. Wisniewski 2013-09-01 17:08:37 UTC
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
Comment 6 Gustavo Padovan 2013-09-01 17:54:31 UTC
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.
Comment 7 M. Wisniewski 2013-09-01 20:21:42 UTC
It seems to work: hciconfig hci0 up really brings dongle up an pairing is possible.

Thank you for quick patch
Comment 8 Gustavo Padovan 2013-09-10 15:58:55 UTC
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?
Comment 9 M. Wisniewski 2013-09-10 16:38:16 UTC
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)
Comment 10 cuboxuser 2013-09-11 05:57:13 UTC
I had the same problem. I have tested on ARM dove 3.11.0 - works fine.
Comment 11 Šarūnas 2013-09-14 16:34:54 UTC
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
Comment 12 daniel.leong 2013-09-23 20:59:43 UTC
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
Comment 13 Younes Manton 2013-10-01 17:23:02 UTC
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.
Comment 14 ALexandre Maloteaux 2013-10-21 20:17:20 UTC
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)
Comment 15 Götz 2014-01-02 21:16:23 UTC
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.
Comment 16 andreap 2014-01-14 09:38:49 UTC
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
Comment 17 Oliver Frolovs 2014-01-14 11:13:10 UTC
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?
Comment 18 Alan 2014-01-14 12:29:51 UTC
Bugzilla is just tracking its existence - if you want it fixed then I would raise it with linux-bluetooth@vger.kernel.org
Comment 19 Oliver Frolovs 2014-01-14 12:40:00 UTC
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
Comment 20 Szymon Janc 2014-01-14 20:16:40 UTC
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
Comment 21 andreap 2014-01-15 16:28:49 UTC
I don't have these files in my kernel...Then the only solution is build a custom kernel? 

thanks
Andrea
Comment 22 Šarūnas 2014-01-15 17:11:21 UTC
> 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.
Comment 23 Götz 2014-04-23 22:47:06 UTC
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
Comment 24 Carlos 2014-12-04 18:42:33 UTC
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
Comment 25 Johan Hedberg 2014-12-12 09:30:23 UTC
(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.
Comment 26 Carlos 2014-12-31 13:16:40 UTC
Created attachment 162171 [details]
'hcidump -X' while executing 'hciconfig hci0 up' for carlosgarciaq
Comment 27 Carlos 2014-12-31 13:23:11 UTC
Created attachment 162181 [details]
contents of /sys/kernel/debug/usb/devices for carlosgarciaq
Comment 28 Carlos 2014-12-31 13:25:53 UTC
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
Comment 29 raestloz 2019-06-24 14:43:50 UTC
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)
Comment 30 raestloz 2019-06-24 17:12:30 UTC
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)
Comment 31 raestloz 2019-06-25 16:15:17 UTC
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
Comment 32 barfin 2019-08-01 01:56:09 UTC
(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 :(
Comment 33 Arthur Fragoso 2019-08-15 05:54:09 UTC
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.
Comment 34 Sergey Kondakov 2019-08-17 04:52:51 UTC
(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 ?
Comment 35 Arthur Fragoso 2019-08-17 22:42:04 UTC
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;
}
Comment 36 Sergey Kondakov 2019-08-18 01:45:25 UTC
(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.
Comment 37 Sergey Kondakov 2019-08-20 04:49:46 UTC
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.
Comment 38 Fernando Carvalho 2019-09-11 18:20:08 UTC
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.
Comment 39 Sergey Kondakov 2019-09-16 07:30:54 UTC
(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.
Comment 40 raestloz 2019-09-16 11:12:25 UTC
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?
Comment 41 Fernando Carvalho 2019-10-13 17:25:06 UTC
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.
Comment 42 GABE 2019-10-15 21:00:02 UTC
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
Comment 43 takacsk2004 2019-11-03 09:12:39 UTC
(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.