Talk:Bluetooth

From ArchWiki

What is agent?

Article should explain what is agent and when it should be on. Is it for asking PIN code? When or why we should off if? -- Agent0 (talk) 18:13, 21 December 2014 (UTC)

I stumbled upon the same omission - while I did succeed to follow the CLI-based installation instructions, I still don't know "What is that 'agent', and what is it good for?"
Also, the messages from the software regarding the "controller" disconnecting where somewhat irritating - but since everything works fine I guess that is just a strange way of logging some software interface activity. --Lvml (talk) 16:22, 18 March 2017 (UTC)

Deprecation of hciconfig and hcitool

Since hciconfig was deprecated upstream, we should replace all references to it with proper non-deprecated commands. --Ape (talk) 05:45, 8 March 2017 (UTC)

Feel free to go ahead. Until then see the note in Bluetooth#Installation. -- Lahwaacz (talk) 07:54, 8 March 2017 (UTC)
I just ran into issues because of that as well, so I totally agree with that. Unfortunately, I can't find the time in doing that myself. --LukeLR (talk) 23:32, 30 April 2017 (UTC)
I just used bluetoothctl for Bluetooth#Device does not show up in scan instead of hcitool. Commands were bluetoothctl, menu scan, bluetooth, clear, transport le, duplicated-data on, back, scan on. --Dramm (talk) 15:05, 22 December 2020 (UTC)

DualBoot bluetooth

This seems to be the same problem: https://communities.intel.com/thread/112230 They use the same workaround as I proposed

—This unsigned comment is by Roflmao (talk) 21:11, 8 June 2017‎. Please sign your posts with ~~~~!


Copy Paired devices from Windows is explained here: [1] This prevents the constant re-pairing of devices.

Should this info be included in the DualBoot Section?

Remggo (talk) 19:21, 17 November 2017 (UTC)

I do such thing when I install OS again. One wired thing is that every time my Mouse and KeyBoard's address is dirrerent. Such as pair on linux Mouse'address is c2c8fb0db342. when paired on win, the address little diff from that. Is this ok? I change the EDiv, ERand,LTK and the address, work fine for a whole year. Kearney (talk) 02:53, 26 January 2022 (UTC)

It is ok. I use that for few months. Finally I use usb instead of bluetooth to give more band to wifi(My keyboard has two ways to connect)Kearney (talk)

Merging general setup from Keyboard, Mouse, Headset pages

Bluetooth_mouse, Bluetooth_keyboard, and Bluetooth_headset all contain duplicate info about general bluez5 installation, pairing, connections, and troubleshooting. I'd like to merge all the general info into this Bluetooth page. Then the [mouse|keyboard|headset] pages can expand on any device-specific setup/troubleshooting, which seems to be the original intent. Any objections? Thesqueakychair (talk) 17:05, 14 April 2018 (UTC)

This sounds very good and should make the whole topic much clearer. Remggo (talk) 09:49, 16 April 2018 (UTC)

Adapters article

Should we start a Bluetooth adapters page listing USB Bluetooth adapters confirmed to work with Linux?

We could add a note to the Bluetooth intro asking readers to contribute to it.

Existing resources:

--Larivact (talk) 04:56, 29 August 2018 (UTC)

I'm very sceptical about the purpose of such lists, see also [2]. Basically if you're trying to find out if some device will work or not, it is almost certain that you'll find either that it works absolutely fine (which can be assumed if you hadn't found anything) or that it had some problems with an older version of something (which doesn't answer your question). -- Lahwaacz (talk) 07:38, 29 August 2018 (UTC)
I'd rather buy something known to work than something known not to work. If you want to minimize the chance of the latter, experiences of others are not "completely irrelevant".--Larivact (talk) 08:21, 29 August 2018 (UTC)
Another source for working adapters is Gentoo's Bluetooth headset wiki. It addition to "working" "not working" it shows which components of a Bluetooth headset are working with a Bluez version and notes columns. — Neurognostic (talk) 03:19, 1 March 2020 (UTC)

Bluetooth.conf moved

Since Bluez 5.50-5 the permission configuration file "bluetooth.conf" was moved from /etc/dbus-1/system.d to /usr/share/dbus-1/system.d

—This unsigned comment is by Sangeppato (talk) 10:03, 14 January 2019‎. Please sign your posts with ~~~~!

Broadcom firmware

I was struggling with my broadcom Bluetooth device until I found this https://github.com/winterheart/broadcom-bt-firmware . And no one in wiki ever told me that there is an easy fix. Can I add it to this article? —This unsigned comment is by Forcharc (talk) 03:31, 5 December 2019 (UTC). Please sign your posts with ~~~~!

I don't see why not. You might want to link the broadcom-bt-firmware-gitAUR package instead of the GitHub repo though. -- nl6720 (talk) 09:44, 5 December 2019 (UTC)

Troubleshooting: Low Volume on Bluetooth Headphones

On several devices (like Apple AirPods, Sony LE_WH-1000XM3 headphones and other earbuds) the volume will be sticky to last volume setting used in a previous - usually Android/iOS - device.

This happens because the hardware does not provide means to control the headphones hardware volume level. The headset keeps last volume set by the iOS/Android device and result in a very confusing behaviour with PulseAudio - as the last set headphone volume level now dictates the available volume range.

As there are 2 different volumes for most bluetooth headsets: The software volume and the hardware volume. Traditionally on Linux you only control the software, however headsets can have an additional internal hardware volume, which is not possible to control currently.

Workaround solution: Reconnect bluetooth device to an Android/iOS device and reset the bluetooth volume.

Bug reports: Pulseaudio #724.

SuperHeroINTJ (talk) 12:27, 21 October 2020 (UTC)

Pulseaudio output lag

It might be worth mentioning common issues and workarounds like this for PulseAudio output lag.

L0b0 (talk) 21:18, 12 March 2021 (UTC)

Debugging controller input lag

I'm using a keyboard, mouse and X-Box controller over Bluetooth. Only the X-Box controller is having any appreciable input lag, but that's up in the several hundred milliseconds range, making it unusable for gaming. I've seen hcitool and l2ping recommended for debugging such issues, but it looks like at least hcitool is deprecated and l2ping isn't available at all from a quick web search. What are the current tools to achieve the same thing?

L0b0 (talk) 21:18, 12 March 2021 (UTC)

Bluetooth 5.1 Devices

I got my Logitech MX Master 3 working with a duel boot but not exactly as described in this wiki. I would like to contribute my findings but I am new to Arch and don't know what to do with this information so I hope it's correct to dump it here for discussion.

Each time you pair the MX master 3, the MAC address with increment, so pairing in Linux will give you say ...:2A, then when you pair in Windows it will increment and be then be ...:2B. When returning to Linux you have to move the folder /var/lib/bluetooth/<BT-Adapter-MAC-address>/<MAC address> to the new ID. Next, there is no [LinkKey] section generated for this device. To make it work LTK must go into SlaveLongTermKey.Key and IRK must go into IdentityResolvingKey.Key. Rand and EDiv are both 0 and don't need to be edited.

KuleRucket (talk) 06:42, 22 September 2021 (UTC)

Can confirm Logitech M350 Mouse and K580 Keyboard have the same behavior, each pairing attempt will increase the Mac Address by one. Wizeu (talk) 02:59, 23 July 2022 (UTC)
Added. I am under the impression that the incrementing is an implementation detail of Logitech's. As for the LTK/IRK issue, I think that has to do with Bluetooth 5.1. I have assumed that BT5.1 devices do not have a traditional pairing key, but rather just the more complex set of keys. We can keep this open until the 5.1 key situation is clarified, as this info does directly conflict with the current instructions on how to handle BT5.1. Thanks, CodingKoopa (talk) 02:42, 24 July 2022 (UTC)
When it comes to delineating the behavior of different BT >=5.1 devices, I think the answers I seek might lie within the Bluetooth specification. I am told the BT spec is a terrible, convoluted spec that is turtles all the way down, but c'est la vie. I might also ask the bluez folk, but they don't seem to be very active on IRC. -- CodingKoopa (talk) 05:33, 9 August 2022 (UTC)
There may be useful information in the bt-dualboot repository. -- CodingKoopa (talk) 04:08, 22 September 2022 (UTC)
I just did the pairing of Pebble M350. I found that not just ERand, but the octets of EDiv and IRK are in reverse order between Windows and Linux. Nevertheless, one can simply copy the decimal value of ERand and EDiv. They're in order. But IRK has to be reserved by hand. Rand and EDiv are not 0 either. One should follow the existing information. I think we should update this piece of information. Archerindigo (talk) 17:14, 15 August 2022 (UTC)
Oh dear. I have applied a quick fix, but I have a feeling that this section could get very complicated. Maybe we'll need a big table.
It seems to conflict that ERand and EDiv are "in reverse order" but also can be simply converted to decimal as-is, unless it really is the case that it works either way. Please do make any necessary changes if I got it wrong. Thanks, CodingKoopa (talk) 04:58, 16 August 2022 (UTC)
Just found that the Lenovo ThinkPad TrackPoint Keyboard II has the same behavior: it uses a different MAC address on Linux and macOS when dual-booting. In MacOS I saw that the address was "Random" - perhaps that's why it differs? --Ayke (talk) 12:11, 12 October 2022 (UTC)

I managed to get a Bluetooth device to work between macOS and Linux. I did it as follows:

  1. Copy bt_keys.txt as described in the wiki.
  2. Copy the Remote IRK field, convert it from base64 to hex, and replace the IdentityResolvingKey.Key field on Linux.
  3. Copy the "Long-term Key" (under "Remote Encryption"), convert it from base64 to hex, and replace the LongTermKey.Key field.
  4. Copy "Encrypted Diversifier" (under "Remote Encryption"), convert it from base64 to a little endian number, and replace the LongTermKey.EDiv field.
  5. Copy "Random Number" (under "Remote Encryption"), convert it from base64 to a little endian number, and replace the LongTermKey.Rand field.

Converting from base64 to hex in Python:

binascii.hexlify(base64.decodebytes(b'...')).upper()

Converting the Encrypted Diversifier in Python:

struct.unpack('<H', base64.decodebytes(b'...'))

Converting the Random Number in Python:

struct.unpack('<Q', base64.decodebytes(b'...'))

I hope this helps! I'm not sure how this can be best added to the wiki, feel free to use the text above.

--Ayke (talk) 13:12, 12 October 2022 (UTC)

This is perfect, thank you! I resolved the BT5.1 flag, and created the big table that I have been wanting to make. It's long and perhaps hard to follow, but I see this as progress. Thanks, CodingKoopa (talk) 21:29, 16 October 2022 (UTC)
Just paired my Logitech G604 Lightspeed, I tried all 3 methods but only the one for the M350 pebble worked. It also increments the MAC address by one. Also, is there some list behaviors of devices somewhere? -- Technical restrictions (talk) 21:04, 7 December 2022 (UTC)
Cool, thanks! I'm not sure what you mean by list of behaviors; the table at Bluetooth#Preparing Bluetooth 5.1 Keys is our attempt to aggregate behavior in one place. -- CodingKoopa (talk) 00:56, 19 December 2022 (UTC)

I would like to add some important information on how to set up 5.1 bluetooth. Some things I don't think is properly explained as well. Your MAC address for the bluetooth unit is actually its own directory in the registry editor, it's HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\<MAC of bluetooth adapter>\<MAC of Bluetooth device> and you can easily add an entry to /var/lib/bluetooth by just making a directory with the proper MAC-address there being the same as the registry file you're getting from Windows. If you have multiple channels on your device this is very easy but if you don't then you the easiest way would be to first pair in Linux in order to make a skeleton configuration, then pair it in Windows, then you use the information in Windows to set up your bluetooth device with the skeleton configuration you created when you first paired in Linux, if the MAC-address is different, then change your Linux MAC address to the one used in Windows. The most important file here is the info file and you can add all the keys and such you need to that. For the LG M720 Triathlon I for instance had to add an IdentityResolvingKey, LocalSignatureKey in addition to the LongTermKeys containing Rand and Ediv as documented here. That's 5 keys! But with the LG MX Keys Wireless keyboard I had I add 4 keys, IRK, LTK, Rand and Ediv. All the keys are in the registry file but they're shortened! CSRK denotes the LocalSignatureKey and IRK denotes the IdentityResolvingKey. I think this information might be interesting for the documentation here. Kent lang (talk) 14:23, 8 January 2023 (UTC)

It's a little hard to follow your propositions in one large paragraph, but this is my understanding:
  • Your MAC address for the bluetooth unit is actually its own directory in the registry editor':
I think this was mostly reflected in the page, but had a typo in the terminology. I tried fixing it with Special:Diff/761726.
  • you can easily add an entry to /var/lib/bluetooth by just making a directory with the proper MAC-address there being the same as the registry file you're getting from Windows
I guess this would work, but as you point out later, it's easier to have Linux create the structure by pairing it first. This is precisely what Bluetooth#Setup already recommends, if I understand correctly.
  • if the MAC-address is different, then change your Linux MAC address to the one used in Window
This is noted in Bluetooth#Setup, and accounted for in Bluetooth#Finishing up.
  • For the LG M720 Triathlon I for instance had to add an IdentityResolvingKey, LocalSignatureKey in addition to the LongTermKeys containing Rand and Ediv as documented here
This sounds like it should be added as a new row to the table; I am not aware of the other devices using CSRK/LocalSignatureKey.
  • with the LG MX Keys Wireless keyboard I had I add 4 keys, IRK, LTK, Rand and Ediv. All the keys are in the registry file but they're shortened!
What does "shortened" mean here? So, the device diverges from say, how the Pebble M350 mouse uses those same four keys?
Let me know if there's anything that I missed. Thanks, CodingKoopa (talk) 03:07, 9 January 2023 (UTC)
I apologize for my poor formatting, I'm not at all familiar with the syntax of the wiki yet.
  • Let me explain again what I did in order to clarify: The devices I use have 3 bluetooth channels I can switch between on the device, 1 which was paired with Linux already, 1 which was paired with Windows. I made a directory for the same device mac address as Windows used and then copied over the info file I had previously from my 1st channel which was already paired with Linux. I reformatted the erand and ediv keys as explained in the section, added all 5 key values to the info file where applicable and I only really needed a properly configured info file here. In my case no other files were necessary.
  • Now I think it's important to note that pairing the device to Linux from the start isn't actually a mandatory step, but an optional step! If this isn't clarified that it's optional, then you might be lead to believe that you mess up the process by not pairing it to Linux beforehand. That is at least what I felt the authors of this article was trying to tell me. Especially with the note on the page of some devices incrementing the mac address.
  • Now I could be very wrong here but my guess is that a device shouldn't increment the mac address indefinitely. It might do so a couple of times because it wants to be able to connect to many different receivers and to do so it needs an unique mac address for each one but it should only do so as many times as the amount of receivers the device supports. Ideally it should loop back to a previous mac address eventually and if it does then it should be checking all its linked mac addresses for linked receivers. I think I remember with my Jabra Elite Active 75t had such a functionality and it could pair to about 3 bluetooth adapters, but I haven't verified if this is actually true. The important part here (and I think once again, this is important to clarify) is that the MAC address which Windows and Linux looks for just needs to be the same, regardless if the device has incremented the address or not. If it's true then that you can just add the key files to the MAC address directory then it's best to skip the step of pairing it to Linux entirely and create the directory manually and place the files inside there, then you don't need to worry about incremented mac addresses either.
  • Correct me if I'm wrong but specific instructions on the IRK and CSRK key values seems to be missing! This specific section only really talks about the LTK, ERand and EDIV key values and the reader is told to convert these key values to files and then place them in the directory of the MAC-address and this didn't work for me. I don't know if it's because I was missing the IRK and CSRK files when I tried this or if this method actually works. If it does, then you really don't need anything from a previous pairing with Linux. I think it might be a good idea to try to explain how to do this with the info file instead since that was the method which worked for me.
  • About my comment about them being shortened; I'm talking about how these keys in the info file are denoted as being abbreviations of the longer names found in the info file. Both of these keys are presented as hexadecimal values of the same length as the LTK file. You only need to simply remove the commas in the registry file between the octets and converting the lower case letters to upper case. Only the M720 Trialthon needed the CRSK key value, the MX Keys Wireless Keyboard didn't need it. Both devices needed the IRK value in addition to the LTK, ERand and EDIV. Kent lang (talk) 05:00, 9 January 2023 (UTC)
  • I apologize for my poor formatting, I'm not at all familiar with the syntax of the wiki yet.
No problem, this reply is already a lot better :)
  • The devices I use have 3 bluetooth channels I can switch between on the device
Ah! Yes, my MX Ergo can do that; I know what you are talking about.
  • If this isn't clarified that it's optional, then you might be lead to believe that you mess up the process by not pairing it to Linux beforehand.
Yeah I think this is correct. If you don't sync it on Linux beforehand, I'm sure you can create the directory structure yourself, it's just a little bit more annoying (though if your device is changing its MAC address then the convenience is even smaller). It's not a big enough deal that I am going to bother putting that nuance in the page, since you would need to accurately describe how to create the files yourself, but it would be correct.
  • If it's true then that you can just add the key files to the MAC address directory then it's best to skip the step of pairing it to Linux entirely and create the directory manually and place the files inside there, then you don't need to worry about incremented mac addresses either.
Yep, sounds right. My previous commentary applies: since we still need to cover the most general cases, "optimizing" specific cases would complicate the page, I think. This is not an outright objection, but I think that this would best be relegated to a "well, actually" note when we tell you to pair on Linux first.
  • Correct me if I'm wrong but specific instructions on the IRK and CSRK key values seems to be missing!
They are! That's why I couldn't add them myself, since I don't know what transformations they need for Linux.
  • I think it might be a good idea to try to explain how to do this with the info file instead since that was the method which worked for me.
Ah, this is interesting! So, you simply add all of the Bluetooth 5.1 keys to the info file, instead of having them be their own files with the transformations? I definitely missed that the first read-through ;)
This has the potential to greatly simplify the page if this can be generalized. Potentially, it seems like the whole base64-hex conversion for, say, LTK, can be eliminated if you go the route of inputting your keys into info.
Thanks, CodingKoopa (talk) 00:46, 10 January 2023 (UTC)
  • Ah, this is interesting! So, you simply add all of the Bluetooth 5.1 keys to the info file, instead of having them be their own files with the transformations?
Yes, that's how I did it. I still did the hex to decimal transformation for the EDIV, and the reverse hex transformation for the ERand value. I don't think there's any way around converting those and that's because the info file I grabbed from another channel on my mouse had them as decimal values as well. When I did it; none of the LTK, IRK or CSRK needs to have any special transformations, only basic ones like removing spaces and commas and then converting to upper case. I've done this operation with both my mouse and keyboard successfully twice now so I'm confident that it works. What I think would be a valuable thing to test is what values in the info file which can be omitted. If we can set up a basic setup with only the keys and connect it, with the bluetooth daemon filling in the blanks we would make the process much easier, perhaps even possible to automate with a script. I'm going to test with some other BT devices I have and report back with my findings. Kent lang (talk) 07:21, 10 January 2023 (UTC)
Ah okay, so they do need the same transformations. Then, I'm not going to prioritize doing any edits myself; however, a couple of valid actions to take would be:
  • Consulting with the bluez developers to see what the deal is with these two methods for reading BT5.1 keys (maybe one of them is better? maybe there's a reason why our documented method didn't seem to work for you?).
  • Removing any keys from the steps that are proven to be optional (e.g. the Bluetooth stack can generate them itself, as you hypothesize is the case sometimes).
-- CodingKoopa (talk) 22:25, 10 January 2023 (UTC)
I just tested this with a Xbox wireless controller as well. This time the info file which was generated had a EDIV and ERand value of 0 and it looks to be the same in Windows. However the info file was generated with a [PeripheralLongTermKey] and a [SlaveLongTermKey] section when paired with Linux, but there were only a simple [LTK] value in the Windows registry file! I decided to remove the commas and convert into upper case and then paste it into the [SlaveLongTermKey] section and it looks like it works as well. This device also had a [IRK] key. Kent lang (talk) 08:55, 10 January 2023 (UTC)

Script for dumping the Bluetooth keys from Windows

I haven't tested this properly yet, thus I feel not comfortable for putting this in the wiki page yet. But feel free to try and let me know in the comments if it worked for you!

https://gist.github.com/h3x4d3c1m4l/884dba007da8d04caf5e8760e43560aa

H3x4d3c1m4l (talk) 20:32, 16 November 2021 (UTC)