Bug 2494734

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.