You are not logged in.

Pages: 1

#1 2026-10-14 20:23:21

gooseyloosey
Member
Registered: 2025-10-15
Posts: 11

KDE Connect on both Android and computer refuse to find each other

What it says on the tin. Neither one recognizes the other, and even adding them to the specific devices list, as described in this section of the KDE Connect help page has no effect.

Following this section or even official Arch recommendations has no effect.

My firewall on Linux is set up thusly:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 1714:1764/tcp              ALLOW IN    192.168.1.0/24            
[ 2] 1714:1764/udp              ALLOW IN    192.168.1.0/24            
[ 3] Anywhere on lxcbr0         ALLOW IN    Anywhere                  
[ 4] Anywhere                   ALLOW FWD   Anywhere on lxcbr0        
[ 5] 1714:1764/udp              ALLOW IN    192.168.100.0/24          
[ 6] 1714:1764/tcp              ALLOW IN    192.168.100.0/24          
[ 7] Anywhere (v6) on lxcbr0    ALLOW IN    Anywhere (v6)             
[ 8] Anywhere (v6)              ALLOW FWD   Anywhere (v6) on lxcbr0

The one allowing 192.168.1.0/24 was me making a dumb mistake, my local network is 192.168.100.0/24.

Here is the output of "sudo netstat -tunelp | grep -i kdeconnectd":

tcp6       0      0 :::1716                 :::*                    LISTEN      1000       40283      4565/kdeconnectd    
udp        0      0 0.0.0.0:57083           0.0.0.0:*                           1000       41408      4565/kdeconnectd    
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           1000       38965      4565/kdeconnectd    
udp        0      0 0.0.0.0:43033           0.0.0.0:*                           1000       41410      4565/kdeconnectd    
udp        0      0 0.0.0.0:47184           0.0.0.0:*                           1000       41406      4565/kdeconnectd    
udp6       0      0 :::48601                :::*                                1000       41411      4565/kdeconnectd    
udp6       0      0 :::5353                 :::*                                1000       38966      4565/kdeconnectd    
udp6       0      0 :::50486                :::*                                1000       41412      4565/kdeconnectd    
udp6       0      0 :::54765                :::*                                1000       41409      4565/kdeconnectd    
udp6       0      0 :::1716                 :::*                                1000       40282      4565/kdeconnectd    
udp6       0      0 :::35916                :::*                                1000       41407      4565/kdeconnectd

And the phone is listening, as confirmed by "netcat -z -v 192.168.100.103 1714-1764":

<A bunch of Connection Faileds>
Connection to 192.168.100.103 1716 port [tcp/xmsg] succeeded!
<Another bunch of Connection Faileds>

The few tiny gotchas that I have confirmed:

They are both connected to the same local network
Said local network has been checked for firewall and other rules that might stop this; none exist in the settings that I can access through the router's webpage.
While probably not likely to affect things, where I live, IPv6 routing basically doesn't exist (I do not have a public-facing IPv6 address, for example), but it doesn't sound like the sort of thing that should break things locally
That said, I should point out that I can't ping my phone by its IPv6 address, nor can I, on my own computer, access a webpage I'm hosting for myself, through IPv6. I can do it fine through IPv4. I can't tell if that would be relevant or no.
That said(^2), I also can't curl or otherwise access the self-hosted webpage through curl, so maybe I just don't understand IPv4-ing vs. IPv6-ing.

Any help would be appreciated!

Offline

#2 2026-10-16 19:35:29

gabrielsec
Member
From: Brazil | Rio De Janeiro
Registered: 2026-10-16
Posts: 18

Re: KDE Connect on both Android and computer refuse to find each other

Your UFW rules already allow TCP and UDP ports 1714–1764 from `192.168.100.0/24`, so I wouldn't add more firewall rules yet. The successful `netcat` test only confirms that your PC can reach the phone's TCP port 1716; it doesn't verify UDP discovery or connectivity in the opposite direction.

The ArchWiki KDE guide confirms that KDE Connect needs TCP and UDP ports 1714–1764. The KDE Connect troubleshooting guide also notes that UDP broadcast packets must not be blocked.

I'd capture the traffic while reproducing the problem. First, identify your LAN interface:

ip -br address

Then replace `<interface>` with the interface connected to `192.168.100.0/24` and run:

sudo tcpdump -ni <interface> 'tcp portrange 1714-1764 or udp portrange 1714-1764 or udp port 5353'

While the capture is running, refresh KDE Connect on both devices and try pairing by IP again. On the phone, use the PC's IP address; on the PC, the `customDevices` setting should contain the phone's IP. The KDE Connect documentation describes manual pairing.

If no packets from the phone reach the PC, I'd investigate Wi-Fi client isolation, guest-network settings, VLAN separation, or a VPN. If the packets do arrive, the capture should help identify whether the connection is being blocked locally or failing at another stage.

Regards, 
Gabriel

The more we help each other, the better the world becomes.

Share knowledge, be kind, and don't let toxicity define the community.

Offline

#3 2026-10-17 08:03:16

gooseyloosey
Member
Registered: 2025-10-15
Posts: 11

Re: KDE Connect on both Android and computer refuse to find each other

I took the output of the tcpdump command you provided, and trimmed it down just a tad, to avoid muddying the waters (for e.g., Tailscale butting in)

My computer's IPv4 address is 192.168.30.177, and my phone is 192.168.30.173.

My phone's IPv6 address is fe80::cb12::<so-on-and-so-forth>, and my computer's is fe80::5959::<so-on-and-so-forth>, but the computer's doesn't appear at all in the output.


(note: I am currently on a different network, the appropriate ufw commands have been run to allow connections from the local network)

11:25:39.507391 IP 192.168.30.173.57981 > 192.168.30.177.1716: UDP, length 1822
11:25:39.576034 IP 192.168.30.173.57981 > 255.255.255.255.1716: UDP, length 1822
11:25:40.523261 IP 192.168.30.173.5353 > 224.0.0.251.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:40.523269 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:41.612164 IP 192.168.30.173.5353 > 224.0.0.251.5353: 3 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:41.612167 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 3 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:42.162696 IP 192.168.30.177.59555 > 255.255.255.255.1716: UDP, length 2303
11:25:42.162723 IP 192.168.30.177.59555 > 192.168.100.103.1716: UDP, length 2303
11:25:42.162743 IP 192.168.30.177.59555 > 192.168.30.173.1716: UDP, length 2303
11:25:42.164080 IP 192.168.30.177.36254 > 224.0.0.251.5353: 0 PTR (QU)? _kdeconnect._udp.local. (40)
11:25:42.245016 IP 192.168.30.173.57552 > 192.168.30.177.1716: Flags [S], seq 1583673051, win 65535, options [mss 1460,sackOK,TS val 596412483 ecr 0,nop,wscale 10], length 0
11:25:42.337954 IP 192.168.30.173.5353 > 192.168.30.177.36254: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:42.365696 IP 192.168.30.173.50627 > 255.255.255.255.1716: UDP, length 1822
11:25:42.367266 IP 192.168.30.173.50627 > 192.168.30.177.1716: UDP, length 1822
11:25:42.649599 IP 192.168.30.161.5353 > 224.0.0.251.5353: 0 [3q] ANY ANY (QM)? _adb-tls-pairing._tcp.local. ANY ANY (QM)? _adb-tls-connect._tcp.local. ANY ANY (QM)? _adb._tcp.local. (99)
11:25:43.468633 IP 192.168.30.173.5353 > 224.0.0.251.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:43.468638 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:44.060631 IP 192.168.30.177.48799 > 255.255.255.255.1716: UDP, length 2303
11:25:44.060673 IP 192.168.30.177.48799 > 192.168.30.173.1716: UDP, length 2303
11:25:44.061620 IP 192.168.30.177.44642 > 224.0.0.251.5353: 0 PTR (QU)? _kdeconnect._udp.local. (40)
11:25:44.098296 IP 192.168.30.173.45410 > 192.168.30.177.1716: Flags [S], seq 1573893882, win 65535, options [mss 1460,sackOK,TS val 596414336 ecr 0,nop,wscale 10], length 0
11:25:44.139581 IP 192.168.30.173.5353 > 192.168.30.177.44642: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:44.292413 IP 192.168.30.173.42146 > 192.168.30.177.1716: UDP, length 1822
11:25:44.392171 IP 192.168.30.173.42146 > 255.255.255.255.1716: UDP, length 1822
11:25:45.311923 IP 192.168.30.173.5353 > 224.0.0.251.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:45.311926 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:46.048986 IP 192.168.30.173.45317 > 192.168.30.177.1716: UDP, length 1822
11:25:46.129312 IP 192.168.30.173.45317 > 255.255.255.255.1716: UDP, length 1822
11:25:46.440398 IP 192.168.30.177.43587 > 255.255.255.255.1716: UDP, length 2303
11:25:46.440446 IP 192.168.30.177.43587 > 192.168.30.173.1716: UDP, length 2303
11:25:46.441552 IP 192.168.30.177.34761 > 224.0.0.251.5353: 0 PTR (QU)? _kdeconnect._udp.local. (40)
11:25:46.666511 IP 192.168.30.173.5353 > 192.168.30.177.34761: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:47.155705 IP 192.168.30.173.5353 > 224.0.0.251.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:47.155712 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:48.076552 IP 192.168.30.173.5353 > 224.0.0.251.5353: 3 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:48.076556 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 3 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:48.242581 IP 192.168.30.177.60323 > 255.255.255.255.1716: UDP, length 2303
11:25:48.242644 IP 192.168.30.177.60323 > 192.168.30.173.1716: UDP, length 2303
11:25:48.243868 IP 192.168.30.177.45975 > 224.0.0.251.5353: 0 PTR (QU)? _kdeconnect._udp.local. (40)
11:25:48.261836 IP 192.168.30.173.45418 > 192.168.30.177.1716: Flags [S], seq 2233318401, win 65535, options [mss 1460,sackOK,TS val 596418498 ecr 0,nop,wscale 10], length 0
11:25:48.394851 IP 192.168.30.173.5353 > 192.168.30.177.45975: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:54.412888 IP 192.168.30.173.45840 > 192.168.30.177.1716: UDP, length 1822
11:25:54.424139 IP 192.168.30.173.45840 > 255.255.255.255.1716: UDP, length 1822
11:25:55.148808 IP 192.168.30.177.45002 > 255.255.255.255.1716: UDP, length 2303
11:25:55.148867 IP 192.168.30.177.45002 > 192.168.30.173.1716: UDP, length 2303
11:25:55.150155 IP 192.168.30.177.51399 > 224.0.0.251.5353: 0 PTR (QU)? _kdeconnect._udp.local. (40)
11:25:55.262551 IP 192.168.30.173.34606 > 192.168.30.177.1716: Flags [S], seq 3140612487, win 65535, options [mss 1460,sackOK,TS val 596425496 ecr 0,nop,wscale 10], length 0
11:25:55.378060 IP 192.168.30.173.5353 > 192.168.30.177.51399: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:55.446245 IP 192.168.30.173.5353 > 224.0.0.251.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:55.446395 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 2 [1a] PTR (QM)? _kdeconnect._udp.local. (87)
11:25:56.473652 IP 192.168.30.173.5353 > 224.0.0.251.5353: 3 PTR (QM)? _kdeconnect._udp.local. (40)
11:25:56.473657 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 3 PTR (QM)? _kdeconnect._udp.local. (40)
11:25:56.473711 IP 192.168.30.173.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:56.576459 IP6 fe80::cb12:4762:7998:7130.5353 > ff02::fb.5353: 0*- [0q] 1/0/6 PTR e3ad6800f90d464e9de024f50bfddb2a._kdeconnect._udp.local. (292)
11:25:57.289636 IP 192.168.30.161.5353 > 224.0.0.251.5353: 0 [3q] ANY ANY (QM)? _adb-tls-pairing._tcp.local. ANY ANY (QM)? _adb-tls-connect._tcp.local. ANY ANY (QM)? _adb._tcp.local. (99)

As far as I've looked into the output of tcpdump, and the little I know about the TCP protocol, both sides are trying to start a TCP connection, but it's failing for... Reasons? I don't know enough about tcpdump to understand why it might fail. I even added 5353/udp to my ufw allowlist and it's still broken.

I have no idea what the connections to 224.0.0.251 are about either.

Offline

#4 2026-10-19 18:23:42

gooseyloosey
Member
Registered: 2025-10-15
Posts: 11

Re: KDE Connect on both Android and computer refuse to find each other

Further testing has revealed that my computer is the issue here; my phone, in connecting to different networks, has managed to "find" available KDE Connect devices; my computer hasn't.

Offline

#5 2026-10-20 10:58:16

gooseyloosey
Member
Registered: 2025-10-15
Posts: 11

Re: KDE Connect on both Android and computer refuse to find each other

More context:

On this machine, I used to run the KDE Plasma DE, with nearly the whole nine yards of packages provided by the package group. I have deleted most of those packages now, and am on Sway. I don't know if this ordering of events means anything to anyone, but I it might be helpful.

Furthermore, I'm using systemd-resolved for DNS resolution.

The output of systemd-resolved contains the following:

Oct 20 14:12:36 pangea systemd-resolved[86968]: mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
Oct 20 14:12:36 pangea systemd-resolved[86968]: mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.

I don't know if this is related to NetworkManager being enabled alongside it, or what else it could be caused by. Or if this is just noise.

Also, running with no firewall doesn't help,, I forgot if I'd said that before or not.

I apologize if this pattern of replying seems like spam, I have been desperately trying to fix this for the past few days and I have hit wall after wall.

Offline

#6 2026-10-20 17:20:19

gooseyloosey
Member
Registered: 2025-10-15
Posts: 11

Re: KDE Connect on both Android and computer refuse to find each other

After fiddling and diddling with everything, and learning more about mDNS than I otherwise would have, (make sure to activate mDNS on your network manager too!), I reached a new impasse:

{"id":1792515899132,
	"type":"kdeconnect.identity",
	"body": {
		"deviceId":"e3ad6800f90d464e9de024f50bfddb2a",
		"deviceName":"Galaxy A34 5G",
		"protocolVersion":8,
		"deviceType":"phone",
		"incomingCapabilities":[
			"kdeconnect.battery",
			"kdeconnect.clipboard",
			"kdeconnect.clipboard.connect",
			"kdeconnect.contacts.request_all_uids_timestamps",
			"kdeconnect.contacts.request_vcards_by_uid",
			"kdeconnect.findmyphone.request",
			"kdeconnect.mousepad.request",
			"kdeconnect.shareinputdevices.request",
			"kdeconnect.mousepad.keyboardstate",
			"kdeconnect.mpris",
			"kdeconnect.mpris.request",
			"kdeconnect.notification.request",
			"kdeconnect.notification.reply",
			"kdeconnect.notification.action",
			"kdeconnect.ping",
			"kdeconnect.notification",
			"kdeconnect.runcommand",
			"kdeconnect.runcommand.output",
			"kdeconnect.sftp.request",
			"kdeconnect.share.request",
			"kdeconnect.share.request.update",
			"kdeconnect.sms.request",
			"kdeconnect.sms.request_conversations",
			"kdeconnect.sms.request_conversation",
			"kdeconnect.sms.request_attachment",
			"kdeconnect.systemvolume",
			"kdeconnect.telephony.request_mute"],
		"outgoingCapabilities":[
			"kdeconnect.battery",
			"kdeconnect.clipboard",
			"kdeconnect.clipboard.connect",
			"kdeconnect.connectivity_report",
			"kdeconnect.contacts.response_uids_timestamps",
			"kdeconnect.contacts.response_vcards",
			"kdeconnect.digitizer.session",
			"kdeconnect.digitizer",
			"kdeconnect.findmyphone.request",
			"kdeconnect.shareinputdevices",
			"kdeconnect.mousepad.request",
			"kdeconnect.mpris.request",
			"kdeconnect.mpris",
			"kdeconnect.notification",
			"kdeconnect.ping",
			"kdeconnect.presenter",
			"kdeconnect.notification.request",
			"kdeconnect.mousepad.echo",
			"kdeconnect.mousepad.keyboardstate",
			"kdeconnect.runcommand.request",
			"kdeconnect.sftp",
			"kdeconnect.share.request",
			"kdeconnect.sms.messages",
			"kdeconnect.sms.attachment_file",
			"kdeconnect.systemvolume.request",
			"kdeconnect.telephony"
			],
		"tcpPort":1716
	}
}

This is the body of the UDP packet(?) that my computer receives from my phone when I tell the phone's KDE Connect to refresh. In response, my computer prepares a response, in the form of ICMP:

{
	"id": 1792515899132,
	"type":"kdeconnect.identity",
	"body": {
		"deviceId":  "e3ad6800f90d464e9de024f50bfddb2a",
		"deviceName": "Galaxy A34 5G",
		"protocolVersion":8,
		"deviceType":"phone",
		"incomingCapabilities": [
			"kdeconnect.battery",
			"kdeconnect.clipboard",
			"kdeconnect.clipboard.connect",
			"kdeconnect.contacts.request_all_uids_timestamps",
			"kdeconnect.contacts.request_vcards_by_uid",
			"kdeconnect.findmyphone.request",
			"kdeconnect.mousepad.request",
			"kdeconnect.shareinputdevices.request",
			"kdeconnect.mousepad.keyboardstate",
			"kdeconnect.mpri

However, as you can see, the JSON is incomplete; the response is cut off. I have deduced, astutely, without any outside help (thank you Wireshark), that the destination is, for some reason, unreachable, with the specific error being "Code 13: Communication Administratively Filtered". This makes me think a firewall would have stopped it in its tracks, but a) I don't have any UFW rules that would stop an outgoing ICMP packet, and b) I can ping the phone just fine, and the phone can similarly ping back. I'm not aware of any settings on my router that would stop ICMP.

Edit: Scratch my theory, they're the same data. I need some sleep. I'll continue tackling it later.

Last edited by gooseyloosey (2026-10-20 17:21:06)

Offline

Pages: 1

Board footer

Powered by FluxBB