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

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