Pair from separate network or through VPN

[Achilleas Koutsou]

Hello Albert and others,

I must apologise in advance for the length of my email. I initially
intended it to be a short description of the status (what works and what
doesn't), but while writing it I felt it would be good to document
everything for the future. I'm not sure whether this is considered
normal on this mailing list (I suspect it isn't, from the short time
I've been subscribed), but nevertheless, since I've been working on
changes to the core of the application, I believe it's best to have
everything as well documented as possible.

Here's the current status of the pairing through VPN.
If anyone wants to check it out, it's all on the 'manualip' branch on my
github fork: https://github.com/achilleas-k/kdeconnect-android/tree/manualip

I'll branch off any future changes into 'manualip_dev' so the current
branch will always be somewhat stable.

Currently, the branch is based off master commit
256ca60036e32a367c1fa30990f5728e5246aac1
https://projects.kde.org/projects/playground/base/kdeconnect-android/repository/revisions/256ca60036e32a367c1fa30990f5728e5246aac1


I'll explain what I've done below for documentation purposes.

In terms of the interface, there is a new menu item below "KDE Connect
Settings" labelled "Custom Device List". This is a simple item list 
where one can add a new host or IP by typing and hitting the "Add" button.
Removing items is done by simply touching the existing item in the
list. There is no confirmation dialogue for removing items (this will be
added soon).

There is no validation done to the entered text. Initially, I was
planning on validating the input string to make sure it's a valid IP
address. I restricted entry to numbers and periods only and
had the interface use the numerical keyboard. I later realised that
hostnames should also be valid items, so one can now enter a host or
domain name that gets resolved to an IP address.

In terms of implementation, there is a new Backend called
CustomLinkBackend (with 'CustomLink' and 'CustomLinkProvider' classes).
The backend reads the stored entries in the Custom Device List and for
each one, it attempts to send an identity packet. If the entered IP
address or hostname is invalid, the packet construction will fail: This
is done when constructing the InetAddress object using
InetAddress.getByName(inputstring), which throws an exception on invalid
strings. Since almost any string can be a valid hostname, I felt it was
best to let the Android system distinguish valid from invalid entries.
I'm not sure whether it is useful to mark invalid entries in the user
supplied list. For instance, a local hostname is only reachable when one
is on the network and it might be annoying to have entries marked as
invalid at all other times. If you believe invalid or unreachable
entries should be marked as such, let me know and I'll add it.

The custom device list is saved as a single string, stored in the
DefaultSharedPreferences. The string is constructed by concatenating all
entries, separated by a single comma ",". I would use a String set, but
that requires API Level 11 and KDE Connect has a min level 9. I'm open
to suggestions if someone has a better idea on how to store the list.

Issues/limitations:
- I have only managed to test pairing (and using) two devices, each on a
   different physical network, but both connected to the same VPN. The
   VPN was my private OpenVPN in TUN mode. I haven't tested TAP mode, or
   any other kind of VPN. There is no *theoretical* reason why it
   shouldn't work, but I can't be certain without testing.
- The pairing doesn't work via the internet, by forwarding ports on my
   router. My phone was on the mobile network (3G), I forwarded the
   appropriate ports on my router, I added my home's public IP to the
   list, but the kdeconnect daemon couldn't detect the phone. I ran
   tcpdump and saw that my desktop does in fact receive the tcp and udp
   packets, but the kdeconnect daemon (running using --nofork), only
   occasionally displays "LanLinkProvider::connectError: Fallback (1),
   try reverse connection". I'll investigate whether any changes are
   required on the desktop application side. I suspect it might be an
   issue with my provider blocking the packets from the desktop to the
   mobile. To test this properly, I need two networks where I can forward
   ports on both ends.


I'll keep using my branch on a daily basis to see if there are any bugs
and I'll let you know if anything changes. Let me know what you think of
some of my choices, if anyone has any strong opinions on the matter.

Regards,
Achilleas


On 16/09/14 23:28, Albert Vaca wrote:
> Ok, thank you! It would be awesome if you succeed implementing it,
> because a lot of people is requesting this feature :D
>
> On Tue, Sep 16, 2014 at 4:54 PM, Achilleas Koutsou
> <achilleas.k at gmail.com <mailto:achilleas.k at gmail.com>> wrote:
>
>     Unfortunately, I haven't had time to do much of anything beyond work
>     the past few months. Things will most likely be easier next month,
>     so I'll try and finish it up then.
>
>     Given my lack of progress, the pairing issue is still there.
>     Also, I haven't made the new backend read IP addresses from the
>     saved settings yet. That should be much simpler, of course.
>
>     What I have done, however, is lots of testing! Especially testing a
>     persistent pairing/connection through a VPN for several hours. I
>     haven't had any issues with communication between devices through a
>     VPN (while the two devices are on different physical networks),
>     given that they are already paired from within the same network.
>
>     I hope to have a patch for you by the end of October, unless someone
>     beats me to it.
>