Bluetooth

Related articles
Bluetooth mouse
Bluetooth keyboard
Bluetooth headset
Blueman
ObexFTP
Bluetooth
is a standard for the short-range wireless interconnection of cellular phones, computers, and other electronic devices. In Linux, the canonical implementation of the Bluetooth protocol stack is
BlueZ
.
Installation
Install
the
bluez
package, providing the Bluetooth protocol stack.
Install
the
bluez-utils
package, providing the
bluetoothctl
utility. Additionally install
bluez-deprecated-tools
to have the
deprecated BlueZ tools
as well.
The generic Bluetooth driver is the
btusb
kernel module.
Check
whether that module is loaded. If it is not, then
load the module
.
Start/enable
bluetooth.service
.
Note
Some Bluetooth adapters are bundled with a Wi-Fi card (e.g. older Intel Centrino cards). These require that the Wi-Fi card is firstly enabled (typically a keyboard shortcut on a laptop) in order to make the Bluetooth adapter visible to the kernel.
Some Bluetooth cards (e.g. Broadcom) conflict with the network adapter. Thus, you need to make sure that your Bluetooth device gets connected before the network service boot.
Some tools such as hcitool and hciconfig have been deprecated upstream, and are no longer included in
bluez-utils
. Since these tools will no longer be updated, it is recommended that scripts be updated to avoid using them. If you still desire to use them, install additionally
bluez-deprecated-tools
. See
FS#53110
and
the Bluez mailing list
for more information.
Since
2024
,
bluez-obex
and
bluez-mesh
have been separated from
bluez
. Therefore, if you plan to transfer files over Bluetooth,
bluez-obex
needs to be installed and the user service
obex.service
needs to be
enabled
.
Front-ends
Console
bluetoothctl
— Pairing a device from the shell is one of the simplest and most reliable options.
https://www.bluez.org/
||
bluez-utils
bluetui
— A TUI for managing Bluetooth devices.
https://github.com/pythops/bluetui
||
bluetui
bluetuith
— Provides a Bluetooth manager via a Terminal User Interface for easier pairing and device/adapter management, with OBEX File Transfer and mouse support.
https://www.github.com/darkhz/bluetuith
||
bluetuith
AUR
bluez-tools
— Basic non-interactive tools covering some functionality missing in bluetoothctl, like sending files or managing bluetooth networks.
https://github.com/khvzak/bluez-tools
||
bluez-tools
Tip
To automate bluetoothctl commands, use
echo -e "
command1
\n
command2
\n" | bluetoothctl
or
bluetoothctl --
command
.
Graphical
The following packages allow for a graphical interface to customize Bluetooth.
GNOME Bluetooth
—
GNOME
's Bluetooth tool.
gnome-bluetooth-3.0
provides the back-end (
gnome-bluetooth
AUR
is now legacy)
gnome-shell
provides the status monitor applet
gnome-control-center
provides the configuration front-end GUI that can be accessed by typing Bluetooth on the Activities overview, or with the
gnome-control-center bluetooth
command.
You can also launch the
bluetooth-sendto
command directly to send files to a remote device.
nautilus-bluetooth
AUR
adds a "Send via Bluetooth" entry to Nautilus' right-click menu
To receive files, open the Bluetooth settings panel; you can only receive whilst the Bluetooth panel is open.
To add a Bluetooth entry to the
Send To
menu in Thunar's file properties menu, see instructions
here
. (The command that needs to be configured is
bluetooth-sendto %F
).
Bluedevil
—
KDE
's Bluetooth tool. If there is no Bluetooth icon visible in Dolphin and in the system tray, enable it in the system tray options or add a widget. You can configure Bluedevil and detect Bluetooth devices by clicking the icon. An interface is also available from the KDE System Settings.
https://invent.kde.org/plasma/bluedevil
||
bluedevil
Blueberry
— Linux Mint's spin-off of GNOME Bluetooth, which works in all desktop environments.
Blueberry
does not support receiving files through Obex Object Push.
https://github.com/linuxmint/blueberry
||
blueberry
AUR
Blueman
— A full featured Bluetooth manager.
https://github.com/blueman-project/blueman
||
blueman
ObexFTP
— A tool for transferring files to/from any OBEX enabled device.
http://dev.zuckschwerdt.org/openobex/wiki/ObexFtp
||
obexftp
AUR
Overskride
— A simple yet powerful Bluetooth client.
https://github.com/kaii-lb/overskride#overskride
||
overskride
AUR
btctl
— A simple Bluetooth connection manager for
fuzzel
and other launchers.
https://codeberg.org/kupospelov/btctl
||
btctl
AUR
Pairing
Note
Before using the Bluetooth device, make sure that it is not blocked by
rfkill
.
This section describes directly configuring
bluez
via the
bluetoothctl(1)
command line tool, which might not be necessary if you are using  an alternative front-end tool (such as GNOME Bluetooth).
The exact procedure depends on the devices involved and their input functionality.  What follows is a general outline of pairing a device using
bluetoothctl
.
Start the
bluetoothctl
interactive command. Input
help
to get a list of available commands.
(optional) Select a default controller with
select
MAC_address
.
(optional) Enter
power on
to turn the power to the controller on if the device is set to off. It is on by default; see
#Default adapter power state
.
Enter
devices
to get the MAC address of the device with which to pair.
Enter device discovery mode with
scan on
command if device is not yet on the list.
Turn the agent on with
agent on
or choose a specific agent: if you press tab twice after
agent
you should see a list of available agents. A Bluetooth agent is what manages the Bluetooth 'pairing code'. It can either respond to a 'pairing code' coming in, or can send one out. The
default-agent
should be appropriate in most cases.
[1]
Enter
pair
MAC_address
to do the pairing (tab completion works).
If using a device without a PIN, one may need to manually trust the device before it can reconnect successfully. Enter
trust
MAC_address
to do so.
Enter
connect
MAC_address
to establish a connection.
An example session may look this way:
$ bluetoothctl
[NEW] Controller 00:10:20:30:40:50
hostname
[default]
[bluetooth]# agent KeyboardOnly
Agent registered

[bluetooth]# default-agent
Default agent request successful

[bluetooth]# power on
Changing power on succeeded
[CHG] Controller 00:10:20:30:40:50 Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:10:20:30:40:50 Discovering: yes
[NEW] Device 00:12:34:56:78:90
device name
[CHG] Device 00:12:34:56:78:90 LegacyPairing: yes

[bluetooth]# pair 00:12:34:56:78:90
Attempting to pair with 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
[CHG] Device 00:12:34:56:78:90 Connected: no
[CHG] Device 00:12:34:56:78:90 Connected: yes
Request PIN code
[agent] Enter PIN code: 1234
[CHG] Device 00:12:34:56:78:90 Paired: yes
Pairing successful
[CHG] Device 00:12:34:56:78:90 Connected: no

[bluetooth]# connect 00:12:34:56:78:90
Attempting to connect to 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
Connection successful
Dual boot pairing
For dual booting Linux systems, as shown in
#Saving the configuration
simply ensure all files from
/var/lib/bluetooth/
BT-Adapter-MAC-address
are identical on each installation, either by copying or symlinking them.
With Windows or macOS, to pair devices on dual boot setups you need to change the pairing keys on your Linux install to match.
This page only describes the manual method of doing so. To automate the process, see the
bt-dualboot project
(does not support
Bluetooth Low Energy
) and
the related repositories
.  For a semi-automated process, use the
bluetooth-dualboot script
which does not edit any files, but it helps you run the right commands and cut-and-paste the correct values.
Setup
To do this, first pair your device on your Arch Linux install. Then reboot into the other OS and pair the device. Now you need to extract the pairing keys, but first switch off the Bluetooth devices to prevent any connection attempts.
Note
Some devices, such as the
Logitech MX Master
and Logitech 604 Lightspeed, increment an octet of their MAC address (typically the last) every time that the device is paired with a new system. You should determine whether this is the case, so that it can be accounted for at the end of the process.
For Windows
You can extract your Bluetooth keys on either Linux or Windows:
Extracting on Windows
First, boot into Windows.
The registry key containing the link keys may only be accessed by the
SYSTEM account
, which cannot be logged into. Therefore, you will need Microsoft's
PsExec
tool from the official Windows Sysinternals site in order to run
regedit.exe
as
SYSTEM
.
Download
PsTools
, and extract
PsExec64.exe
.
In an administrator instance of a
command shell
, from the location of the extracted EXE, launch the registry editor:
.\PsExec64.exe -s -i regedit.exe
In the registry editor, navigate to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys
Within this registry key is one subkey per Bluetooth adapter, named by MAC address. If there are multiple subkeys, and you are unsure of which to use, follow
this guide
to find the MAC address for the desired Bluetooth adapter.
In the desired adapter's registry key, there is a name-value pair for each paired device, with the name being its MAC address. Additionally, you might see some subkeys named by MAC addresses, each containing name-value pairs with names like
LTK
or
IRK
. These subkeys (if any) are for Bluetooth 5.1 devices. If the device you're trying to share has a subkey, it is a Bluetooth 5.1 device. If it does not have a subkey, only a name-value pair, it is not a Bluetooth 5.1 device.
Right click on the adapter's registry key and export it as a
.reg
file. This is a text file that you can copy keys from. As mentioned, it contains pairing keys in name-value pairs for non-Bluetooth 5.1 devices, and pairing keys (and some other information) in per-device subkeys for Bluetooth 5.1 devices. Make this file available to your Linux installation and reboot into it.
If the device you want to share is
not
a Bluetooth 5.1 device, jump to
#Saving the configuration
. If it is a Bluetooth 5.1 device, you need to make some modifications to the pairing keys and the associated information before finishing up. Refer to
#Preparing Bluetooth 5.1 Keys
to see how.
Extracting on Linux
Note
If your Windows partition is encrypted with Bitlocker, you will not be able to access it from Linux using chntpw.
Boot into Arch. Install
chntpw
. Mount your windows system drive. Change to the registry hive directory and start
chntpw
on the SYSTEM hive:
Tip
If
rlwrap
is installed,
chntpw
can be run as
rlwrap chntpw
to provide readline-style command-line editing and history.
$ cd
/path/to/windows/system
/Windows/System32/config
$ chntpw -e SYSTEM
Inside the
chntpw
environment, run:
> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys
Instead of
CurrentControlSet
, you may see
ControlSet00
X
(check using
ls
); use this instead:
> cd ControlSet00
X
\Services\BTHPORT\Parameters\Keys
There will probably be just one subkey, whose name is your Bluetooth adapter's MAC address.
Show it with
ls
and
cd
into it:
> ls
> cd
your-adapter's-mac-address
The subkey names under that adapter are the MAC addresses of the
devices
the adapter is paired to.
Show them with
ls
, then
cd
into each of those you want to dual-pair:
> ls
> cd
your-device's-mac-address
If this is
not
a Bluetooth 5.1 device, you will only see the pairing key:
> ls
Node has 0 subkeys and 1 values
size  type        value name    [value if type DWORD]
16    REG_BINARY <ab12cd34ef56>
If so, show a hexdump of your device's key using
hex
:
> hex ab12cd34ef56
:00000 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX (some other chars)
The "XX"s are the pairing key. Make note of which keys map to which MAC addresses.
If this
is
a Bluetooth 5.1 device, then you will see several keys corresponding to the one device:
Node has 0 subkeys and 8 values
  size     type              value name             [value if type DWORD]
    16  3 REG_BINARY         <LTK>
     4  4 REG_DWORD          <KeyLength>               16 [0x10]
     8  b REG_QWORD          <ERand>
     4  4 REG_DWORD          <EDIV>                 37520 [0x9290]
    16  3 REG_BINARY         <IRK>
     8  b REG_QWORD          <Address>
     4  4 REG_DWORD          <AddressType>              1 [0x1]
     4  4 REG_DWORD          <AuthReq>                 45 [0x2d]
Refer to
#Preparing Bluetooth 5.1 Keys
to see how to use these, using
hex
value_name
to obtain the requested values.
Finally, to import the key(s) into your Linux installation, proceed to
#Saving the configuration
.
For macOS
Boot into macOS:
For macOS Monterey or newer:
Open Keychain Access and search for Bluetooth.
Sort by date.
If you've recently removed and reconnected the device then you can simply sort the keys by date modified and pick the latest. It is probably called MobileBluetooth (for older Bluetooth devices) or is just an UUID (for Bluetooth 5.1+).
Double click on the entry. Check that the MAC address in the Account field matches the MAC address of your device.
Click the "Show password" checkbox. You will now need to enter your password, twice.
Copy the text in the password field, it's actually an XML file (
⌘+a
⌘+c
)
Paste the text in
bt_keys.txt
in your home directory.
For High Sierra or newer, run the following in a terminal:
# defaults read /private/var/root/Library/Preferences/com.apple.bluetoothd.plist LinkKeys > ~/bt_keys.txt
For Sierra or older, run the following in a terminal:
# defaults read /private/var/root/Library/Preferences/blued.plist LinkKeys > ~/bt_keys.txt
The
~/bt_keys.txt
file now contains the established Bluetooth keys. For older versions of macOS (High Sierra and older) you will have to reverse the keys before proceeding. For example,
98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm
becomes
MM LL KK JJ GG FF EE DD CC BB AA 2F 54 98
.
Note
The reversal can be done with the following
Python
code:
>>> key = "98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm"
>>> " ".join(reversed(key.split()))
If this is a Bluetooth 5.1 device, then there will be more than one key corresponding to one device. Refer to
#Preparing Bluetooth 5.1 Keys
to see how to use these.
Finally, to import the key(s) into your Linux installation, reboot into Linux and proceed to
#Saving the configuration
.
Preparing Bluetooth 5.1 Keys
This article or section needs expansion.
Reason:
We are still working on getting a comprehensive idea of how these work across vendors. For now, documenting specific devices' compatibility with these methods is helpful - especially non-Logitech data points. (Discuss in
Talk:Bluetooth#Bluetooth 5.1 Devices
)
If you observed the presence of Bluetooth 5.1 keys while following
#For Windows
or
#For macOS
, you must apply certain transformations to their values before importing them into Linux. Create the requested files with their appropriate contents, for installation in
#Saving the configuration
. This process will depend on the device, and some of the values have to be manipulated; code utilities for doing so are provided below.
Device
Source Key and Transformations (Windows)
Source Key and Transformations (macOS)
Destination Key File
Logitech MX Anywhere 3S
Logitech MX Master 3
Logitech MX Master 3S
Logitech MX Keys
Logitech MX Keys Mini
Logitech MX Mechanical
Xbox One S Wireless Controller
Copy
IRK
.
Remove the spaces between the hex octets.
?
IdentityResolvingKey.Key
Copy
LTK
.
Remove the spaces between the hex octets.
?
SlaveLongTermKey.Key
and
PeripheralLongTermKey.Key
ERand
and
EDIV
should be
0
Random Number
and
Encrypted Diversifier
should be
0
.
–
Logitech MX Anywhere 2S
ELECOM Bitra
Copy
IRK
.
Remove the spaces between the hex octets.
?
IdentityResolvingKey.Key
Copy
CSRK
.
Remove the spaces between the hex octets.
?
LocalSignatureKey.Key
Copy
LTK
.
Remove the spaces between the hex octets.
?
LongTermKey.Key
Copy
KeyLength
.
Convert the whole number to decimal.
?
LongTermKey.EncSize
Copy
EDIV
.
Convert the whole number to decimal.
?
LongTermKey.EDiv
Copy
ERand
.
Reverse the order of the octets.
Convert the whole number to decimal.
?
LongTermKey.Rand
Dygma Defy
Copy
IRK
.
Remove the spaces (or commas) between the hex octets.
?
IdentityResolvingKey.Key
Copy
LTK
.
Remove the spaces (or commas) between the hex octets.
?
LongTermKey.Key
Copy
KeyLength
.
Convert the whole number from hex to decimal.
?
LongTermKey.EncSize
Copy
EDIV
.
Convert the whole number from hex to decimal.
?
LongTermKey.EDiv
Copy
ERand
.
Reverse the order of the octets and remove the spaces (or commas).
Convert the whole number from hex to decimal.
?
LongTermKey.Rand
Royal Kludge F68 keyboard is like the Logitech MX Anywhere 2S
Also copy
CSRKInbound
too.
Remove the spaces between the hex octets.
?
RemoteSignatureKey.Key
ThinkPad TrackPoint Keyboard II
Pebble M350 mouse
Logitech G604 Lightspeed mouse
Copy
IRK
.
Reverse the order of the octets.
Copy
Remote IRK
.
Convert from base64 to hex.
IdentityResolvingKey.Key
Copy
LTK
.
Remove the spaces between the hexadecimal octets.
Copy
Remote Encryption
>
Long-term Key
.
Convert from base64 to hex.
LongTermKey.Key
Copy
ERand
.
Reverse the order of the octets.
Convert the whole number to decimal.
Copy
Remote Encryption
>
Random Number
.
Convert from base64 to a little-endian decimal number (see Python code below).
LongTermKey.Rand
Copy
EDIV
.
Reverse the order of the octets.
Convert the whole number to decimal.
Copy
Remote Encryption
>
Encrypted Diversifier
.
Convert from base64 to a little-endian decimal number (see Python code below).
LongTermKey.EDiv
Other devices
Copy
LTK
.
Remove the spaces between the hex octets.
Copy
Remote IRK
.
Convert from base64 to hex.
LongTermKey.Key
Copy
ERand
.
Reverse the order of the octets.
Convert the whole number to decimal.
Copy
Remote Encryption
>
Long-term Key
.
Convert from base64 to hex.
LongTermKey.Rand
Copy
EDIV
.
Remove the spaces between the hex octets.
Copy
Remote Encryption
>
Encrypted Diversifier
.
Convert from base64 to hex.
Reverse the order of the octets.
LongTermKey.EDiv
Xbox wireless controller
Copy
LTK
.
Remove the spaces between the hex octets.
?
SlaveLongTermKey.Key
Note
To just remove the spaces from a value, you can use
this online tool
or this
Python
code:
>>> "
key_value
".replace(" ", "")
This Python code does only the octet reversal:
>>> ERand=" 63 02 84 B8 5D 40 44 DF   "
>>> ERand=list(reversed(ERand.strip().split()))
This Python code does the additional decimal conversion required for some:
>>> int("".join(ERand), 16)
16088054540146049635
This Python code does the base64 to hex conversion:
binascii.hexlify(base64.decodebytes(b'...')).upper()
This Python code does the full macOS Encrypted Diversifier conversion:
struct.unpack('<H', base64.decodebytes(b'...'))
This Python code does the full macOS Random Number conversion:
struct.unpack('<Q', base64.decodebytes(b'...'))
For an example of the general case:
An
LTK
of
48 4D AF CD 0F 92 22 88 0A 52 9A F4 76 DA 8B 94
makes for a
LongTermKey.Key
of
484DAFCD0F9222880A529AF476DA8B94
.
An
ERand
of
63 02 84 B8 5D 40 44 DF
makes for a
Rand
of
16088054540146049635
.
An
EDIV
of
37520
makes for an
EDiv
of
37520
.
Saving the configuration
Now that you have the keys change user to root, then continue with:
# cd /var/lib/bluetooth/
BT-Adapter-MAC-address
Here you will find folders for each paired Bluetooth device. For each device you want to pair with Arch and your dual boot, do the following:
# cd
device-MAC-address
Note
At this point, if you are using a device which increments its MAC address on pairing, you must move the MAC address directory to the incremented path. Either copy the MAC address from Windows, or increment it yourself while minding the fact that each octet is a two-digit
hexadecimal
number.
If you have a pairing key (i.e. this is not a Bluetooth 5.1 device), then edit the
info
file and change the key under
[LinkKey]
. E.g.:
info
[LinkKey]
Key=XXXXXXXXXXXXXXX
Note
You will have to make sure that all the letters are in capital case. Remove any spaces.
If you have several keys, as in Bluetooth 5.1, edit the
info
file and substitute all applicable keys with their recorded values. E.g. for an Xbox One S Wireless Controller:
info
[IdentityResolvingKey]
Key=<IdentityResolvingKey.Key>

[PeripheralLongTermKey]
Key=<PeripheralLongTermKey.Key>

[SlaveLongTermKey]
Key=<SlaveLongTermKey.Key>
Then
restart
bluetooth.service
and
pulseaudio
(with
pulseaudio -k && pulseaudio --start
).
You should be able to connect to your device now.
Note
Depending on your Bluetooth manager, you may need to perform a full reboot in order to reconnect to the device.
Configuration
Default transport 3.0 vs 5.x (low energy)
To force Bluetooth controller to use older Bluetooth transport protocol (e.g. because its simpler to setup dual boot pairing for 3.0 device, than for 5.x BLE device), set
ControllerMode=bredr
in
/etc/bluetooth/main.conf
in the
[General]
section:
/etc/bluetooth/main.conf
[General]
ControllerMode=bredr
Default value is
ControllerMode=dual
i.e. both BR/EDR and LE enabled.
Default adapter power state
As of
bluez
5.65, BlueZ' default behavior is to power on all Bluetooth adapters when starting the service or resuming from suspend.
[2]
If you would like the adapter to not be automatically enabled (e.g. on a portable device where you wish to save battery), set
AutoEnable=false
in
/etc/bluetooth/main.conf
in the
[Policy]
section:
/etc/bluetooth/main.conf
[Policy]
AutoEnable=false
The adapter can still be turned on manually by running
power on
as described in
#Pairing
.
Discoverable on startup
If the device should always be visible and directly connectable:
/etc/bluetooth/main.conf
[General]
DiscoverableTimeout = 0
Wake from suspend
To allow Bluetooth keyboards, mice, etc. to wake the system from suspend. First, check the bios settings and make sure that wake from USB is not disabled. In many cases, Bluetooth from the motherboard is a USB device.
Add a new udev rule for Bluetooth adapter(s) (
USB Wireless Controller Base Class
, Bluetooth Programming Interface Protocol) to enable wake from suspend:
/etc/udev/rules.d/91-bluetooth-wakeup.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", \
    ATTR{bDeviceClass}=="e0", \
    ATTR{bDeviceProtocol}=="01", \
    ATTR{bDeviceSubClass}=="01", \
ATTR{power/wakeup}="enabled"
To automatically re-configure your Bluetooth keyboard after wakeups to e.g. have a different keymap or key press repeat rate (for details, see
Xorg/Keyboard configuration#Adjusting typematic delay and rate
and
xmodmap
), create an
executable
script:
configure_keyboard.sh
#!/bin/sh
export DISPLAY=:0
xset r rate 220 30
xmodmap /
your
/
path
/
to
/.Xmodmap
Then create an additional udev rule like above:
/etc/udev/rules.d/92-keyboard-reconfiguration-wakeup.rules
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", \
    ATTR{bDeviceClass}=="e0", \
    ATTR{bDeviceProtocol}=="01", \
    ATTR{bDeviceSubClass}=="01" \
RUN+="/
your
/
path
/
to
/configure_keyboard.sh"
Enabling experimental features
The Bluez stack keeps new, potentially buggy features behind the D-Bus experimental and kernel experimental options. The functionality included under these varies over time, as experimental features are determined to be stable and no longer require the option (as an example: enabling D-Bus experimental interfaces currently allows to report battery level for old headsets). To enable these, uncomment the corresponding line in the configuration:
/etc/bluetooth/main.conf
...

# Enables D-Bus experimental interfaces
# Possible values: true or false
Experimental = true
# Enables kernel experimental features, alternatively a list of UUIDs
# can be given.
# Possible values: true,false,<UUID List>
# Possible UUIDS:
...
# Defaults to false.
KernelExperimental = true
Alternatively, you can
edit
the
bluetooth.service
to add the
--experimental
or
--kernel
flag, like this
drop-in file
:
/etc/systemd/system/bluetooth.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd --experimental
Either way, you must then
restart
the
bluetooth.service
.
Audio
You will typically need to take an additional step to integrate the audio server with Bluetooth. This is detailed in the below sections.
See the
Bluetooth headset
page for more information about Bluetooth audio and Bluetooth headsets.
PulseAudio
In order to be able to use audio equipment like Bluetooth headphones or speakers, you need to install the additional
pulseaudio-bluetooth
package. Make sure to restart
PulseAudio
to make the installation take effect:
pulseaudio -k
. With a default PulseAudio installation (specifically, using a user instance with the packaged
default.pa
) you should immediately be able to stream audio from a Bluetooth device to your speakers.
[3]
If you have a system-wide PulseAudio setup make sure the user running the daemon (usually
pulse
) is in the
lp
group and you load the Bluetooth modules in your PulseAudio config:
/etc/pulse/system.pa
...
load-module module-bluetooth-policy
load-module module-bluetooth-discover
...
Optionally, add
load-module module-switch-on-connect
if you want to auto-switch all audio to the Bluetooth device.
PipeWire
PipeWire
as of v0.3.19 enables its Bluetooth support by default.
ALSA
Note
Bluez5 has dropped direct integration for
ALSA
and supports
PulseAudio
only. Follow the instructions below if you cannot or do not want to use PulseAudio.
First, ensure that your Bluetooth audio device is correctly paired and connected to the system.
Then, install
bluez-alsa-git
AUR
, start (and enable) the
bluealsa
service, and add your user to the
audio
group.
Run the following command to check if everything is working as intended (replace
XX:XX:XX:XX:XX:XX
and
FILE.wav
below):
$ aplay -D bluealsa:SRV=org.bluealsa,DEV=
XX:XX:XX:XX:XX:XX
,PROFILE=a2dp
FILE.wav
Finally, add the following lines to your
~/.asoundrc
:
~/.asoundrc
defaults.bluealsa {
    service "org.bluealsa"
    device "XX:XX:XX:XX:XX:XX"
    profile "a2dp"
}
You can now use the
bluealsa
device to reach your Bluetooth audio device. Volume management is conducted normally via
alsamixer
with the option
-D bluealsa
.
Bluetooth serial
To get Bluetooth serial communication working on Bluetooth-to-Serial modules (HC-05, HC-06) do the following steps:
Pair
your Bluetooth device using
bluetoothctl
as described
above
.
Install
bluez-deprecated-tools
, as it provides certain functionality which is missing from newer tools.
Bind paired device MAC address to tty terminal:
# rfcomm bind rfcomm0
MAC_address_of_Bluetooth_device
Now you can open
/dev/rfcomm0
for serial communication:
$ picocom /dev/rfcomm0 -b 115200
Troubleshooting
This article or section is out of date.
Reason:
Replace hciconfig with newer commands. (Discuss in
Talk:Bluetooth
)
General Troubleshooting
Debugging
In order to debug, first
stop
bluetooth.service
.
And then start it with the
-d
parameter:
# /usr/lib/bluetooth/bluetoothd -n -d
Another option is via the
btmon
tool.
Deprecated BlueZ tools
Eight BlueZ tools
were deprecated
and removed from
bluez-utils
, although not all of them were superseded by newer tools. The
bluez-deprecated-tools
package now provides these deprecated tools.
Deprecated tool
Most likely replacement
gatttool
btgatt-client, D-Bus Gatt API (
GattCharacteristic
,
GattDescriptor
,
GattManager
,
GattProfile
, and
GattService
)
hciattach
btattach
hciconfig
btmgmt (and bluetoothctl?)
hcidump
btmon (and btsnoop)
hcitool
missing,
D-Bus Device API
available
rfcomm
missing, implement with D-Bus
Profile
/
ProfileManager
API?
ciptool
sdptool
missing, functionality seems to be scattered over different D-Bus objects:
Profile
, Advertising (
LEAdvertisement
and
LEAdvertisingManager
), and the UUIDs arrays in
device
and
adapter
.
Service issues
systemd: Condition check resulted in Bluetooth service being skipped
bluetooth.service
only requires the directory
/sys/class/bluetooth
to exist, which should be created by kernel module
bluetooth
, which is only autoloaded by
systemd-udev
if it actually finds a working Bluetooth hardware device.
If your
/sys/class/bluetooth
does not exist, check if your kernel Bluetooth module is loaded by
lsmod
. If not, and you believe you have a Bluetooth device, you can try manually starting them by
loading the Bluetooth module
and
restarting
bluetooth.service
.
You should also load your corresponding kernel Bluetooth driver when loading the
bluetooth
module, most likely
btusb
, but can also be
btrtl,btintel,btbcm,bnep,btusb
etc.
Check
bluetooth.service
's
unit status
to see whether it started.
See also
Debian Bug report logs - #853207
.
If
bluetooth.service
started successfully, there is a chance that you still cannot use Bluetooth normally (e.g.
bluetoothctl
says something like
org.Bluez.Error.NotReady
when you
scan on
). If this happens, try rebooting your computer, and double-check: whether directory
/sys/class/bluetooth
exists; whether
lsmod
includes correct Bluetooth modules; log messages in the
journal
; etc.
systemd-udev
should pickup your Bluetooth hardware automatically without manual changes again.
Bluetooth immediately waking up suspend-to-idle devices
On systems capable of
suspend-to-idle/S2idle/S0ix/Modern Standby
, Bluetooth controllers will stay enabled during sleep. This will usually cause the system to
wake up immediately after going to sleep
if any Bluetooth device is connected.
To prevent this, you can disable Bluetooth completely before going to sleep - install
bluez-utils
and create this file:
/etc/systemd/system/bluetooth-disable-before-sleep.service
[Unit]
Description=Disable Bluetooth before going to sleep
Before=sleep.target
Before=suspend.target
Before=hybrid-sleep.target
Before=suspend-then-hibernate.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/bin/bluetoothctl power off
ExecStop=/usr/bin/bluetoothctl power on

[Install]
WantedBy=sleep.target
WantedBy=suspend.target
WantedBy=hybrid-sleep.target
WantedBy=suspend-then-hibernate.target
Enable
this service and check if Bluetooth devices disconnect when going to sleep, and whenever Bluetooth goes back up after waking up the system.
If this workaround is in use,
waking up the system with a Bluetooth mouse/keyboard
will not work.
Bluetooth turns off after logout on a headless/server system
This can have various causes:
Both
PulseAudio
and
PipeWire
run as user services by default, which are terminated once the last session ends. Enable
lingering
for the user to fix this.
Additionally, when running
WirePlumber
with
PipeWire
(which is usually the case), WirePlumber runs a "logind-monitor" which enables Bluetooth on login and disables it on logout. See
WirePlumber#Keep Bluetooth running after logout / Headless Bluetooth
for a fix.
Adapter issues
hcitool scan: Device not found
On some laptops (e.g. Dell Studio 15, Lenovo Thinkpad X1) you have to switch the Bluetooth mode from HID to HCI. Install the
bluez-hid2hci
package, then
udev
should do this automatically. Alternatively, you can run this command to switch to HCI manually:
# /usr/lib/udev/hid2hci
If the device will not show up and you have a Windows operating system on your machine, try booting it and enable the Bluetooth adapter from windows.
Sometimes also this simple command helps:
# bluetoothctl power on
bluetoothctl: No default controller available
First, make sure the device is not being blocked by
rfkill
. If using
USBGuard
, make sure it is not blocking the device (see
USBGuard#Allow Bluetooth controllers
).
Otherwise, consider the following possible causes:
Some motherboard Bluetooth controllers have a bug which causes this. To see whether this is the issue, run
journalctl | grep hci
and check whether it contains
command tx timeout
or
Reading Intel version command failed
. If it does, power off your computer and physically unplug the power cable for a few seconds. This forces the controller to reload the firmware, unlike a standard reboot (see
bug report
).
Some Intel cards (such as the 8260) are not picked up correctly by the Bluetooth service. In this case, using the deprecated
bluez-deprecated-tools
instead of
bluez-utils
might fix the issue.
Some dongles, such as the
CSR clones
, have compatibility issues at the kernel level.
Power saving measures can cause issues, in which case adding the
kernel parameter
btusb.enable_autosuspend=n
is a potential solution (see
bug report
).
Finally, unloading and loading
btusb
without options sometimes helps to get the controller back:
# modprobe -r btusb
# modprobe btusb
rfkill unblock: Do not unblock
If your device still soft blocked and you run
ConnMan
, try this:
$ connmanctl enable bluetooth
Bluetooth USB dongle
If you are using a USB dongle, you should check that your Bluetooth dongle is recognized. You can do that by running
journalctl -f
as root when you have plugged in the USB dongle (or inspecting
/var/log/messages.log
). It should look something like the following (look out for hci):
Feb 20 15:00:24 hostname kernel: [ 2661.349823] usb 4-1: new full-speed USB device number 3 using uhci_hcd
Feb 20 15:00:24 hostname bluetoothd[4568]: HCI dev 0 registered
Feb 20 15:00:24 hostname bluetoothd[4568]: Listening for HCI events on hci0
Feb 20 15:00:25 hostname bluetoothd[4568]: HCI dev 0 up
Feb 20 15:00:25 hostname bluetoothd[4568]: Adapter /org/bluez/4568/hci0 has been enabled
If you only get the first two lines, you may see that it found the device but you need to bring it up.
Example:
# btmgmt
[mgmt]# info
Index list with 1 item
hci0:	Primary controller
	addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x000000
	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
current settings:
connectable discoverable bondable ssp br/edr le secure-conn
	name Mozart
	short name

[mgmt]# select hci0
Selected index 0

[hci0]# power up
hci0 Set Powered complete, settings:
powered
connectable discoverable bondable ssp br/edr le secure-conn

[hci0]# info
hci0:	Primary controller
	addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x1c0104
	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
current settings: powered
connectable discoverable bondable ssp br/edr le secure-conn
Or
# bluetoothctl
[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
	Name: Mozart
	Alias: Mozart
	Class: 0x0000095c
Powered: no
Discoverable: yes
	Pairable: yes

[bluetooth]# power on
[CHG] Controller 00:1A:7D:DA:71:10 Class: 0x001c0104
Changing power on succeeded
[CHG] Controller 00:1A:7D:DA:71:10
Powered: yes
[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
	Name: Mozart
	Alias: Mozart
	Class: 0x001c0104
Powered: yes
Discoverable: yes
	Pairable: yes
To verify that the device was detected you can use
btmgmt
which is part of the
bluez-utils
. You can get a list of available devices and their identifiers and their MAC address by issuing:
$ btmgmt info
Index list with 1 item
hci0:	Primary controller
	addr 00:1A:7D:DA:71:10
version 6
manufacturer 10 class 0x1c0104
	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
	current settings: powered connectable discoverable bondable ssp br/edr le secure-conn
It is possible to check the Bluetooth version as mapped to the HCI version according to the table in the
official specification
. For example, in the previous output, HCI
version 6
is Bluetooth version 4.0.
More detailed information about the device can be retrieved by using the deprecated
hciconfig
. (
bluez-deprecated-tools
)
$ hciconfig -a hci0
hci0:   Type: USB
        BD Address: 00:1B:DC:0F:DB:40 ACL MTU: 310:10 SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:1226 acl:0 sco:0 events:27 errors:0
        TX bytes:351 acl:0 sco:0 commands:26 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'BlueZ (0)'
        Class: 0x000100
        Service Classes: Unspecified
        Device Class: Computer, Uncategorized
        HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver: 0xc5c
        Manufacturer: Cambridge Silicon Radio (10)
Audio devices start to skip at short distance from dongle
If other devices share the same USB host, they can
interrupt communication with audio devices
. Make sure it is the only device attached to its bus. For example:
$ lsusb
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 048d:1345 Integrated Technology Express, Inc. Multi Cardreader
Bus 001 Device 003: ID 0424:a700 Standard Microsystems Corp. 2 Port Hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
CSR dongle 0a12:0001
The device
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
has a regression bug, and currently only works in the kernel version 5.17 and < 6.0. For more information, see
Kernel Bug 60824
.
Logitech Bluetooth USB dongle
There are Logitech dongles (ex. Logitech MX5000) that can work in two modes: Embedded and HCI. In embedded mode dongle emulates a USB device so it seems to your PC that you are using a normal USB mouse/keyoard.
If you hold the little red Button on the USB BT mini-receiver it will enable the other mode. Hold the red button on the BT dongle and plug it into the computer, and after 3-5 seconds of holding the button, the Bluetooth icon will appear in the system tray.
Discussion
Alternatively, you can install the
bluez-hid2hci
package. When you connect your Logitech dongle it will automatically switch.
Foxconn / Hon Hai / Lite-On Broadcom device
Some of these devices require the firmware to be flashed into the device at boot.
Some firmware is available when searching for
broadcom
on the
AUR
, a notable package being
broadcom-bt-firmware
AUR
, which provides the files for
multiple cards
.
Alternatively, the firmware can be converted from a Microsoft Windows
.hex
file into a
.hcd
using
hex2hcd
(which is installed with
bluez-utils
).
In order to get the right
.hex
file, try searching the device vendor:product code obtained with
lsusb
, for example:
Bus 002 Device 004: ID
04ca:2006
Lite-On Technology Corp. Broadcom BCM43142A0 Bluetooth Device
or
Bus 004 Device 004: Id
0489:e031
Foxconn / Hon Hai
Alternatively, boot into Windows (a virtual machine installation will suffice) and get the firmware name from the Device Manager utility. If you want to know the model of your device but cannot see it in
lsusb
, you might see it in
lsusb -v
as
iProduct
.
The
.hex
file can be extracted from the downloaded Windows driver without having to run Windows for it. Download the right driver, for example
Bluetooth Widcomm
. Depending on the format, extracting the files might need
unrar
or
cabextract
. To find out which of the many
.hex
files is the right one for you, look in the file
Win32/bcbtums-win7x86-brcm.inf
and search for
[RAMUSB
E031
.CopyList]
, where
E031
should be replaced with the product code (the second hex number in
lsusb
) of your device in upper-case. Underneath you should see the file name of the right
.hex
file.
Once you have the
.hcd
file, copy it into
/lib/firmware/brcm/BCM.hcd
- this filename is suggested by
dmesg
and it may change in your case so check your
dmesg
output in order to verify. Then reload the
btusb
module:
# rmmod btusb
# modprobe btusb
The device should now be available. See
BBS#162688
for information on making these changes persistent.
Intel combined Wi-Fi and Bluetooth cards
See
Wireless network configuration#Bluetooth coexistence
.
Mediatek MT7921 or MT7961 on dual boot with windows
On dual boot systems, if Bluetooth firmware versions are different for Windows and Linux, the Bluetooth adapter is not working after rebooting to Windows.
The best way to prevent this is updating the Bluetooth drivers (especially firmware) with latest version for each OS.
If you cannot find the latest version driver (or firmware) for Windows, you can copy the latest firmware file
/usr/lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.xz
from Arch Linux and extract to Windows (e.g.
C:\WINDOWS\system32\DRIVERS\
, you can find the firmware file path in the device manager on Windows).
Adapter disappears after suspend/resume
First, find vendor and product ID of the adapter. For example:
$ lsusb -tv
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    ...
    |__ Port 3: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0025 Intel Corp.
    |__ Port 3: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0025 Intel Corp.
    ...
In this case, the vendor ID is 8087 and the product ID is 0025.
Then, use
usb_modeswitch
to reset the adapter:
# usb_modeswitch -R -v
vendor_ID
-p
product_ID
Pairing and connectivity issues
Computer is not visible
Enable discoverable mode if your computer cannot be discovered from your phone:
# bluetoothctl discoverable on
Verify that discoverable mode is on:
# bluetoothctl show
Powered: yes
	Discoverable: yes
	Pairable: yes
Note
Check
DiscoverableTimeout
and
PairableTimeout
in
/etc/bluetooth/main.conf
.
If the computer still does not show up, try changing the device class in
/etc/bluetooth/main.conf
as follows:
# Default device class. Only the major and minor device class bits are
# considered.
#Class = 0x000100 # Computer Type (from default config)
Class = 0x100100 # (Object-Transfer Service & Computer Type)
Note
In some cases,
Class
in
main.conf
gets overridden after device initialization, so set the class directly with
hciconfig hci0 class 100100
.
A user reported that this was the only solution to make their computer visible for their phone. LG TVs (and some others) are discoverable from their audio devices, so using
000414
(the soundbar class) will make such devices appear.
See
https://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html
to generate Bluetooth device/service classes.
Device connects, then disconnects after a few moments
A bug
introduced in BlueZ 5.83 (still present as of 5.86) causes a disconnection after an extraneous authentication attempt is made and fails. This bug appears to only affect devices with multipoint support
[4]
. A temporary workaround is to
restart
bluetooth.service
. On KDE Plasma, killing or disabling KDE Connect can stop the issue.
If you see messages like the following in the journal, and your device fails to connect or disconnects shortly after connecting:
bluetoothd: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)
bluetoothd: connect error: Connection refused (111)
This may be because you have already paired the device with another operating system using the same Bluetooth adapter (e.g., dual-booting).  Some devices cannot handle multiple pairings associated with the same MAC address (i.e., Bluetooth adapters). Follow instructions on
#Dual boot pairing
for solving this issue.
Device does not show up in scan
Some devices using Bluetooth low energy do not appear when scanning with bluetoothctl, for example the
Logitech MX Master
. You can use
transport le
to scan it.
# bluetoothctl
[bluetooth]# menu scan
[bluetooth]# transport le
[bluetooth]# back
[bluetooth]# scan on
[bluetooth]# devices
...
Device XX:XX:XX:XX:XX:XX DA V2 X <---- low energy device here
Another way to connect them is by installing
bluez-deprecated-tools
, then
start
bluetooth.service
and do:
# bluetoothctl
[NEW] Controller (MAC) myhostname [default]

[bluetooth]# power on
[CHG] Controller (MAC) Class: 0x0c010c
Changing power on succeeded
[CHG] Controller (MAC) Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller (MAC) Discovering: yes
In another terminal:
# hcitool lescan
Wait until your device shows up, then
Ctrl+c
hcitool. bluetoothctl should now see your device and pair normally.
No BLE device can be discovered with Intel Corp. AX200 Bluetooth
It seems that BLE passive scan is broken on this device. See
upstream bug report
for more details.
Cannot reconnect after sleep
You may notice that you cannot automatically reconnect to a device after it goes to sleep, or after the computer wakes from suspend.
You would for example notice the following errors in your logs:
bluetoothd[487]: Authentication attempt without agent
bluetoothd[487]: Access denied: org.bluez.Error.Rejected
This could be because the device is not marked as
trusted
. See
#Pairing
.
Device-specific issues
Bluetooth mouse lags / disconnect / does not respond
See
Bluetooth mouse#Troubleshooting
.
Audio device fails to connect with br-connection-profile-unavailable
A Bluetooth audio device will fail to connect if pipewire (rather than pulseaudio-bluetooth) is being used, but an instance of pipewire is not running.
Start
the
pipewire.service
user unit
or play some audio to start the pipewire daemon, then try to connect the audio device again.
Interference between headphones and mouse
If you experience audio stuttering while using a Bluetooth mouse and keyboard simultaneously, you can try the following as referenced in #23
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/424215
# hciconfig hci0 lm ACCEPT,MASTER
# hciconfig hci0 lp HOLD,SNIFF,PARK
Continually connect/disconnect with TP-LINK UB400 and Xbox controller
Use the settings below:
/etc/bluetooth/main.conf
...
[General]
JustWorksRepairing = always
FastConnectable = true
Class = 0x000100
...
[GATT]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true
...
Then
restart
the
bluetooth.service
.
You can see relevant
discussion on xpadneo
but the xpadneo driver is not needed.
File transfer issues
gnome-bluetooth
If you see this when trying to enable receiving files in bluetooth-properties:
Bluetooth OBEX start failed: Invalid path
Bluetooth FTP start failed: Invalid path
Then make sure that the
XDG user directories
exist.
Cannot receive transferred files due to symlink
If incoming file transfers fail on an an otherwise functional Bluetooth connection, the problem may be due to symlinks in your file transfer path.  Logs like this would appear in the journal:
Jun 18 11:18:13 ember obexd[3338969]: open(/home/me/.cache/obexd/MOC740): Operation not permitted (1)
If the path shown in the error message contains a symlink, then obexd by default
will not accept it
. The behavior can be overridden on initialization using a
drop-in file
for the
obex.service
user service
:
~/.config/systemd/user/obex.service.d/10-symlink.conf
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd --symlinks
Then
reload
the
systemd
manager configuration of the calling user and
restart
the
obex.service
user unit.
See also
Keeping Bluetooth devices paired between Linux and Windows
Bluetooth link keys on dual-boot systems