Skip to content
icedwater edited this page Aug 23, 2023 · 25 revisions

Troubleshooting blueman

Reporting a bug / asking for support

The least information we typically need to help with an issue is the version of blueman you're using. In most cases the BlueZ version makes sense as well. You can use the following template to make sure you're providing the most basic information:

blueman:
BlueZ:
Distribution:
Desktop environment:

It may also be useful to provide the debugging output from the next section, sometimes even multiple examples (e.g. a working one and one where the issue comes up). Please use some service like Pastebin or GitHub Gists to post your logs and keep the thread clean and readable. Make sure to describe the exact steps you took when producing it.

Debugging blueman

To retrieve useful information, the best starting point is to run blueman-applet --loglevel debug from a Terminal window. It needs to be shut down, since only one instance may be running. You should always be able to do that with killall blueman-applet.

There will be plenty of output in the Terminal window, also including messages from blueman-manager. If you're unsure how to get behind a given problem, please provide the full output in your error report.

Debugging BlueZ

Problems with bluetooth connections are often not related to blueman and debugging needs to be carried out on the underlying bluetoothd. bluetoothd log messages usually go to /var/log/syslog. To get debugging output, bluetoothd needs to get started with the -d switch. You can either stop the managed bluetooth service (e.g. systemctl stop bluetooth.service (systemd)) and start bluetoothd manually or add the -d switch to the service configuration (e.g. the ExecStart line in /lib/systemd/system/bluetooth.service (systemd)) and restart the managed service.

https://wiki.archlinux.org/title/bluetooth

https://fedoraproject.org/wiki/How_to_debug_Bluetooth_problems

https://wiki.ubuntu.com/DebuggingBluetooth

No adapter or not able to turn on bluetooth

To test if your device is recognized by BlueZ you can use tools that list all Bluetooth devices on your machine. The following command are supposed to be run from a terminal.

  • For Bluez version 5 run bluetoothctl list

Example output

# bluetoothctl list
[NEW] Controller 00:02:72:C5:BB:B4 infirit [default]
[NEW] Device 6C:83:36:B9:C6:D6 Galaxy Nexus

If there are no controllers listed you either have,

  • A hardware killswitch enabled, usually called "airplane mode".
  • The adapter is not supported by the Linux bluetooth stack.

To check the later, you can find the hardware ID with lsusb or lspci depending on the interface to google for it.

Pairing fails on the remote device's side without a pairing dialog showing

There might be some issue when blueman tries to display the pairing notification. To confirm, open bluetoothctl, enable its agent with the agent on command, and issue a pair command for the device. You should get a request there. If not, you're having a more generic issue.

To inspect the issue with notifications, first type:

head -1 $(which blueman-applet)

This should show you which python version blueman uses in case you have multiple. Then fire up a python console and type:

from blueman.gui.Notification import Notification
Notification("Title", "Message", 0, [["action1", "Action 1"], ["action2", "Action 2"]]).show()

A2DP audio device PAIRED but fails to connect.

If the device pairs properly but fails to connect it may be that you need to install packages and/or enable options in BlueZ. For A2DP to work you need the pulseaudio bluetooth module installed and enabled. There are two good wiki pages from Debian [1] and Arch [2] that cover most, if not all, that is needed to set this up.

[1] https://wiki.debian.org/BluetoothUser/a2dp

[2] https://wiki.archlinux.org/index.php/Bluetooth_headset

If you are using GDM as a login manager and the required packages are installed and A2DP still fails to connect, there's a fix. GDM starts its own Pulseaudio session upon startup, grabs the A2DP sink, thus making it unavailable to the user session. The fix is to create a pulse config for the GDM session that disables bluetooth pulse module.

Edit (and create directories as needed) /var/lib/gdm/.config/pulse/default.pa with the contents

#!/usr/bin/pulseaudio -nF
#

# load system wide configuration
.include /etc/pulse/default.pa

### unload driver modules for Bluetooth hardware
.nofail

.ifexists module-bluetooth-policy.so
unload-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
unload-module module-bluetooth-discover
.endif

.fail

Turn on bluetooth device on boot

Officially supported way

As of BlueZ version 5.35 it is possible to configure this. In file /etc/bluetooth/main.conf look for AutoEnable option under [Policy] and change it from False to True.

Deprecated way

If you require turning on your bluetooth device at boot time automatically, for instance when you require keyboard / mouse support. You can add a udev rule to enable that. Additionally, you need to make sure you have the package bluez-utils installed.

Create a file in /etc/udev/rules.d/ (eg 50-bluetooth-hci-auto-poweron.rules) with the following content.

ACTION=="add", SUBSYSTEM=="bluetooth", KERNEL=="hci[0-9]*", RUN+="/bin/hciconfig %k up"