How Ubuntu’s broken bluetooth support came to be

Bluetooth supported? Pairing up your Bluetooth device was relatively well documented, by the community anyway. It was mostly done using the bluez package from bluez.com. Ubuntu town and in fact all of Linux land was generally at peace and the trendy folk at the BlueTooth Bar were being all trendy-like.

Then it happened. Ubuntu went up one release: Jaunty came to be and subsequently Bluetooth support died. Even now the Internet is teeming with Bluetooth bug reports, problems and forums are filled with questions such as ‘my keyboard is not being paired’. In fact, Debian seemed to be hit as well as some other distributions that leveled up.

What had happened?

Bluez changed is what happened

The developers of bluez, once the nice Bluetooth package everyone could live with, decided it was time for a major overhaul: they merged the packages bluez-libs and bluez-utils and then some. And with ‘and then some’ meaning completely changing the way Bluetooth devices are configured and thereby breaking backwards compatibility.

All of this shouldn’t really matter, except for one little detail: The Ubuntu dev team thought it was a good idea to drop the old Bluetooth support and go for the new version. They included bluez 4.0 and everybody broke in tears. That’s all there is to this little story, Bluetooth has been neglected since 2008 when Jaunty came about and things have not improved.

Why is that?

Bluez is a bunch of cowboy coders is why

Actually, I know nothing of the team except that it seemingly has about one active developer. Bluez arguably is an awesome team: they have these coders, stomping away on probably wireless keyboards to create utterly thorough Bluetooth support for Linux. They’re awesome right? Perhaps not.

Bluez doesn’t document anything. At all. It’s a widely acknowledged fact (Gentoo too?) that they didn’t document the legacy Bluetooth support and they didn’t document the new support. If you read the bluez 4.0 release notes you still don’t know anything and you won’t either. Nobody will, because there is no documentation! Oh, they’ll completely overhaul Bluetooth support but they’ll never tell how it works now. That’s for you to find out. I’ve even glanced over the source code only to find out that they don’t like to comment their code either.

Definition of a Cowboy Coder
Although normally I couldn’t care less about some random piece of software, but if you include a significant framework in your operating system, there has got to be some kind of set of standards that includes documentation, right?

That’s why everyone is still dealing with the same problems it did in 2008: the old community documentation is still there, but it isn’t getting updated. That page is just one of hundreds ofcourse. Here’s the typical research process one goes through figuring out how to get Bluetooth working (notice how he’s constantly confronted with conflicting guides and ultimately didn’t find a solution). The problem again is that nobody can update those pages. If you are feeling particularly masochistic, try reading this thread (especially the last post where it says ‘SOLVED’).

Let’s discuss what must be one of the most encountered problem: ‘hcid.conf is missing!’. Old documentation will tell you how to configure your Bluetooth device in Ubuntu so that it connects when your pc boots. That is to say, how you need to edit a /etc/bluetooth/hcid.conf configuration file. Well, that file was removed by the bluez team in bluez 4.0. Reread the bluez 4.0 release notes:

With this new major version a lot of things have been changed:
– The main daemon is now called bluetoothd (instead of hcid)
– The main configuration file is /etc/bluetooth/main.conf and follows INI-style syntax

And indeed, scanning the source files reveal that the hcid.conf is no longer used, but other configuration files instead. It appears to me that hcid.conf has become main.conf, except that scanning the code doesn’t confirm this. Instead, main.conf and input.conf are only used to read the options already provided. Changing the names of configuration files ofcourse isn’t the only thing that changed, since just using main.conf or whatever doesn’t seem to magically do the trick. I still can’t figure out how to enumerate devices in the new configuration files, it’s not like you can just say, ‘Well, instead of hcid.conf just use blah.conf’. I did get a long way configuring my keyboard in rfcomm.conf, but since my keyboard doesn’t seem to support SMP (Session Multiplex Protocol, I got errors reporting this to me), I assume it is used mainly for pairing phones.

Even now, everyone still uses the deprecated but still supported hidd, primitive but effective bluetooth adapter tool. You can install it using the command sudo apt-get install bluez-compat and then use it the way I used it to connect my keyboard. You just can’t use it to reconnect devices with, from reboot, wake up, or the device coming out of suspension. The hcid.conf was used for this, but now it is dead.

About hidd being deprecated anyway

If hidd has become deprecated, I wonder what replaced it. Searching the internet revealed nothing. Until I found this deeply hidden gem. In this Debian bug report, this guy ‘Phil’ mentions how a guy on the bluez mailing list mentioned that a wiki mentioned something about hidd being replaced with a more generic so called ‘”input service” over dbus‘ approach? Woh, have I just found a vague piece of information about how things changed? Let’s see this Wiki! Oh wait! IT DOESN’T EXIST! Sigh.

I had set up my bluetooth keyboard based on the instructions in /usr/share/doc/bluez-utils/README.Debian, i.e. starting hidd –server by enabling it in /etc/default/bluetooth, running hcitool scan, and then hidd –conect . This method is now deprecated; instead we should use something called the “input service” over dbus. See the following page, which contains examples of dbus-send commands to do this: http://wiki.bluez.org/wiki/HOWTO/InputDevices

Ofcourse I just *had* to know what was on that Wiki, so I turned to the ever so awesome Wayback Machine. Here’s what I found. Read it yourself. Hint: you won’t get anywhere, but here’s what I get from it. It seems the new approach is a more generic ultra obfuscated command that accepts an instruction class or identifier such as ‘org.bluez.input.Manager.RemoveDevice’. No manual and certainly nothing about configuring your connections for auto-connect during boot.

I don’t know why they took down the wiki, but from the looks of it, most of it was about the API anyway, useful for developers, not end-users using the command-line.

Also, there’s an interesting discussion on bluez 4.0 in Arch Linux I found, the first one I’ve encountered where the participants actually try to get the new ‘dbus’ way working. Nothing we can use in Ubuntu though. I’ve tried to get bluez talking to me using dbus, but I couldn’t get it to do anything but spout a range of errors.

Finally, a guide I found on using Bluetooth with bluez 3 and 4 not related to a particular Linux distribution. Unfortunately, the dbus keeps barfing up on everything I throw at it, so no dice for Ubuntu I guess.

Current state of Ubuntu’s Bluetooth support

Technically the title of this blog post is wrong: Ubuntu’s Bluetooth support is probably better now than it ever was, it’s just that nobody knows how to use it. To be fair, it’s not an entirely lost cause; people still get their devices to work properly after many people have tried to fix some variation of a given problem and people figured out how to connect a mouse or a phone using the new Bluetooth support for example, often with obscure workarounds. But a lot of people, including me, still can’t get a Bluetooth keyboard to connect and pair during boot.

Also there is a solution if you happen to use some desktop, using the Bluetooth Applet. It handles everything for you and reportedly it generally works. It’s no use to me however as I’m only running a server, but I might check out the applet’s source code to see how it works, hopefully using bluez’ command line API.

As of yet, there has been no answer from the dev team on the number one search result for ‘missing hcid.conf’ bug report: Bug 365779. Technically it’s not a bug, but the fact that it hasn’t been closed, deferred to another bug or had a dev on it since May 2009 indicates it either has no priority or nobody had the courage to fix it. Notice though there are literally hundreds of bluez related bug reports for numrous distro’s.

Also a search on the original writers of the last hcid.conf man page didn’t reveal a comment on how things changed and how things now work.

So what needs to be done to get some clarity on the matter? If you know, please shout out, because yes, I’m currently still looking to fix my keyboard under Ubuntu 10.04.

Meanwhile, try downgrading the bluez package to its previous version (note: I couldn’t get the bluetooth package to work with the older bluez packages in Ubuntu 10.04, good luck and have fun).

trackback

This entry was posted in Linux and tagged , , , , , , . Bookmark the permalink.

19 Responses to How Ubuntu’s broken bluetooth support came to be

  1. I absolutely agree with all above. The story started when I tried new blue-channel functionality with Asterisk (Linux based). Only thing that I needed was working bluetooth dongle. Too much to ask? Yes, it was.

    First of all, Google is your friend and off I went to only find out that person behind bluez (I think his name was/is Marcel Holtman) did shut down user forum, stating that “it was more pain then use” ?????????? Very strange behavior for man whose name was on Linux kernel maintainer’s list. Each and any question to the developer’s forum (unless it’s something deep into the code) was just ignored, no user guide, no nothing. Impression was that development team (whoever it was) were entertaining them self with some bogus problems. Strangely enough each and every report regarding not working device had response like “oh, yeah, we know that this particular vendor X doesn’t obey bluetooth standard and as such we need new patch to set it as exceptional case”. Out of curiosity I did take a look at the exceptions specification and my hair went up – each and every device on a list worked perfectly fine with my kid’s PC with Windows XP that I didn’t even bother upgrade since SP2 era. So, I said to myself, Microsoft folks were visionaries and figured out all the exceptions prior devices did hit the shelf? Or they just did implement the standard? I asked this question in developers forum, and was replied immediately by Mr. Holtman that if next time I’ll put my “irrelevant” questions as high priority he will ban me from posting. Nice, heh? My question was left without an answer. I actiually know quite a few people who were driven away from using Linux ONLY because of bluetooth issues. SHAME!!!!! Being myself a contributor to Linux development (at work and for fun) I would say that activities like that has to be dealt with accordingly by main kernel maintainers.

    To me, after all this bluez experience, I will never use it again (as far as I remember I found inexpensive commercial solution which my customer is using up to date with no issues and no exceptions). The only question in my mind is how it happen that Linux community did allow this bunch of cowboys to drive the show for that long and affect so many people?

  2. Bitt Faulk says:

    This really is a nightmare. I was finally able to get my keyboard/mouse (single device) connected in the Bluez4 method. Here are the steps I used:

    hcitool scan

    This just provides the MAC address of the keyboard. If you already know it, then you can skip it.

    sudo simple-agent hci0 xx:xx:xx:xx:xx:xx

    This pairs the keyboard. (Replace “xx:xx:xx:xx:xx:xx” with your device’s MAC address, obviously.) You will be asked for a PIN code. This is the PIN you want the keyboard to send to authenticate, which is the same as the random PIN that a more automated system would provide for you. After you enter the PIN on the Ubuntu machine, enter the PIN on the keyboard and press enter. Once that’s done, simple-agent should take a few seconds and respond “Release” and then “New device (/org/bluez/nnnnn/hci0/dev_xx_xx_xx_xx_xx_xx)”. If the device is already paired with your system, you’ll get a message “Creating device failed: org.bluez.Error.AlreadyExists: Bonding already exists”. If you need to re-pair for whatever reason, just provide simple-agent a third argument, anything at all, like “sudo simple-agent hci0 xx:xx:xx:xx:xx:xx repair”, and it will first delete its pairing before starting over. Under Ubuntu 10.04, simple-agent exists at /usr/share/doc/bluez/examples/simple-agent.

    sudo dbus-send –system –dest=org.bluez –print-reply /org/bluez/nnnnn/hci0/dev_xx_xx_xx_xx_xx_xx org.bluez.Input.Connect

    This actually connects the device. For me, it responded “method return sender=:1.273 -> dest=:1.309 reply_serial=2″ when it worked properly. It responded “Error org.bluez.Error.ConnectionAttemptFailed: Host is down (112)” when it didn’t. I think I may have needed to power-cycle or enable pairing mode for this to work after the connection timed out, but this might be a quirk of my keyboard.

    I get the impression that the intended method is to use a daemon process to rebind known devices when they start talking. It seems like an amalgamation of monitor-bluetooth and list-devices plus some code to actually send the dbus connect message could do that. Why it doesn’t already exist I don’t know.

    The pairing survives reboot, but the connection doesn’t, and the device path will probably change, specifically the “nnnnn” part, which means that you can’t just hard-code some values in an init.d script.

  3. Steve Murphy says:

    I’m trying to pair a mouse (Targus AMB04US) via an ASUS class-1 dongle. And no luck,
    which is somewhat not surprising, I guess, on a 10.10 Kubuntu. The “Add device” of the GUI
    triggers this conversation (via hcidump):

    2010-10-07 21:42:55.227158 HCI Event: Command Status (0x0f) plen 4
    Create Connection (0×01|0×0005) status 0×00 ncmd 1
    2010-10-07 21:42:55.899268 > HCI Event: Connect Complete (0×03) plen 11
    status 0×00 handle 12 bdaddr 00:12:A1:66:00:01 type ACL encrypt 0×00
    2010-10-07 21:42:55.899306 HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0×01|0x001b) status 0×00 ncmd 1
    2010-10-07 21:42:55.903266 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0×00 handle 12
    Features: 0xbc 0×02 0×04 0×38 0×08 0×00 0×00 0×00
    2010-10-07 21:42:55.976856 HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0×01|0×0019) status 0×00 ncmd 1
    2010-10-07 21:42:55.979299 HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0×01|0×0011) status 0×00 ncmd 1
    2010-10-07 21:42:55.983261 > HCI Event: Link Key Request (0×17) plen 6
    bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:55.983729 HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Negative Reply (0×01|0x000c) ncmd 1
    status 0×00 bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:55.988265 > HCI Event: PIN Code Request (0×16) plen 6
    bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:56.043261 > HCI Event: Remote Name Req Complete (0×07) plen 255
    status 0×00 bdaddr 00:12:A1:66:00:01 name ‘Targus Optical BT Laptop Mouse’
    2010-10-07 21:42:56.091224 HCI Event: Command Complete (0x0e) plen 10
    PIN Code Request Reply (0×01|0x000d) ncmd 1
    status 0×00 bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:56.204260 > HCI Event: Auth Complete (0×06) plen 3
    status 0×05 handle 12
    Error: Authentication Failure
    2010-10-07 21:42:56.400248 > HCI Event: Disconn Complete (0×05) plen 4
    status 0×00 handle 12 reason 0×05
    Reason: Authentication Failure

    Which is also reflected in the above command:

    [276]/etc/bluetooth Yes, Master? sudo /usr/share/doc/bluez/examples/simple-agent hci0 00:12:A1:66:00:01
    RequestPinCode (/org/bluez/20566/hci0/dev_00_12_A1_66_00_01)
    Enter PIN Code: 0000
    Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed

    Somehow, my mouse is not playing the protocol as the bluez stuff expects, and it’s ending in failure.
    I see the “Link Key Request Negative Reply” message, I can imagine that it has something to do with
    the Authentication Failure.

    I wrote a blog entry of my own a while back on pairing a cell phone to the chan_mobile module of Asterisk, after
    fighting with it for days, and finding almost every shred of advice was obsolesced by newer versions of bluez.

    For all I know, the bluetooth protocol is unavailable to the average home-developer, costing perhaps hundreds
    of dollars to obtain a copy of the spec.

    murf

  4. Pingback: Apple Magic Trackpad for Ubuntu Linux 10.10 Maverick « Nick Moore

  5. rh says:

    Yea, I have to admit I was very surprised when it took me nearly four hours to connect my bluetooth keyboard *when my adapter worked out of the box*. Even now I have to re-pair it every time on boot, but I’m scared to change anything lest I have to waste another day trying to connect it again!

    Oh, and this is not from a linux amateur, lest you think that I just don’t know what I am doing…

  6. Pingback: Ubuntu and Bluetooth | Ross Home

  7. Marx says:

    I’ve succesfully installed Motorola HT820 headset in A2DP mode on Linux Debian Squeeze.
    1) install blueman pulseaudio plugin
    2) modprobe uinput (will add it to /etc/modules)
    https://bugs.launchpad.net/blueman/+bug/350479
    3) fix python script
    http://blueman-project.org/forum/viewtopic.php?f=6&t=317
    4) discover headset and switch on A2DP mode via blueman-plugin
    5) launch pavucontrol and switch to headset
    6) it works!

  8. tony says:

    The fact that development shams like BlueZ become anything approaching official undermines Linux’s credibility. I can’t believe that the modules associated with BlueZ aren’t blacklisted. Is it really that hard to develop a Bluetooth stack? And is it really that hard to document it? I eagerly await the development of an alternative.

  9. JW says:

    I created a dirty, dirty hack that allows my bluetooth keyboard to connect upon boot.

    I created the following script:

    #!/bin/bash

    while true; do let a=`hcitool con |grep -c1 00:07:61:74:C0:2D`; echo “This is $a”; if [ $a -lt 1 ]; then echo “not connected”; hidd –connect 00:07:61:74:C0:2D; else echo “connected”; break; fi; sleep 2; done

    where 00:07:61:74:C0:2D is the ID of my keyboard (you can find that by using hcitool scan while the kb is in pairing mode).

    as bluepair.sh, and then entered bluepair.sh into the /etc/init.d/local file. I still have to push the “pair” button on my keyboard, but I can do this anytime after boot as the loop keeps attempting to connect until it succeeds. Hopefully this will help others who are as frustrated as I.

  10. Pingback: Setup Apple Wireless Keyboard via Bluetooth on Fedora 17 - VirtuallyHyper

  11. Johan says:

    Very good description!
    I run Debian squeeze and couldn’t get a bluetooth mouse to connect at boot with hidd –connect. I had to press mouse-connect button al the time. In Lenny that worked alright, even with the keyboard.
    I found simple-agent in /usr/share/doc/bluez/examples !?
    When I use that python-script at boot (rc.local) it connect.
    Before that I used blueman (better than bluetooth-applet) to set up all files in /var/lib/bluetooth/00:xx:xx…/
    The file trusts must have: 00:xx:… [all]
    I didn’t need hidd or any other change in bluetooth-files
    The cowboys didn’t bother to tell anyone about all this. Strange that Debian team doesn’t have do anything. This kind of problem is the main cause that Linux isn’t the most installed OS.
    Long live Linux!

  12. Pingback: play audio through bluetooth speakers in 12.04 using CLI | Ubuntu Info - James n Sheri.comUbuntu Info – James n Sheri.com

  13. Pavel Bludov says:

    I’ve succeeded to pair my bluetooth keyboard with bluez-5.5 package from debian-experimental. Sometime it will get to an Ubuntu release.

  14. Pingback: Bluetooth Serial Communication with HC-05 | MyRaspberryAndMe

  15. uclanoc says:

    bluez-test-device create xx:xx:xx:xx:xx:xx
    bluez-test-input connect xx:xx:xx:xx:xx:xx
    bluez-test-device trusted xx:xx:xx:xx:xx:xx yes

  16. Vinod says:

    Hi,
    I am trying to upgrade the bluez libraries from 4.96 to 4.101 on iMX board. (4.96 is the latest from Synaptic).
    I have cross compiled the Bluez stack and while replacing the libraries, I have missed dbus interfaces corresponding to ‘Handsfree’ and ‘A2DP’.
    Can anyone, help me how to replace and upgrade Bluez stack libraries.

    Thanks & Regards,
    Vinod.

  17. Vladimir Kunschikov says:

    Today I’ve upgraded bluez on my gentoo box and it stopped to work. It was configured earlier relatively simple, by usage of the forementioned scripts. To my surprize, there is no more any bluez-test-input utilities. Anyway, old setup (I have m555b bluetooth mouse) started to work after execution of the ‘power on’ cmd in the bluetoothctl shell.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>