Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: After upgrading from bluez-5.86-4.fc44 to bluez-5.86-5.fc44 on Fedora 44, my Bluetooth Logitech keyboard and mouse stopped reliably reconnecting after system suspend. Version-Release number of selected component (if applicable): bluez-5.86-5 has problems not present in bluez-5.86-4 How reproducible: 95% All BT devices (logitech kb, ms) connect as expected at the login screnn (xfce, lightdm). After suspend, then only occasionally will a BT device reconnect,, and only after an extended delay. Steps to Reproduce: 1. Pair Logitech MX Keys Mini and MX Master 3S via Bluetooth. 2. Suspend the system. 3. Resume the system. Actual results: No connection to BT peripherals - Expected results: Should automatically reconnect to peripherals with only modest delay. Additional info: Hardware Lenovo Yoga 9 14IAP7 Intel AX211 Bluetooth (USB ID 8087:0033) Logitech MX Keys Mini Logitech MX Master 3S Software Working: Fedora 44 kernel 7.0.13-200.fc44.x86_64 bluez-5.86-4.fc44 Broken: Fedora 44 kernel 7.0.13-200.fc44.x86_64 bluez-5.86-5.fc44 Reversion from bluez-5.86-5.fc44 to bluez-5.86-4.fc44 immediately alleviated the problem Actual result Mouse sometimes reconnects only after manually issuing bluetoothctl connect. Keyboard frequently fails to reconnect. bluetoothctl connect <keyboard> eventually fails with: org.bluez.Error.InProgress Other observations: bluetoothctl show reports: Powered: yes Discovering: yes even when no scan was intentionally started. Attempting to stop discovery fails: bluetoothctl scan off Failed to stop discovery: org.bluez.Error.Failed btmgmt find reports: Unable to start discovery. status 0x0a (Busy) bluetoothctl devices Connected lists only the mouse. Logging out to the display manager often allows the devices to reconnect. Restarting bluetoothd, unloading/reloading btusb, and stopping Blueman did not resolve the problem. Regression testing Downgrading only BlueZ from 5.86-5.fc44 to 5.86-4.fc44 immediately restored correct suspend/resume behavior.
FEDORA-2026-a3298b621e (bluez-5.87-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a3298b621e
FEDORA-2026-7f7d44651d (bluez-5.87-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f7d44651d
FEDORA-2026-a3298b621e has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a3298b621e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a3298b621e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-7f7d44651d has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-7f7d44651d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f7d44651d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a3298b621e` greatly improved the problem. Now after suspend, either one or two of the (KB&MS) devices reconnect, but often only one. The Logitech MX MASTER 3S - almost always reconnects. The Logitech MX Keys Mini B - reconnects about half the time Perhaps a distinct problem, but both would regularly reconnect in current fc44 about 8 weeks ago,
FEDORA-2026-a3298b621e (bluez-5.87-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-b3df983849 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b3df983849` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b3df983849 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-b3df983849 (bluez-5.87-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
Please reopen this bug. The issue is still reproducible on Fedora 44 with the version that is supposed to contain the fix: bluez-5.87-3.fc44.x86_64 Logitech MX Vertical connected through Bluetooth Low Energy The issue occurs after the mouse has been inactive; system suspend is not required. The pairing remains intact: Paired: yes Bonded: yes Trusted: yes Connected: no LE.Paired: yes LE.Bonded: yes LE.Connected: no When the problem occurs, BlueZ reports that discovery is active even though no scan was intentionally started: $ bluetoothctl show | grep Discovering Discovering: yes Discovery cannot be stopped or restarted: $ bluetoothctl scan off Failed to stop discovery: org.bluez.Error.Failed $ sudo btmgmt stop-find Stop Discovery failed: status 0x0d (Invalid Parameters) $ sudo btmgmt find Unable to start discovery. status 0x0a (Busy) A manual connection attempt does not complete. The following recovery attempts do not restore the connection immediately: sudo systemctl stop bluetooth sudo rfkill block bluetooth sudo rfkill unblock bluetooth sudo systemctl start bluetooth I also unloaded and reloaded the btusb driver: sudo systemctl stop bluetooth sudo modprobe -r btusb sudo modprobe btusb sudo systemctl start bluetooth The controller is USB and uses btusb: $ readlink -f /sys/class/bluetooth/hci0/device/driver /sys/bus/usb/drivers/btusb After reloading the driver, BlueZ still initially reported: Discovering: yes Connected: no LE.Connected: no The mouse eventually reconnected spontaneously after an abnormally long delay. A system reboot also restores the connection immediately without removing or recreating the pairing. This reproduces the characteristic symptoms originally reported in this bug, including the stuck Discovering: yes state and status 0x0a (Busy). Therefore, the fix shipped in BlueZ 5.87 appears to have improved the issue but has not fully resolved it. Please reopen the bug. I can provide a btmon capture when the issue reproduces again.
I am also seeing the Logitech Bluetooth reconnect problem on Fedora 44 with the current Fedora BlueZ package: Fedora 44 x86_64 Kernel: 7.1.13-200.fc44.x86_64 BlueZ: 5.87-6.fc44 bluetoothctl: 5.87 Hardware: ASUS X406UAR Bluetooth controller: Qualcomm-based internal controller Logitech M720 Triathlon (BLE) Logitech MX Mechanical (BLE) The devices remain paired/bonded/trusted: M720: E6:E7:A5:70:C4:51 MX Mechanical: DC:98:CA:D9:8C:47 The main problem is automatic reconnect after boot. The devices can remain unavailable for a long time, or GNOME can report a connection timeout, while an explicit bluetoothctl connection succeeds essentially immediately. Important observations: 1. The M720 BLE connection itself is fast. Using btmon, the M720 connection sequence shows: LE Create Connection LE Connection Complete: Success encryption succeeds GATT/HID discovery continues In one trace, LE Create Connection was followed by LE Connection Complete in only a few milliseconds. The M720 address observed by btmon is a static random address, not an RPA. Therefore this does not appear to be an address-resolution/RPA problem. 2. Explicit manual connection is very fast. I disconnected the M720 and then ran: time bluetoothctl connect E6:E7:A5:70:C4:51 Result: Connection successful Elapsed time was approximately 0.034 seconds. So the low-level Bluetooth connection can be established immediately once the connection is explicitly requested. 3. The problematic behavior appears later in the BlueZ HOG/UHID path. During the problematic periods, bluetoothd repeatedly logs: profiles/input/hog-lib.c:report_value_cb() bt_uhid_input: Invalid argument (22) followed by: No matching connection for device These are not isolated messages; they recur during the reconnect problem. 4. The M720 HID/UHID device is repeatedly recreated. The kernel log shows the M720 HID device appearing repeatedly at different times, for example: 23:11:23 23:14:52 23:25:13 23:31:52 23:39:19 23:39:48 23:41:26 23:42:26 with new virtual UHID/HID instances being created. This looks more like connection/profile state churn than a failure to establish the BLE link. 5. GNOME can time out while the lower-level Bluetooth stack is still progressing. For the MX Mechanical I also saw: Failed to connect device "MX MCHNCL": Timeout was reached and the MX HID device appeared shortly afterwards. 6. This does not look like a pairing/trust problem. Both devices report: Paired: yes Bonded: yes Trusted: yes Blocked: no and manual connection succeeds without re-pairing. 7. This also does not look like a general Bluetooth-radio failure. The btmon trace shows successful LE connection establishment, encryption and GATT/HID activity. My current interpretation is that the failure is most likely in the BlueZ BLE HID/HOG/UHID reconnect/state handling rather than in the actual LE radio connection. This seems related to the Logitech reconnect regression tracked by this bug. BlueZ 5.87 improved the situation, but in my case the problem is still reproducible with Fedora's 5.87-6.fc44 package. The most useful reproducibility detail may be this: Automatic reconnect: delayed/unreliable Manual `bluetoothctl connect`: succeeds in ~34 ms That suggests that the fundamental BLE link establishment is working, but the automatic reconnect/profile handling is not completing cleanly. Please let me know if a specific BlueZ debug trace or a smaller btmon capture would be useful for isolating the HOG/UHID state transition.