https://bugs.kde.org/show_bug.cgi?id=506319
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from [email protected] --- (In reply to Ivan from comment #4) > I can reproduce this and I traced the exact mechanism with btmon (HCI) plus a > deterministic A/B test. Confirming the earlier comment about "the second > authentication fails" — here is *why* it fails. > > == Device == > Baseus Bowie 30 Max, a NoInputNoOutput headset (it can only do "Just Works" > pairing, no MITM). Host: Arch Linux, BlueZ 5.86, KDE Connect 26.04.2, > PipeWire 1.6.6. > > == Root cause (from the HCI trace) == > With the Bluetooth backend enabled, KDE Connect registers an RFCOMM/SPP > service > in SDP: > - UUID 185f3df4-3268-4e3f-9fca-d4d559915bd, service name "KDE Connect" > > On every connection the headset comes up fine on A2DP first (BlueZ accepts > the > stored *unauthenticated* link key: Link Key Request Reply, E0 encryption on, > audio plays). Then, ~5-6 s in, the headset browses the host's SDP, finds the > "KDE Connect" SPP on RFCOMM channel 1, and opens it (RFCOMM DLC Parameter > Negotiation on dlci 2, then SABM). The moment BlueZ receives SABM on that > channel it authenticates the incoming RFCOMM connection: > > > Authentication Requested > > Link Key Request -> Link Key Request *Negative* Reply (BlueZ refuses > its > own stored key because the service requires an authenticated key) > > IO Capability Request Reply: "General Bonding - MITM required (0x05)" > > (headset is NoInputNoOutput) -> User Confirmation Request Neg Reply > > Simple Pairing Complete: Authentication Failure (0x05) > > Disconnect Complete, Reason: Remote User Terminated (0x13) > > So the headset's firmware auto-connects to KDE Connect's RFCOMM/SPP, BlueZ > forces a MITM re-pair the NoInputNoOutput headset cannot satisfy, the auth > fails, and the headset tears down the *whole* ACL link. That is the ~4-6 s > drop. > > == Proof (deterministic, both directions) == > - kdeconnectd running -> drop at 6-7 s (5/5 runs) > - kdeconnectd stopped -> holds (5/5 runs) (SPP gone) > - Bluetooth backend disabled, > kdeconnectd still running -> holds (5/5 runs) > Stopping the daemon makes BlueZ drop the SPP record, so the headset finds > nothing on channel 1 and never triggers the auth. > > == Workaround == > Disable only the Bluetooth backend. The CLI toggle currently crashes the > daemon > (SIGSEGV in Daemon::setLinkProviderState, see bug 516170), so do it via > config: > stop kdeconnectd, set in ~/.config/kdeconnect/config: > [General] > disabled_providers=AsyncLinkProvider > then start kdeconnectd. LAN/WiFi backend keeps working. > > == Suggested real fix == > KDE Connect already authenticates at the application layer (TLS client > certificates), so BlueZ link-level authentication on this SPP is redundant. > Registering the RFCOMM service / QBluetoothServer without requiring > authentication (security flags NoSecurity/Encryption instead of > Authorization/Authentication) would let BlueZ accept the existing key and > skip > the re-pair, fixing the disconnect for these headsets without anyone having > to > disable the backend. This workaround works for me and is a much better workaround than a polkit rule to allow unauthenticated service restart of bluetooth.service on user login. -- You are receiving this mail because: You are watching all bug changes.
