Bluetooth on latest Raspian version is just not working.

[Jw321123]

I'm new to Linux, btw, and on the latest version of Raspian.

My Raspberry Pi 3 can connect briefly to my Macbook Air 2013, but once I accept the connection on the Raspberry Pi, I get this error:

"GDBus.Error:org.bluez.Error.Failed: No such file or directory. Try to connect manually."

(The Raspberry Pi appears on my macbook, but the macbook which is discoverible does not appear on my raspberry pi)

I also tried connecting from the terminal, that didn't work either.

Here are the bluetooth-related packages I have, am I missing any or are they interfering with each other?
(p.s. this was done with a package search in Synaptic

-Bluez
-Bluez-firmware
-firmware-atheros
-firmware-reaktek
-libbluetooth3
-libcwiid1
-libmm-glib0
-modemmanager
-obex-data-server
-pi-bluetooth
-pulseaudio-module-bluetooth

Hopefully I do not have a faulty Raspberry Pi, i'm praying

[Jw321123]

BUMP:
I think I can justify this because well..... no one responded

[jbeale]

I don't know much about Bluetooth but what are you trying to do? According to the most recent blog post about bluetooth, it can connect to most any BT device, but it cannot do anything useful unless it is a HID model (like mouse or keyboard) or Audio device (headphones or speakers). What type of device is your Mac Air?

[Dis93]

I sorta agree with jbeale.. I can network with my Mac, my PC via standard networking... Bluetooth is slow and limited.. for connecting to phones, or connecting a kb or mouse, or maybe a BT speakers it's fine.. otherwise why bother?

[Jw321123]

My Macbook Air 2013 is 11-inch and 128GB. Of course, it also has bluetooth.

The BT Speaker that I am trying to connect to is the MIni Jambox from Jawbone. That works fine with other devices, too.

I'm trying to transfer and receive files to my Macbook Air, and I am trying to pump some jams to my Bluetooth speaker.

EDIT: I also tried connecting to a Microsoft Arc Mouse SE (a bluetooth mouse), it said it "Paired successfully, but this device has no services which can be used with the Raspberry Pi"

[Rive]

had this same kind of error after upgrade

"GDBus.Error:org.bluez.Error.Failed:..."

Resolved it by restoring 4.1 and then doing dist-upgrade again. Works fine now.

see: viewtopic.php?p=973744#p973744

Also, you should be aware there is a major performance bug in the new release that affects the uart (which is what the bluetooth uses). The Pi has computational degradation to the tune of approx 1 billion operations per second.
viewtopic.php?p=974088#p974088

[Dis93]

I bumped my kernel to 4.4.10, Rive.
I have to agree with OP, BT seems funky. I've left it scanning for 30 minutes, it did see my two phones, it can't now. It has picked up various devices my neighbours have, and my Mac but can't connect like OPs. Can't see my phones half a metre away ( that's about 1.6 foot away for those in the USA)

[Jw321123]

Again, i'm new to Linux so.... I don't get that at all. Can you explain in further detail? Sorry

[Rive]

Again, i'm new to Linux so.... I don't get that at all. Can you explain in further detail? Sorry

What specifically would you like elaboration on?

[spl23]

There's no point connecting to a MacBook Air with the latest Jessie release - as I said in the blog post, we support UI devices (mice, keyboards etc) and speakers and headsets. Your Mac is none of those, so while you can pair with it, you won't be able to establish a connection to it, as the Pi has no client services which can make use of anything the MacBook has to offer.

In future we might add the ability to share a network connection over Bluetooth, but it's quite a lot of work to enable that on the Pi, so we haven't had a chance to do it yet!

The Arc Mouse SE is a BTLE device, which is a newer version of the Bluetooth protocol, and software support for that is shaky, to say the least; the BlueZ stack treats BTLE devices completely differently from traditional BT devices. Until we get a better handle on BTLE, you're very unlikely to be able to use that mouse with your Pi. (Note that this isn't a Pi-specific problem - my Mac mini can't connect to BTLE devices either...)

[Douglas6]

@spl23, you could look into adding support for OBEX and Serial Port Profile. I believe blueman has limited file transfer support.

[spl23]

@spl23, you could look into adding support for OBEX and Serial Port Profile. I believe blueman has limited file transfer support.

It does, but file transfer is not that common on other devices; Apple devices tend not to allow it, for example, although Android tablets do. A huge chunk of code is required on the Pi to enable OBEX - I did look into doing it, but wondered if the demand was there to justify it, which is one of the reasons we launched with the current limited BT functionality. Once we get a handle on what other features are wanted (and by how many people...) we can work out where best to apply our limited amount of programming effort (i.e. me...) to add the bits people want.

[Rive]

A huge chunk of code is required on the Pi to enable OBEX - I did look into doing it, but wondered if the demand was there to justify it, which is one of the reasons we launched with the current limited BT functionality.

BT file transfer is ideal (for Windows and Android- which are the dominant OSes atm). It is a PITA to have to move around an sdcard, or flash drive between devices. I didn't realize the new bt ui is lacking in that regard. That sucks.

[gkreidl]

A huge chunk of code is required on the Pi to enable OBEX - I did look into doing it, but wondered if the demand was there to justify it, which is one of the reasons we launched with the current limited BT functionality.

BT file transfer is ideal (for Windows and Android- which are the dominant OSes atm). It is a PITA to have to move around an sdcard, or flash drive between devices. I didn't realize the new bt ui is lacking in that regard. That sucks.

You have WiFi and / or ethernet networking. Why do you want to use BT for it?

[Dis93]

You have WiFi and / or ethernet networking. Why do you want to use BT for it?

+1 This

[spl23]

I didn't realize the new bt ui is lacking in that regard. That sucks.

In that case, you are very welcome to try writing a C implementation of OBEX over Bluetooth with a GTK UI that we can integrate. My estimate is that it is a couple of thousand lines of code and probably a couple of weeks work, plus testing...

In all seriousness, in an ideal world, we would support anything and everything people want to do on Pi - in the real world, we are a very small software team, and we have to prioritise - if I spend a few weeks on OBEX over BT, that's a few weeks I don't spend on something else.

If people really want OBEX, then they can install blueman and use it from there for the time being - blueman should happily coexist with the inbuilt BT UI.

[Douglas6]

Bluetooth file transfer is not that difficult on the Pi, it just requires some command line finagling.

WiFi is easier.

[Dis93]

Bluetooth file transfer is not that difficult on the Pi, it just requires some command line finagling.

WiFi is easier.

Lots of internet points for the use of the word finagling.

Also , use wifi.

[Rive]

You have WiFi and / or ethernet networking. Why do you want to use BT for it?

Not all my devices are setup for LAN sharing (hardware and software firewalls), and not all my devices are even on the same network ( I have multiple physical and virtual interfaces (5 currently), some with ap isolation, on my wireless router...

Most of the mobile and Windows devices (5), are setup for BT connectivity & transfers though, which is way more convenient than configuring router interfaces, firewalls, and Windows sharing privileges.

[Rive]

- in the real world, we are a very small software team, and we have to prioritise - if I spend a few weeks on OBEX over BT, that's a few weeks I don't spend on something else.

Yeah, I kinda figured that since someone missed that glaring uart bug in the new raspbian image.

[spl23]

Yeah, I kinda figured that since you guys missed that glaring uart bug in the new image.

Actually, we didn't miss it - we just didn't discover it until a few days before the release, and made the decision that it wasn't worth delaying the release for. In reality, the number of people who will even notice it is tiny. It is already fixed in the latest kernel and firmware - the usual method for updating kernel will get the fix for anyone who desperately needs it. Which is hardly anyone.

[Rive]

Yeah, I kinda figured that since you guys missed that glaring uart bug in the new image.

Actually, we didn't miss it - we just didn't discover it until a few days before the release, and made the decision that it wasn't worth delaying the release for.

Yes you did.

I was the one who reported there was an issue ( that there was performance degradation to the tune of approx 1 billion operations per sec), and had I not, you would have 'missed' it.

nearly an order of magnitude more interrupts per second and context switches per second in 4.4.9 compared to 4.1...unused uart being left with an interrupt asserted but no interrupt handler to clear it...

[Dis93]

Yes you did.
I was the one who reported there was an issue ( that there was performance degradation to the tune of approx 1 billion operations per sec), and had I not, you would have 'missed' it.

Me-ow.
https://www.youtube.com/watch?v=7syJJrsmrts

[jamesh]

- in the real world, we are a very small software team, and we have to prioritise - if I spend a few weeks on OBEX over BT, that's a few weeks I don't spend on something else.

Yeah, I kinda figured that since someone missed that glaring uart bug in the new raspbian image.

So glaring in fact that thousands of people reported it...oh.....hold on.....

[Fanch]

Hello,

I had the same problem. The OS and software were updated, but not the firmware.

I has been solved after a "sudo rpi-update".