Bug 209745 - Bluetooth connection to Logitech MX Master 2S lost after each reboot
Summary: Bluetooth connection to Logitech MX Master 2S lost after each reboot
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Bluetooth (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: linux-bluetooth@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-19 12:00 UTC by mskmsk
Modified: 2022-10-17 02:36 UTC (History)
25 users (show)

See Also:
Kernel Version: 5.9.1
Tree: Mainline
Regression: No


Attachments

Description mskmsk 2020-10-19 12:00:21 UTC
Bluetooth connection to Logitech mouse lost after upgrading to kernel 5.9.1.
I have to remove the paired mouse and re-pair it every time I login to make it work.


Laptop:    ThinkPad T14 Gen 1
CPU:       AMD Ryzen 7 PRO 4750U with Radeon Graphics (16) @ 1.700GHz
Network:   Intel Corporation Wi-Fi 6 AX200 (rev 1a)
Kernel:    Linux 5.9.1-arch1-1
Comment 1 labaunti3 2020-10-19 13:44:27 UTC
I can confirm this with a Logitech MX Anywhere 2S. Same symptoms, same solution.

Laptop:    XPS 15 9570
CPU:       Intel Core i7 8750H
Network:   Intel Corporation Wireless-AC 9260 (rev 29)
Kernel:    Linux 5.9.1-arch1-1
Comment 2 Ales Kounovsky 2020-10-19 15:18:19 UTC
The very same issue first appeared in 5.9.0 for me, still present in 5.9.1. tested with Logitech MX Master 2 and Logitech MX Master 3.

Laptop:    ThinkPad T14 Gen 1
CPU:       AMD Ryzen 7 PRO 4750U with Radeon Graphics (16) @ 1.700GHz
Network:   Intel Corporation Wi-Fi 6 AX200 (rev 1a)
Kernel:    Linux 5.9.1-arch1-1
Comment 3 hexchain 2020-10-19 22:39:46 UTC
Same problem for me after 5.9.0, with a Logitech MX Anywhere 2S.

Someone on the Arch forum finds out that disabling link-layer privacy can be a workaround, and I can confirm it also works for me: https://bbs.archlinux.org/viewtopic.php?pid=1932543#p1932543

Network: Intel Corporation Wi-Fi 6 AX200 [8086:2723] (rev 1a)
Comment 4 Fabian 2020-10-27 08:38:26 UTC
Same for me

Laptop:   ASUS Vivobook X421IA_M433IA
CPU:      AMD Ryzen 5 4500U
Network:  Intel Corporation Wi-Fi 6 AX200
Kernel:   Linux 5.9.1-zen2-1-zen
BT-Mouse: Logitech Pebble

Desktop:  Selfmade
CPU:      AMD Ryzen 7 1700
Network:  Intel Corporation Wi-Fi 6 AX200
Kernel:   Linux 5.9.1-zen2-1-zen
BT-mouse: Logitech MX Master 2
Comment 5 matias 2020-10-27 15:34:34 UTC
Same problem for me since 5.9.0 (remains with 5.9.1).

Adapter: USB, ID 8087:0025 Intel Corp. Wireless-AC 9260 Bluetooth Adapter

Tested with the following Bluetooth devices:

* Logitech MX Anywhere 2S: Requires a re-pair every time the radio goes off either at the computer or at the device.

* Logitech MX Anywhere 2: Requires a re-pair every time the radio goes off either at the computer or at the device.

* WI-XB400: Does not autoconnect to the computer after turned on, but works after manually asking to connect on bluetoothctl. Does not require a re-pair.
Comment 6 matias 2020-10-27 15:38:09 UTC
There are some additional reports of issues at https://bugs.archlinux.org/task/68346, with Intel Corporation Wireless-AC 9560 adapter and the following Bluetooth devices:

* Logitech MX-Ergo

* HHKB Professional Hybrid bluetooth keyboard
Comment 7 Sönke Huster 2020-10-28 08:59:59 UTC
Same problem for me with Intel Wireless-AC 9260 with the following bluetooth devices:

* Logitech MX Vertical
* Logitech Ergo K860
Comment 9 ripetrescu 2020-11-13 16:21:51 UTC
Same problem for me after 5.9.+, with a Logitech Master MX 3.
Comment 10 Alex Kampas 2020-11-15 02:55:11 UTC
I can confirm, same problem here: 

Kernel 5.9.7 and 5.9.8 from xanmod on Pop 20.10
BT module is the intel ax200
Mouse: Logitech Anywhere 2 and Logitech MX2s

The mouse fails to reconnect after a reboot, or even (most times) after switched on or off, or if the laptop suspends and resumes.

The problem disappears by booting 5.8 and older kernels.
Comment 12 Fabian 2020-11-19 20:08:06 UTC
Kernel 5.9.9 fixed the Problem for me. Mouse reconnects as it should be. BT itself feels still a bit unstable but that might be just me seeing ghosts.
Comment 13 rocko 2020-12-15 05:38:43 UTC
I'm encountering this bug in kernel 5.10 with a Logitech triathlon mouse.
Comment 14 rocko 2020-12-16 03:09:11 UTC
It's still in the mainline Ubuntu 5.10.1 kernel as well. The patch https://lkml.kernel.org/lkml/20201003160713.GA1512229@kroah.com/T/ might have been applied to the 5.9 series but not to 5.10.1 according to the code git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack cod/mainline/v5.10.1.

However, the workaround at https://wiki.archlinux.org/index.php/Bluetooth#Problems_with_all_BLE_devices_on_kernel_5.9+ (comment out IdentityKey in the bluetooth info file) fixes the problem for me.
Comment 15 Fabian 2020-12-16 13:33:25 UTC
Tried 5.10.1-arch1-1, that is currently in testing.
All my bloutooth devices work. They connect and reconnect just fine. Including the Logitech mice Logitech MX Master 2, Logitech Pebble.
No additional workarounds in place.
Comment 16 Oleksandr Natalenko 2020-12-16 14:42:40 UTC
That's because Arch kernel carries extra patches to address Bluetooth issues.
Comment 17 Krzysztof.Krason 2020-12-28 16:36:03 UTC
I'm using kernel 5.10.1 (mainline, downloaded from kernel.org) and the issue still exists.
Comment 19 Yegor Yegorov 2022-02-09 06:30:44 UTC
It seems that I have a similar problem, but on the 5.17-RC kernel. I have Logitech MX Anywhere 3 mouse. It works properly on 5.16 kernel. I have noticed that on every repair to my computer the mouse changes its MAC address, but it seems to be unrelated to this bug. On 5.17-RC kernel the mouse is working right after pairing to the computer, but stops working on the first disconnect from my computer (on computer sleep or reboot, on mouse standby or power down, and on software disconnect from the mouse in bluetoothctl). The mouse start working again only after removing the mouse from paired devices and repairing again.
Comment 20 Massimo Burcheri 2022-06-07 14:35:31 UTC
Same issue with a Logitech MX Master 2S on a 5.17.8 kernel.
Isn't that a bug of the Logitech mouse changing the bluetooth address on every restart?
Comment 21 Chow Loong Jin 2022-06-08 08:45:19 UTC
I was facing this issue with my Logitech MX Master 3 as well, but applying this patch[1] seems to make it work, quoted here for posterity:

-------------------8<---------------------
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 9873e1c8cd16..7ed862135110 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1363,7 +1363,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
                         ((dev)->le_rx_def_phys & HCI_LE_SET_PHY_CODED))
 
 /* Use LL Privacy based address resolution if supported */
-#define use_ll_privacy(dev) ((dev)->le_features[0] & HCI_LE_LL_PRIVACY)
+#define use_ll_privacy(dev) (0)
 
 /* Use ext scanning if set ext scan param and ext scan enable is supported */
 #define use_ext_scan(dev) (((dev)->commands[37] & 0x20) && \
------------------->8---------------------

I'm not entirely sure if the issue is in Logitech's implementation of Bluetooth  LL Privacy, or the kernel's, but it doesn't seem to work very well together.

The other workaround of removing the IdentityResolvingKey as documented in the ArchLinux wiki[2] seems to also work, but not quite as well as the mouse frequently disconnects and reconnects randomly, especially when scrolling for a long time.

[1] https://bbs.archlinux.org/viewtopic.php?pid=1932543#p1932543
[2] https://wiki.archlinux.org/title/bluetooth#Problems_with_all_BLE_devices_on_kernel_5.9+
Comment 22 Massimo Burcheri 2022-06-10 09:58:43 UTC
Somehow I got it solved without removing IdentityResolvingKey with these settings in /etc/bluetooth/main.conf:
AutoEnable=true
Experimental = false
I guess the Experimental flag is important. However after restarting the machine, the pointer device was just connected and working.
Comment 23 Luiz Von Dentz 2022-06-10 16:37:05 UTC
(In reply to Massimo Burcheri from comment #22)
> Somehow I got it solved without removing IdentityResolvingKey with these
> settings in /etc/bluetooth/main.conf:
> AutoEnable=true
> Experimental = false
> I guess the Experimental flag is important. However after restarting the
> machine, the pointer device was just connected and working.

It seems the problem is LL Privacy (aka. Address Resolution), when that is enabled certain controller seem to be unable to resolve addresses so the host stack is unable to reconnect. I guess we should be splitting the kernel experimental features from userspace experimental features, anyway Experimental is never meant to be enabled by default so if anyone is shipping with it enabled on main.conf please reconsider.
Comment 24 Chow Loong Jin 2022-06-13 08:36:14 UTC
Looks like I have `bluetoothd` running with `-E`, probably from my initial setup of Pipewire's HFP/HSP stuff. I guess that's what the issue was on my end. I haven't rebooted into a kernel that doesn't have this patch to test the theory, but it seems plausible.
Comment 25 Luiz Von Dentz 2022-06-15 22:00:22 UTC
We are going to change how -E works, it shall only enable experimental D-Bus interfaces rather than Kernel Experimental features including LL Privacy:

https://patchwork.kernel.org/project/bluetooth/list/?series=650352
Comment 26 Chow Loong Jin 2022-06-21 07:28:11 UTC
I've confirmed that removing the `-E` flag from bluetoothd makes it work on v5.18.1 without the patch I was using before.
Comment 27 Krzysztof.Krason 2022-06-21 09:05:57 UTC
Just adding one another note.
I didn't have the issue for few months (I'm not sure what I did back then) and now when I upgraded to kernel 5.18.5 the issue is back :(

I need to manually connect to my mouse (MX Master 3) and also keyboard (MX Keys Mini) and also my bluetooth set (Jabra Elite Active 65t). So it looks like a general issue with bluetooth.

I'm on old Ubuntu 20.04.
Comment 28 Paul Menzel 2022-06-21 09:09:04 UTC
> I didn't have the issue for few months (I'm not sure what I did back then)
> and > now when I upgraded to kernel 5.18.5 the issue is back :(

What Linux
Comment 29 Paul Menzel 2022-06-21 09:10:00 UTC
[Sorry for submitting an incomplete reply.]

> I didn't have the issue for few months (I'm not sure what I did back then)
> and > now when I upgraded to kernel 5.18.5 the issue is back :(

What Linux kernel version did you update from?
Comment 30 Krzysztof.Krason 2022-06-21 10:08:11 UTC
I moved from 5.18.3.

What is strange I tried to double check it, booted into 5.18.3, mouse and keyboard connected almost right away. Booted back to 5.18.5 and it worked also.

And then I tried suspend and this is the issue on my end. Doing suspend and resume causes the bluetooth devices not to reconnect (I need to connect manually from bluetoothctl).

It is hard to tell when it stopped working because at around 5.18.x suspend stopped working on my laptop, so it was basically  dying each night, 5.18.5 fixed that, but it broke bluetooth reconnect.

So basically, this is a different issue, I need to find the right kernel that had reliable suspend (it was one earlier 5.17.x).
Comment 31 Luiz Von Dentz 2022-07-14 17:42:27 UTC
I think I finally found what is causing these issues when LL Privacy is enabled the controller requires setting Device Privacy Mode in order to accept reconnecting when the peripheral is using its identity address:

https://patchwork.kernel.org/project/bluetooth/patch/20220714002236.3540353-1-luiz.dentz@gmail.com/
Comment 32 Paul Menzel 2022-10-13 12:28:15 UTC
According to Patchwork, version 2 of that patch [1] was committed as commit ab345b04433da6191f5cecfc036c9419ce05011e. I only see that commit in the tag `next-20220722` though.

Searching for the string, it turns out, this is commit 0900b1c62f43, part of next-20220728 and successors, and part of v6.0-rc1, so in current mainline release 6.0.

The people with the Logitech mouse problem, could you please test that version?

[1]: https://patchwork.kernel.org/project/bluetooth/patch/20220714181224.3793757-1-luiz.dentz@gmail.com/
Comment 33 Chow Loong Jin 2022-10-17 02:36:18 UTC
Just tried running v6.0.1, same issue.

Note You need to log in before you can comment on or make changes to this bug.