when it works it's amazing. but very often both my phone and laptop are connected to the same WiFi, yet kde connect can't see them. I can't figure out how to diagnose and solve that when it happens
replies(14):
I would try fixed IPs to see if this solves the issue for you.
Many VPN configurations break mDNS and other broadcasts (i.e. Chromecast, file shares, that kind of thing), though. A lot of "how to get started with WireGuard/OpenVPN/etc." guides stop the moment HTTP(S) connections work, but there's more to a functional network than that.
I found that I could get KDE Connect working on my buggy VPN profile by manually specifying remote IP addresses for devices on the other end of the VPN in the settings.
The computer doesn't even change addresses, there is no need for mDNS or anything fancy, setting up devices manually once would be just fine.
In the last year I have even given up on KDE in favor of Cinnamon on Mint.I loved KDE but there would always be some issue coming up. LTS Mint with Cinnamon has been rock solid.
If I was working on KDE Connect I would add a microphone and speaker based pairing system using OFDM modulation lifted from Rattlegram. Each device would share all IP addresses associated with themselves using sound to broadcast the information.
Linux, Android, iOS, macOS all worked in harmony. Now not even two Android phones using the same software version can see each other, file transfers keep failing after a brief while. And all with the same devices that worked before, across various networks.
Not to say anything about connectivity between Linux and Android or iOS.
Suffice it to say: at the time I bought this iPhone 12 mini, there weren't really good options when prioritizing {small form factor,good privacy posture,good security posture,software freedom}.
Often desktop client just cannot connect to mobile. At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):
kdeconnect.core: Too many remembered identities, ignoring "<id of KDE Connect on my android device>" received via UDP
#!/bin/dash -x
while sleep 1m; do
nmcli connection show --active | grep wifi || continue
kdeconnect-cli -l | grep reachable && continue
# notify-send 'No reachable devices via kdeconnect. Restarting'
systemctl --no-pager --user status app-org.kde.kdeconnect.daemon@autostart.service
systemctl --no-pager --user stop app-org.kde.kdeconnect.daemon@autostart.service
killall kdeconnectd
systemctl --no-pager --user start app-org.kde.kdeconnect.daemon@autostart.service
done
But it doesn't really matter, because KDE Connect implements its own sort-of mDNS system by itself, in the form of JSON broadcast across the local network on a standard port offering hostnames, services, and other metadata. Actual, real mDNS would require integration into the host's networking setup and that's too much to ask for clients like Android or iOS and you'd need to implement it manually in many other cases, so they kind of made their own mDNS. It also means you don't need root access to run KDE Connect on your device, which makes it viable on platforms like the Steam Deck.
To get KDE Connect working reliably, you need to make multicast traffic work reliably. Every network has its own restrictions when it comes to multicast so it's hard to know what specific tweaks your workstation needs. Having KDE Connect open on your phone, you should see packets coming in on your desktop on 255.255.255.255 on 1716/udp.
To the point that I'd say that Wi-Fi drivers are the most offender in printer discovery problems, which also rely on mDNS.
Another issue that many mDNS applications, including KDE Connect, don't account on multi-interface setups and send respond to mDNS request using incorrect network interface: https://bugs.kde.org/show_bug.cgi?id=507972 / https://bugs.kde.org/show_bug.cgi?id=507954
> > Then why use iOS?
> I don't need software freedom preached to me, thanks
...and we don't need to hear kvetching about self-inflicted punishment. If it was 'amazing' on Android and is 'dreadful' on iOS the solution seems clear.
> Suffice it to say: at the time I bought this iPhone 12 mini, there weren't really good options when prioritizing {small form factor,good privacy posture,good security posture,software freedom}.
Who cares about privacy and security postures? I'd rather have real privacy and security, never mind any posturing done by vendors whom have shown not to be trustworthy anyway.
Mentioning something iOS together with software freedom is as oxymoronic as it gets. There is no software freedom on iOS, you accept what you're offered and say thank you Sir may I have another [1]. Complaining about these well-known restrictions while passive-aggressively defending your choice does not make any sense.