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

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

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)

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

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.

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

Same problem for me with Intel Wireless-AC 9260 with the following bluetooth devices:

* Logitech MX Vertical
* Logitech Ergo K860

https://lore.kernel.org/linux-bluetooth/20201022082304.31757-1-sathish.narasimman@intel.com/ works for me.

Same problem for me after 5.9.+, with a Logitech Master MX 3.

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.

The patch was applied to Bluetooth-next:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=1fb17dfc258ff6208f7873cc7b8e40e27515d2d5

(In reply to matias from comment #8)
> https://lore.kernel.org/linux-bluetooth/20201022082304.31757-1-sathish.
> narasimman@intel.com/ works for me.

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.

I'm encountering this bug in kernel 5.10 with a Logitech triathlon mouse.

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.

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.

That's because Arch kernel carries extra patches to address Bluetooth issues.

I'm using kernel 5.10.1 (mainline, downloaded from kernel.org) and the issue still exists.

The fix found its way into 5.10.4 and 5.11-rc1.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/bluetooth/hci_request.c?id=c98d3357920623bbb5a316907bfbc9c300552873

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/bluetooth/hci_request.c?id=1fb17dfc258ff6208f7873cc7b8e40e27515d2d5

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.

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?

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+

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.

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

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.

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

I've confirmed that removing the `-E` flag from bluetoothd makes it work on v5.18.1 without the patch I was using before.

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.

> 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

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

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

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/

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/

Just tried running v6.0.1, same issue.