https://bugs.kde.org/show_bug.cgi?id=470085
--- Comment #2 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
Either I tracked down another issue, or the bug description is not really
correct even though it's mostly what users are expected to observe without
paying a lot of attention to details.
I don't really know much about Android development, but attempted to see if the
network status change callback is working, and it seems to be more than just
fine, there's even quite a bit of "overachieving":
```
KDE/BackgroundService: onNetworkChange
KDE/LanLinkProvider: identity packet received from a TCP connection from [...]
KDE/LanLinkProvider: Starting SSL handshake with [...] trusted:true
LanLinkProvider: Starting handshake
KDE/LanLinkProvider: identity packet received from a TCP connection from [...]
KDE/LanLinkProvider: Starting SSL handshake with [...] trusted:true
KDE/LanLinkProvider: Handshake as client successful with [...] secured with
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
KDE/LanLinkProvider: Creating a new link for device [...]
updateDeviceInfo: Updating supported plugins according to new capabilities
LanLinkProvider: Starting handshake
```
Then the sockets (yes, two!) just manage to get closed.
The PC side also shows the same oddity:
```
kdeconnect.core: LanLinkProvider started
kdeconnect.core: Daemon started
kdeconnect.core: Broadcasting identity packet
kdeconnect.core: TCP connection done (i'm the existing device)
kdeconnect.core: Starting server ssl (I'm the client TCP socket)
kdeconnect.core: TCP connection done (i'm the existing device)
kdeconnect.core: Starting server ssl (I'm the client TCP socket)
kdeconnect.core: Socket successfully established an SSL connection
kdeconnect.core: It is a known device "[...]"
kdeconnect.core: Not loading plugin "kdeconnect_lockdevice" because device
doesn't support it
kdeconnect.core: Not loading plugin "kdeconnect_remotesystemvolume" because
device doesn't support it
kdeconnect.core: Not loading plugin "kdeconnect_remotecommands" because device
doesn't support it
kdeconnect.core: Not loading plugin "kdeconnect_virtualmonitor" because device
doesn't support it
error activating kdeconnectd: QDBusError("org.freedesktop.DBus.Error.NoReply",
"Did not receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply, the reply
timeout expired, or the network connection was broken.")
```
The connection can be observed in both GUIs for a tiny window of opportunity
which is quite easy to miss.
Take my guess with a bucket of salt, but I think there's a bug exposing a race
condition. I'm not sure why are there 2 connections established, but I believe
the two handshakes are racing because link update/replacement seems to be for
only already established (handshake done) links.
Moved to Wireshark to see who's naughty. One broadcast (with way too much
information, now I get the "trusted" network concept) from the phone, then it
makes two connections, but not even seeing the desktop telling the phone where
should it connect to, that can't be right... unless the communication is on
another interface.
Currently not even running a multi-cable setup, but WiFi is also connected, so
disabled that, and boom, now I can't even reproduce the issue even after
turning on WiFi again. So overall I'm not sure if mine is yet another issue,
but I seem to have the apparently not uncommon issue of multiple networks links
not being handled well, so maybe those with tethering issues are also suffering
from this.
Please make sure you have only 1 network link on both sides (phone is likely to
have just WiFi already which is the only relevant link as cellular connection
shouldn't matter), then report back so it can be judged if it's the same issue
I'm seeing, or we are dealing with multiple problems here.
I remember seeing WiFi getting turned off when Ethernet was connected, just not
sure how long ago was that, and of course this behavior heavily depends on the
setup, but it may be a recent-ish change both for faster disconnect recovery
and for letting MPTCP use both connections as support for that is evolving.
Sorry for the (lack of proper) formatting, but even without the code block
format working I believe the log chunks are short enough not to be disturbing.
--
You are receiving this mail because:
You are watching all bug changes.
