GNOME Bugzilla – Bug 617050
my USB bluetooth dongle gets detected, but I cannot activate it
Last modified: 2010-04-30 08:52:10 UTC
[This has originally been reported as Debian #579392.] Hi, I have an USB bluetooth dongle that gets detected as following by lsusb: Bus 006 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) As soon as I plug it into my computer, the gnome-bluetooth icon appears in the notification area (with a red [x] though) and dmesg reports the following: [ 52.744010] usb 6-2: new full speed USB device using uhci_hcd and address 2 [ 52.912055] usb 6-2: New USB device found, idVendor=0a12, idProduct=0001 [ 52.912058] usb 6-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 52.912140] usb 6-2: configuration #1 chosen from 1 choice [ 52.962674] Bluetooth: Generic Bluetooth USB driver ver 0.6 [ 52.964730] usbcore: registered new interface driver btusb Now when I open bluetooth-properties to actually activate the dongle the following messages are reported on my terminal: ** Message: adding killswitch idx 1 state 1 ** Message: killswitch 1 is 1 ** Message: killswitches state 1 [Now I click on the "Activate Bluetooth" button.] ** Message: RFKILL event: idx 1 type 2 op 2 soft 0 hard 0 ** Message: killswitch 1 is 1 ** Message: killswitches state 1 However, nothing really happens, i.e. the "Activate bluetooth" button is greyed out, the Bluetooth icon in the notification area still shows the red cross and the computer can neither be found by other bluetooth devices nor find some itself (e.g. via nautilus-sendto). It may be worth noting that I experienced this bug for a while already but was never able to reproduce which package actually broke it, as I only realized it after a series of huge dist-upgrades. I tried several combinations of linux-2.6, bluez and gnome-bluetooth packages, but never found a working solution again. While the gnome-bluetooth icon still claims my Bluetooth dongle is disabled, "hcitool scan" reports reasonable results, so it's most likely a bug in the gnome-bluetooth frontend and not in bluez itself. I have the following Debian packages installed: bluez 4.63-1 gnome-bluetooth 2.30.0-1 linux-image-2.6.32-4-686 2.6.32-11 udev 153-1 If there is any more information I can provide to help getting this fixed, please let me now! - Fabian
What's the output of "bluetooth-properties -d" before and after enabling the device?
1) Freshly rebootet computer, Bluetooth dongle unplugged: $ bluetooth-properties -d No known devices Is bluetoothd running, and a Bluetooth adapter enabled? 2) Bluetooth dongle plugged in, bluetooth icon with a red [x] appears in notification area: $ bluetooth-properties -d No known devices Is bluetoothd running, and a Bluetooth adapter enabled? Please note that both dmesg and lsusb do already report about the new device. 3) Click on the bluetooth icon, select "Properties", click on "Turn on Bluetooth" button: The "Turn on Bluetooth" button grays out, I can only close the window (or select either "Help" or "Receive Files"), the red [x] in the bluetooth icon persists. $ bluetooth-properties -d No known devices Is bluetoothd running, and a Bluetooth adapter enabled? To answer the question: Yes, bluetoothd is running: $ ps aux | grep bluetoothd root 1641 0.0 0.0 3972 1964 ? Ss 16:48 0:00 /usr/sbin/bluetoothd Furthermore, AFAICT I have all the necessary kernel modules loaded: $ lsmod | egrep 'b(t|lu)' btusb 7997 2 bluetooth 36327 9 rfcomm,btusb,sco,bnep,l2cap rfkill 10264 3 bluetooth usbcore 98302 5 btusb,usbhid,uhci_hcd,ehci_hcd
(In reply to comment #2) > 1) Freshly rebootet computer, Bluetooth dongle unplugged: > > $ bluetooth-properties -d > No known devices > Is bluetoothd running, and a Bluetooth adapter enabled? > > 2) Bluetooth dongle plugged in, bluetooth icon with a red [x] appears in > notification area: > > $ bluetooth-properties -d > No known devices > Is bluetoothd running, and a Bluetooth adapter enabled? > > Please note that both dmesg and lsusb do already report about the new device. Is bluetoothd running? What's the output of hciconfig at that point?
Yes, bluetoothd is running (see above). $ sudo hciconfig hci0: Type: BR/EDR Bus: USB BD Address: 00:09:DD:10:6A:8F ACL MTU: 192:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:1028 acl:0 sco:0 events:35 errors:0 TX bytes:145 acl:0 sco:0 commands:35 errors:0
More verbose output: $ sudo hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 00:09:DD:10:6A:8F ACL MTU: 192:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:681 acl:0 sco:0 events:22 errors:0 TX bytes:86 acl:0 sco:0 commands:22 errors:0 Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: Link mode: SLAVE ACCEPT Name: 'James-1711����' Class: 0x4a0000 Service Classes: Networking, Capturing, Telephony Device Class: Miscellaneous, HCI Version: 1.1 (0x1) Revision: 0x460 LMP Version: 1.1 (0x1) Subversion: 0x460 Manufacturer: Cambridge Silicon Radio (10)
'James-1711����' non-UTF-8 in your device name. bluetoothd shouldn't allow that. However you managed to get that broken name, undo it. "hciconfig hci0 name foobar" as root should do.
Done: $ sudo hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 00:09:DD:10:6A:8F ACL MTU: 192:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:1772 acl:0 sco:0 events:33 errors:0 TX bytes:367 acl:0 sco:0 commands:33 errors:0 Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: Link mode: SLAVE ACCEPT Name: 'foobar' Class: 0x4a0000 Service Classes: Networking, Capturing, Telephony Device Class: Miscellaneous, HCI Version: 1.1 (0x1) Revision: 0x460 LMP Version: 1.1 (0x1) Subversion: 0x460 Manufacturer: Cambridge Silicon Radio (10) The described faulty behaviour persisted unti I restarted the bluetooth daemon and now *it works*! However, if I unplug the dongle and plug it back in, the device name is reset to this non-UTF-8 string and the faulty behaviour is back. Is there anything I can do to make the name change persistant or convince either bluez or gnome-bluetooth to work even if the device name is crap?
(In reply to comment #7) > Done: > > $ sudo hciconfig -a > hci0: Type: BR/EDR Bus: USB > BD Address: 00:09:DD:10:6A:8F ACL MTU: 192:8 SCO MTU: 64:8 > UP RUNNING PSCAN > RX bytes:1772 acl:0 sco:0 events:33 errors:0 > TX bytes:367 acl:0 sco:0 commands:33 errors:0 > Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 > Link policy: > Link mode: SLAVE ACCEPT > Name: 'foobar' > Class: 0x4a0000 > Service Classes: Networking, Capturing, Telephony > Device Class: Miscellaneous, > HCI Version: 1.1 (0x1) Revision: 0x460 > LMP Version: 1.1 (0x1) Subversion: 0x460 > Manufacturer: Cambridge Silicon Radio (10) > > The described faulty behaviour persisted unti I restarted the bluetooth daemon > and now *it works*! Yeah, bluetoothd doesn't like it. > However, if I unplug the dongle and plug it back in, the device name is reset > to this non-UTF-8 string and the faulty behaviour is back. Is there anything I > can do to make the name change persistant or convince either bluez or > gnome-bluetooth to work even if the device name is crap? Not really, bluetooth won't pass the name of the device, along with the other properties, as it's not valid UTF-8. You'll need to change the name while bluetoothd is running, check under: /var/lib/bluetooth/******/config to see if it's getting updated.
(In reply to comment #8) > Not really, bluetooth won't pass the name of the device, along with the other > properties, as it's not valid UTF-8. I've found a similar bug report in the Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=450081 Do you think the patch you posted here will fix the issue: http://thread.gmane.org/gmane.linux.bluez.kernel/1687
(In reply to comment #9) > (In reply to comment #8) > > Not really, bluetooth won't pass the name of the device, along with the other > > properties, as it's not valid UTF-8. > > I've found a similar bug report in the Red Hat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=450081 > > Do you think the patch you posted here will fix the issue: > http://thread.gmane.org/gmane.linux.bluez.kernel/1687 No, that patch only fixes *remote* names. In the worst case, you'd end up seeing the Bluetooth address instead of the device name. More work on bluetoothd would be needed if we wanted to allow this kind of names.
(In reply to comment #10) > No, that patch only fixes *remote* names. In the worst case, you'd end up > seeing the Bluetooth address instead of the device name. More work on > bluetoothd would be needed if we wanted to allow this kind of names. Well, either bluetoothd gets improved to also handle non-UTF-8 device names or bluetoothd does g_utf8_validate as soon as it reads out the device names, converts faulty strings to UTF-8 and immediately writes them back to the device. I managed to write a patch that works like this for hciconfig, but not for the daemon...