Bug 502478 - Peer discovery seems to still have a race condition in handshake on some devices
Summary: Peer discovery seems to still have a race condition in handshake on some devices
Status: REPORTED
Alias: None
Product: kdeconnect
Classification: Applications
Component: android-application (other bugs)
Version First Reported In: unspecified
Platform: Android Android 12.x
: NOR crash
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-06 09:04 UTC by Daniel Landau
Modified: 2025-09-05 14:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Landau 2025-04-06 09:04:10 UTC
SUMMARY

I can't reproduce it, but there have been numerous reports of protocol v8 devices showing up and disappearing on the GSConnect github repo.

One of the reports (https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1980#issuecomment-2766411619) came with a useful looking adb logcat, that seems to indicate that Device.kt is firing off some packet while LanLinkProvider.java is still trying to do the secure identity packet exchange, causing conscrypt to go haywire similarly but different than in the issue fixed in 1.33.2. Actually according to https://bugs.kde.org/show_bug.cgi?id=501635#c6, it might be that this reliably reproducing racyness might even caused by that fix.
Comment 1 Marcel Partap 2025-09-05 14:04:09 UTC
With 24.12.0-1 on desktop and 1.33.4 on phone there was the problem the desktop would shop up in the device list for half a second, then be gone again, same for each refresh. `logcat` showed `KDE/onConnectionLost` being triggered (reproducably) 300ms after `KDE/LanLinkProvider` created a new link. Downgrading to 1.33.3 fixed it for time being, happy to be able to use it again but up for further testing.

> 15:42:34.649  3884  6192 I MdnsDiscovery: Service discovery started: _kdeconnect._udp                                                                                    
> 15:42:34.656  3884  6192 D MdnsDiscovery: Service discovered: name: _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_, type: _kdeconnect._udp., host: null, port: 0, txtRecord:     
> 15:42:34.658  3884  6192 D MdnsDiscovery: Service discovered: name: 7e064f87_405b_4ef1_bc01_c6550c457726, type: _kdeconnect._udp., host: null, port: 0, txtRecord:       
> 15:42:34.658  3884  6192 D MdnsDiscovery: Service discovered: name: 7e064f87_405b_4ef1_bc01_c6550c457726, type: _kdeconnect._udp., host: null, port: 0, txtRecord:       
> 15:42:34.648   919  2170 D NsdService: Native daemon message SERVICE_FOUND: 603 3379 "7e064f87_405b_4ef1_bc01_c6550c457726" _kdeconnect._udp. local.                     
> 15:42:34.660   919  2170 D NsdService: mdnssd [resolve, 3380, _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_, _kdeconnect._udp., local.]                                         
> 15:42:34.661   665   681 D MDnsDS  : resolveService(3380, (null), _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_, _kdeconnect._udp., local.)                                     
> 15:42:34.663   665   680 D MDnsDS  : resolve succeeded for 3380 finding _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_._kdeconnect._udp.local. at base.local.:1716 with txtLen 76
> 15:42:34.667  3884 29419 I KDE/LanLinkProvider: identity packet received from a TCP connection from base                                                                 
> 15:42:34.667  3884 29419 I KDE/LanLinkProvider: Starting SSL handshake with base trusted:false                                                                           
> 15:42:34.668   919  2170 D NsdService: Native daemon message SERVICE_RESOLVED: 608 3380 "_86d802d1_dbac_417f_ab9e_06ebd6c5aa85_._kdeconnect._udp.local." "base.local." 1716 76 "CnByb3R…
> 15:42:34.689  3884  6192 I MdnsDiscovery: MDNS successfully resolved name: _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_, type: ._kdeconnect._udp, host: /192.168.178.23, port: 1716, txtRecor…
> 15:42:34.724  3884 28504 I KDE/LanLinkProvider: Handshake as client successful with base secured with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384                                            
> 15:42:34.724  3884 28504 D KDE/LanLinkProvider: Creating a new link for device _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_                                                                  
> 15:42:35.024  3884 29419 I KDE/onConnectionLost: removeLink, deviceId: _86d802d1_dbac_417f_ab9e_06ebd6c5aa85_                                                                          
> 15:42:35.025  3884 29419 I KDE/Device: removeLink: LanLinkProvider -> base active links: 0                                                                                             
> 15:43:05.148   919  1290 D ActiveServices_AS: notify:org.kde.kdeconnect_tp