https://bugs.kde.org/show_bug.cgi?id=525160
Aldy Prastyo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|REPORTED |CONFIRMED --- Comment #3 from Aldy Prastyo <[email protected]> --- Thanks for the excellent analysis. I can confirm this on different hardware, and I'd like to propose an alternative fix that I'm happy to implement as an MR. CONFIRMATION distro Kubuntu 25.10 kdeconnect 25.08.1-0ubuntu2.1 bluez 5.83 kernel 6.17.0-41-generic adapter Realtek (USB) device Moondrop Space Travel (A2DP Sink + AVRCP + HFP + Serial Port, NoInputNoOutput) Same chain as in your report. The link authenticates with the stored key and HFP, A2DP (SBC) and AVRCP all come up. About 1.5 s later the earbuds SDP-query Serial Port (0x1101), get the KDE Connect record, and open RFCOMM server channel 1. The host then sends Link Key Request Negative Reply, followed by IO Capability Request Reply with General Bonding - MITM required (0x05). The earbuds answer NoInputNoOutput / MITM not required (0x04). The User Confirmation Request is rejected about 100 µs after it arrives, so this also matches your observation that no agent is consulted. The link then drops with Remote User Terminated Connection (0x13). pkill kdeconnectd fixes it immediately. I can attach the full btmon capture (MACs and link key redacted). This seems to be the same issue as this KDE Discuss thread, with the exact same earbuds: https://discuss.kde.org/t/earphones-get-disconnected-automatically/43046 Note that I'm on bluez 5.83, which fits the CachyOS report that downgrading to 5.82 or earlier avoids the problem. ALTERNATIVE FIX The reason unrelated devices find this service at all is that the SDP record advertises the generic Serial Port class. As far as I can tell, this comes from the convenience overload QBluetoothServer::listen(const QBluetoothUuid &uuid, const QString &serviceName), which registers a record with SerialPort in both ServiceClassIds and BluetoothProfileDescriptorList. Our record on the wire shows exactly that: Service Class ID List: 185f3df4-3268-4e3f-9fca-d4d5059915bd, Serial Port (0x1101) Profile Descriptor List: Serial Port (0x1101) KDE Connect itself only discovers peers by its own UUID (mServiceDiscoveryAgent->setUuidFilter(mServiceUuid)), so the generic SPP class looks unnecessary. My proposal: - Call listen() without the UUID overload, and register a QBluetoothServiceInfo manually that lists only the KDE Connect UUID in ServiceClassIds (plus L2CAP/RFCOMM in the protocol descriptor list and PublicBrowseGroup), without Serial Port. - Keep QBluetooth::Security::Secure as it is, so KDE Connect peers still get MITM-protected links. Headsets and other SPP-probing devices simply never match the record. This avoids having to decide on the security trade-off of dropping Secure. It could also be combined with your suggestion of not registering the record at all when no device is paired over Bluetooth. -- You are receiving this mail because: You are watching all bug changes.
