Bug 459171 - Network discovery is performed only using main interface (no devices when VPN or multiple interfaces are connected)
Summary: Network discovery is performed only using main interface (no devices when VPN...
Status: RESOLVED FIXED
Alias: None
Product: kdeconnect
Classification: Applications
Component: windows-application (other bugs)
Version First Reported In: unspecified
Platform: Other Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: valdikss
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-15 15:43 UTC by valdikss
Modified: 2022-10-17 22:27 UTC (History)
0 users

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 valdikss 2022-09-15 15:43:47 UTC
SUMMARY
When I use both Ethernet and Wi-Fi on my laptop (to different networks), or connect to any VPN using OpenVPN client, KDE Connect could not discover any devices on the LAN and could not connect to already paired ones.


STEPS TO REPRODUCE
1. Connect to Ethernet and Wi-Fi, make sure KDE Connect devices are only on Wi-Fi
2. Open KDE Connect, refresh the device list


OBSERVED RESULT
No devices found. Already paired ones, which are present on Wi-Fi network, are not connected.


EXPECTED RESULT
Devices are discovered and connected.


SOFTWARE/OS VERSIONS
Windows: Windows 10 21H2
Windows KDE Connect "offline installer" build kdeconnect-kde-21.12.3-903-windows-msvc2019_64-cl


ADDITIONAL INFORMATION
"Faster" network interface types (Wi-Fi vs Gigabit Ethernet), with "Automatic Metric" feature of Windows (enabled by default), always have lower interface metric even if it does not install any routes (Windows adds 224.0.0.0/4 for multicast and 255.255.255.255/32 for broadcast automatically).

Turns out KDE Connect daemon fails to send UDP broadcast packet using all available interfaces and tries to send it only via default interface (the one with lowest metric, because it has lower metric route for 255.255.255.255 broadcast address), despite having the code to do so:
https://invent.kde.org/network/kdeconnect-kde/-/blob/a918ffc0cbd7d85a2a482cfa1019508720498517/core/backends/lan/lanlinkprovider.cpp#L164
Comment 1 valdikss 2022-09-15 16:26:08 UTC
https://invent.kde.org/network/kdeconnect-kde/-/blob/a918ffc0cbd7d85a2a482cfa1019508720498517/core/backends/lan/lanlinkprovider.cpp#L171

There should be a call to

    sendSocket.setSender(sourceAddress, 0)

which seem to be missing.
Comment 2 Bug Janitor Service 2022-09-15 19:15:27 UTC
A possibly relevant merge request was started @ https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/495
Comment 3 Simon Redman 2022-10-17 22:27:54 UTC
Git commit 390a44a901de2a887fa37c7f7c6cdb20fd50a371 by Simon Redman, on behalf of ValdikSS ValdikSS.
Committed on 17/10/2022 at 22:21.
Pushed by sredman into branch 'master'.

Really set source IP for broadcast discovery packets on Windows/FreeBSD

This whole code was no-op: it enumerates network interfaces, enumerates
its IP addresses, but does not change the address of broadcast UDP
packet, sending it only via default route/interface.

Bind the socket to IP addresses of the interfaces to fix the issue.

M  +1    -0    core/backends/lan/lanlinkprovider.cpp

https://invent.kde.org/network/kdeconnect-kde/commit/390a44a901de2a887fa37c7f7c6cdb20fd50a371