apple bluetooth keyboard and suspend/resume

[elthariel]

Hey ! <3

This is half a bug report and half a note to have a workaround documented somewhere on the internet.

I'm running:

• Ubuntu 20.04
• using bluez 5.53-0ubuntu3.4
• kernel 5.11.0-44-generic
• linux-firmware_1.201.4 (imported from 21.10, but the behavior was the same with the lts firmwares)
• On a Tuxedo pulse 15
• using an Apple "magic" bluetooth keyboard, from 2014/2015

Here's my hci config:

$> hciconfig -a hci0 
hci0:   Type: Primary  Bus: USB
    BD Address: E0:D4:64:35:BC:76  ACL MTU: 1021:4  SCO MTU: 96:6
    UP RUNNING PSCAN ISCAN INQUIRY 
    RX bytes:60411 acl:2094 sco:0 events:3694 errors:0
    TX bytes:817376 acl:31 sco:0 commands:3584 errors:0
    Features: 0xbf 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH SNIFF 
    Link mode: SLAVE ACCEPT 
    Name: 'ardoise'
    Class: 0x1c010c
    Service Classes: Rendering, Capturing, Object Transfer
    Device Class: Computer, Laptop
    HCI Version:  (0xb)  Revision: 0x27a4
    LMP Version:  (0xb)  Subversion: 0x27a4
    Manufacturer: Intel Corp. (2)

Here's the issue:

Whenever I suspend and resume the laptop, the bluetooth keyboard takes a very long time to reconnect and some times just doesn't. Restarting the bluetooth daemon would eventually fix the issue but still would take some time.

Information I've gathered

The bluez log would include a bunch of line like this device 68:D9:3C:DE:6D:D9 profile input-hid state changed: disconnected -> connected (0) and eventually drop this line after which it would soon reconnect: src/device.c:device_bonding_failed() status 14.

After trying a bunch of thing and reading a few btmon traces I realized it always reconnected after emitting the following line:

> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                    #12 [hci0] 6.308246
        Status: Success (0x00)
        Handle: 256
        Reason: LMP Response Timeout / LL Response Timeout (0x22)

After this, the discovery would start, the keyboard would initiate a connection and it would start working.

With a few other experiments I started to realize connecting from the host to the keyboard doesn't work, only the keyboard could initiate the connection. But it seems that when suspending the bluetooth daemon still thinks it can resume the connection to the keyboard. The opinion of bluez on the matter seems rather reasonnable to me, but it seems the keyboard disagrees [insert apple troll here]

In order to prevent this reconnection, I've added a hacky suspend script in /lib/systemd/system-sleep/bluetooth:

#! /bin/bash

if [ "${1}" == "pre" ]; then
    bluetoothctl disconnect 68:D9:3C:DE:6D:D9
fi;

After adding this, the keyboard resumes quite quickly and consistently it seems.

So I'm wondering whether there's a nice config option in bluez to make it behave this way ? if this is a bug in the default ubuntu configuration ? or a bug in bluez ? or just if the apple keyboard doesn't behave nicely.

I can provide the bluez logs and btmon traces if it is of any help.

[Vudentz]

@elthariel I suspect this could be either due to the kernel not disconnecting properly or something similar to https://github.com/bluez/bluez/issues/275, anyway we did made a lot of changes around how the suspend work but you will likely need to update your kernel in order to get it working properly.

[elthariel]

Thanks for the answer @Vudentz.

I've just today upgraded to 5.13. Are the relevant changes included in that one ? Or should I use a more recent one ? In all the cases, I'm away from my office now and will give it a try when I get back in about a week. <3

[Vudentz]

@elthariel I think the suspend/resume changes is only available on 5.16 an later.

[Vudentz]

@elthariel also it is worth checking if is nothing like #275 which was causing bluetoothd to be unable to load LTK of devices after resume.

[elthariel]

Thanks @Vudentz for the hints. I'll check those issues out.

By the way, I've built a newer kernel (5.16.0) and disabled my hack but the issue still persist. I haven't had a look at the trace and logs yet though, maybe the situation evolved. Also, is there a chance that I need to upgrade my system version of bluez to use some new kernel side bluetooth features ?

[macdabby]

I'm running into a similar issue with a logitch wireless mouse, although it didn't show up until a few weeks ago. of the 100 times i've awaken my system over the past few weeks, maybe 2 or 3 times it automatically reconnected.

debian testing Linux version 5.18.0-3-amd64 bluez 5.64-2

i checked journalctl and there aren't any logs except for this, right at the time the system was awaken

Aug 06 10:58:17 x15 bluetoothd[1392]: Controller resume with wake event 0x0

i'm using gnome 42 (with some components coming in from 43) and as soon as i check the box in the bluetooth settings, the mouse connects almost instantly

[macdabby]

i did some more testing and I think what is happening is just that it takes a really long time before it tries to reconnect. sometimes 10 to 20 seconds. but the mouse is only actively trying to connect for a short time while the light blinks, so i have to continuously move the mouse for that entire time so it's ready when the system tries to connect to it. seems like fixing that delay would fix the problem.

[elthariel]

FYI, I've bought myself a new keyboard, so I don't have any incentive to investigate this issue anymore. You're on your own buddy(ies)

[bam80]

Is this still reproduces?