https://bugs.kde.org/show_bug.cgi?id=524617
Bug ID: 524617
Summary: Android app silently drops peers with non-RFC1918
source IPs, breaking KDE Connect on any LAN using a
public prefix
Classification: Applications
Product: kdeconnect
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: android-application
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
[23.8.2026 0:58] Николай ניקולאי: ---
DESCRIPTION
KDE Connect for Android 1.35+ silently drops incoming connections from peers
whose source IP is outside RFC1918 / RFC6598 CGNAT / IPv6 ULA ranges. There is
no user-visible error, no log entry on the phone side, and no way to override
the check via app settings (the existing "Trusted networks" SSID whitelist does
not affect this filter). Any LAN that happens to use a non-private IP prefix —
including SOHO routers that ship non-RFC1918 defaults, and homelabs with
static-IP servers on such a prefix — becomes unusable with KDE Connect, even
when the network is fully under the user's control.
Bug 515707 addressed the specific Tailscale/CGNAT case, but the broader
private-only guard remains and produces the same failure mode for legitimate
non-RFC1918 LANs.
STEPS TO REPRODUCE
1. Put the Android device and a desktop running KDE Connect on the same L2 LAN,
where the LAN uses a subnet that is not part of 10/8, 172.16/12, 192.168/16,
100.64/10 or IPv6 ULA (in my case 190.1.1.0/24).
2. Ensure UDP/TCP 1716-1764 pass both ways (verified with tcpdump — UDP
identity broadcasts flow, TCP handshake completes, identity JSON is delivered
and ACKed).
3. Launch KDE Connect on both sides and wait for the device to appear.
OBSERVED RESULT
The device never appears on either side. Desktop-side journal shows the normal
TCP connection done → Starting server ssl (I'm the client TCP socket) and then
goes silent — no sslErrors(), no encrypted(), no timeout error. The desktop
repeatedly reconnects from new source ports; each attempt reaches the same dead
end.
Packet capture on the desktop (desktop 190.1.1.2, phone 190.1.1.142):
1. 190.1.1.2 → 190.1.1.142:1716 [SYN]
2. 190.1.1.142 → 190.1.1.2 [SYN-ACK]
3. 190.1.1.2 → 190.1.1.142 [ACK]
4. 190.1.1.2 → 190.1.1.142 [PSH, 2371 bytes] kdeconnect.identity JSON
(protocolVersion:8)
5. 190.1.1.142 → 190.1.1.2 [ACK 2372] ← phone ACKs the identity
6. ...silence... ← ClientHello never sent by
phone
7. desktop tears down, retries. Loop forever.
The phone receives the identity, TCP-acks the full payload, and refuses to
progress to TLS. Because kdeconnect's protocol makes the phone the SSL client
in this role-inversion, the handshake never begins.
Confirmed empirically by adding a secondary 192.168.77.2/24 address to the
desktop's interface and bringing the phone into that private subnet (via USB
tethering): pairing completed instantly and normally. Moving the phone back to
the 190.1.1.0/24 LAN restored the silent-drop behaviour, ruling out anything
except the source-IP category of the desktop peer.
EXPECTED RESULT
Either the phone completes the TLS handshake and the device appears (my
preference — a LAN whose SSID I have explicitly marked as trusted should be
trusted for source-IP too), OR the phone surfaces the rejection to the user
with a visible reason ("device rejected: non-private source IP <x>") instead of
silently dropping. Silent-drop is the worst part of this bug — it took a
full-day diagnostic and a packet capture to identify the cause.
Suggested fixes, any one of which would resolve this class of report:
1. A user-configurable trusted-subnet list in Android app settings, in addition
to the existing Trusted SSID feature.
2. Extend the existing "Trusted networks (SSID)" feature to also relax the
source-IP check while connected to a trusted SSID. If the user has declared
"this Wi-Fi is trusted", accept peers on it regardless of their IP block.
3. At minimum, log the rejection so users can diagnose it without a packet
capture.
Why this matters to me: my home LAN is 190.1.1.0/24 (a public prefix that some
SOHO routers ship as factory default). I have multiple servers on static IPs in
that range wired into DNS, firewall rules, backup scripts, docker configs.
Renumbering to 192.168/24 is a multi-day operation that would break dozens of
pinned configs. The private-only guard makes KDE Connect unusable on the one
network where I actually need it — my own home — while providing no
user-visible way to loosen it. More generally: whether a network is trustworthy
is a policy the user is in a position to state, not something the app can
safely infer from RFC1918-ness of a source IP.
SOFTWARE/OS VERSIONS
Operating System: CachyOS Linux (rolling), Linux 7.1.8-1-cachyos x86_64
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Android side: KDE Connect for Android 1.35.13 (current stable, F-Droid & Play
Store), Android 14, Samsung Galaxy S23 Ultra.
Desktop side: kdeconnect 26.08.0 (also reproduced on 26.04.1, 26.04.2,
26.04.3). OpenSSL 3.6.3.
ADDITIONAL INFORMATION
Diagnostics already ruled out (do not need to be re-suggested):
- Firewall: UFW rules for 1714-1764 tcp+udp+v6 added; ufw disable — no change.
- Router / L2: UDP identity broadcasts flow in both directions, TCP handshake
completes, Avahi discovers the peer correctly. Avahi: Discovered "<device-id>"
at "190.1.1.142" in desktop logs.
- kdeconnect-kde downgrade/upgrade across 26.04.1 → 26.04.2 → 26.04.3 → 26.08.0
— identical behaviour.
- OpenSSL: 3.6.3, in place since 2026-06-10; KDE Connect worked on this exact
OpenSSL for over two months before the phone side started dropping.
- Config: full wipe of ~/.config/kdeconnect,
~/.local/state/kdeconnect.daemonstaterc, cache. Regenerated EC key (RSA gets
overwritten to EC on daemon start, hardcoded). Multiple daemon restarts + full
desktop reboot.
- Android app: reinstalled 5×, cleared data, re-paired from scratch.
- "Trusted networks" (SSID whitelist) enabled in Android app for my home Wi-Fi
— no effect on the failure. This confirms the SSID-trust feature and the
source-IP guard are independent checks.
- The failure is purely at the "phone should now start TLS" step; every prior
step of the protocol works.
Full tcpdump captures and daemon debug logs available on request.
[23.8.2026 1:00] Николай ניקולאי: Android app silently drops peers with
non-RFC1918 source IPs, breaking KDE Connect on any LAN using a public prefix
Related bugs (same underlying private-IP source filter, different scenarios):
- Bug 443207 (REPORTED, 2021) — KDE Connect fails over WireGuard on RFC1918.
Same silent-drop symptom, VPN scenario.
- Bug 515707 (RESOLVED FIXED in 1.35.3, 2026) — TLS handshake fails over
Tailscale VPN. Fixed by widening the whitelist to include CGNAT (100.64/10)
and IPv6 ULA. This report asks for the same widening to cover
user-declared trusted LANs on public prefixes.
Together these three bugs suggest the private-only filter needs to become
user-configurable rather than being widened one exception at a time.
--
You are receiving this mail because:
You are watching all bug changes.
