Package: bluez
Version: 5.82-1.1
Severity: important
Tags: upstream
X-Debbugs-Cc: [email protected]
Dear Maintainer,
A bonded/trusted LE HID device (Bluetooth mouse) that disconnects itself
after ~10 minutes of idle (HCI Disconnect Complete, reason 0x13 "Remote
User Terminated Connection") normally reconnects instantly on its own the
next time it's touched, via a directed advertisement (ADV_DIRECT_IND) that
the kernel's background auto-connect mechanism picks up in under 30ms.
On some idle->reconnect cycles, this stops working: the device never
reconnects no matter how long it's touched/moved, passive scanning
(bluetoothctl scan on) never shows any advertisement from it at all, and
an explicit "Connect" from the GUI (or `bluetoothctl connect <MAC>`) fails
with:
MGMT Event: Connect Failed (0x000d)
LE Address: <device MAC> (Static)
Status: Disconnected (0x0e)
Power-cycling the peripheral, swapping its battery, and using its
hardware pairing-reset button all have no effect once the device is in
this state -- strongly indicating the peripheral itself is not the
problem. The only thing that recovers it is killing and restarting
bluetoothd (`systemctl kill --signal=SIGKILL bluetooth`); a plain
`systemctl restart bluetooth` (SIGTERM) does NOT recover it, even run
twice in a row.
-- Evidence --
A ~12 hour continuous `btmon` capture spanning multiple idle/disconnect/
reconnect cycles for the same device shows:
1. `MGMT Command: Add Device ... Action: Auto-connect remote device (0x02)`
is issued exactly ONCE per bluetoothd process lifetime (observed once,
at daemon startup, across the entire 12-hour capture). This is the
command that arms the kernel-level background auto-connect that reacts
to the device's directed advertisement.
2. Two reconnects during that capture succeeded normally: the device sent
an ADV_DIRECT_IND, and `LE Extended Create Connection` fired and
succeeded within ~30ms, with no scanning/discovery visible beforehand
-- consistent with kernel-side auto-connect, not bluetoothd polling.
3. A third disconnect was never recovered for the remainder of the
capture (43+ minutes) despite continuous passive scanning picking up
dozens of *other* nearby BLE devices normally. Zero
`LE Extended Create Connection` attempts were issued toward the mouse's
address after that disconnect -- not "retried and failed", but never
attempted at all.
4. In a separate, live-monitored episode: `bluetoothctl info <MAC>`
correctly showed `Connected: no` (not a stale/stuck state). An explicit
GUI "Connect" click produced the `Connect Failed / Status: Disconnected
(0x0e)` event above. After that failed attempt, the device remained
completely invisible to both passive scan and repeated physical
interaction with the peripheral (power cycle, battery swap, pairing
button) for the rest of the session.
5. Killing bluetoothd (`kill -9` on the bluetoothd PID) and letting
systemd restart it caused the fresh process to re-issue the same
`Add Device ... Auto-connect remote device (0x02)` MGMT command seen in
point 1. Approximately 10 seconds later, the device's directed
advertisement appeared and the connection succeeded instantly and
completely (GATT discovery, HID reports, battery level all working
normally afterward).
-- Suspected root cause --
The evidence is consistent with: a failed connection attempt (from the
explicit "Connect" action in step 4) causes bluetoothd/kernel to drop or
suspend the auto-connect registration for that device, and this is never
retried or re-armed except by a full daemon restart. This would explain
why passive scanning is unaffected (separate code path, doesn't touch
auto-connect state) while the actual auto-connect mechanism silently and
permanently stops working for that one device until bluetoothd restarts.
I have NOT been able to confirm the exact internal trigger (whether it's
specifically the failed Connect call, the "Status: Disconnected (0x0e)"
result, or something else in bluetoothd's policy/reconnect logic) -- flagging
this as the most likely explanation, not a certainty.
-- Steps to reproduce (best effort; timing-dependent) --
1. Pair/bond/trust an LE HID device that disconnects itself after a period
of inactivity (many BLE mice do this to save power).
2. Let it idle-disconnect.
3. Attempt an explicit manual connect via GUI or
`bluetoothctl connect <MAC>` while it is not yet ready to reconnect
(e.g. immediately after disconnect) so the connect attempt fails.
4. Attempt to reconnect normally afterward (touch/move the peripheral).
In the affected state, it will not reconnect no matter how long you
wait or how much you interact with the peripheral.
5. `sudo systemctl restart bluetooth` (SIGTERM) does not recover it.
6. `sudo systemctl kill --signal=SIGKILL bluetooth` does recover it.
-- Workaround --
`sudo systemctl kill --signal=SIGKILL bluetooth` reliably recovers the
device. NOT YET CONFIRMED but worth testing: re-arming just the
auto-connect registration without a full daemon restart may also work:
bluetoothctl untrust <MAC>
bluetoothctl trust <MAC>
-- System info --
Distribution: Debian 13 (trixie)
bluez: 5.82-1.1
Kernel: 7.0.13+deb13-amd64 (backports)
Bluetooth adapter: Intel AX210 (8087:0032), driver btusb
Affected device: Lenovo Bluetooth Mouse, BLE HID, static random address
-- System Information:
Debian Release: 13.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 7.1.3+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bluez depends on:
ii adduser 3.152
ii dbus [default-dbus-system-bus] 1.16.2-2
ii init-system-helpers 1.69~deb13u1
ii kmod 34.2-2
ii libasound2t64 1.2.14-1
ii libc6 2.41-12+deb13u3
ii libdbus-1-3 1.16.2-2
ii libdw1t64 0.192-4
ii libglib2.0-0t64 2.84.4-3~deb13u3
ii libreadline8t64 8.2-6
ii libudev1 257.13-1~deb13u1
ii udev 257.13-1~deb13u1
bluez recommends no packages.
Versions of packages bluez suggests:
pn pulseaudio-module-bluetooth <none>
-- no debconf information
