Continue to Get Message Your Pc Needs to Be Restarted to Finish Setting Up Intel Wireless Bluetooth

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. Alternatively install bluez-utils-compat ^AUR to additionally have the deprecated BlueZ tools.
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:

By default the Bluetooth daemon will only give out bnep0 devices to users that are a member of the lp group. Make sure to add your user to that group if you intend to connect to a Bluetooth tether. You can change the group that is required in the file /usr/share/dbus-1/system.d/bluetooth.conf.
Some Bluetooth adapters are bundled with a Wi-Fi card (e.g. Intel Centrino). 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 bluez-utils-compat ^AUR. See FS#53110 and the Bluez mailing list for more information.

Front-ends

Console

bluetoothctl — Pairing a device from the shell is one of the simplest and most reliable options.

http://www.bluez.org/ || bluez-utils

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

Tip: To automate bluetoothctl commands, use echo -e "command1\ncommand2\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 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).

https://wiki.gnome.org/Projects/GnomeBluetooth ||

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

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

Pairing

Note: Before using the Bluetooth device, make sure that it is not blocked by rfkill.

This section describes directly configuring bluez5 via the bluetoothctl CLI, 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

To pair devices on dual boot setups you need to change the pairing keys on your Linux install so that they are consistent with what Windows or macOS is using.

This page only describes the manual method of doing so. To automate the process, see the bt-dualboot project and the related repositories.

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 Logitech devices, such as the MX Master 3, increment the MAC address by one 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

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 PsExe64.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 key is a key for each Bluetooth adapter, by MAC address. If there are multiple keys, and you are unsure of which to use, follow this guide to find the MAC address for the desired Bluetooth adapter.

Within the desired device adapter key, there is a binary value for each paired device, by MAC address in the same way.

For each paired device that you wish to share between the installations, right click on the whole key and export it as a .reg file. This is a text file that you can copy the keys from.

Within this file, if there is a single binary key, then this is not a Bluetooth 5.1 device, and that paring key is all that is needed.

Otherwise, if there are several keys for the paired device such as LTK or IRK, then this is a BT5.1 device. Refer to #Preparing Bluetooth 5.1 Keys to see how to use them.

Finally, to import the key(s) into your Linux installation, reboot into Linux and proceed to #Finishing up.

Note: If your Windows partition is encrypted with Bitlocker, you will not be able to access it from Linux using chntpw.

Reboot into Arch. Install chntpw. Mount your windows system drive.

$ cd          /path/to/windows/system/Windows/System32/config $ chntpw -e SYSTEM

Note: Instead of CurrentControlSet you may see ControlSet00X, where X is any number. Check using the ls command.

Inside the chntpw environment, run

> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys

> cd ControlSet00X\Services\BTHPORT\Parameters\Keys

Then get your Bluetooth adapter's MAC address and enter its folder

> ls > cd          your-device's-mac-address

Do the same for your paired devices. 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 <123456789876>

If so, get your device's key through hex:

> hex 123456789876

: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 #Finishing up.

For macOS

Boot into macOS. Then:

For macOS Monterey or newer:
1. Open Keychain Access and search for Bluetooth.
2. Sort by date.
3. 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+).
4. Double click on the entry. Check that the MAC address in the Account field matches the MAC address of your device.
5. Click the "Show password" checkbox. You will now need to enter your password, twice.
6. Copy the text in the password field, it's actually an XML file (⌘+A, ⌘+C)
7. 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}" >>> Key=list(reversed(ERand.strip().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 #Finishing up.

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)

The Bluetooth 5.1 keys and parameters that were extracted have to be mapped to their Linux equivalents. Create the requested files with their appropriate contents, for installation in #Finishing up. 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 Master 3	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`.	–
ThinkPad TrackPoint Keyboard II and Pebble M350 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 hex. Reverse the order of the octets.	`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 hex. Reverse the order of the octets.	`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`

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('<H', 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.

Finishing up

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 Bluetooth 5.1 keys, then you must instead copy the key files to the MAC address directory.

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 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.

Find the vendor code and device ID for the Bluetooth adapter.

$ lsusb | grep bluetooth -i

Bus 001 Device 002: ID 8087:0039 Intel Corp. AX200 Bluetooth

Add a new udev rule for the vendor code and device ID to enable wake from suspend.

/etc/udev/rules.d/91-keyboard-mouse-wakeup.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/../power/wakeup;'"

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

SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" 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. 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 you should immediately be able to stream audio from a Bluetooth device to your speakers.

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-utils-compat ^AUR, 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)

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-utils-compat ^AUR package provides an alternative version of bluez-utils with the deprecated tools.

Deprecated tool	Most likely replacement
gatttool	btgatt-client, D-Bus Gatt API
hciattach	btattach
hciconfig	btmgmt (and bluetoothctl?)
hcidump	btmon (and btsnoop)
hcitool	missing, D-Bus Device API available
rfcomm	missing, implement with D-Bus Profile1 API?
ciptool	missing, implement with D-Bus Profile1 API?
sdptool	missing, functionality seems to be scattered over different D-Bus objects: Profile, Advertising, and the UUIDs arrays in device and adapter.

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.

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

# 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-utils-compat ^AUR)

$ 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 ≤ 3.9.11. There is a patch available for newer versions. 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.

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

There is a bug with some motherboard bluetooth controllers. To see if this might be the issue, run journalctl | grep hci. If there are entries like "command tx timeout" or "Reading Intel version command failed", then power off your pc and physically unplug the power cable for a few seconds. This forces the controller to reload the firmware (while a standard reboot will not). See bug report here.

Make sure the device is not being blocked by rfkill.

It might also happen with some intel cards (such as the 8260) to not be picked up correctly by the Bluetooth service. In some cases, using the deprecated bluez-utils-compat ^AUR in lieu of bluez-utils have reportedly fixed the issue.

This might also be caused by power saving measures, in which case adding the kernel parameter btusb.enable_autosuspend=n is a potential solution. See also Red Hat Bugzilla – Bug 1573562.

Sometimes unloading and loading btusb without options helps to get the controller back:

# modprobe -r btusb # modprobe btusb

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, but there is 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.

rfkill unblock: Do not unblock

If your device still soft blocked and you run ConnMan, try this:

$ connmanctl enable bluetooth

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.

Foxconn / Hon Hai / Lite-On Broadcom device

Some of these devices require the firmware to be flashed into the device at boot. The firmware is not provided but can 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 ...

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 (listed among the drivers for Lifebook P771^{[dead link 2022-09-17 ⓘ]}), which contains the drivers for many Broadcomm devices. In case of Bluetooth Widcomm, the driver is a self-extracting RAR archive, so it can be extracted using unrar x. 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 [RAMUSBE031.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 WiFi and Bluetooth cards

See Wireless network configuration#Bluetooth coexistence.

Device connects, then disconnects after a few moments

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. The simplest way I have found to connect them is by installing bluez-utils-compat ^AUR, 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.

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.

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

Bluetooth mouse laggy movements

Try to edit the file /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/YY:YY:YY:YY:YY:YY/info (XX:XX:XX:XX:XX:XX - your Bluetooth adapter MAC address, YY:YY:YY:YY:YY:YY - your mouse MAC address) and add these lines:

[ConnectionParameters] MinInterval=6 MaxInterval=9 Latency=44 Timeout=216

You can see your local adapter MAC address by running the command hcitool dev. You can see the MAC addresses of currently connected remote devices by running the command hcitool con.

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

Problems with all BLE devices on kernel 5.9+

Starting with v5.9, the kernel Bluetooth stack tries to use link-layer privacy on BLE connections. If the device works after pairing but does not survive a reboot or suspend, it is probably because of this.

To workaround [3] this issue, open /var/lib/bluetooth/adapter_mac/device_mac/info, remove the following lines, and restart bluetooth.service:

[IdentityResolvingKey] Key=...

See the relevant discussion on the Arch forum.

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.

Continually connect/disconnect with tp-link UB400 and xbox controller

Edit /etc/bluetooth/main.conf and set below settings (uncomment/change value):

[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.