Comment 293 for bug 268502

Revision history for this message
SrinivasaMoorthy (rsmoorthy) wrote :

I have tested this on Karmic, Lucid and Maverick and continued to find this problem (timeout). After some googling and debugging, I found this bug #453885 specifying in detail and also the workaround from that bug.

First, here's the workaround for those (like me) who want to get bluetooth working in Karmic / Lucid / Maverick: (I have tried this only on Karmic)

1. Downgrade your bluez package to the jaunty's version. (apt-get remove bluez, dpkg -i <jaunty's 4.32-0ubuntu4 deb file>)
2. You may want to install blueman, since gnome-bluetooth has other package dependencies)

I have got it finally working consistently and without any issues, after this!!!

My Device details:

Bus 002 Device 015: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Based on my debugging and the info from bug #453885, I noticed the following:

a. After the device initializes, /usr/sbin/bluetoothd is issuing the command to the device "Read Default Link Policy Settings" and there is no response from the device. This may happen because the device does not support and is a HCI Version 1.1 and/or bluez cannot handle such devices (and ignores the error that encountered by the prev "Write Default Link Policy Settings").

b. Even though there is no response to this command, there is no syslog error indicating a timeout.

c. Most usually at this time, the hci0 interface would say "UP RUNNING" without any "PSCAN". The moment you issue any action (hciconfig hci0 pscan or hcitool scan), the kernel issues a timeout syslog error -- to the previous "Read Default Link Policy Settings" command.

d. After this, it goes haywire and nothing works. It has worked very few times though for me (scanning or browsing files) -- I am not entirely sure how -- but it stops working after sometime, and I suspect it would have hit the above scenario. However, during the entire period I was testing with hcidump on, it never worked and I can't say how the scanning was successful a time or two.

e. bluez 4.32 did not issue the "Read Default Link Policy Settings" command, so this issue never comes up.

f. To me the issue can be resolved by fixing bluez that should not issue "Read Default Link Policy Settings" command, for devices that does not support it (I am not very sure, but this may be due to HCI ver 1.1 on the device, which you can look at by hciconfig -a) and/or properly handle errors if the HCI command was not responded.