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

Hello Jussi,

I’ve been submerged in some work activities and replying dropped off my radar. Apologies.

The “wireguard_and_vpn_association” patchset (with reverts) has been used in the dev/test images that I share for a while now and so far there are no negative user reports, so all seems fine. LE users generally have the rather simple use-case of making a connection to home (on a dynamic IP) so it’s not advanced configuration.

The re-resolve option name is long but I’m not able to come up with anything better/shorter :)

Christian

> On 10 Apr 2025, at 4:26 pm, Jussi Laakkonen <[email protected]> wrote:
> 
> Hi Christian and others,
> 
> I noticed that the testing thread has been quite silent for a while. So I've done some internal testing here, and made changes to the git repo
> https://github.com/LaakkonenJussi/connman_upstream/commits/wireguard_and_vpn_association/ - mostly reverts, as in my tests it seemed to be enough to fix the FQDN -> IP use in routing. But can you, and others, tell if this works for you too? I'm trying to minimize the changes.
> 
> But on the other hand I thought also that the feature to use the transport service's DNSs for the DNS reresolve in WireGuard might be something someone would want to enable for their WireGuard. Like in a scenario where the user has no power to change anything on the server side if the resolving of the server's IP is not possible via WireGuard connection due to broken DNS configuration on the server. And if this would be a good idea to have as an option for WireGuard, I'm taking in suggestions on option name, "ReresolveUseTransportDNS" is, well, long.
> 
> But let me know if the version with reverts works. Easy to return to the later version if this change causes any regressions.
> 
> Cheers,
> Jussi
> 
> 
> 
> On 3/25/25 19:18, Jussi Laakkonen wrote:
>> 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
>>> 
>