Pair from separate network or through VPN

[Achilleas Koutsou]

On 22/10/14 21:41, Albert Vaca wrote:
> Awesome, it's very nice to see that good progress! No worries with the
> long mail, and sorry in advance to be lazy to read through it and answer
> it until today ;)

> On Oct 19, 2014 9:48 AM, "Achilleas Koutsou" <achilleas.k at gmail.com
> <mailto:achilleas.k at gmail.com>> wrote:
>  >
>  > 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
>  >
>
> You managed to only change the Android side? Nice! But... isn't the
> desktop side expecting identify packets to be received via UDP broadcast
> only? Because you are sending TCP packets I guess (?)

Well, the new provider is almost a complete copy of the LanLinkProvider, 
so it works the same way. The difference is that, where LanLinkProvider 
sends a DatagramPacket addressed to -1.-1.-1.-1 (LanLinkProvider:249), 
CustomLinkProvider creates several DatagramPackets, each one addressed 
to an IP from the user-supplied list.

>  >
>  > 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).
>  >
>
> Couldn't we use the same main device list? I think it will be cleaner,
> but anyway it's just about the interface and we can change that later
> once the functionality is there.

We could have an "add device" button on the main screen, I guess. The 
reason I added it as a separate option was because the first time we 
talked, you mentioned that this might be considered an advanced feature 
and for normal use, the app should "just work", a decision which I 
totally understand and support. Final decision is on you though and it's 
a minor change we can do later.

>  > 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.
>  >
>
> Makes sense.

Good to know.

>  > 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.
>  >
>
> I faced the same issue somewhere else and I solved it the same way.
>
>  > 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 will do some testing when I have a chance (I'm boarding a plane right
> now), but about establishing connections through the Internet, I think
> it's not a problem if it doesn't work: it would be too laggy anyway for
> touchpad and other features, and you probably don't want to transfer
> files over 3G either.
>
> :D

Great. Can't wait to hear how it works for you.

--
Achilleas