Pair from separate network or through VPN

[Albert Vaca]

It finally found some time to test it and it works perfect! I think
we could merge it already :) We should add a confirmation before removing a
host and that would be enough for a first release.

Is there any other think you think that needs to be improved?

I would maybe add some text saying that you should only use this option if
your device is not automatically detected, to avoid confusion from new
users.

On Wed, Oct 22, 2014 at 4:59 PM, Achilleas Koutsou
<achilleas.k at gmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20141102/4cc1e46a/attachment.html>