[kdeconnect] [Bug 508820] KDE Connect on desktop claims to be connected to KDE Connect on phone, but phone claims the opposite, when using bluetooth

https://bugs.kde.org/show_bug.cgi?id=508820

Yaron Shahrabani <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #5 from Yaron Shahrabani <[email protected]> ---
I'm also running into this kind of behavior so I let Claude Code free access to
my ADB and Linux machine, it came up with the following AI Conclusions, feel
free to reject if it's unacceptable, I can generate an MR with all the
AGENTS.md restrictions if it's acceptable, enjoy:

The Android side closes inbound Bluetooth links immediately after creating
them,
which matches the symptom here: the desktop still has its link, the phone has
already dropped its own.

In ServerRunnable.connect(), the connection is wrapped in a use{} block:

   
src/main/java/org/kde/kdeconnect/backends/bluetooth/BluetoothLinkProvider.kt:182

        ConnectionMultiplexer(socket).use { connection ->
            ...
            val link = BluetoothLink(context, connection, inputStream,
outputStream, ...)
            addLink(identityPacket, link)
            Log.i("BTLinkProvider/Server", "Link Added")
        }

use{} closes the connection when the block exits, including on the success
path,
where BluetoothLink has just taken ownership of it and closes it itself in
disconnect() (BluetoothLink.kt:103).

The client path in the same file does not do this. At line 365 it keeps the
connection in a plain val and closes it explicitly on the failure exits. That
is
why a connection initiated by the phone survives and one initiated by the
desktop
does not.

Logcat, Plasma 26.04.3 desktop connecting to the phone over Bluetooth,
Android 16, KDE Connect from master:

    16:29:18.024 BTLinkProvider/Server: Received connection from
C8:58:C0:86:E3:94
    16:29:18.564 BTLinkProvider/Server: Sent identity packet
    16:29:18.742 BTLinkProvider/Server: Received identity packet
    16:29:18.744 BluetoothLinkProvider: addLink to _762eeb16_...
    16:29:18.760 BTLinkProvider/Server: Link Added
    16:29:18.766 BluetoothLinkProvider: disconnectedLink called
    16:29:18.766 KDE/Device: removeLink: BluetoothLinkProvider -> yaronjaro
active links: 1

Six milliseconds between Link Added and the link being removed. Note the last
line: the phone keeps its LAN link and drops only the Bluetooth one, so the
desktop can still report the device as connected.

Desktop journal, same second:

    kdeconnectd: Couldn't connect to bluetooth socket: "Cannot connect to
remote profile"

Same behaviour with a macOS desktop, where close() lands in the same
millisecond
as Link Added:

    17:41:32.065 BTLinkProvider/Server: Link Added
    17:41:32.065 BluetoothSocket: close() ... channel=9
    17:41:32.066 ConnectionMultiplexer: java.io.IOException: bt socket closed,
read return: -1
    17:41:32.066 BluetoothLinkProvider: disconnectedLink called

Keeping the connection in a val and closing it explicitly on the failure path,
the same way the client path does, fixes it. Built a debug APK from master with
only that change:

    15:44:12.416 BluetoothLinkProvider: addLink to 51ee4a33...
    15:44:12.419 Device: yaron-mbp: reloading plugins
    15:44:12.421 KDE/addPlugin: Permissions OK BatteryPlugin

No close, no IOException. The link stayed up, pairing over Bluetooth worked,
17 plugins loaded and pings were delivered. The patched app also still links
over Bluetooth to the Linux desktop.

Note this does not explain the certificate handling discussed in comment 2; the
trace shows a local socket close with no TLS error involved.

-- 
You are receiving this mail because:
You are watching all bug changes.