Re: [PATCH 00/12] Improve WireGuard disconnect, error and hostname lookup

Hi Christian,

I'm happy to hear this. And very grateful of that publicity and 
possibility to get even more testing on this.

I pushed only one cleanup commit today, as it seems that the route setup 
that is done when endpoint resolves to an different IP should be enough. 
In ideal case the gateway (endpoint IP) changes would be propagated to 
connmand but I need to write another internal task for it and work on it 
later.

But lets see what testing reveals.

- Jussi


On 3/25/25 15:02, Christian Hewitt wrote:
> Hello Jussi,
> 
> The updated branch compiles fine now and I’m able to connect with ‘Host’ configured with an FQDN instead of an IP address, which is awesome to see!
> 
> I’ve posted a thread to our user forum with an experimental image to crowdsource further feedback:
> 
> https://forum.libreelec.tv/thread/29601-wireguard-experimental-support-for-connecting-via-fqdn-not-ip/
> 
> Let’s see what issues come up :)
> 
> Christian
> 
>> On 25 Mar 2025, at 1:58 pm, Jussi Laakkonen <[email protected]> wrote:
>>
>> Hi Christian and all,
>>
>> On 3/24/25 21:30, Jussi Laakkonen wrote:
>>> Hi Christian,
>>> On 3/22/25 06:45, Christian Hewitt wrote:
>>>>> On 21 Mar 2025, at 11:31 pm, Jussi Laakkonen <[email protected]> wrote:
>>>>>
>>>>> Hi Christian and all,
>>>>>
>>>>>> I’ve been using this series combined with the following series and patch for several weeks:
>>>>>> https://patchwork.kernel.org/project/connman/ cover/[email protected]/
>>>>>> https://patchwork.kernel.org/project/connman/patch/ DB6PR10MB1845EBB07DB785B580B3F6ECE1E02@DB6PR10MB1845.EURPRD10.PROD.OUTLOOK.COM/
>>>>>> Plus a revert of this commit which I’ve previously flagged as breaking the default “route all traffic down tunnel” with WireGuard (the main use-case for LibreELEC users):
>>>>>> https://git.kernel.org/pub/scm/network/connman/connman.git/commit/? id=9eb1772d31b6fcf78e8711976696491aec9ff5df
>>>>>> For easier testing all patches are in this branch: https:// github.com/chewitt/connman/commits/wireguard
>>>>>> No issues observed, so:
>>>>>> Tested-by: Christian Hewitt <[email protected]>
>>>>>
>>>>> I'm happy to hear. I have been fixing other issues related to WG in the past weeks a lot and considering to push all of the changes into one big WG patch set, as this has been left dangling.
>>>>>
>>>>> I haven't fully tested this on top of upstream ConnMan, but if you or someone else is interested to see if the issues that were previously encountering are fixed or not.
>>>>>
>>>>> All changes are available here, on top of latest upstream ConnMan: https://github.com/LaakkonenJussi/connman_upstream/pull/9
>>>>>
>>>>> It is a PR to the internal repository so anyone can comment there too. Decided to put this into public as Mullvad seems to give only IP addresses and cannot really rely on demo.wireguard.com alone on this. So, feel free to test, if it works I'll setup a patch set, maybe combine some of the changes to make fewer patches.
>>>>>
>>>>> Have a nice weekend you all!
>>>>
>>>> Thanks for sharing Jussi. Minor compile error fixed with:
>>>>
>>>> diff --git a/src/shared/util.h b/src/shared/util.h
>>>> index 44e07b84..9af0303d 100644
>>>> --- a/src/shared/util.h
>>>> +++ b/src/shared/util.h
>>>> @@ -25,7 +25,7 @@
>>>>      #include <glib.h>
>>>>    #include <stdbool.h>
>>>> -#include <inet.h>
>>>> +#include <connman/inet.h>
>>>>      #define AF_INET_POS 0
>>>>    #define AF_INET6_POS 1
>>> Oops, thanks for spotting this. I wonder how my build on Debian did not warn about this. I think only <arpa/inet.h> is needed at this point, but that works too. Added a commit to that branch.
>>>>
>>>> An existing WireGuard configuration on the family daily-driver RPi5 running LibreELEC shows no obvious regressions with a private VPN server (not a commercial service). Lots more testing required :)
>>>>
>>>> Christian
>>>>
>>> Glad to hear this. I keep wondering if something is still needed from our fork... as at least with Mullvad WG I got dual IP support working, and data gets routed from both IP families to the host with an IP. But this is a quite a big change, so yes, lost more testing is required and thanks for helping with this.
>>> Few things I want to point out, that now sure yet if it is correct way to do this but the transport services' DNS servers are sent to vpnd from connmand when a VPN reaches ready state. It could be earlier, at configuration state too, any opinnions? This is because then the reresolving of the FQDN hostname seems to start working well.
>>> But, as I now did some more digging I noticed that the FQDN was also propagated "as is" to connmand resulting it ending up in the routing table, which may be cause for this not working in the first place. And I'm talking about DNS reresolve broken in such case as well as the traffic getting blocked. I pushed a WIP change to the PR/branch which I need to continue tomorrow (as we want this to be working in Sailfish OS too) so this can be tested that how it works. The TODO part is about making DNS reresolve to work in the similar way too.
>>> Have fun testing!
>>> Cheers,
>>>   Jussi
>>
>>
>> Forgot to push the commits there late at night, now they're available and will update today as well.
>>
>> - Jussi
>