https://bugs.kde.org/show_bug.cgi?id=524523
Bug ID: 524523
Summary: macOS: TCP keepalive tuning is compiled out, so a dead
LAN link blocks reconnecting over other routes
Classification: Applications
Product: kdeconnect
Version First unspecified
Reported In:
Platform: macOS (DMG)
OS: macOS
Status: REPORTED
Severity: normal
Priority: NOR
Component: macos-application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
I use KDE Connect together with Tailscale between a Mac and an Android phone
(Samsung Galaxy), so the two stay connected when I am away from home. On the
Mac
I added the phone's Tailscale IP under "Add devices by IP", and the Mac's
Tailscale IP on the phone.
Cellular -> Wi-Fi (arriving home) works. The other direction does not. When I
leave home and the phone switches from Wi-Fi to cellular, the Mac never
reconnects over Tailscale on its own, even though that route is up. It keeps
showing the phone at the LAN address it can no longer reach.
Looking into it, the TCP keepalive tuning in configureSocket() is compiled out
on
macOS, so the dead LAN socket stays "reachable" and the normal disconnect
handling never runs.
STEPS TO REPRODUCE
1. Set up a Mac and an Android phone with Tailscale, and register each other's
Tailscale IP in KDE Connect ("Add devices by IP" on the phone, customDevices
on the Mac), so there is a route that does not depend on the LAN.
2. Put both on the same home Wi-Fi and let them connect. The link comes up on
the
LAN address (192.168.x.y), not the Tailscale one.
3. Leave the Wi-Fi with the phone so it switches to cellular. Tailscale stays
up
on both sides.
OBSERVED RESULT
The Mac keeps the link pinned to the dead LAN address and does not fall back to
the Tailscale route:
$ kdeconnect-cli -l
- Galaxy: <device-id> on 192.168.45.149 via LAN (paired and reachable)
192.168.45.149 is unreachable at this point. It stays like this until I run
`kdeconnect-cli --refresh`, which brings the connection back over Tailscale
within a few seconds.
The opposite transition (cellular -> Wi-Fi, coming home) is fine. That makes
sense, since the Tailscale address stays valid across that change and no link
has
to be torn down.
EXPECTED RESULT
The dead LAN link is detected in a reasonable time and KDE Connect reconnects
over the Tailscale route by itself, without me running --refresh.
SOFTWARE/OS VERSIONS
Operating System: macOS 26.5.2 (25F84), Apple M2 Max (arm64)
KDE Plasma Version: N/A (macOS)
KDE Frameworks Version: 6.26.0
Qt Version: 6.10.2
KDE Connect: 26.07.70 (official macOS build, 2026-05-20)
Phone: Android, Samsung Galaxy
ADDITIONAL INFORMATION
In core/backends/lan/lanlinkprovider.cpp, LanLinkProvider::configureSocket()
sets
the keepalive parameters inside `#ifdef TCP_KEEPIDLE`, added in commit 31c755d2
for BUG 476747. Darwin does not define TCP_KEEPIDLE, so on macOS the whole
block
is compiled out and the socket keeps the system defaults.
Checked against the macOS SDK on this machine:
TCP_KEEPIDLE : not defined
TCP_KEEPALIVE : 0x10 ("idle time used when SO_KEEPALIVE is enabled",
seconds)
TCP_KEEPINTVL : 0x101
TCP_KEEPCNT : 0x102
The defaults the socket falls back to:
$ sysctl net.inet.tcp.keepidle net.inet.tcp.keepintvl net.inet.tcp.keepcnt
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.keepcnt: 8
That is a 2 hour idle time before the first probe. I have not timed the full
two
hours - I work around this with a script that calls --refresh - but it lines up
with how long the stale link survives.
Setting TCP_KEEPALIVE / TCP_KEEPINTVL / TCP_KEEPCNT to 30 / 10 / 3 on a
connected
socket and reading them back works on macOS, giving the same ~60s detection the
Linux path already gets.
Windows may be in the same position: the Q_OS_WIN keepalive block was removed
in
commit 2295f696 and was not restored by 31c755d2. I have not tested that.
I used an AI assistant while investigating this and while writing this report
in
English. The measurements above are from my own machine.
I have a patch and will open a merge request.
--
You are receiving this mail because:
You are watching all bug changes.
