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

--- Comment #6 from Keith Zubot-Gephart <keit...@gmail.com> ---
(In reply to Matthijs Tijink from comment #5)
> I think the problem might be that connecting to a server which is remotely
> connected through VPN is impossible (after all: how should the VPN know
> which remote VPN connection it should go to?). KDE Connect works by sending
> an UDP broadcast as you mentioned, and direct UDP packets to the configured
> ip addresses (only on Android). The other device reacts by setting up a TCP
> connection to the source of the UDP packet. So both devices act like a
> server in this setting up process. I hope it's somewhat clear what I mean.

Sure, but everything there except for the UDP broadcast works completely fine
via the VPN connection; I can send TCP and UDP packets between remote and local
machines just fine using their addresses, and I can't see what the UDP
broadcast could possibly be for other than discovering the addresses to
potentially send to; if you tell it precisely the address, why not use that
address? Figuring out where to route the traffic to when given an address to
use is the networking stack's job, not the software's job. And in my testing,
manually sending UDP packets over the VPN to specific addresses has worked
fine.

Anyways, though, I've given your testing steps a shot---thanks very much for
bringing that up, I should have thought of that myself! My initial finding is
that I see the following error from kdeconnectd twice whenever I hit "refresh"
on the Android app:

kdeconnect.core: Fallback (1), try reverse connection (send udp packet)
"Connection refused"

I'll attach the logcat output from the same brief timeframe.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to