Bug 507954

Summary: mDNS reply is not bound to the network interface the request came from
Product: [Applications] kdeconnect Reporter: valdikss
Component: commonAssignee: Albert Vaca Cintora <albertvaka>
Status: REPORTED ---    
Severity: normal CC: andrew.g.r.holmes
Priority: NOR    
Version First Reported In: 25.04.3   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description valdikss 2025-08-06 20:53:57 UTC
SUMMARY

kde connect daemon sends MDNS response using incorrect interface on multi-homed network.

The response packet is not bound to the same interface from where the request came from, which forces the response to the well-known 224.0.0.251 MDNS IP address to go via the routing table and the default route (which may be another interface).


STEPS TO REPRODUCE

1.  Connect to two network interfaces, only one of which has default route (eth0), and another one is its IP range only (LAN-only, eth1)
2.  Connect another device (Android smartphone) to the second (LAN-only) network
3.  Press "refresh" on another device

OBSERVED RESULT

The mDNS request comes from Android device via LAN-only interface (eth1), but the mDNS reply goes via default route (eth0).
The device is not found upon refresh.

EXPECTED RESULT

The device is found upon refresh. mDNS reply goes via the same network interface.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 41
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.8.3
Kernel Version: 6.15.8-100.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Comment 1 valdikss 2025-08-06 21:45:50 UTC
In lanlinkprovider.cpp, there's already code for Windows and FreeBSD which "sends the reply over all available interfaces", I bevieve to fix this error.
But for some reason it is put behind ifdef.

https://invent.kde.org/network/kdeconnect-kde/-/blob/release/25.04/core/backends/lan/lanlinkprovider.cpp?ref_type=heads#L194

The lazy fix is:
* To enable this code for Linux
* To use setsockopt SO_BINDTODEVICE for Linux

The proper fix is to bind to the same interface with SO_BINDTODEVICE (or at least find the interface with the same source IP from which the incoming packet was from) and send it from that interface.