Bug 507972

SUMMARY

KDE Connect Android application seems to send "UdpIdentityPacket" using incorrect interface when both Wi-Fi and VPN is connected on the smartphone.

The UDP 255.255.255.255 port 1716 packet is not bound to the same interface from where the request came from, which forces this packet to go via the routing table and the default route (which may be another interface).
I see this packet on the VPN interface (on the VPN server), and not on the Wi-Fi.

The KDE Connect peer is not discovered when VPN (OpenVPN Connect) is connected, because it sets default route over VPN (including 255.255.255.255).

In LanLinkProvider.java I see that in sendUdpIdentityPacket `network` parameter is passed only on network change. Manual refresh from the application's interface does not use the `network`, forcing everything via the default one (VPN).

On Windows and FreeBSD (for some reason), KDE Connect sends identity packet over all available interfaces. See https://bugs.kde.org/show_bug.cgi?id=507954
The lazy fix is to do the same here as well.


STEPS TO REPRODUCE
1. Connect to the Wi-Fi and to VPN which routes all the traffic and does not do excludes for 255.255.255.255 IP (OpenVPN Connect application, or OpenVPN for Android with v3 core enabled in the options)
2. Press refresh in the KDE Connect Android

OBSERVED RESULT

No Wi-Fi KDE Connect clients are found

EXPECTED RESULT

Identity Packet is sent over Wi-Fi, not VPN, and other KDE Connect clients are found.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Android application: from F-Droid, 1.33.4