https://bugs.kde.org/show_bug.cgi?id=526727
Bug ID: 526727
Summary: KDE Connect fails to connect to an Android device when
the Linux PC is behind a WISP/NAT router, with UDP
packets being discarded as duplicate packets from the
router's source IP.
Classification: Applications
Product: kdeconnect
Version First 26.08.1
Reported In:
Platform: Other
OS: Android 17.x
Status: REPORTED
Severity: normal
Priority: NOR
Component: android-application
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Created attachment 196881
--> https://bugs.kde.org/attachment.cgi?id=196881&action=edit
Log from the app
DESCRIPTION
KDE Connect fails to establish a connection between an Android device and a
Linux PC when the PC is behind a TP-Link router operating in WISP mode.
The network topology is:
Android phone
192.168.68.x
│
│ Wi-Fi
▼
Main router
192.168.68.1
│
│ Wi-Fi
▼
TP-Link WR840N (WISP mode)
WAN: 192.168.68.101
LAN: 192.168.0.1
│
│ Ethernet
▼
Linux PC
192.168.0.100
The PC has KDE Connect listening on port 1716, and TCP/UDP ports 1714–1764 are
allowed through the PC firewall. Port forwarding is also configured on the WISP
router.
The devices were previously paired successfully. The Linux PC still retains the
Android device as a paired device.
However, KDE Connect currently fails to establish the connection.
The Android KDE Connect log contains repeated messages indicating that UDP
packets are being received from 192.168.68.101, which is the WISP router's WAN
address, rather than the actual PC address:
LanLinkProvider: Discarding second UDP packet from the same ip /192.168.68.101
received too quickly
KDE Connect starts its UDP listener normally on port 1716. The above
packet-discard message occurs repeatedly in the log.
This appears to be related to the NAT performed by the WISP router, where
packets originating from the PC appear to the Android device as coming from the
router's single WAN address.
I am reporting this because KDE Connect appears to receive the packets but then
discard subsequent packets based on their apparent source IP.
STEPS TO REPRODUCE
1. Connect an Android device to a normal Wi-Fi router on network
192.168.68.0/24.
2. Connect a Linux PC through a second TP-Link WR840N router operating in WISP
mode.
3. Configure the WISP router with:
- WAN: 192.168.68.101
- LAN: 192.168.0.1
- Linux PC: 192.168.0.100
4. Allow TCP/UDP ports 1714–1764 through the Linux firewall and forward those
ports from the WISP router to 192.168.0.100.
5. Pair the Android device with the Linux PC in KDE Connect.
6. Attempt to establish the KDE Connect connection.
OBSERVED RESULT
The Android device does not establish a KDE Connect connection with the Linux
PC.
The Android KDE Connect log repeatedly reports:
LanLinkProvider: Discarding second UDP packet from the same ip /192.168.68.101
received too quickly
The source IP shown in this message is the WISP router's WAN address rather
than the Linux PC's address.
Basic IP connectivity between the networks is functional; the Android device
can reach 192.168.68.101.
EXPECTED RESULT
KDE Connect should either:
- correctly handle multiple KDE Connect packets arriving through NAT from the
same source IP, or
- provide a supported mechanism for manually connecting to a known peer behind
NAT/routing without relying on LAN discovery.
If NAT/WISP networks are intentionally unsupported, KDE Connect should ideally
document this limitation and/or provide a clear indication that the connection
cannot be established because of the network topology.
SOFTWARE/OS VERSIONS
Operating System: Linux (distribution/version to be filled in)
KDE Plasma Version: [please fill in]
KDE Frameworks Version: [please fill in]
Qt Version: [please fill in]
KDE Connect Android version: 1.35.17
Android version: Android 17
Device: Google Pixel 7a
ADDITIONAL INFORMATION
The Linux PC has kdeconnectd listening on TCP/UDP port 1716.
UFW is configured to allow KDE Connect's port range:
1714:1764/tcp
1714:1764/udp
The Android device was previously paired successfully, and the pairing
information is still present on the Linux PC.
The Android log also shows that KDE Connect starts its UDP listener
successfully and uses port 1716.
The main issue appears to occur after packets reach the Android KDE Connect
process, where packets from the same apparent source address (192.168.68.101)
are discarded by LanLinkProvider. The same behavior is repeated elsewhere in
the log.
I can provide the complete Android KDE Connect debug log, Linux logs, packet
captures, and router configuration if additional information is required.
--
You are receiving this mail because:
You are watching all bug changes.
