<p dir="ltr">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 ;) </p>
<p dir="ltr">On Oct 19, 2014 9:48 AM, "Achilleas Koutsou" <<a href="mailto:achilleas.k@gmail.com">achilleas.k@gmail.com</a>> wrote:<br>
><br>
> If anyone wants to check it out, it's all on the 'manualip' branch on my<br>
> github fork: <a href="https://github.com/achilleas-k/kdeconnect-android/tree/manualip">https://github.com/achilleas-k/kdeconnect-android/tree/manualip</a><br>
></p>
<p dir="ltr">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 (?) </p>
<p dir="ltr">> <br>
> In terms of the interface, there is a new menu item below "KDE Connect<br>
> 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.<br>
> Removing items is done by simply touching the existing item in the<br>
> list. There is no confirmation dialogue for removing items (this will be<br>
> added soon).<br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">> There is no validation done to the entered text. Initially, I was<br>
> planning on validating the input string to make sure it's a valid IP<br>
> address. I restricted entry to numbers and periods only and<br>
> had the interface use the numerical keyboard. I later realised that<br>
> hostnames should also be valid items, so one can now enter a host or<br>
> domain name that gets resolved to an IP address.<br>
></p>
<p dir="ltr">Makes sense. </p>
<p dir="ltr">> The custom device list is saved as a single string, stored in the<br>
> DefaultSharedPreferences. The string is constructed by concatenating all<br>
> entries, separated by a single comma ",". I would use a String set, but<br>
> that requires API Level 11 and KDE Connect has a min level 9. I'm open<br>
> to suggestions if someone has a better idea on how to store the list.<br>
></p>
<p dir="ltr">I faced the same issue somewhere else and I solved it the same way. </p>
<p dir="ltr">> Issues/limitations:<br>
> - I have only managed to test pairing (and using) two devices, each on a<br>
> different physical network, but both connected to the same VPN. The<br>
> VPN was my private OpenVPN in TUN mode. I haven't tested TAP mode, or<br>
> any other kind of VPN. There is no *theoretical* reason why it<br>
> shouldn't work, but I can't be certain without testing.<br>
> - The pairing doesn't work via the internet, by forwarding ports on my<br>
> router. My phone was on the mobile network (3G), I forwarded the<br>
> appropriate ports on my router, I added my home's public IP to the<br>
> list, but the kdeconnect daemon couldn't detect the phone. I ran<br>
> tcpdump and saw that my desktop does in fact receive the tcp and udp<br>
> packets, but the kdeconnect daemon (running using --nofork), only<br>
> occasionally displays "LanLinkProvider::connectError: Fallback (1),<br>
> try reverse connection". I'll investigate whether any changes are<br>
> required on the desktop application side. I suspect it might be an<br>
> issue with my provider blocking the packets from the desktop to the<br>
> mobile. To test this properly, I need two networks where I can forward<br>
> ports on both ends.<br>
></p>
<p dir="ltr">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. </p>
<p dir="ltr">:D</p>
<p dir="ltr">Albert</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Albert and others,<br>
<br>
I must apologise in advance for the length of my email. I initially<br>
intended it to be a short description of the status (what works and what<br>
doesn't), but while writing it I felt it would be good to document<br>
everything for the future. I'm not sure whether this is considered<br>
normal on this mailing list (I suspect it isn't, from the short time<br>
I've been subscribed), but nevertheless, since I've been working on<br>
changes to the core of the application, I believe it's best to have<br>
everything as well documented as possible.<br>
<br>
Here's the current status of the pairing through VPN.<br>
If anyone wants to check it out, it's all on the 'manualip' branch on my<br>
github fork: <a href="https://github.com/achilleas-k/kdeconnect-android/tree/manualip" target="_blank">https://github.com/achilleas-<u></u>k/kdeconnect-android/tree/<u></u>manualip</a><br>
<br>
I'll branch off any future changes into 'manualip_dev' so the current<br>
branch will always be somewhat stable.<br>
<br>
Currently, the branch is based off master commit<br>
256ca60036e32a367c1fa30990f572<u></u>8e5246aac1<br>
<a href="https://projects.kde.org/projects/playground/base/kdeconnect-android/repository/revisions/256ca60036e32a367c1fa30990f5728e5246aac1" target="_blank">https://projects.kde.org/<u></u>projects/playground/base/<u></u>kdeconnect-android/repository/<u></u>revisions/<u></u>256ca60036e32a367c1fa30990f572<u></u>8e5246aac1</a><br>
<br>
<br>
I'll explain what I've done below for documentation purposes.<br>
<br>
In terms of the interface, there is a new menu item below "KDE Connect<br>
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.<br>
Removing items is done by simply touching the existing item in the<br>
list. There is no confirmation dialogue for removing items (this will be<br>
added soon).<br>
<br>
There is no validation done to the entered text. Initially, I was<br>
planning on validating the input string to make sure it's a valid IP<br>
address. I restricted entry to numbers and periods only and<br>
had the interface use the numerical keyboard. I later realised that<br>
hostnames should also be valid items, so one can now enter a host or<br>
domain name that gets resolved to an IP address.<br>
<br>
In terms of implementation, there is a new Backend called<br>
CustomLinkBackend (with 'CustomLink' and 'CustomLinkProvider' classes).<br>
The backend reads the stored entries in the Custom Device List and for<br>
each one, it attempts to send an identity packet. If the entered IP<br>
address or hostname is invalid, the packet construction will fail: This<br>
is done when constructing the InetAddress object using<br>
InetAddress.getByName(<u></u>inputstring), which throws an exception on invalid<br>
strings. Since almost any string can be a valid hostname, I felt it was<br>
best to let the Android system distinguish valid from invalid entries.<br>
I'm not sure whether it is useful to mark invalid entries in the user<br>
supplied list. For instance, a local hostname is only reachable when one<br>
is on the network and it might be annoying to have entries marked as<br>
invalid at all other times. If you believe invalid or unreachable<br>
entries should be marked as such, let me know and I'll add it.<br>
<br>
The custom device list is saved as a single string, stored in the<br>
DefaultSharedPreferences. The string is constructed by concatenating all<br>
entries, separated by a single comma ",". I would use a String set, but<br>
that requires API Level 11 and KDE Connect has a min level 9. I'm open<br>
to suggestions if someone has a better idea on how to store the list.<br>
<br>
Issues/limitations:<br>
- I have only managed to test pairing (and using) two devices, each on a<br>
different physical network, but both connected to the same VPN. The<br>
VPN was my private OpenVPN in TUN mode. I haven't tested TAP mode, or<br>
any other kind of VPN. There is no *theoretical* reason why it<br>
shouldn't work, but I can't be certain without testing.<br>
- The pairing doesn't work via the internet, by forwarding ports on my<br>
router. My phone was on the mobile network (3G), I forwarded the<br>
appropriate ports on my router, I added my home's public IP to the<br>
list, but the kdeconnect daemon couldn't detect the phone. I ran<br>
tcpdump and saw that my desktop does in fact receive the tcp and udp<br>
packets, but the kdeconnect daemon (running using --nofork), only<br>
occasionally displays "LanLinkProvider::<u></u>connectError: Fallback (1),<br>
try reverse connection". I'll investigate whether any changes are<br>
required on the desktop application side. I suspect it might be an<br>
issue with my provider blocking the packets from the desktop to the<br>
mobile. To test this properly, I need two networks where I can forward<br>
ports on both ends.<br>
<br>
<br>
I'll keep using my branch on a daily basis to see if there are any bugs<br>
and I'll let you know if anything changes. Let me know what you think of<br>
some of my choices, if anyone has any strong opinions on the matter.<br>
<br>
Regards,<br>
Achilleas<br>
<br>
<br>
On 16/09/14 23:28, Albert Vaca wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, thank you! It would be awesome if you succeed implementing it,<br>
because a lot of people is requesting this feature :D<br>
<br>
On Tue, Sep 16, 2014 at 4:54 PM, Achilleas Koutsou<br>
<<a href="mailto:achilleas.k@gmail.com" target="_blank">achilleas.k@gmail.com</a> <mailto:<a href="mailto:achilleas.k@gmail.com" target="_blank">achilleas.k@gmail.com</a>><u></u>> wrote:<br>
<br>
Unfortunately, I haven't had time to do much of anything beyond work<br>
the past few months. Things will most likely be easier next month,<br>
so I'll try and finish it up then.<br>
<br>
Given my lack of progress, the pairing issue is still there.<br>
Also, I haven't made the new backend read IP addresses from the<br>
saved settings yet. That should be much simpler, of course.<br>
<br>
What I have done, however, is lots of testing! Especially testing a<br>
persistent pairing/connection through a VPN for several hours. I<br>
haven't had any issues with communication between devices through a<br>
VPN (while the two devices are on different physical networks),<br>
given that they are already paired from within the same network.<br>
<br>
I hope to have a patch for you by the end of October, unless someone<br>
beats me to it.<br>
<br>
</blockquote>
<br>
<br>
</div>