How Ubuntu’s broken bluetooth support came to be


Bluetooth supported? Checking in on 2016: yep, still the same.

Pairing up your Bluetooth device was relatively well documented, by the community anyway. It was mostly done using the bluez package from 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.

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?
Definition of a Cowboy Coder

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:

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 (2009): 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 it expired after 6 years of neglection 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).

  • Alexander Zakharov

    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?


  • Bitt Faulk

    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.


  • Steve Murphy

    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 (0x01|0x0005) status 0x00 ncmd 1
    2010-10-07 21:42:55.899268 > HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 12 bdaddr 00:12:A1:66:00:01 type ACL encrypt 0x00
    2010-10-07 21:42:55.899306 HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
    2010-10-07 21:42:55.903266 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 12
    Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
    2010-10-07 21:42:55.976856 HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
    2010-10-07 21:42:55.979299 HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
    2010-10-07 21:42:55.983261 > HCI Event: Link Key Request (0x17) 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 (0x01|0x000c) ncmd 1
    status 0x00 bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:55.988265 > HCI Event: PIN Code Request (0x16) plen 6
    bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:56.043261 > HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 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 (0x01|0x000d) ncmd 1
    status 0x00 bdaddr 00:12:A1:66:00:01
    2010-10-07 21:42:56.204260 > HCI Event: Auth Complete (0x06) plen 3
    status 0x05 handle 12
    Error: Authentication Failure
    2010-10-07 21:42:56.400248 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 12 reason 0x05
    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.



  • rh

    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…


  • Marx

    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)
    3) fix python script
    4) discover headset and switch on A2DP mode via blueman-plugin
    5) launch pavucontrol and switch to headset
    6) it works!


  • tony

    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.


  • JW

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

    I created the following script:


    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, and then entered 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.


  • Johan

    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!


  • Pavel Bludov

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


  • uclanoc

    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


  • Vinod

    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,


  • Vladimir Kunschikov

    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.


  • Will

    Based on my experiences the past couple of days I agree entirely. I’ve given up on Bluetooth under Ubuntu at this point.


  • Ben in Seattle

    Argh. Four years after this blog post, bluetooth is still borken.

    Debian’s latest release, Jessie, is about to be released and it no longer has the bluez3 compat package. Meaning, I can’t keep using hidd and ignoring the new “innovations” from the bluez team. They keep adding things that are supposed to make everything just work magically (“just like Microsoft Windows!”) but often break utterly with no work around (also, “just like Microsoft Windows!”)

    Who are these cowboy coders who do a good enough job that people don’t make another solution, but then keep breaking things? I remember hearing a rumor that Microsoft was paying “moles” to join the GNU/Linux community in order to create dissent and provide subpar software. I doubt that’s the case, but it makes you wonder.


  • Ben in Seattle

    Okay, now that hidd is gone AND bluez-test-* and friends are gone (as mentioned above), I’ve found another way that seems to work. For now, anyway…

    $ bluetoothctl
    [NEW] Controller 00:1A:7D:DA:71:13 clunker-0 [default]
    [NEW] Device 00:07:61:61:F5:D3 Dell BT Keyboard
    [NEW] Device 00:1F:5B:B0:82:D9 TammyLeung’s mouse
    [bluetooth]# help
    Available commands:
    list List available controllers
    show [ctrl] Controller information
    select <ctrl> Select default controller
    devices List available devices
    paired-devices List paired devices
    power <on/off> Set controller power
    pairable <on/off> Set controller pairable mode
    discoverable <on/off> Set controller discoverable mode
    agent <on/off/capability> Enable/disable agent with given capability
    default-agent Set agent as the default one
    scan <on/off> Scan for devices
    info <dev> Device information
    pair <dev> Pair with device
    trust <dev> Trust device
    untrust <dev> Untrust device
    block <dev> Block device
    unblock <dev> Unblock device
    remove <dev> Remove device
    connect <dev> Connect device
    disconnect <dev> Disconnect device
    version Display version
    quit Quit program
    bluetooth]# scan on
    Discovery started
    [CHG] Controller 00:1A:7D:DA:71:13 Discovering: yes
    {... after about 15 seconds ...}
    [NEW] Device 00:50:F2:E8:27:6B Microsoft Keyboard
    [bluetooth]# agent on
    Agent registered
    [bluetooth]# pair 00:50:F2:E8:27:6B
    {Note that tab completion does work in the HCI address above, yay!}
    Attempting to pair with 00:50:F2:E8:27:6B
    [CHG] Device 00:50:F2:E8:27:6B Connected: yes
    [agent] PIN code: 045200
    [CHG] Device 00:50:F2:E8:27:6B Modalias: usb:v045Ep0099d0010
    [CHG] Device 00:50:F2:E8:27:6B UUIDs:
    [CHG] Device 00:50:F2:E8:27:6B Paired: yes
    Pairing successful
    [CHG] Device 00:50:F2:E8:27:6B Connected: no
    [CHG] Device 00:50:F2:E8:27:6B RSSI: -84
    [bluetooth]# paired-devices
    Device 00:1F:5B:B0:82:D9 TammyLeung’s mouse
    Device 00:50:F2:E8:27:6B Microsoft Keyboard
    [bluetooth]# connect 00:50:F2:E8:27:6B
    Attempting to connect to 00:50:F2:E8:27:6B
    [CHG] Device 00:50:F2:E8:27:6B Connected: yes
    Connection successful
    [bluetooth]# quit
    Agent unregistered


  • jmalmari

    So from bluez4 to bluez5 there’s yet another new way for handling bt devices: bluetoothctl.

    I wonder how much confusion this will create again. It seems that bluez-simple-agent, bluez-test-device, bluez-test-input (and friends) were just temporary utilities that we had to learn without documentation just for them to be deprecated again in the next major release. Although I do realize that tools that have “-test-” in their names may not have very long lifetime. But still they were (and are) the official way of handling bluetooth devices for ubuntu at least, as described in /usr/share/doc/bluez/README.Debian.


    • jmalmari

      I shouldn’t actually say “without documentation” as whoever packaged bluez for Debian provided that little text file that helped to bring some clarity.


  • thor

    Bluetooth on 14.4 is plain out not working. If you have to code like a fiend to get it to work it means the software is an epic fail.

    Ubuntu may as well not include Bluetooth and give up thinking Linux is ready for commercial use. Too bad such a think has happened to what looked like a good idea.
    I would not disparage real cowboys by calling these developers “cowboys”


  • Yves

    BT is a huge mess on Ubuntu 14.04.

    After an upgrade, what was working out of the box suddenly fails to pair, to connect, to work. We’re not talking about out of the ordinary devices… the things are a keyboard and a mouse!

    “Cowboy coder” is way too much of a kind word.


  • Rauly’s really a pain in the ass pairing a bluetooth device into Ubuntu 14.04.
    I have a Magic Mouse here in my work where I were able to pair on Windows 8.1 (I’m waiting my mac pro).
    But coding with windows is a pain in the ass too (nginx + php + mysql).
    I installed Ubuntu. No way to pair.

    After looking all over the internet, everybody was able to pair via GUI and I started to think: What am I doing wrong?

    Than I searched for command line.
    First I used to command:
    $ hcitool dev
    To discover my adapter:
    hci0 60:57:18:F2:4A:3F”

    Than the scan:
    $ hcitool scan
    Scanning …
    B8:17:C2:9C:7C:F4 Araujo’s mouse

    $ sudo bluez-simple-agent hci0 B8:17:C2:9C:7C:F4

    Then will ask for the Pin (here is “0000” magic mouse pin). Enter your Pin and hit Enter.

    $ sudo bluez-test-device trusted B8:17:C2:9C:7C:F4 yes

    $ sudo bluez-test-input connect B8:17:C2:9C:7C:F4
    Here an error outputed to me:
    “org.bluez.Error.Failed: Device or resource busy (16)’

    I just reboted the device and tryed again until is paired and connected.

    Now I’m happy =)


  • Gabriel Sharp

    almost 6 years later (~2016)

    and I still see the total lack of documentation, source comments, and ‘dotted’ support for bluetooth devices, where it should be solid by now, right? I can’t imagine what could be more important than backward compatibility, and revamping any major framework is a big no no…. unless you love to torture your users. Big lesson learned, if it aint broke, dont fix it. But, now that it IS broke, will they ever fix it? Are we just doomed to one shotty release after another of bluez? im sorry but my devices are supposed to do more than just show a nice string of text in the bluetoothctl program when they are discovered… rarely do they seem to connect:yes and stay that way. Usually a connected:no is not far behind if there ever is a yes. The GUI that they have imposed on us restricts us basically to the same thing only worse. I cant imagine wanting to use the GUI when i can use the CLI. In fact, i never even got a good scan for some devices untill using the CLI. dont get me wrong SOME devices work, but they should ALL work. I mean, my cell phone can do it, and it crappy old 25$ POS from the dollar store, come on bluez, really? is that the best you can do??


  • El Dato

    Uhhh…. Bluetooth by itself is already a security problem (

    “Quality-AWOL bluetooth implementation” pairs quite well with “p0wned at Starbucks from across the table”. Or am I mistaken?


Leave a Reply