057c:3800 BlueFRITZ! Bluetooth Stick broken since 2.6.something

Hi list,

as bugzilla.kernel.org seems to be down right now I thought about reporting directly to lkml but then I saw a bt-specific list and... here we are.

I have a Bluetooth USB-Stick that does not work anymore with more recent 2.6 and 3.x kernels. I have another stick which works ok on all kernels (at least with those I run / tested ;))

When plugged in, the USB-LED lights up permanently (no blinking), the bluetooth LED is off. It does not show up anywhere apart from hciconfig which reports it to be down and a hciconfig hci1 up times out after a few seconds.

adrastea:~# hcitool dev
Devices:
    hci0    11:11:11:11:11:11
adrastea:~# hciconfig
hci0:    Type: BR/EDR  Bus: USB
    BD Address: 11:11:11:11:11:11  ACL MTU: 678:8  SCO MTU: 48:10
    UP RUNNING PSCAN ISCAN
    RX bytes:1461 acl:0 sco:0 events:44 errors:0
    TX bytes:697 acl:0 sco:0 commands:44 errors:0

hci1: Type: BR/EDR Bus: USB

    BD Address: 00:04:0E:8C:E2:93  ACL MTU: 120:20  SCO MTU: 24:5
    DOWN
    RX bytes:1086 acl:0 sco:0 events:39 errors:0
    TX bytes:171 acl:0 sco:0 commands:39 errors:0

adrastea:~# hciconfig hci1 up
Can't init device hci1: Connection timed out (110)
adrastea:~#

I never bisected an issue, but if necessary I will try it out. But sure, I prefer that someone (Mr. Holtmann?) just has an heureka!-moment and knows the second he reads this report what went wrong in what patch / enhancement. :) And as said (to make it utterly clear) the device works with older kernels. Tested and approved with kernel 2.6.32 (on Debian squeeze) and ist not physically broken.

Greetings
Michael

P.S.: Here the lsusb -v output for that device (if the usb-id is not enough):

Bus 004 Device 003: ID 057c:3800 AVM GmbH BlueFRITZ! Bluetooth Stick Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10

  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x057c AVM GmbH
  idProduct          0x3800 BlueFRITZ! Bluetooth Stick
  bcdDevice           15.00
  iManufacturer           1 Bluetooth Device
  iProduct                2 Bluetooth Device
  iSerial                 3 93E28C0E0400
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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
Device Status: 0x0000
(Bus Powered)

Hi Michael,

I'm pretty sure we'll at least need to see the hcidump output for the initialization sequence of this adapter (i.e. start hcidump before calling hciconfig hci0 up) and show us the output. Which Bluetooth version does this adapter support and how old is it?

Johan

Am 18.11.2011 16:36, schrieb Johan Hedberg:

Hi Johann,

let me fire up a machine that runs 2.6.32 (Debian squeeze) and where it works... or is there a way to get the bt-version it supports with the "broken" kernel? And no idea how old it is... at least some years as I got it for free from a buddy some time ago. It is from a AVM BlueTooth-ISDN-set which was in a box in the cellar and never used by the original owner (that was years ago too). Anyway, here is the hcidump output as requested. Only the timespan since issueing hciconfig hci0 up and error message displayed in terminal:

adrastea:~# hcidump
HCI sniffer - Bluetooth packet analyzer ver 2.1
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0

    Reset (0x03|0x0003) ncmd 1
    status 0x00

< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0

    Read Local Supported Features (0x04|0x0003) ncmd 1
    status 0x00
    Features: 0xff 0xff 0x05 0x00 0x18 0x18 0x00 0x00

< HCI Command: Read Local Version Information (0x04|0x0001) plen 0

    Read Local Version Information (0x04|0x0001) ncmd 1
    status 0x00
    HCI Version: 1.2 (0x2) HCI Revision: 0x2006
    LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
    Manufacturer: AVM Berlin (31)

< HCI Command: Read Buffer Size (0x04|0x0005) plen 0

    Read Buffer Size (0x04|0x0005) ncmd 1
    status 0x00
    ACL MTU 120:20 SCO MTU 24:5

< HCI Command: Read BD ADDR (0x04|0x0009) plen 0

    Read BD ADDR (0x04|0x0009) ncmd 1
    status 0x00 bdaddr 00:04:0E:8C:E2:93

< HCI Command: Read Class of Device (0x03|0x0023) plen 0

    Read Class of Device (0x03|0x0023) ncmd 1
    status 0x00 class 0x000000

< HCI Command: Read Local Name (0x03|0x0014) plen 0

    Read Local Name (0x03|0x0014) ncmd 1
    status 0x00 name ''

< HCI Command: Read Voice Setting (0x03|0x0025) plen 0

    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

    Set Event Filter (0x03|0x0005) ncmd 1
    status 0x00
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
    timeout 32000

    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

    Delete Stored Link Key (0x03|0x0012) ncmd 1
    status 0x00 deleted 0
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
    Mask: 0xfffffbff07180000

    Set Event Mask (0x03|0x0001) ncmd 1
    status 0x00

< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0

Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command

greetings
Michael

Hi Michael,

Ok, so this is a 1.2 adapter.

This is the reason why you're getting a timeout. Since the adapter claims to support Bluetooth version 1.2 it should also support this HCI command, so from that perspective it's not conforming to the specification. Right now the kernel (lib/bluetooth/hci_event.c) is completely missing a command status handler for this command. If such a handler was in place instead of a timeout you would be getting an immediate error (the kernel maps this HCI status code to EBADRQC).

However, since this is also not acceptable behavior (as the adapter still wouldn't work for you) I suspect the need for some adapter-specific quirk is in place or then the kernel should just ignore any errors for HCI_Read_Local_Supported_Commands.

Johan

Am 18.11.2011 17:21, schrieb Johan Hedberg:

Thanks for the input. But do you know why the device works with older kernel / userland? As Debian stable may be old, but not THAT old ;) (bluetooth 1.2 was released somewhere around 2005 I think).

So, and what do we do from here on? Btw. I did mix up the two bt-sticks I have so the last info was from the wrong stick. Here is the right info but it looks almost the same (at least the version numbers...):

mschmitt@sogo:~$ /usr/sbin/hciconfig -a
hci0:    Type: BR/EDR  Bus: USB
    BD Address: 00:04:0E:8C:E2:93  ACL MTU: 120:20  SCO MTU: 24:5
    UP RUNNING PSCAN ISCAN
    RX bytes:695 acl:0 sco:0 events:23 errors:0
    TX bytes:97 acl:0 sco:0 commands:23 errors:0
    Features: 0xff 0xff 0x05 0x00 0x18 0x18 0x00 0x00
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy:
    Link mode: SLAVE ACCEPT
    Name: ''
    Class: 0x4a0000
    Service Classes: Networking, Capturing, Telephony
    Device Class: Miscellaneous,
    HCI Version: 1.2 (0x2)  Revision: 0x2006
    LMP Version: 1.2 (0x2)  Subversion: 0x1806
    Manufacturer: AVM Berlin (31)

greetings
Michael

HI Michael,

Probably because the list of supported commands wasn't previously requested as part of the adapter init sequence, or because the kernel code didn't actually wait for all commands to complete before notifying success to user space (I know the latter is at least true since I submitted a patch for it).

Well, the attached patch will at least make sure that the failure of this command is correctly detected so you get an immediate error instead of a timeout. The next step is to decide whether to do a quirk for your specific adapter or to make it a general rule that errors for this particular HCI command are ignored (for that we'd need feedback from the real kernel experts like Marcel and Gustavo).

Johan

From: Johan Hedberg <[email protected]>
Date: Fri, 18 Nov 2011 22:21:48 +0200
Subject: [PATCH] Bluetooth: Fix request completion for command status events

If a HCI command triggered by hci_request() fails at the command status phase we need to properly inform the request tracking code of the completion of the request.

---
 net/bluetooth/hci_event.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

index dfe6fbc..236f895 100644
@@ -2055,6 +2055,9 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
 
 	opcode = __le16_to_cpu(ev->opcode);
 
+	if (ev->status != 0)
+		hci_req_complete(hdev, opcode, ev->status);
+
 	switch (opcode) {
 	case HCI_OP_INQUIRY:
 		hci_cs_inquiry(hdev, ev->status);

1.7.7.2

Am 18.11.2011 21:30, schrieb Johan Hedberg:

So that means, if the bt-stack in the kernel would ignore the successful completion of those "what protocol version do you understand"-commands all bt-related stuff with the stick would work nevertheless?

But apparently none of them had the urge to actually respond in this ml-thread yet. :) Let's see, I try to poke them "mildly" in cc'ing them...

General speaking, the bt-stick in question is old (at least 5 years or so) and I have another (working) stick here, so there is no immediate adversity for me. But I guess as this stick is from major bt-accessoirs supplier from germany (AVM GmbH Berlin) this hardware may be around for many users for a fairly long time. But then again... it seems to be a hardware-bug...

Anyway, I guess it would ne nice to have it "fixed" someday. :)

Greetings
Michael

Just as a follow-up question (as I did not get a clear conclusion out of the discussion and it seems to me the "discussion" did stop without a real conclusion)...

What is the plan right now? Will there be a patch upstream (in the kernel) at some point? Is it not clear how to fix that (broken?) hardware driver-wise yet? Should I test something?

regards
Michael

Hi Michael,

Could you test Johan's patch:

http://permalink.gmane.org/gmane.linux.bluez.kernel/18752

[PATCH 2/2] Bluetooth: Ignore HCI_Read_Local_Commands failures

You can also apply the first patch.

Best regards
Andrei Emeltchenko

Hi Johan,

Apparently we check for "Bluetooth Core Specification 1.1"

Shall we change to:

index f0fbb02..ed55b33 100644
@@ -562,7 +562,7 @@ static void hci_setup(struct hci_dev *hdev)
 {
        hci_setup_event_mask(hdev);
 
-       if (hdev->lmp_ver > 1)
+       if (hdev->lmp_ver > 2)
                hci_send_cmd(hdev, HCI_OP_READ_LOCAL_COMMANDS, 0, NULL);
 
        if (hdev->features[6] & LMP_SIMPLE_PAIR) {

Reference:
https://www.bluetooth.org/Technical/AssignedNumbers/link_manager.htm

Best regards
Andrei Emeltchenko

Sorry, it is already checking for it.

Discard the code below.

Best regards
Andrei Emeltchenko

Hi Andrei,

Hi Marcel,

Can we define in bluetooth.h something like:

#define BLUETOOTH_LMP_VER_1.1 1
#define BLUETOOTH_LMP_VER_1.2 2

Maybe same define for HCI_VER ?

Best regards
Andrei Emeltchenko

Hi Andrei,

yes, but just leave LMP out of it. Just do BLUETOOTH_VER_1_1 or similar. Even the . in the define will not work out.

They are identical. So one is enough. They just have a different meaning. The LMP is air protocol version and HCI is host controller version. In most cases they are the same, but not have to be.

Regards

Marcel

Hi Marcel,

That doesn't help much with this particular dongle though since the LMP and HCI versions are the same. What I'd propose is the patch which I already attached to an earlier email in this thread and then either a quirk for this adapter or just generally ignoring the HCI_Read_Local_Commands failure status.

Johan

Hi Johan,

using lmp_ver instead of hci_ver is still a bug, but fair enough it is a different bug.

I am fine just allowing Read_Local_Commands to fail. However that will serious limit some features since we have to be using the result more often in the future. But luckily that does not matter for 1.2 controller at all.

Regards

Marcel

Hi Marcel,

Ok. I just sent two patches for this. I have a hunch these might also fix the recently reported "resume takes longer due to increased timeout" regression report.

Johan

Am 18.11.2011 16:36, schrieb Johan Hedberg:

I am not sure if this is the right version you were talking about, but here it is (from the squeeze box):

mschmitt@sogo:~$ /usr/sbin/hciconfig -a
hci0:    Type: BR/EDR  Bus: USB
    BD Address: 11:11:11:11:11:11  ACL MTU: 678:8  SCO MTU: 48:10
    UP RUNNING PSCAN
    RX bytes:969 acl:0 sco:0 events:27 errors:0
    TX bytes:361 acl:0 sco:0 commands:27 errors:0
    Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH HOLD SNIFF PARK
    Link mode: SLAVE ACCEPT
    Name: 'sogo-0'
    Class: 0x4a0100
    Service Classes: Networking, Capturing, Telephony
    Device Class: Computer, Uncategorized
    HCI Version: 1.2 (0x2)  Revision: 0x1fe
    LMP Version: 1.2 (0x2)  Subversion: 0x1fe
    Manufacturer: Integrated System Solution Corp. (57)

greetings
Michael