I have used KDEConnect before no problem. Some recent updates have completely broken the connections between my desktop (Arch linux, kdeconnect 24.05.2-2), laptop (Arch linux, kdeconnect 24.05.2-2)and phone (android/Oneplus 6). None of the devices are finding each other. All devices are on the same network.
I have deleted ~/.config/kdeconnect folders on both computers and reinstalled the packages.
I have enabled firewall ports 1714-1764 and am allowing the kdeservice on the profile my network interface uses for the network in question.
I have also tried disabling firewalld on both computers and they are still not finding each other.
I have followed troubleshooting steps on the kde userbase wiki which I cannot link.
$ netcat -z -v 192.168.0.136 1714-1764
192.168.0.136 1716 (xmsg) open
This seems fine although I don’t know if xmesg is expected or something else.
This post seems very similar which I cannot link but the title is ‘KDE Connect - Devices on same network not visible’, but I do not have opensnitch installed.
The only firewall related packages I install and enable are: nftables-nft and firewalld.
While troubleshooting further it seems the netcat -z -v x.x.x.x 1714-1764 command does not find an open port on my laptop or desktop. This is true even when firewalld is off.
Using netstat I can confirm that the both the laptop and desktop have opened their ports on 1716.
I’m trying to get to the bottom of this but I’m not versed in iptables so any help would be appreciated.
Just booted my laptop for poking around with netcat, just as you did.
I noticed that my phone was happy to connect to the laptop. It’s also running Arch, but the last upgrade was from 9.5. Upgrading everything broke kdeconnect on the laptop too.
Using the downgrade (AUR) package I tried downgrading the kdeconnect package to 24.04.90, 24.02.2, 24.01.95. I cannot downgrade to 23.x.x however since it results in a dependency conflict. Any of the previous versions I have managed to try out have not solved the problem.
I managed to install the dependency separately, and was able to downgrade to 23.07.80-1 and even 22.12.3-1. None of these versions worked, and this last version is from a year ago and the issue has not persisted for that long. This leads me to conclude the issue is not directly related to the kdeconnect package.
EDIT: In these cases I used my phone (oneplus 11) and desktop (Arch). And I stopped and restarted the kdeconnect process between downgrades
Hmmmh. Some change in OpenSSH broke filesystem expose already before kdeconnect broke down completely, but perhaps it’s not to blame for the total loss of connectivity.
Firewall things would be the next suspects I suppose. I’m using firewalld also, and can confirm that there was an update to that too on the laptop. (I tried to enable logging on firewalld to no avail.)
I found out that flushing the nftables ruleset solves the problems, although I think it’s probably not wise to do so. See also Arch Linux page on nftables.
Remove rules
$ sudo nft list ruleset # many rules
$ sudo nft flush ruleset
$ sudo systemctl restart NetworkManager firewalld
$ sudo nft list ruleset # no rules
Add rules
$ sudo systemctl restart nftables NetworkManager firewalld
$ sudo nft list ruleset # many rules
So yeah, I am not sure why but nftables is blocking this. I don’t have the knowledge to troubleshoot this atm, and I am unsure whether this is due to a bug between nftables and firewalld or just a misconfiguration in the end user’s part. It’s probably high time I figure out a bit more how firewalls on linux work lol.
I’m not an expert either, but to me it looks like everywhere where there’s a reject rule, there’s also a loggin rule just before it, and yet my logs remain empty…
Ok I took the time to figure out nftables tracing, and figured out what was my problem (but not what was different before).
The kdeconnect packets were dropped by the default policy in the nftables configuration delivered with the nftables package. It’s defined in /etc/nftables.conf. This happens because this configuration has higher priority than firewalld’s own input chain.
This default config probably shouldn’t be used together with firewalld at all. The sole job of nftables.service is to load this config, so the fix is to disable this service and reboot. Really I think that nftables.service and firewalld.service should conflict each other to prevent this sorta confusion.
This default config probably shouldn’t be used together with firewalld at all.
Right… I think firewalld uses nftables as a backend but this doesnt mean we need to load the default nftables config file for the firewalld to work. I think firewalld does this properly on it’s own.
As per the archlinux page on nftables:
nftables comes with a simple and secure firewall configuration stored in the /etc/nftables.conf file.
The nftables.service will load rules from that file when started or enabled.