Bluetooth

The following packages allow for a graphical interface to customize Bluetooth.

• Blueman — A full featured Bluetooth manager.

https://github.com/blueman-project/blueman || blueman

To pair devices on dual boot setups you need to change the pairing keys manually on your Linux install, so that they match in both systems.

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.

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

Download PsTools, and extract .

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.

If there are LTK, , and values present, this is a Bluetooth 5.1 device, and these too must be saved.

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

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

Inside the environment, run

> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys

or

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

Now get your device's key through :

The "XX"s are the pairing key. Make note of which keys map to which MAC addresses.

In a BT5.1 Mouse, you might see this output:

Of these values, you must save LTK, , and .

If there were LTK, , and values in the registry for the desired device, they must be converted for use with Linux. LTK corrsponds to , to Rand, to . The value shound be reversed and converted to decimal. For example:

• An LTK of makes for a of .
• An of makes for a Rand of .
• An of 37520 makes for an of 37520.

Boot into macOS, then open a terminal.

• If you are on Sierra or older, run

• If you are on High Sierra or newer, run

For older versions of macOS (High Sierra and older) you will have to reverse the keys. For example, becomes MM LL KK JJ GG FF EE DD CC BB AA 2F 54 98.

Copy the file to a drive that can be read from Arch Linux. Reboot into Arch Linux.

Now that you have the keys change user to root, then continue with:

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:

Edit the file and change the key under . E.g.:

Then restart and (with ).

You should be able to connect to your device now.

By default, the Bluetooth adapter does not power on after a reboot or resuming from suspend. If you would like the adapter to be powered on after reboot or resume, set in /etc/bluetooth/main.conf in the section:

If the device should always be visible and directly connectable:

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

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

In order to be able to use audio equipment like Bluetooth headphones or speakers, you need to install the additional 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 ) is in the group and you load the Bluetooth modules in your PulseAudio config:

Optionally, add if you want to auto-switch all audio to the Bluetooth device.

PipeWire as of v0.3.19 enables its Bluetooth support by default.

First, ensure that your Bluetooth audio device is correctly paired and connected to the system.

Then, install , start (and enable) the bluealsa service, and add your user to the group.

Run the following command to check if everything is working as intended (replace and 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:

You can now use the bluealsa device to reach your Bluetooth audio device. Volume management is conducted normally via with the option .

In order to debug, first stop .

And then start it with the -d parameter:

# /usr/lib/bluetooth/bluetoothd -n -d

Another option is via the tool.

Eight BlueZ tools were deprecated and removed from bluez-utils, although not all of them were superseded by newer tools. The package provides an alternative version of bluez-utils with the deprecated tools.

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.

If you are using a USB dongle, you should check that your Bluetooth dongle is recognized. You can do that by running as root when you have plugged in the USB dongle (or inspecting ). It should look something like the following (look out for hci):

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

Or

# bluetoothctl

[bluetooth]# show

Controller 00:1A:7D:DA:71:10 (public)
	Name: Mozart
	Alias: Mozart
	Class: 0x0000095c
	'''Powered: no'''
	Discoverable: yes
	Pairable: yes

To verify that the device was detected you can use which is part of the bluez-utils. You can get a list of available devices and their identifiers and their MAC address by issuing:

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

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:

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

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 package. When you connect your Logitech dongle it will automatically switch.

• On some laptops (e.g. Dell Studio 15, Lenovo Thinkpad X1) you have to switch the Bluetooth mode from HID to HCI. Install the 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

This error may happen if the device is 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 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 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

bluetooth.service only requires the directory to exist, which should be created by kernel module bluetooth, which is only autoloaded by if it actually finds a working Bluetooth hardware device.

If your does not exist, check if your kernel Bluetooth module is loaded by . 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 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 when you scan on). If this happens, try rebooting your computer, and double-check: whether directory exists; whether includes correct Bluetooth modules; log messages in the journal; etc. should pickup your Bluetooth hardware automatically without manual changes again.

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

$ connmanctl enable bluetooth

Enable discoverable mode if your computer cannot be discovered from your phone:

# bluetoothctl discoverable on

Verify that discoverable mode is on:

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)

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

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

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 (listed among the drivers for Lifebook P771), 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 x. To find out which of the many .hex files is the right one for you, look in the file and search for , where 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 - 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.

See Wireless network configuration#Bluetooth coexistence.

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.

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:

In another terminal:

# hcitool lescan

Wait until your device shows up, then hcitool. bluetoothctl should now see your device and pair normally.

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:

Then reload the systemd manager configuration of the calling user and restart the obex.service user unit.

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

Try to edit the file ( - your Bluetooth adapter MAC address, - 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 . You can see the MAC addresses of currently connected remote devices by running the command hcitool con.

First, find vendor and product ID of the adapter. For example:

In this case, the vendor ID is 8087 and the product ID is 0025.

Then, use to reset the adapter:

# usb_modeswitch -R -v vendor_ID -p product_ID

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 this issue, open , remove the following lines, and restart bluetooth.service:

See the relevant discussion on the Arch forum.

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.

The Bluez stack keeps new, potentially buggy features behind the Experimental option. The functionality included under this by this vary over time, as experimental features are determined to be stable and no longer require the option. To enable this, uncomment the relevant line in the configuration:

/etc/bluetooth/main.conf

# Enables experimental features and interfaces.
# Defaults to false.
Experimental = true