Bluetooth device acts connected, but bluez does not show it this way. The device is partially usable but things like mode-switching for conference calls (in the case of this device, which is an audio headset) don't work like they should unless I "manually" connect the device using bluetoothctl such that the device is properly registered. Reproducible: Always Steps to Reproduce: 1. Pair headset normally 2. Power headset off 3. Power headset on It will say it reconnects (from the headset side) but will not show as a connected device in the system tray or in bluetoothctl Actual Results: Device acts connected (can play music through it, and it shows up in the Sound controls in GNOME) but automatic mode switching (i.e. in gmeet, where it switches to the handsfree modes and msbc) is flaky Expected Results: Bluetoothctl and system tray show connected when device says it is connected The "normal" connection sequence looks like this: [bluetooth]# connect 14:3F:A6:60:58:58 Attempting to connect to 14:3F:A6:60:58:58 [CHG] Device 14:3F:A6:60:58:58 Connected: yes [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 [WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 [WH-1000XM4]# [NEW] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 [WH-1000XM4]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 Delay: 0x06a4 (1700) [WH-1000XM4]# Connection successful [WH-1000XM4]# [CHG] Device 14:3F:A6:60:58:58 ServicesResolved: yes [WH-1000XM4]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 Volume: 0x002d (45) When powering off the sequence looks like this: [WH-1000XM4]# [DEL] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 [WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 [WH-1000XM4]# [CHG] Device 14:3F:A6:60:58:58 ServicesResolved: no [CHG] Device 14:3F:A6:60:58:58 Connected: no On reconnection attempt this is the sequence: [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 [bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 [bluetooth]# [NEW] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 [bluetooth]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 Delay: 0x06a4 (1700) [bluetooth]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 Volume: 0x002d (45) Note the lack of Connected: yes Additionally journalctl -u bluetooth has this: Apr 08 14:58:06 martjack.imladris.lan bluetoothd[1489]: No matching connection for device Apr 08 14:59:04 martjack.imladris.lan bluetoothd[1489]: src/profile.c:ext_io_disconnected() Unable to get io data for H> Apr 08 15:00:00 martjack.imladris.lan bluetoothd[1489]: Authorization request for non-connected device!? And at this point, the device _acts_ connected, and I can even have bluetoothctl disconnect it, but it doesn't show as connected in the bluetoothctl device list or in the system tray: [bluetooth]# devices Connected [bluetooth]# I can work around this using bluetoothctl to "manually" connect and disconnect, but I did not have to do this before.
it'd be best to report this upstream at https://github.com/bluez/bluez/issues . I assume it's yet another thing that broke between 5.72 and 5.73? we really aren't doing much to bluez downstream besides packaging it and backporting some fixes for 5.73 breakage.
Turns out this is being tracked upstream at https://github.com/bluez/bluez/issues/804. I've linked this report there in case there's additional info that would be helpful.
This is a kernel problem introduced wit 6.8.2 (which sort of explains why it wasn't seen with the various bluez changes).
The patch is available: https://lore.kernel.org/all/20240404185022.1.Ic27505c8f1ca7d4a653b1dcc1b08cdfc862a4622@changeid/ https://bugzilla.redhat.com/show_bug.cgi?id=2272864
Proposing this as a Final FE just in case we wind up slipping, seems like it'd be nice to get that fix in if we do.
*** Bug 2272864 has been marked as a duplicate of this bug. ***
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1586 , marking accepted FE.
FEDORA-2024-6d35739db7 (kernel-6.8.5-301.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d35739db7
FEDORA-2024-33a9ea72d1 (kernel-6.8.5-201.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-33a9ea72d1
FEDORA-2024-a56a47ef1b (kernel-6.8.5-101.fc38) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a56a47ef1b
FEDORA-2024-6d35739db7 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6d35739db7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d35739db7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-33a9ea72d1 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-33a9ea72d1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-33a9ea72d1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-a56a47ef1b has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-a56a47ef1b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a56a47ef1b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-33a9ea72d1 (kernel-6.8.5-201.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-6d35739db7 (kernel-6.8.5-301.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-a56a47ef1b (kernel-6.8.5-101.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2274769 has been marked as a duplicate of this bug. ***
*** Bug 2274766 has been marked as a duplicate of this bug. ***