Tested with version 1.0.3 from the Kubuntu backports PPA. Phone is a Nexus 6P running up-to-date Android (7.1.1, Jan 5 security patches). For the Android app, I have tested version 1.4.4 from F-Droid, and the current Play Store beta of 1.5 (Dec 17, 2016 is the updated date I see on the Play Store). On my home system (running yakkety), this works fine (with a caveat I'll get to below). However, at work (running xenial) where our WiFi is not the same LAN as our wired LAN and thus I connect via OpenVPN, my desktop and phone never see eachother. I would have assumed this could be mitigated by manually specifying the IP address or hostname to connect to in the Android app, but this causes no change in behaviour. In fact, bizarrely enough, connecting to my work VPN while at home, my 6P appears to remain paired with my home PC, and even receives pings from it! Is there any way to get kdeconnect to respect my intentions vis-a-vis network traffic routing?
Addendum: I have tried connecting both my home PC and my Nexus 6P to my work VPN. As long as both are "physically" (somewhat figurative in the case of the phone, but you know) on my local LAN, then they still see eachother, regardless of their respective states in regard to the VPN. If I disconnect my phone from my home wireless yet still connect it to the work VPN, they cease seeing eachother through KDE Connect. Everything else I can think to try (ping, ssh, sftp) acts as expected, ie. works if they're ostensibly connected to the same network via the VPN (or are both not connected to the VPN but via my home network) and doesn't work if one is connected to the VPN and the other isn't. What dark sorcery is at work here? (Or alternatively---as it is I who runs the work OpenVPN instance---what weird edge case with OpenVPN+kdeconnect could I be running into here in terms of failing to actually route traffic through the VPN?)
My uneducated guess would be that they aren't scanning all the local addresses (ie 10.10.*.*)
Some thoughts of what happens (not 100% sure this is correct): KDE Connect tries to discover other devices using UDP. If it receives UDP packets of other KDE Connect devices it tries to connect to them with TCP. So I'd guess that the VPN does not route the UDP packets to the other peer. Maybe you can check how UDP behaves on the VPN? Regarding the home network, I'm not sure what you want to achieve: - Do you want to disallow connecting directly over Wifi when you're connected to a VPN? - Do you want the devices to connect over the VPN?
It's not just a matter of UDP. I can communicate via UDP between clients on the VPN and computers physically on the network being connected into. For instance, if I run a UDP iperf server instance on a PC in the office, a remote computer connecting via our VPN (which is specifically: OpenVPN, device TUN, protocol TCP) can connect to it just fine. The problem would appear to be that TUN doesn't support broadcasting across subnets, and KDE Connect apparently uses UDP broadcasting; see https://community.kde.org/KDEConnect#I_have_two_devices_running_KDE_Connnect_on_the_same_network.2C_but_they_can.27t_see_each_other. So yes, the VPN does not route these *specific* UDP packets, even though UDP is supported in general, but it's weird to me that this is a problem. What is the point of being able to specify addresses if it will refuse to try those and rely on the same UDP broadcasting approach to discover other instances anyways?
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. But we can do something to see what really happens. Can you send the following logs (both is best, but may not be necessary): Desktop: 1. Kill the running kdeconnectd process 2. Run "/usr/lib/x86_64-linux-gnu/libexec/kdeconnectd" from the command line and copy the output. Try refreshing from both the Android app and from the desktop KDE Connect settings. Android: 1. Connect your phone using USB to any computer, and run "adb logcat". A lot of output will appear, but anything before you open KDE Connect is irrelevant. You may need to install some packages to run the "adb" command. 2. Try refreshing from both the Android app and from the desktop KDE Connect settings and copy the resulting log.
(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.
Created attachment 109920 [details] logcat output while hitting refresh in the Android app
Sorry for the late reaction, I've been busy. What the PC log message means: the PC received the UDP packet from the phone and tries to connect to the phone (using TCP). That fails (maybe because of the thing I mentioned, maybe not), so it tries the reverse: it sends out an UDP message so the phone will instead connect to the PC. As your issue indicates, that doesn't work either. Since the android log does not contain a message that it received an UDP package, the direction UDP/TCP from PC to phone does not work. As I read your earlier messages, you can ping/ssh/etc. from your PC to your phone correctly in the same network setup. Can you confirm this for me? If so, we've pinpointed the issue somewhat (although hard to test for me).
(In reply to Matthijs Tijink from comment #8) > Sorry for the late reaction, I've been busy. > > What the PC log message means: the PC received the UDP packet from the phone > and tries to connect to the phone (using TCP). That fails (maybe because of > the thing I mentioned, maybe not), so it tries the reverse: it sends out an > UDP message so the phone will instead connect to the PC. As your issue > indicates, that doesn't work either. > > Since the android log does not contain a message that it received an UDP > package, the direction UDP/TCP from PC to phone does not work. > > As I read your earlier messages, you can ping/ssh/etc. from your PC to your > phone correctly in the same network setup. Can you confirm this for me? If > so, we've pinpointed the issue somewhat (although hard to test for me). Not the OP but also the same problem here. Using a VPN on my android phone results in the same result with not being able to connect. I can confirm that I can ping my phone from my pc with no issue.
Tested it just now with my own openvpn setup. I ran into the same problem because when the phone is connected to my private vpn it gets a 10.x.x.x ip-address. My vpn server masquerades all traffic from 10.x.x.x going to my home lan. The pc I'm trying to pair with is not the vpn server so that sees the UPD packet coming from the vpn server's 192.x.x.x address and tries to establish a TCP connection to the vpn server which off course won't work. When I remove the masquerading and add a route to my home pc to direct all 10.x.x.x traffic to my vpn server all is well
Is this still an issue for any of you? Basically when you add a device by IP-address or hostname if any firewall allows the traffic and routing between subnets is configured correctly everything should work as expected
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Works for me on Android 9.0, KDE Connect for Android 1.12.5, kde-connect-1.3.3-1.fc29.x86_64 on Fedora Linux.
I do intend on trying to bludgeon an OpenVPN and routing setup at work this week (hopefully Monday if nothing else gets in the way) into accomplishing this. I'm still somewhat unsure that this is entirely possible with my own setup, however; Erik Duisters' solution including removing a masquerade rule making all traffic appear to be coming from the VPN server doesn't apply to my case, where each VPN client in fact gets its own IP address. That a lack of an applicable routing rule is nonetheless stymieing me doesn't seem entirely unlikely; however I've tried setting one from the host PC and added the hostname in the Android app and seen no success. (All of this would be abrogated, at least in scenarios identical in practice to mine, by bluetooth support finally landing, which I'm *also* looking to try out this week although I know it's far from actually ready yet.)
To be explicit: after adding a routing rule, I can then ping from the host PC to the Android device (vice-versa was always true). However, the Android app still does not see the PC as a valid pairing target, even after adding the hostname or IP address via "Add devices by IP".
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!