You are not logged in.
Judging by the number of entries in Linux support forums, and the number of views these get, there is a lot of interest in making bluetooth, and especially audio over bluetooth, work. There is also a lot of frustration because things that used to work do not work any more.
I have found several reasons for this:
The Linux bluetooth stack, called 'bluez', changed about a year ago. Bluez version 5 introduced some new APIs and methods. Not everything supports these new APIs yet.
The process for pairing bluetooth devices is time-senstive and this is not always clearly spelled out in the documentation. If something works one time and not the next, it is probably because you changed the sequence without being aware of it. This can lead to following a lot of blind alleys and red herrings trying to get it to work again when all you really needed to do was power everything off and start over.
Searching for help with Google will turn up instructions from past years where things worked differently.
Console error messages from bluetoothctl are not very informative yet.
Not all audio devices will work. In particular, PulseAudio (at least as of v4.0-6) only supports A2DP devices, not HFP devices.
Having recently gone through all this myself, I thought I would write down the steps that I found actually do work. These steps have been verified on both an AMD x86_64 system and on a ARMv7 BeagleBone, using a Plantroncis headset and an Oontz speaker.
Take a backup of your current working system. If anything goes wrong you can always restore to this. You do not need to include "/home", but you should backup all the rest of “/” and make sure you include “/var” if it is on a separate partition.
Upgrade your Arch to the latest consistent versions.
$ sudo pacman -Syy
$ sudo pacman -Su
After the upgrade you might want to
Reboot to make sure everything else still works and
Backup again
You will need to have all of these packages installed by pacman. If you have installed a graphical desktop manager, you probably have most of them already:
dbus (interprocess communication)
alsa-plugins
pulseaudio (audio interfacing that supports bluetooth)
pulseaudio-alsa
pavucontrol (mixer for graphical desktop machines) or
ponymix (CLI mixer for pulseaudio for headless machines)
DBUS permissions
Bluetooth operations are controlled over DBUS, which has its own security system. The default settings are not quite open enough, so in /etc/dbus-1/system.d/bluetooth.conf add the lines indicated here:
<policy user="root">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.Agent"/>
<allow send_interface="org.bluez.HandsfreeAgent"/>
<allow send_interface="org.bluez.MediaEndpoint"/>
<allow send_interface="org.bluez.MediaPlayer"/>
<allow send_interface="org.bluez.Watcher"/>
<allow send_interface="org.bluez.ThermometerWatcher"/>
<!-- Insert the lines below -->
<allow send_destination="org.bluez.Manager"/>
<allow receive_sender="org.bluez.Manager"/>
<allow send_destination="org.bluez.Adapter"/>
<allow receive_sender="org.bluez.Adapter"/>
<allow send_destination="org.bluez.Device"/>
<allow receive_sender="org.bluez.Device"/>
<allow send_destination="org.bluez.Service"/>
<allow receive_sender="org.bluez.Service"/>
<allow send_destination="org.bluez.Database"/>
<allow receive_sender="org.bluez.Database"/>
<allow send_destination="org.bluez.Security"/>
<allow receive_sender="org.bluez.Security"/>
<!-- End of insertion -->
</policy>
Starting Dbus
There are two instances of the dbus-daemon process that have to be running.
One of them is started as root by systemd. If you did not have dbus installed before, you will need to configure systemd to start it:
$ sudo systemctl enable dbus
$ sudo systemctl start dbus
The other one runs as the user and is started when you log in. If you have a graphic user interface, your desktop manager will have started it for you. If you have a headless system you will need to do this in your ~/.bashrc file:
$ dbus-daemon --session --fork
Starting Bluetooth
The bluetooth daemon runs as a service and you want it to start automatically after every reboot:
$ sudo systemctl enable bluetooth
$ sudo systemctl start bluetooth
Bluez5 has a new unified control utility named 'bluetoothctl' that combines the functions of the old hciconfig, hcitool, and the simple-agent python script. You can do all of the remaining part of configuration using this single utility.
Before performing these steps make sure that your new bluetooth device (headphones, speaker, etc) is powered off. Most such devices go into pairable mode on power up and will look for hosts to pair with. You do not want that to happen before your computer is ready.
Troubleshooting
Console error messages from bluetoothctl are not always very informative. But more details are always written to the system journal. Clues about what really went wrong can usually be found by looking in the recent journal entries. This command will print the last 20 lines of the journal.
$ sudo journalctl -n 20
Adapter
The bluetooth adapter is the little thing you have probably plugged into a USB port. On many laptops it is built-in. By default, bluez leaves bluetooth adapters powered down at boot. Before anything will work it has to be powered up. We will use the 'show' subcommand to see the current state of the adapter:
$ bluetoothctl
[bluetooth]# show
Controller 00:02:72:C9:53:A6
Name: bone
Alias: bone
Class: 0x000000
Powered: no
Discoverable: no
Pairable: yes
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d050E
Discovering: no
This contains a few interesting pieces of information.
'Controller 00:02:72:C9:53:A6' shows the MAC address of the adapter itself. Yours will be a different value.
'Name: bone' is the name assigned to this adapter. It defaults to your 'hostname' which in my case is “bone”.
'Class: 0x000000' means that the adpter is not advertising that it is capable of any particular protocol support. This is reasonable because it is turned off. The Class will automatically get filled in when we power it up.
'Powered: no' this means the adapter is powered off. We will need to change this before proceeding, with the 'power on' command.
[bluetooth]# power on
[CHG] Controller 00:02:72:C9:53:A6 Class: 0x0c0100
Changing power on succeeded
[CHG] Controller 00:02:72:C9:53:A6 Powered: yes
The adapter is now powered up and the Class bitmask has been set.
Automatic power on
You can set it up so that the bluetooth adapter does power on all by itself on reboot. This is done by adding a rule to 'udev', the hardware device manager.
Create a new file /etc/udev/rules.d/10-local.rules containing the following:
# Set bluetooth power up
ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"
For this step it is important at the start that your Bluetooth device (headset, speakers, etc, are powered off.
The pairing step might require you to enter a PIN. For this you need an 'agent' running on your computer that will ask you for the PIN. Bluetoothctl has this functionality built in; you just have to turn it on:
[bluetooth]# agent KeyboardOnly
Agent registered
Now you should turn on the power to your new bluetooth device and let it initialize. Once it has done that, we can tell bluez to scan for it. In my test case I was using an “Oontz Curve” speaker, which becomes discoverable and open for pairing for about a minute after turning on:
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:02:72:C9:53:A6 Discovering: yes
[NEW] Device 88:82:54:00:13:1E OontZ Curve
This process can actually take a few seconds before bluez actually finds the device. But you can see that it found the Oontz and it's address is 88:82:54:00:13:1E (yours will be different). Now is a good time to copy that address into your copy/paste buffer, because you will need to re-enter it a few times.
The next step is to tell bluez to trust this device.
[bluetooth]# trust 88:82:54:00:13:1E
[CHG] Device 88:82:54:00:13:1E Trusted: yes
Changing 88:82:54:00:13:1E trust succeeded
[CHG] Device 88:82:54:00:13:1E RSSI: -74
The RSSI is an indication of the signal strength from the device as received by your computer's bluetooth adapter.
Now we can proceed to pair the two devices:
[bluetooth]# pair 88:82:54:00:13:1E
Attempting to pair with 88:82:54:00:13:1E
[CHG] Device 88:82:54:00:13:1E Connected: yes
[CHG] Device 88:82:54:00:13:1E Modalias: bluetooth:v000Fp0000d0000
[CHG] Device 88:82:54:00:13:1E UUIDs has unsupported type
[CHG] Device 88:82:54:00:13:1E Paired: yes
Pairing successful
[CHG] Device 88:82:54:00:13:1E Connected: no
In the process of pairing, the device is connected for a brief interval, and then it disconnects again. Do not worry about this.
An important concept in bluetooth connecting is that both ends of the connection have to be capable of using the same application protocol. The bluetooth daemon itself does not support any of these protocols, and if you try to connect your device now, it may immediately disconnect again. If you look in the system journal you might find a message like:
bluetoothd[16232]: Unable to select SEP
This is a reference to the “Stream End Point” which is part of the Bluetooth “Audio/Video Distribution Transport Protocol Specification” (AVDTP).
Since we are trying to connect audio devices in this example, we need to have something running on the computer that knows about audio over bluetooth, and it has to register its ability using the new bluez5 interface. Alsa used to be able to do this with bluez4, but the API has changed for bluez5 and as of this writing (February 2014) nobody has stepped forward to update the necessary Alsa interface module for it. With bluez5 you must use pulseaudio. (Alsa can work through pulseaudio, so your old audio programs should still work.)
Pulseaudio
The pulseaudio daemon runs as your user, not as root, and is started automatically by your graphical desktop manager, or you can do it manually by
pulseaudio –-start
If you are using a headless device as some kind of audio server you will want to put this command in your ~/.bashrc file.
Alsa
ALSA output has to be redirected to pulseaudio. Put this in /etc/asound.conf
# Use PulseAudio by default
pcm.!default {
type pulse
fallback "sysdefault"
hint {
show on
description "ALSA Output to pulseaudio"
}
}
ctl.!default {
type pulse
fallback "sysdefault"
}
Everything up to now only has to be done once. Bluez will remember that this device is trusted and paired, even across reboots. (The information is kept in files at /var/lib/bluetooth if you are curious. But do not modify any of those files manually.) Your bluetooth device will also remember that it is paired with your computer, unless you pair it again with some other computer. Most small devices like speakers and headphones can only remember one paired host at a time. The Logitech PLT_M50 is an example of a headset that can remember two. More powerful devices like tablets and smartphones can remember many pairings.
Back to bluetoothctl:
[bluetooth]# connect 88:82:54:00:13:1E
Attempting to connect to 88:82:54:00:13:1E
[CHG] Device 88:82:54:00:13:1E Connected: yes
Connection successful
[CHG] Device 88:82:54:00:13:1E Modalias: bluetooth:v000Fp0000d0000
pavucontrol is the graphical volume control and device selection console. If you have a headless system or otherwise want to control audio from the command line, install 'ponymix' instead of 'pavucontrol'.
mplayer
Mplayer defaults to using OSS for output. Pulseaudio can emulate OSS and handle this for mplayer, but you can direct mplayer directly to pulseaudio with the -ao option:
mplayer -ao pulse file.mp3
You can make pulseaudio the default by putting this in your ~/.mplayer/config file:
ao=pulse
paplay
If you are used to using the aplay command as a lighter weight way to play simple .wav files, you can do that, or use paplay instead and go directly to pulseaudio.
$ paplay file.wav
Network
To allow remote access to pulseaudio, unncomment this line in /etc/pulse/default.pa on all computers involved:
load-module module-native-protocol-tcp auth-ip-acl=192.168.2.0/24
The 'auth' clause limits access to members of your local network. Put the appropriate IP address and mask there.
Also the file ~/.config/pulse/cookie must be the same on all nodes or the pulseaudio daemons will not talk to each other. It does not matter which one you copy. It is a very small file.
Then you can specify the host where the audio is to be played:
$ paplay -s HOST filename.wav
$ mplayer -ao pulse:HOST music.mp3
If the computer where you are running mplayer does not have speakers attached and you always want the audio directed to another computer running pulseaudio, you can put the hostname right in the ~/.mplayer/config file:
ao=pulse:HOST
Tip: once I started mplayer running and it seemed to be progressing without errors, but no sound came out. It turned out the volume was turned down all the way, and a few taps on the "0" key to mplayer brought up the level.
If you make it this far, you should then reboot and run the tests from section 8 again. If things that used to work now do not work, here are some things to check:
Is the bluetooth adapter power on? (check with bluetoothctl 'show' command)
Are all the daemons running? (check with 'ps -fA | grep dbus' and and 'ps -fA | grep pulse')
Any new error messages in 'journalctl -n 20'?
Last edited by Daimusou (2014-01-31 13:46:13)
Offline
Fabulous post! Thanks for taking the time.
This needs to go in the Wiki.
Offline
Thanks for the detailed post, unfortunately it does not work for me, my device is 00:0C:55:1C:CD:DA Motorola H500
I carefully followed your instructions until I got to the connect instructions:
[bluetooth]# scan on
Discovery started
[CHG] Controller 0C:EE:E6:F7:A5:C7 Discovering: yes
[CHG] Device 18:14:56:4B:F9:40 RSSI: -42
[CHG] Device C8:7E:75:A9:1B:D5 LegacyPairing: yes
[CHG] Device C8:7E:75:A9:1B:D5 RSSI: -51
[CHG] Device C8:7E:75:A9:1B:D5 RSSI: -59
[CHG] Device 00:0C:55:1C:CD:DA LegacyPairing: yes
[CHG] Device 00:0C:55:1C:CD:DA RSSI: -25
[CHG] Device 00:0C:55:1C:CD:DA Class: 0x200404
[CHG] Device 00:0C:55:1C:CD:DA Icon: audio-card
[CHG] Device 00:0C:55:1C:CD:DA RSSI: -35
then
[bluetooth]# paired-devices
Device 18:14:56:4B:F9:40 Nokia X2-00
Device 00:0C:55:1C:CD:DA Motorola H500
[CHG] Device 18:14:56:4B:F9:40 RSSI: -50
and
[bluetooth]# info 00:0C:55:1C:CD:DA
Device 00:0C:55:1C:CD:DA
Name: Motorola H500
Alias: Motorola H500
Class: 0x200404
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: yes
UUID: Headset (00001108-0000-1000-8000-00805f9b34fb)
UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)
and finally
[bluetooth]# connect 00:0C:55:1C:CD:DA
Attempting to connect to 00:0C:55:1C:CD:DA
Failed to connect: org.bluez.Error.Failed
[CHG] Device 18:14:56:4B:F9:40 RSSI: -49
Any help would be appreciated
Andrew
Offline
It is perhaps interesting that before I made these changes i achieved a "connect" followed by a "disconnect". Now it just fails to connect, as above.
I am, however, getting the error message
00:0C:55:1C:CD:DA: error updating services: Permission denied (13)
Off to google to see if I can find out what that means
Andrew
Offline
I have seen this. Look in the journal and it will tell you exactly what it was trying to access. My guess it has to do with the Dbus settings in section 4.
Offline
That was the only message in the journal.
I will look into the dbus settings, but I have no idea what to look for.
Andrew
Offline
Sigh! This is what I love about bluetooth. Wait. Did I say love? I meant hate.
So the next day after making the post above, I retraced my steps using bluez4 and ... nada! No connection. Nothing streamed to my headset. And Gmail didn't see the new headset.
I uninstalled bluez4. Back to bluez5 and the "bluetoothctl" routine per the wiki and the headset connected.
How can a setup work one day and not the next???? Grrrr. What a frustrating merry-go-round bluetooth is.
Will pay careful attention to Daimusou's post above. Hopefully he has the key to this madness after all.
Last edited by whatshisname (2014-01-30 19:00:35)
Offline
I had exactly the same experience until I figured out that the order you do things is important.
DBUS must start before bluetoothd, the adapter powered on, and pulseaudio must start last.
Then you can connect a device.
I was doing this on a headless BeagleBone so I was not getting the 'free' installation of some
of the parts that are installed automatically when you use GNOME or XFCE or KDE. I had
to chase down each component, get it working, then move to the next step. And I went down
many dead-ends trying obsolete instructions from older versions.
Last edited by Daimusou (2014-01-30 19:07:33)
Offline
Tried all that, checked the dbus settings, but still get the "Permission denied (13)" message.
Any other ideas?
Andrew
Offline
Well it seems to me that the problem is simple, according to the Pulseaudio site HSP/HFP devices are not supported for Bluez5, only A2DP devices will work. Can anyone confirm this and I will stop trying?
Andrew
Offline
Offline
Offline
The limitation is in the current Pulseaudio, not bluez.
I will add a note to this effect in the article.
Last edited by Daimusou (2014-01-31 13:40:45)
Offline
That seems clear enough then. Shame.
Andrew
Offline
Pulseaudio is under continuous development, so keep an eye on that upstream page for developments in this area.
Last edited by Daimusou (2014-01-31 15:17:16)
Offline
From the PulseAudio page referenced above (Quoting here for the sake of posterity) :
PulseAudio now supports BlueZ 5, but only the A2DP profile. BlueZ 4 is still the only way to make HSP/HFP work.
We now use upstream gettext instead of the GLib version. The minimum required version is 0.18.1.
The minimum supported alsa-lib version is now 1.0.19 (down from 1.0.24).
and
HSP/HFP support for BlueZ 5 will hopefully arrive in the next PulseAudio release, but that requires someone to write the code for that. Some code already exists, but it hasn't been submitted for upstream inclusion, and lately there has not been much visible progress on that front (TODO: check the latest status and plans from João).
As I noted above, my experience proved - to me, at least - that hardware made a difference. Thank you guys for uncovering why this is so. I could have saved myself several days of frustration had I been able to zero in on A2DP / HSP/HFP compatibility.
Offline
Oh wow, so I just got lucky because I didn't try and use the HSP/HFP profile for my headset. Good to know. Thanks for the info!!
Offline
I wanted to use a Nokia BH-700 with skype on a toshiba laptop and kept getting the disconnect error.
Despite trying all of the above (thanks to Daimusou for the effort), the only solution that worked for me has been to install
aur/bluez4
aur/pulseaudio-bluez4
no further effort required, used bluez-simple-agent to pair, gnome 3.10 working ok with this pulseaudio
just wanted to report that as a workable solution for anyone in need
Last edited by dummyano (2014-02-14 11:15:08)
Offline
I'm chiming in in agreement with fdservices. It's all in the hardware!
I have spent *days* trying to get the 2 or 3 headsets around my house (the latest being a Plantronics 330) working with my laptop, trying both Bluez4 and Bluez5 to no avail.
The wiki for Bluetooth Headsets, https://wiki.archlinux.org/index.php/Bl … dio_method, mentioned success with the SoundBot SB220. So I broke down and bought a pair. They arrived today. (Nice headsets, BTW!)
My last attempt at this madness had me trying bluez4 so I started there this evening.
I began with the wiki: https://wiki.archlinux.org/index.php/Bluez4 paying particular attention to https://wiki.archlinux.org/index.php/Bl … SA_devices and editing the /etc/asound.conf file per the wiki.
The command sequence was:
systemctl start bluetooth
hcitool scan # To get the Mac address of my new headset
bluez-simple-agent # Ctrl-C to exit after the agent is registered. Ignore the error messages.
bluez-simple-agent hci0 FC:58:FA:C6:49:B3 # pairing the SoundBot
(Enter 0000 passkey)
bt-audio -c FC:58:FA:C6:49:B3 # as normal user to connectIt connected!!!
Then a quick trip to alsamixer to make sure there weren't any muted outputs. (This is a big gotcha. For some reason, probably due to all the tinkering around, some of the outputs continually get muted even though I have unmuted them numerous times before. Also, beware of outputs that have their volume set to max or 80%, etc. but are nonetheless muted as evidenced by the "MM" in the box below the volume scale. Click "m" to unmute them.)
This proved to be sufficient to get the new headset working with Google Talk, the primary reason for my messing with bluetooth in the first place. Happily, the SB220 was one of the options in both the "Microphone" and "Speakers" drop down boxes in "Chat" settings. Selected the SB220 in both boxes, successfully tested the mike and and headset and I'm finally back to making long distance phone calls with my laptop. Yay!
Back to my laptop only to discover that music played with mplayer wasn't streaming to the headset
So another trip to the wiki and this section: https://wiki.archlinux.org/index.php/Bl … om_the_AUR
I installed bluez-tools which changed the /etc/asound.conf file but happily got my headset listed in pavucontrol. In the "Output devices" tab I had to click the green check mark to activate the headset whereupon "mplayer some.mp3" streamed music to my headset!!
I *might* get around to testing this with bluez5 but having gotten this far, I'm not inclined to fix something that isn't broken.
The moral of this story is the choice of bluetooth headset/hardware makes all the difference. At least it did for me.
Perhaps we should start a list of compatible bluetooth headsets in the wiki? There is clearly a big interest in this topic considering the well over 4,400 views of this thread alone.
Hope this helps someone.
Nice I got my headset working for the first time in linux. Thanks.
Nevertheless I get disconnected after a couple of minutes.
Offline
I know that it is not just BT headsets that have problems with connect/disconnect. Even the humble BT mouse has erratic connections for some users in bluez5. I wonder if there are bugs in the bluez packages that need to be hunted down by providing the appropriate diagnostic output - though I don't know the best route to getting a trace or some kind of useful information that might track down where the problem lies?
Does anyone know the best way to debug these BT connections issues?
Mike C
Offline
I also get some noise from the headset sometimes. BTW, these are the bluetooth related package I have installed:
pacman -Qs blue
local/bluez-fedora 20130208-1
Libraries and tools for the Bluetooth protocol stack with patches from the
Fedora Project git repository
local/bluez-tools 0.1.38-3
A set of tools to manage bluetooth devices for linux from the cli
local/btsco 0.5-3
Bluez Bluetooth SCO Tool
local/lib32-sbc 1.1-2
Bluetooth Subband Codec (SBC) library (32-bit)
local/python2-pybluez 0.20-1
Python wrapper for the BlueZ Bluetooth stack
local/sbc 1.2-1
Bluetooth Subband Codec (SBC) library
I think bluez-fedora is bluez4. Now I am trying to get bluetooth audio using alsa and not pulseaudio, maybe this will make any difference.
Last edited by zwa (2014-03-05 01:24:26)
Offline
my paired and connected bluetooth devices do not autoreconnect after reboot with bluez5...
I should always connect it manually after reboot...
Offline
I have a working BT headset since a couple of months, right now I have the following packages installed:
local/bluez 5.19-1
Daemons for the bluetooth protocol stack
local/bluez-libs 5.19-1
Deprecated libraries for the bluetooth protocol stack
local/bluez-tools 0.1.38-3
A set of tools to manage bluetooth devices for linux from the cli
local/bluez-utils 5.19-1
Development and debugging utilities for the bluetooth protocol stack
local/sbc 1.2-1
Bluetooth Subband Codec (SBC) library
And I have to reconnect from my bt devices after rebooting too, but that's not a problem for me
Now I must get my smartphone to communicate with the computer through BT.
Offline
Not to necrobump, but I can get my bluetooth headphones to pair and sound will work with a2dp, but it only in mono and is very low quality. Any thoughts?
I don't really know what I'm doing.
Offline
Few years after...
Did you try the command
[bluetooth]# discoverable on
Changing discoverable on succeeded
that for the other device (bluetooth headset etc) can find your computer
To connect, pair and then exchange data, sound, video, etc between 2 bluetooth devices, they have to find each other and accept each other...
CAUTION: Be sure your device is in connecting/pairing mode; by example, a JBL bluetooth sound music box, a button is to be "pushed", then the blue led "blinks" until connection. Careful, the JBL device *switch off* if no connection after a few minutes, or no sound received, to save power!
I did this:
[root@hostname arch]# bluetoothctl
[NEW] Controller 0C:D2:XX:XX:XX:XX hostname [default]
[NEW] Device 0C:A6:XX:XX:XX:XX JBL GO
[bluetooth]# show
Controller 0C:D2:XX:XX:XX:XX
Name: hostname
Alias: hostname
Class: 0x1c010c
Powered: yes
Discoverable: no
Pairable: yes
UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:vXXXXXXXXXXXX
Discovering: no
Changing discoverable on succeeded
[bluetooth]# discoverable on
Changing discoverable on succeeded
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful
[bluetooth]# scan on
Discovery started
[CHG] Controller 0C:D2:XX:XX:XXXX Discovering: yes
[bluetooth]# scan on
Failed to start discovery: org.bluez.Error.InProgress
[bluetooth]# pair 0C:A6:XX:XX:XX:XX
Attempting to pair with 0C:A6:XX:XX:XX:XX
Failed to pair: org.bluez.Error.AlreadyExists
[bluetooth]# connect 0C:A6:XX:XX:XX:XX
Attempting to connect to 0C:A6:XX:XX:XX:XX
Failed to connect: org.bluez.Error.Failed
[CHG] Device 0C:A6:XX:XX:XX:XX Connected: yes
[JBL GO]#
so, beeing in [JBL GO] seems to prouve you are connected to !
To show what happens when I push the JBL bluetooth button on the JBL music box, just after the "show" : fallback from [JBL GO] to [bluetooth], and have to reset "discoverable" to "on", etc
[JBL GO]# show
Controller 0C:D2:XX:XX:XX:XX
Name: hostname
Alias: hostname
Class: 0x1c010c
Powered: yes
Discoverable: no
Pairable: yes
UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052C
Discovering: yes
[CHG] Device 0C:A6:XX:XX:XX:XX Connected: no
[CHG] Device 0C:A6:XX:XX:XX:XX Connected: yes
[CHG] Device 0C:A6:XX:XX:XX:XX Connected: no
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -54
[CHG] Device 0C:A6:XX:XX:XX:XX TxPower: 4
[bluetooth]# discoverable yes
Changing discoverable on succeeded
[CHG] Controller 0C:D2:XX:XX:XX:XX Discoverable: yes
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -102
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -51
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -64
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -52
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -63
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -52
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -63
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -51
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -102
[CHG] Device 0C:A6:XX:XX:XX:XX RSSI: -54
[bluetooth]# connect 0C:A6:XX:XX:XX:XX
Attempting to connect to 0C:A6:XX:XX:XX:XX
[CHG] Device 0C:A6:XX:XX:XX:XX Connected: yes
Connection successful
[CHG] Device 0C:A6:XX:XX:XX:XX ServicesResolved: yes
[JBL GO]#
Discovering: yes
[JBL GO]# connect on
Device on not available
[JBL GO]# device on
Invalid command
[JBL GO]# info
Device 0C:A6:XX:XX:XX
Name: JBL GO
Alias: JBL GO
Class: 0x240404
Icon: audio-card
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Headset (00001108-0000-1000-8000-00805f9b34fb)
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v000Ap8615d0100
RSSI: -54
TxPower: 4
[JBL GO]#
So here, the two devices, Computer and JBL Box are connected, and ready to exchange data (computer send sound to JBL).
Offline