[karmakaze]

I was wondering what "the network" here means:

> To achieve this, KDE Connect:

    implements a secure communication protocol over the network, and allows any developer to create plugins on top of it.
    Has a component that you install on your desktop.
    Has a KDE Connect client app you run on your phone.

Looking further it is only for the local network (with ways to extend it e.g. VPNs).

[blooalien]

> Has a component that you install on your desktop.

This is only if you use Windows (or MacOS, as there's also a KDE Connect compatible Mac app out there somewhere IIRC). If you're on KDE Desktop Linux, you're already good-to-go, as it's a pre-installed component of a typical KDE environment. :)

[1oooqooq]

not true for all distros. and this kind of thinking is really bad imo for network services.

[creatonez]

It has bluetooth support now as well

[m463]

it also talks about using a VPN and what ports to open in a firewall.

I don't know how it handles the harder part, the "device on internet" talks to "device in my house"

most phones and apps use this "harder part" to interpose their corporate server for more than TURN/STUN and continue to "collect all the data" or "insert a subscription"

[Oxodao]

Did you get this to work with wireguard though?

As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.

I would really like to have a solution to this issue but since its baked in WG i don't think this is possible

[jeroenhd]

WireGuard doesn't do any forwarding out of the box, you need to set up your iptables/nftables to get all of that working. If you follow the WG quick-start guides, they often work by masquerading traffic, making VPN clients act the same way a bunch of computers behind a NAT router would.

You'll need to set up all other kinds of routing as well for cross-network discovery to work. WireGuard doesn't do broadcasting in general (it's a point-to-point protocol after all) so you'll need to wrap broadcasting protocols manually.

Other VPNs go more low-level (at least in TAP mode), mirroring an ethernet network with all the broadcasting and low-level protocols you can think of. In theory you could do that in WireGuard (running L2TP over a WireGuard link) but many phones won't support that, and it'd probably be just as easy to set up an OpenVPN/IPSec+L2TP VPN in that case.

I'm not sure if it's a good idea, though. I imagine most people wouldn't want a printer publishing its mDNS hostname to wake the 5G radio on their phone, or the battery level of their laptop in the case of KDE connect.

[m463]

Actually, I mean the whole "find and talk to my home server over the internet"

Generally it does this by having a DNS record for your home server, or having some other well-known server give out its address or relay the packets.

[jeroenhd]

KDE Connect leverages mDNS on the network (non-Bluetooth) side, which relies on broadcasts. That means it'll break across networks without a VPN of some kind. For some VPNs (Wireguard, OpenVPN in TUN mode) that also means connectivity is impossible.

You can, if you want, open ports and configure KDE connect to reach out across the internet (practically only feasible with one device behind your router on IPv4, any on IPv6), but because it doesn't use "real" DNS, you can't just enter a DDNS hostname, you have to specify the full IP address.

[ValdikSS]

>As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.

It's a bug in the application.

https://bugs.kde.org/show_bug.cgi?id=507954 / https://bugs.kde.org/show_bug.cgi?id=507972

[1oooqooq]

mdns is a really awful protocol. it was already bad in the era it was born, being just an evolution of Microsoft NetBIOS out something. today in the age of wifi and overlay networks, i just consider it information leak with zero benefits.

so, the rfc have a section on how the mdns server have to evolve to handle multiple interfaces and own that. but in reality nobody gives a damn because the maintainer (redhat ibm) is it in the context it was invented (work networks on the 00s), so everyone (like many comments below) just work around in all the wrong ways making other things more complicated.

"just do these hundreds changed on wireguard, your firewall, install this reverse proxy... now your service that only exists to route things automatically can look like it works" heh.

[seszett]

> the "device on internet" talks to "device in my house"

It doesn't handle it well other than with bluetooth or awkward port forwarding and manual entering of IPs.

I don't see it as a problem though, I don't think I have needed a single time over my many years of use to share my clipboard with, or control the media player or mouse and keyboard, of a device that was not in the same room or on the same network as me.