https://bugs.kde.org/show_bug.cgi?id=520110
--- Comment #1 from Mice <[email protected]> --- Additional local validation details: I confirmed the failure was not caused by missing tailnet reachability. From the desktop side, packets reached the Android device's tailnet IP and port 1716. From the Android side, the same connection was visible to the app process as loopback. Once I changed the LAN backend to treat loopback as an explicit-proxy path only when custom devices are configured, pairing completed successfully and the desktop reported the Android device as paired and reachable via the tailnet IP. The reason I think this belongs in KDE Connect rather than only in the VPN/tailnet implementation is that KDE Connect already has an explicit peer concept ("Add devices by IP"). In userspace VPN/tailnet environments, the transport may erase the original peer address before the Java socket layer can compare it with the configured address. So the trust decision may need to preserve the user's explicit opt-in even when the app-visible source is loopback. A possible safer design than simply accepting loopback would be: - keep rejecting loopback by default; - allow it only if the custom device list is non-empty, or behind a more explicit setting; - still require normal KDE Connect identity/TLS handling after the initial address gate; - optionally log that the connection was accepted as a userspace VPN/proxy loopback path. I have a local fork with this behavior and can turn it into a merge request if this approach is acceptable. -- You are receiving this mail because: You are watching all bug changes.
