| Message ID | DB6PR10MB184509788A86F13B5F8C7378E11F2@DB6PR10MB1845.EURPRD10.PROD.OUTLOOK.COM (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | gateway: Fix typo when setting 'is_vpn6' | expand |
> On 13 Jan 2025, at 5:59 pm, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > > Hi, > > I was testing connman's wireguard plugin and got a segmentation fault. > > Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > > I simply changed them to ipv6 and got it working. Hello Gabriel, I’d like to suggest a change to the commit message for a v2 patch (removing the discussion and questions so it can be merged): >>> Subject: fix calculation of is_vpn6 Fix is_vpn6 to use ipv6 variables not ipv4 variables. This stops the WireGuard plugin from faulting on startup. Fixes: commit 823d5a2a8cc4 ("connection: Refactor ‘__connman_connection_gateway_add’”)” Signed-of-by: Gabriel Sanches <gabriel.sanches@prevas.dk> Tested-by: Christian Hewitt <christianshewitt@gmail.com> <<< ^ You can add my Tested-by. The distro I maintain (LibreELEC) has been using the same patch for a few months [0] - I’ve asked the patch contributor to send it upstream but that hasn’t happened, so it’s great you have. [0] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/network/connman/patches/connman-07-connman_gateway_add-fix-calculation-of-is_vpn6.patch > not related to the patch: > I had to manually add ip route so the other devices could be pinged > The plugin adds routes for the WireGuard.DNS configuration setting > # ip route > 1.1.1.1 dev wg0 scope link > 8.8.8.8 dev wg0 scope link > 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > 10.42.0.1 dev end1 scope link > <vpn host ip> via 10.42.0.1 dev end1 > > the missing route added manually: > ip route add 10.33.0.0/16 dev wg0 scope link > > an equivalent wireguard file adds it properly (using wg-quick) > > Is the plugin lacking some implementation? The patch in [1] reverts an earlier change from Zoltán that broke WireGuard routing. I’ve flagged this on the list at the time, but then the very large refactoring changeset from Grant (requiring this patch) total broke WireGuard so discussion on the earlier issue fizzled out. If you’d like to submit the revert patch at the same time as v2 of this patch - please do (no need for patch attribution on the revert, though feel free to add my tested-by again). [1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/network/connman/patches/connman-06-Revert-Don-t-add-route-for-invalid-dst-and-gateway-a.patch Christian > --- > src/gateway.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/gateway.c b/src/gateway.c > index 16c87f83..b2c211e2 100644 > --- a/src/gateway.c > +++ b/src/gateway.c > @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > is_gateway_config_vpn( > new_gateway->ipv4_config); > > - is_vpn6 = do_ipv4 && > - new_gateway->ipv4_config && > + is_vpn6 = do_ipv6 && > + new_gateway->ipv6_config && > is_gateway_config_vpn( > - new_gateway->ipv4_config); > + new_gateway->ipv6_config); > > } else { > if (do_ipv4 && new_gateway->ipv4_config) > -- > 2.43.0
On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > I was testing connman's wireguard plugin and got a segmentation fault. > > Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > > I simply changed them to ipv6 and got it working. > > not related to the patch: > I had to manually add ip route so the other devices could be pinged > The plugin adds routes for the WireGuard.DNS configuration setting > # ip route > 1.1.1.1 dev wg0 scope link > 8.8.8.8 dev wg0 scope link > 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > 10.42.0.1 dev end1 scope link > <vpn host ip> via 10.42.0.1 dev end1 > > the missing route added manually: > ip route add 10.33.0.0/16 dev wg0 scope link > > an equivalent wireguard file adds it properly (using wg-quick) > > Is the plugin lacking some implementation? > > --- > src/gateway.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/gateway.c b/src/gateway.c > index 16c87f83..b2c211e2 100644 > --- a/src/gateway.c > +++ b/src/gateway.c > @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > is_gateway_config_vpn( > new_gateway->ipv4_config); > > - is_vpn6 = do_ipv4 && > - new_gateway->ipv4_config && > + is_vpn6 = do_ipv6 && > + new_gateway->ipv6_config && > is_gateway_config_vpn( > - new_gateway->ipv4_config); > + new_gateway->ipv6_config); > > } else { > if (do_ipv4 && new_gateway->ipv4_config) > -- > 2.43.0 Gabriel, Great catch on this copy-and-paste typo; thank you! Best, Grant
Hi I have opened a ticket for connman-vpn not working with wireguard in April 2024. If you give me the patches I can test them Best regards Daniel Le mer. 22 janv. 2025 à 18:01, Grant Erickson <gerickson@nuovations.com> a écrit : > > On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > > I was testing connman's wireguard plugin and got a segmentation fault. > > > > Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > > > > I simply changed them to ipv6 and got it working. > > > > not related to the patch: > > I had to manually add ip route so the other devices could be pinged > > The plugin adds routes for the WireGuard.DNS configuration setting > > # ip route > > 1.1.1.1 dev wg0 scope link > > 8.8.8.8 dev wg0 scope link > > 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > > 10.42.0.1 dev end1 scope link > > <vpn host ip> via 10.42.0.1 dev end1 > > > > the missing route added manually: > > ip route add 10.33.0.0/16 dev wg0 scope link > > > > an equivalent wireguard file adds it properly (using wg-quick) > > > > Is the plugin lacking some implementation? > > > > --- > > src/gateway.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/src/gateway.c b/src/gateway.c > > index 16c87f83..b2c211e2 100644 > > --- a/src/gateway.c > > +++ b/src/gateway.c > > @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > > is_gateway_config_vpn( > > new_gateway->ipv4_config); > > > > - is_vpn6 = do_ipv4 && > > - new_gateway->ipv4_config && > > + is_vpn6 = do_ipv6 && > > + new_gateway->ipv6_config && > > is_gateway_config_vpn( > > - new_gateway->ipv4_config); > > + new_gateway->ipv6_config); > > > > } else { > > if (do_ipv4 && new_gateway->ipv4_config) > > -- > > 2.43.0 > > Gabriel, > > Great catch on this copy-and-paste typo; thank you! > > Best, > > Grant > >
Hello, Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. BR, Jussi On 1/23/25 12:45, daniel antoine wrote: > Hi > > I have opened a ticket for connman-vpn not working with wireguard in > April 2024. If you give me the patches I can test them > > Best regards > > Daniel > > Le mer. 22 janv. 2025 à 18:01, Grant Erickson > <gerickson@nuovations.com> a écrit : >> >> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>> I was testing connman's wireguard plugin and got a segmentation fault. >>> >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>> >>> I simply changed them to ipv6 and got it working. >>> >>> not related to the patch: >>> I had to manually add ip route so the other devices could be pinged >>> The plugin adds routes for the WireGuard.DNS configuration setting >>> # ip route >>> 1.1.1.1 dev wg0 scope link >>> 8.8.8.8 dev wg0 scope link >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>> 10.42.0.1 dev end1 scope link >>> <vpn host ip> via 10.42.0.1 dev end1 >>> >>> the missing route added manually: >>> ip route add 10.33.0.0/16 dev wg0 scope link >>> >>> an equivalent wireguard file adds it properly (using wg-quick) >>> >>> Is the plugin lacking some implementation? >>> >>> --- >>> src/gateway.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/gateway.c b/src/gateway.c >>> index 16c87f83..b2c211e2 100644 >>> --- a/src/gateway.c >>> +++ b/src/gateway.c >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>> is_gateway_config_vpn( >>> new_gateway->ipv4_config); >>> >>> - is_vpn6 = do_ipv4 && >>> - new_gateway->ipv4_config && >>> + is_vpn6 = do_ipv6 && >>> + new_gateway->ipv6_config && >>> is_gateway_config_vpn( >>> - new_gateway->ipv4_config); >>> + new_gateway->ipv6_config); >>> >>> } else { >>> if (do_ipv4 && new_gateway->ipv4_config) >>> -- >>> 2.43.0 >> >> Gabriel, >> >> Great catch on this copy-and-paste typo; thank you! >> >> Best, >> >> Grant >> >> >
Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). Christian > On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > > Hello, > > Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn > > But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 > > And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. > > At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. > > BR, > Jussi > > > On 1/23/25 12:45, daniel antoine wrote: >> Hi >> I have opened a ticket for connman-vpn not working with wireguard in >> April 2024. If you give me the patches I can test them >> Best regards >> Daniel >> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >> <gerickson@nuovations.com> a écrit : >>> >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>> >>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>> >>>> I simply changed them to ipv6 and got it working. >>>> >>>> not related to the patch: >>>> I had to manually add ip route so the other devices could be pinged >>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>> # ip route >>>> 1.1.1.1 dev wg0 scope link >>>> 8.8.8.8 dev wg0 scope link >>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>> 10.42.0.1 dev end1 scope link >>>> <vpn host ip> via 10.42.0.1 dev end1 >>>> >>>> the missing route added manually: >>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>> >>>> an equivalent wireguard file adds it properly (using wg-quick) >>>> >>>> Is the plugin lacking some implementation? >>>> >>>> --- >>>> src/gateway.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/src/gateway.c b/src/gateway.c >>>> index 16c87f83..b2c211e2 100644 >>>> --- a/src/gateway.c >>>> +++ b/src/gateway.c >>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>> is_gateway_config_vpn( >>>> new_gateway->ipv4_config); >>>> >>>> - is_vpn6 = do_ipv4 && >>>> - new_gateway->ipv4_config && >>>> + is_vpn6 = do_ipv6 && >>>> + new_gateway->ipv6_config && >>>> is_gateway_config_vpn( >>>> - new_gateway->ipv4_config); >>>> + new_gateway->ipv6_config); >>>> >>>> } else { >>>> if (do_ipv4 && new_gateway->ipv4_config) >>>> -- >>>> 2.43.0 >>> >>> Gabriel, >>> >>> Great catch on this copy-and-paste typo; thank you! >>> >>> Best, >>> >>> Grant >>> >>> >
Hi Christian, That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. Br, Jussi On 1/23/25 13:12, Christian Hewitt wrote: > You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> > Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: > > https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd > > Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). > > Christian > > On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > > Hello, > > Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn > > But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 > > And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. > > At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. > > BR, > Jussi > > > On 1/23/25 12:45, daniel antoine wrote: > Hi > I have opened a ticket for connman-vpn not working with wireguard in > April 2024. If you give me the patches I can test them > Best regards > Daniel > Le mer. 22 janv. 2025 à 18:01, Grant Erickson > <gerickson@nuovations.com> a écrit : > > On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > I was testing connman's wireguard plugin and got a segmentation fault. > > Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > > I simply changed them to ipv6 and got it working. > > not related to the patch: > I had to manually add ip route so the other devices could be pinged > The plugin adds routes for the WireGuard.DNS configuration setting > # ip route > 1.1.1.1 dev wg0 scope link > 8.8.8.8 dev wg0 scope link > 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > 10.42.0.1 dev end1 scope link > <vpn host ip> via 10.42.0.1 dev end1 > > the missing route added manually: > ip route add 10.33.0.0/16 dev wg0 scope link > > an equivalent wireguard file adds it properly (using wg-quick) > > Is the plugin lacking some implementation? > > --- > src/gateway.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/gateway.c b/src/gateway.c > index 16c87f83..b2c211e2 100644 > --- a/src/gateway.c > +++ b/src/gateway.c > @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > is_gateway_config_vpn( > new_gateway->ipv4_config); > > - is_vpn6 = do_ipv4 && > - new_gateway->ipv4_config && > + is_vpn6 = do_ipv6 && > + new_gateway->ipv6_config && > is_gateway_config_vpn( > - new_gateway->ipv4_config); > + new_gateway->ipv6_config); > > } else { > if (do_ipv4 && new_gateway->ipv4_config) > -- > 2.43.0 > > Gabriel, > > Great catch on this copy-and-paste typo; thank you! > > Best, > > Grant > > > > >
Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? Christian > On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > > Hi Christian, > > That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. > > Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. > > Br, > Jussi > > > On 1/23/25 13:12, Christian Hewitt wrote: >> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >> Christian >> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> Hello, >> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >> BR, >> Jussi >> On 1/23/25 12:45, daniel antoine wrote: >> Hi >> I have opened a ticket for connman-vpn not working with wireguard in >> April 2024. If you give me the patches I can test them >> Best regards >> Daniel >> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >> <gerickson@nuovations.com> a écrit : >> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >> I was testing connman's wireguard plugin and got a segmentation fault. >> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >> I simply changed them to ipv6 and got it working. >> not related to the patch: >> I had to manually add ip route so the other devices could be pinged >> The plugin adds routes for the WireGuard.DNS configuration setting >> # ip route >> 1.1.1.1 dev wg0 scope link >> 8.8.8.8 dev wg0 scope link >> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >> 10.42.0.1 dev end1 scope link >> <vpn host ip> via 10.42.0.1 dev end1 >> the missing route added manually: >> ip route add 10.33.0.0/16 dev wg0 scope link >> an equivalent wireguard file adds it properly (using wg-quick) >> Is the plugin lacking some implementation? >> --- >> src/gateway.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> diff --git a/src/gateway.c b/src/gateway.c >> index 16c87f83..b2c211e2 100644 >> --- a/src/gateway.c >> +++ b/src/gateway.c >> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >> is_gateway_config_vpn( >> new_gateway->ipv4_config); >> - is_vpn6 = do_ipv4 && >> - new_gateway->ipv4_config && >> + is_vpn6 = do_ipv6 && >> + new_gateway->ipv6_config && >> is_gateway_config_vpn( >> - new_gateway->ipv4_config); >> + new_gateway->ipv6_config); >> } else { >> if (do_ipv4 && new_gateway->ipv4_config) >> -- >> 2.43.0 >> Gabriel, >> Great catch on this copy-and-paste typo; thank you! >> Best, >> Grant >
Hi Christian, Ok, now I do not know what is going on, I personally cherry-picked that particular commit from upstream, made by Daniel Wagner, into our fork. And yes, you are right, it no longer exists there. That had an issue with invalid setup, that it did block vpnd for a long time and I changed it to use GResolv instead, which seems to work better. But why it is not in upstream anymore is a big question. If you use the cherry-pick commit id, which points to our "upstream" content (yeah, not the best way..) I find this https://git.kernel.org/pub/scm/network/connman/connman.git/commit/vpn/plugins/wireguard.c?id=90592f7a58358a98bde5df6928e2b871041c12bc but it is not in master? Br, Jussi On 1/23/25 13:35, Christian Hewitt wrote: > Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > > Christian > >> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> >> Hi Christian, >> >> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >> >> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >> >> Br, >> Jussi >> >> >> On 1/23/25 13:12, Christian Hewitt wrote: >>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>> Christian >>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>> Hello, >>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>> BR, >>> Jussi >>> On 1/23/25 12:45, daniel antoine wrote: >>> Hi >>> I have opened a ticket for connman-vpn not working with wireguard in >>> April 2024. If you give me the patches I can test them >>> Best regards >>> Daniel >>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>> <gerickson@nuovations.com> a écrit : >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>> I was testing connman's wireguard plugin and got a segmentation fault. >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>> I simply changed them to ipv6 and got it working. >>> not related to the patch: >>> I had to manually add ip route so the other devices could be pinged >>> The plugin adds routes for the WireGuard.DNS configuration setting >>> # ip route >>> 1.1.1.1 dev wg0 scope link >>> 8.8.8.8 dev wg0 scope link >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>> 10.42.0.1 dev end1 scope link >>> <vpn host ip> via 10.42.0.1 dev end1 >>> the missing route added manually: >>> ip route add 10.33.0.0/16 dev wg0 scope link >>> an equivalent wireguard file adds it properly (using wg-quick) >>> Is the plugin lacking some implementation? >>> --- >>> src/gateway.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> diff --git a/src/gateway.c b/src/gateway.c >>> index 16c87f83..b2c211e2 100644 >>> --- a/src/gateway.c >>> +++ b/src/gateway.c >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>> is_gateway_config_vpn( >>> new_gateway->ipv4_config); >>> - is_vpn6 = do_ipv4 && >>> - new_gateway->ipv4_config && >>> + is_vpn6 = do_ipv6 && >>> + new_gateway->ipv6_config && >>> is_gateway_config_vpn( >>> - new_gateway->ipv4_config); >>> + new_gateway->ipv6_config); >>> } else { >>> if (do_ipv4 && new_gateway->ipv4_config) >>> -- >>> 2.43.0 >>> Gabriel, >>> Great catch on this copy-and-paste typo; thank you! >>> Best, >>> Grant >> >
Ignore: https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=90592f7a58358a98bde5df6928e2b871041c12bc So I think this is not the feature I’m thinking of, as it discusses Endpoint re-resolving. The challenge our users have is ‘Host’ which currently must be an IP address. Upstream WireGuard with wg-quick etc. allows an FQDN. I see users that need to connect to home locations on dynamic IPs where Host will periodically change. I also see users with commercial VPN services which use an FQDN in the (upstream) wireguard configuration format and this resolves to multiple A records (round-robin balancing) and the ‘static’ IPs move around in their ASN range over time in an an attempt to mitigate (poor) IP reputation issues. Christian > On 23 Jan 2025, at 3:35 pm, Christian Hewitt <christianshewitt@gmail.com> wrote: > > Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > > Christian > >> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> >> Hi Christian, >> >> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >> >> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >> >> Br, >> Jussi >> >> >> On 1/23/25 13:12, Christian Hewitt wrote: >>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>> Christian >>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>> Hello, >>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>> BR, >>> Jussi >>> On 1/23/25 12:45, daniel antoine wrote: >>> Hi >>> I have opened a ticket for connman-vpn not working with wireguard in >>> April 2024. If you give me the patches I can test them >>> Best regards >>> Daniel >>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>> <gerickson@nuovations.com> a écrit : >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>> I was testing connman's wireguard plugin and got a segmentation fault. >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>> I simply changed them to ipv6 and got it working. >>> not related to the patch: >>> I had to manually add ip route so the other devices could be pinged >>> The plugin adds routes for the WireGuard.DNS configuration setting >>> # ip route >>> 1.1.1.1 dev wg0 scope link >>> 8.8.8.8 dev wg0 scope link >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>> 10.42.0.1 dev end1 scope link >>> <vpn host ip> via 10.42.0.1 dev end1 >>> the missing route added manually: >>> ip route add 10.33.0.0/16 dev wg0 scope link >>> an equivalent wireguard file adds it properly (using wg-quick) >>> Is the plugin lacking some implementation? >>> --- >>> src/gateway.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> diff --git a/src/gateway.c b/src/gateway.c >>> index 16c87f83..b2c211e2 100644 >>> --- a/src/gateway.c >>> +++ b/src/gateway.c >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>> is_gateway_config_vpn( >>> new_gateway->ipv4_config); >>> - is_vpn6 = do_ipv4 && >>> - new_gateway->ipv4_config && >>> + is_vpn6 = do_ipv6 && >>> + new_gateway->ipv6_config && >>> is_gateway_config_vpn( >>> - new_gateway->ipv4_config); >>> + new_gateway->ipv6_config); >>> } else { >>> if (do_ipv4 && new_gateway->ipv4_config) >>> -- >>> 2.43.0 >>> Gabriel, >>> Great catch on this copy-and-paste typo; thank you! >>> Best, >>> Grant >> >
Ok, right. I get your point, if that feature is missing it will be quite impossible to use WG. Our version with the changes does handle that, and also requires CIDR format for IP address, well, check is a bit rudimentary: https://github.com/sailfishos/connman/blob/master/connman/vpn/plugins/wireguard.c#L201 but since all goes through getaddrinfo() checks it should work if DNS is working on the transport medium. - Jussi On 1/23/25 13:49, Christian Hewitt wrote: > Ignore: https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=90592f7a58358a98bde5df6928e2b871041c12bc > > So I think this is not the feature I’m thinking of, as it discusses Endpoint re-resolving. > > The challenge our users have is ‘Host’ which currently must be an IP address. Upstream WireGuard with wg-quick etc. allows an FQDN. I see users that need to connect to home locations on dynamic IPs where Host will periodically change. I also see users with commercial VPN services which use an FQDN in the (upstream) wireguard configuration format and this resolves to multiple A records (round-robin balancing) and the ‘static’ IPs move around in their ASN range over time in an an attempt to mitigate (poor) IP reputation issues. > > Christian > > >> On 23 Jan 2025, at 3:35 pm, Christian Hewitt <christianshewitt@gmail.com> wrote: >> >> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? >> >> Christian >> >>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>> >>> Hi Christian, >>> >>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >>> >>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >>> >>> Br, >>> Jussi >>> >>> >>> On 1/23/25 13:12, Christian Hewitt wrote: >>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>>> Christian >>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>> Hello, >>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>>> BR, >>>> Jussi >>>> On 1/23/25 12:45, daniel antoine wrote: >>>> Hi >>>> I have opened a ticket for connman-vpn not working with wireguard in >>>> April 2024. If you give me the patches I can test them >>>> Best regards >>>> Daniel >>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>>> <gerickson@nuovations.com> a écrit : >>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>> I simply changed them to ipv6 and got it working. >>>> not related to the patch: >>>> I had to manually add ip route so the other devices could be pinged >>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>> # ip route >>>> 1.1.1.1 dev wg0 scope link >>>> 8.8.8.8 dev wg0 scope link >>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>> 10.42.0.1 dev end1 scope link >>>> <vpn host ip> via 10.42.0.1 dev end1 >>>> the missing route added manually: >>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>> an equivalent wireguard file adds it properly (using wg-quick) >>>> Is the plugin lacking some implementation? >>>> --- >>>> src/gateway.c | 6 +++--- >>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>> diff --git a/src/gateway.c b/src/gateway.c >>>> index 16c87f83..b2c211e2 100644 >>>> --- a/src/gateway.c >>>> +++ b/src/gateway.c >>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>> is_gateway_config_vpn( >>>> new_gateway->ipv4_config); >>>> - is_vpn6 = do_ipv4 && >>>> - new_gateway->ipv4_config && >>>> + is_vpn6 = do_ipv6 && >>>> + new_gateway->ipv6_config && >>>> is_gateway_config_vpn( >>>> - new_gateway->ipv4_config); >>>> + new_gateway->ipv6_config); >>>> } else { >>>> if (do_ipv4 && new_gateway->ipv4_config) >>>> -- >>>> 2.43.0 >>>> Gabriel, >>>> Great catch on this copy-and-paste typo; thank you! >>>> Best, >>>> Grant >>> >> >
It’s not impossible, but definitely less convenient. There are some messy script workarounds in our forum and a regular drip-feed of people reporting WireGuard connects but doesn’t work; because they configured Host with an FQDN. I’m going to have a play with your fork to see if that meets our needs. If yes, I won’t be switching LibreELEC as we love upstream sources not forks, but I’ll be enquiring how we can bribe you into upstreaming the required changes :) Christian > On 23 Jan 2025, at 4:08 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > > Ok, right. I get your point, if that feature is missing it will be quite impossible to use WG. > > Our version with the changes does handle that, and also requires CIDR format for IP address, well, check is a bit rudimentary: > https://github.com/sailfishos/connman/blob/master/connman/vpn/plugins/wireguard.c#L201 but since all goes through getaddrinfo() checks it should work if DNS is working on the transport medium. > > - Jussi > > > > On 1/23/25 13:49, Christian Hewitt wrote: >> Ignore: https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=90592f7a58358a98bde5df6928e2b871041c12bc >> So I think this is not the feature I’m thinking of, as it discusses Endpoint re-resolving. >> The challenge our users have is ‘Host’ which currently must be an IP address. Upstream WireGuard with wg-quick etc. allows an FQDN. I see users that need to connect to home locations on dynamic IPs where Host will periodically change. I also see users with commercial VPN services which use an FQDN in the (upstream) wireguard configuration format and this resolves to multiple A records (round-robin balancing) and the ‘static’ IPs move around in their ASN range over time in an an attempt to mitigate (poor) IP reputation issues. >> Christian >>> On 23 Jan 2025, at 3:35 pm, Christian Hewitt <christianshewitt@gmail.com> wrote: >>> >>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? >>> >>> Christian >>> >>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>> >>>> Hi Christian, >>>> >>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >>>> >>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >>>> >>>> Br, >>>> Jussi >>>> >>>> >>>> On 1/23/25 13:12, Christian Hewitt wrote: >>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>>>> Christian >>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>> Hello, >>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>>>> BR, >>>>> Jussi >>>>> On 1/23/25 12:45, daniel antoine wrote: >>>>> Hi >>>>> I have opened a ticket for connman-vpn not working with wireguard in >>>>> April 2024. If you give me the patches I can test them >>>>> Best regards >>>>> Daniel >>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>>>> <gerickson@nuovations.com> a écrit : >>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>>> I simply changed them to ipv6 and got it working. >>>>> not related to the patch: >>>>> I had to manually add ip route so the other devices could be pinged >>>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>>> # ip route >>>>> 1.1.1.1 dev wg0 scope link >>>>> 8.8.8.8 dev wg0 scope link >>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>>> 10.42.0.1 dev end1 scope link >>>>> <vpn host ip> via 10.42.0.1 dev end1 >>>>> the missing route added manually: >>>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>>> an equivalent wireguard file adds it properly (using wg-quick) >>>>> Is the plugin lacking some implementation? >>>>> --- >>>>> src/gateway.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> diff --git a/src/gateway.c b/src/gateway.c >>>>> index 16c87f83..b2c211e2 100644 >>>>> --- a/src/gateway.c >>>>> +++ b/src/gateway.c >>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>>> is_gateway_config_vpn( >>>>> new_gateway->ipv4_config); >>>>> - is_vpn6 = do_ipv4 && >>>>> - new_gateway->ipv4_config && >>>>> + is_vpn6 = do_ipv6 && >>>>> + new_gateway->ipv6_config && >>>>> is_gateway_config_vpn( >>>>> - new_gateway->ipv4_config); >>>>> + new_gateway->ipv6_config); >>>>> } else { >>>>> if (do_ipv4 && new_gateway->ipv4_config) >>>>> -- >>>>> 2.43.0 >>>>> Gabriel, >>>>> Great catch on this copy-and-paste typo; thank you! >>>>> Best, >>>>> Grant >>>> >>> >
Hi Christian, Yes, it will get a bit messy by doing so. Heh, no need to talk about bribes... unless you have a flux capacitor and some glowing fuel for a DeLorean... so it is really a matter of time. I'll try to squeeze some time off for doing the patch sets. - Jussi On 1/23/25 15:16, Christian Hewitt wrote: > It’s not impossible, but definitely less convenient. There are some messy script workarounds in our forum and a regular drip-feed of people reporting WireGuard connects but doesn’t work; because they configured Host with an FQDN. > > I’m going to have a play with your fork to see if that meets our needs. If yes, I won’t be switching LibreELEC as we love upstream sources not forks, but I’ll be enquiring how we can bribe you into upstreaming the required changes :) > > Christian > >> On 23 Jan 2025, at 4:08 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> >> Ok, right. I get your point, if that feature is missing it will be quite impossible to use WG. >> >> Our version with the changes does handle that, and also requires CIDR format for IP address, well, check is a bit rudimentary: >> https://github.com/sailfishos/connman/blob/master/connman/vpn/plugins/wireguard.c#L201 but since all goes through getaddrinfo() checks it should work if DNS is working on the transport medium. >> >> - Jussi >> >> >> >> On 1/23/25 13:49, Christian Hewitt wrote: >>> Ignore: https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=90592f7a58358a98bde5df6928e2b871041c12bc >>> So I think this is not the feature I’m thinking of, as it discusses Endpoint re-resolving. >>> The challenge our users have is ‘Host’ which currently must be an IP address. Upstream WireGuard with wg-quick etc. allows an FQDN. I see users that need to connect to home locations on dynamic IPs where Host will periodically change. I also see users with commercial VPN services which use an FQDN in the (upstream) wireguard configuration format and this resolves to multiple A records (round-robin balancing) and the ‘static’ IPs move around in their ASN range over time in an an attempt to mitigate (poor) IP reputation issues. >>> Christian >>>> On 23 Jan 2025, at 3:35 pm, Christian Hewitt <christianshewitt@gmail.com> wrote: >>>> >>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? >>>> >>>> Christian >>>> >>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>> >>>>> Hi Christian, >>>>> >>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >>>>> >>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >>>>> >>>>> Br, >>>>> Jussi >>>>> >>>>> >>>>> On 1/23/25 13:12, Christian Hewitt wrote: >>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>>>>> Christian >>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>>> Hello, >>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>>>>> BR, >>>>>> Jussi >>>>>> On 1/23/25 12:45, daniel antoine wrote: >>>>>> Hi >>>>>> I have opened a ticket for connman-vpn not working with wireguard in >>>>>> April 2024. If you give me the patches I can test them >>>>>> Best regards >>>>>> Daniel >>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>>>>> <gerickson@nuovations.com> a écrit : >>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>>>> I simply changed them to ipv6 and got it working. >>>>>> not related to the patch: >>>>>> I had to manually add ip route so the other devices could be pinged >>>>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>>>> # ip route >>>>>> 1.1.1.1 dev wg0 scope link >>>>>> 8.8.8.8 dev wg0 scope link >>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>>>> 10.42.0.1 dev end1 scope link >>>>>> <vpn host ip> via 10.42.0.1 dev end1 >>>>>> the missing route added manually: >>>>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>>>> an equivalent wireguard file adds it properly (using wg-quick) >>>>>> Is the plugin lacking some implementation? >>>>>> --- >>>>>> src/gateway.c | 6 +++--- >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>> diff --git a/src/gateway.c b/src/gateway.c >>>>>> index 16c87f83..b2c211e2 100644 >>>>>> --- a/src/gateway.c >>>>>> +++ b/src/gateway.c >>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>>>> is_gateway_config_vpn( >>>>>> new_gateway->ipv4_config); >>>>>> - is_vpn6 = do_ipv4 && >>>>>> - new_gateway->ipv4_config && >>>>>> + is_vpn6 = do_ipv6 && >>>>>> + new_gateway->ipv6_config && >>>>>> is_gateway_config_vpn( >>>>>> - new_gateway->ipv4_config); >>>>>> + new_gateway->ipv6_config); >>>>>> } else { >>>>>> if (do_ipv4 && new_gateway->ipv4_config) >>>>>> -- >>>>>> 2.43.0 >>>>>> Gabriel, >>>>>> Great catch on this copy-and-paste typo; thank you! >>>>>> Best, >>>>>> Grant >>>>> >>>> >> >
Hi Christian, Actually, that commit is in upstream. https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c - the date on the cherry-picked commits is the date of cherry picking (I guess I missed some option while doing this..) but the original commit is there submitted on 2020-07-31. I also pushed the association state and most of the wireguard fixes I've done to the mailing list. Have fun testing and tell me if it works better, we can always improve it if something is still missing. There are few commits I held back as they could be the next patch set, because support for IPv4 and IPv6 addresses, and the route adding fixes are also quite large changes. BR, - Jussi On 1/23/25 13:35, Christian Hewitt wrote: > Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > > Christian > >> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >> >> Hi Christian, >> >> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >> >> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >> >> Br, >> Jussi >> >> >> On 1/23/25 13:12, Christian Hewitt wrote: >>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>> Christian >>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>> Hello, >>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>> BR, >>> Jussi >>> On 1/23/25 12:45, daniel antoine wrote: >>> Hi >>> I have opened a ticket for connman-vpn not working with wireguard in >>> April 2024. If you give me the patches I can test them >>> Best regards >>> Daniel >>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>> <gerickson@nuovations.com> a écrit : >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>> I was testing connman's wireguard plugin and got a segmentation fault. >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>> I simply changed them to ipv6 and got it working. >>> not related to the patch: >>> I had to manually add ip route so the other devices could be pinged >>> The plugin adds routes for the WireGuard.DNS configuration setting >>> # ip route >>> 1.1.1.1 dev wg0 scope link >>> 8.8.8.8 dev wg0 scope link >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>> 10.42.0.1 dev end1 scope link >>> <vpn host ip> via 10.42.0.1 dev end1 >>> the missing route added manually: >>> ip route add 10.33.0.0/16 dev wg0 scope link >>> an equivalent wireguard file adds it properly (using wg-quick) >>> Is the plugin lacking some implementation? >>> --- >>> src/gateway.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> diff --git a/src/gateway.c b/src/gateway.c >>> index 16c87f83..b2c211e2 100644 >>> --- a/src/gateway.c >>> +++ b/src/gateway.c >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>> is_gateway_config_vpn( >>> new_gateway->ipv4_config); >>> - is_vpn6 = do_ipv4 && >>> - new_gateway->ipv4_config && >>> + is_vpn6 = do_ipv6 && >>> + new_gateway->ipv6_config && >>> is_gateway_config_vpn( >>> - new_gateway->ipv4_config); >>> + new_gateway->ipv6_config); >>> } else { >>> if (do_ipv4 && new_gateway->ipv4_config) >>> -- >>> 2.43.0 >>> Gabriel, >>> Great catch on this copy-and-paste typo; thank you! >>> Best, >>> Grant >> >
Hi Jussi Grant Christian and Gabiel I have installed first the Gabriel patch and tested but my vpn connexion drops after 5 seconds and finally hangs the wifi connexion I have continued by installing the eleven and twelves jussi patches but my compilation failed with the first patch 11-1 =======> name: connman =======> version: 1.43 =======> release: 9 =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist =======> WARNING: connman.man1737741659any.cards.tar.xz already exist =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist =======> Building starting... cp allow_group_network.diff /tmp/work/src cp vpn6.patch /tmp/work/src cp vpn-11-1.patch /tmp/work/src cp vpn-11-2.patch /tmp/work/src cp vpn-11-3.patch /tmp/work/src cp vpn-11-4.patch /tmp/work/src cp vpn-11-5.patch /tmp/work/src cp vpn-11-6.patch /tmp/work/src cp vpn-11-7.patch /tmp/work/src cp vpn-11-8.patch /tmp/work/src cp vpn-11-9.patch /tmp/work/src cp vpn-11-10.patch /tmp/work/src cp vpn-11-11.patch /tmp/work/src cp vpn-12-1.patch /tmp/work/src cp vpn-12-2.patch /tmp/work/src cp vpn-12-3.patch /tmp/work/src cp vpn-12-4.patch /tmp/work/src cp vpn-12-5.patch /tmp/work/src cp vpn-12-6.patch /tmp/work/src cp vpn-12-7.patch /tmp/work/src cp vpn-12-8.patch /tmp/work/src cp vpn-12-9.patch /tmp/work/src cp vpn-12-10.patch /tmp/work/src cp vpn-12-11.patch /tmp/work/src cp vpn-12-12.patch /tmp/work/src + prepare + git clone https://git.kernel.org/pub/scm/network/connman/connman.git connman-1.43 Cloning into 'connman-1.43'... remote: Enumerating objects: 41151, done. remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151 Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done. Resolving deltas: 100% (31525/31525), done. + cd connman-1.43 + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66 Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE + patch -Np1 -i /tmp/work/src/allow_group_network.diff patching file src/connman-polkit.conf Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). + patch -Np1 -i /tmp/work/src/vpn6.patch patching file src/gateway.c + patch -Np1 -i /tmp/work/src/vpn-11-1.patch patching file src/agent.c Hunk #1 FAILED at 201. 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed. I have copy the patches from the e-mail , may be it introduce false characters or must i copy them from the dev list Best regards Daniel Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen <jussi.laakkonen@jolla.com> a écrit : > > Hi Christian, > > Actually, that commit is in upstream. > https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c > - the date on the cherry-picked commits is the date of cherry picking (I > guess I missed some option while doing this..) but the original commit > is there submitted on 2020-07-31. > > I also pushed the association state and most of the wireguard fixes I've > done to the mailing list. Have fun testing and tell me if it works > better, we can always improve it if something is still missing. There > are few commits I held back as they could be the next patch set, because > support for IPv4 and IPv6 addresses, and the route adding fixes are also > quite large changes. > > BR, > - Jussi > > > > On 1/23/25 13:35, Christian Hewitt wrote: > > Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > > > > Christian > > > >> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >> > >> Hi Christian, > >> > >> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. > >> > >> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. > >> > >> Br, > >> Jussi > >> > >> > >> On 1/23/25 13:12, Christian Hewitt wrote: > >>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> > >>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: > >>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd > >>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). > >>> Christian > >>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >>> Hello, > >>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn > >>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 > >>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. > >>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. > >>> BR, > >>> Jussi > >>> On 1/23/25 12:45, daniel antoine wrote: > >>> Hi > >>> I have opened a ticket for connman-vpn not working with wireguard in > >>> April 2024. If you give me the patches I can test them > >>> Best regards > >>> Daniel > >>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson > >>> <gerickson@nuovations.com> a écrit : > >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > >>> I was testing connman's wireguard plugin and got a segmentation fault. > >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > >>> I simply changed them to ipv6 and got it working. > >>> not related to the patch: > >>> I had to manually add ip route so the other devices could be pinged > >>> The plugin adds routes for the WireGuard.DNS configuration setting > >>> # ip route > >>> 1.1.1.1 dev wg0 scope link > >>> 8.8.8.8 dev wg0 scope link > >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > >>> 10.42.0.1 dev end1 scope link > >>> <vpn host ip> via 10.42.0.1 dev end1 > >>> the missing route added manually: > >>> ip route add 10.33.0.0/16 dev wg0 scope link > >>> an equivalent wireguard file adds it properly (using wg-quick) > >>> Is the plugin lacking some implementation? > >>> --- > >>> src/gateway.c | 6 +++--- > >>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>> diff --git a/src/gateway.c b/src/gateway.c > >>> index 16c87f83..b2c211e2 100644 > >>> --- a/src/gateway.c > >>> +++ b/src/gateway.c > >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > >>> is_gateway_config_vpn( > >>> new_gateway->ipv4_config); > >>> - is_vpn6 = do_ipv4 && > >>> - new_gateway->ipv4_config && > >>> + is_vpn6 = do_ipv6 && > >>> + new_gateway->ipv6_config && > >>> is_gateway_config_vpn( > >>> - new_gateway->ipv4_config); > >>> + new_gateway->ipv6_config); > >>> } else { > >>> if (do_ipv4 && new_gateway->ipv4_config) > >>> -- > >>> 2.43.0 > >>> Gabriel, > >>> Great catch on this copy-and-paste typo; thank you! > >>> Best, > >>> Grant > >> > > > >
I have copy the patches from the dev list and they have all passed ;
The vpn connection continue to drop with in the journalctl
janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index
5 operstate 6 <UP>
janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania
janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider
configuration wireguard
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6
type 65534 <NONE>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 2 <DOWN>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags
98513 <UP,RUNNING,LOWER_UP>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 0 <UNKNOWN>
janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 2 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6
operstate 2 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6
and
● connman-vpn.service - ConnMan VPN service
Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service;
enabled; preset: enabled)
Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago
Invocation: c3584a6570fc48deb60efbb589e55903
Main PID: 1176 (connman-vpnd)
Tasks: 1 (limit: 4915)
Memory: 1.1M (peak: 1.7M)
CPU: 24ms
CGroup: /system.slice/connman-vpn.service
└─1176 /usr/bin/connman-vpnd -n
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6
type 65534 <NONE>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 2 <DOWN>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags
98513 <UP,RUNNING,LOWER_UP>
janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 0 <UNKNOWN>
janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
operstate 2 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6
operstate 2 <DOWN>
janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6
There was a question about a reverse patch for the iptable. Does I
have missed it
Best regards
Daniel
Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit :
>
> Hi Jussi Grant Christian and Gabiel
>
> I have installed first the Gabriel patch and tested but my vpn
> connexion drops after 5 seconds and finally hangs the wifi connexion
>
> I have continued by installing the eleven and twelves jussi patches
> but my compilation failed with the first patch 11-1
>
> =======> name: connman
> =======> version: 1.43
> =======> release: 9
> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist
> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist
> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist
> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist
> =======> Building starting...
> cp allow_group_network.diff /tmp/work/src
> cp vpn6.patch /tmp/work/src
> cp vpn-11-1.patch /tmp/work/src
> cp vpn-11-2.patch /tmp/work/src
> cp vpn-11-3.patch /tmp/work/src
> cp vpn-11-4.patch /tmp/work/src
> cp vpn-11-5.patch /tmp/work/src
> cp vpn-11-6.patch /tmp/work/src
> cp vpn-11-7.patch /tmp/work/src
> cp vpn-11-8.patch /tmp/work/src
> cp vpn-11-9.patch /tmp/work/src
> cp vpn-11-10.patch /tmp/work/src
> cp vpn-11-11.patch /tmp/work/src
> cp vpn-12-1.patch /tmp/work/src
> cp vpn-12-2.patch /tmp/work/src
> cp vpn-12-3.patch /tmp/work/src
> cp vpn-12-4.patch /tmp/work/src
> cp vpn-12-5.patch /tmp/work/src
> cp vpn-12-6.patch /tmp/work/src
> cp vpn-12-7.patch /tmp/work/src
> cp vpn-12-8.patch /tmp/work/src
> cp vpn-12-9.patch /tmp/work/src
> cp vpn-12-10.patch /tmp/work/src
> cp vpn-12-11.patch /tmp/work/src
> cp vpn-12-12.patch /tmp/work/src
> + prepare
> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git
> connman-1.43
> Cloning into 'connman-1.43'...
> remote: Enumerating objects: 41151, done.
> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151
> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done.
> Resolving deltas: 100% (31525/31525), done.
> + cd connman-1.43
> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66
> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by switching back to a branch.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -c with the switch command. Example:
>
> git switch -c <new-branch-name>
>
> Or undo this operation with:
>
> git switch -
>
> Turn off this advice by setting config variable advice.detachedHead to false
>
> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE
> + patch -Np1 -i /tmp/work/src/allow_group_network.diff
> patching file src/connman-polkit.conf
> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines).
> + patch -Np1 -i /tmp/work/src/vpn6.patch
> patching file src/gateway.c
> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch
> patching file src/agent.c
> Hunk #1 FAILED at 201.
> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej
> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed.
>
> I have copy the patches from the e-mail , may be it introduce false
> characters or must i copy them from the dev list
>
> Best regards
>
> Daniel
>
>
> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen
> <jussi.laakkonen@jolla.com> a écrit :
> >
> > Hi Christian,
> >
> > Actually, that commit is in upstream.
> > https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c
> > - the date on the cherry-picked commits is the date of cherry picking (I
> > guess I missed some option while doing this..) but the original commit
> > is there submitted on 2020-07-31.
> >
> > I also pushed the association state and most of the wireguard fixes I've
> > done to the mailing list. Have fun testing and tell me if it works
> > better, we can always improve it if something is still missing. There
> > are few commits I held back as they could be the next patch set, because
> > support for IPv4 and IPv6 addresses, and the route adding fixes are also
> > quite large changes.
> >
> > BR,
> > - Jussi
> >
> >
> >
> > On 1/23/25 13:35, Christian Hewitt wrote:
> > > Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream?
> > >
> > > Christian
> > >
> > >> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote:
> > >>
> > >> Hi Christian,
> > >>
> > >> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features.
> > >>
> > >> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c.
> > >>
> > >> Br,
> > >> Jussi
> > >>
> > >>
> > >> On 1/23/25 13:12, Christian Hewitt wrote:
> > >>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
> > >>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting:
> > >>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd
> > >>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!).
> > >>> Christian
> > >>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote:
> > >>> Hello,
> > >>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn
> > >>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97
> > >>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc.
> > >>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big.
> > >>> BR,
> > >>> Jussi
> > >>> On 1/23/25 12:45, daniel antoine wrote:
> > >>> Hi
> > >>> I have opened a ticket for connman-vpn not working with wireguard in
> > >>> April 2024. If you give me the patches I can test them
> > >>> Best regards
> > >>> Daniel
> > >>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson
> > >>> <gerickson@nuovations.com> a écrit :
> > >>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote:
> > >>> I was testing connman's wireguard plugin and got a segmentation fault.
> > >>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn.
> > >>> I simply changed them to ipv6 and got it working.
> > >>> not related to the patch:
> > >>> I had to manually add ip route so the other devices could be pinged
> > >>> The plugin adds routes for the WireGuard.DNS configuration setting
> > >>> # ip route
> > >>> 1.1.1.1 dev wg0 scope link
> > >>> 8.8.8.8 dev wg0 scope link
> > >>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83
> > >>> 10.42.0.1 dev end1 scope link
> > >>> <vpn host ip> via 10.42.0.1 dev end1
> > >>> the missing route added manually:
> > >>> ip route add 10.33.0.0/16 dev wg0 scope link
> > >>> an equivalent wireguard file adds it properly (using wg-quick)
> > >>> Is the plugin lacking some implementation?
> > >>> ---
> > >>> src/gateway.c | 6 +++---
> > >>> 1 file changed, 3 insertions(+), 3 deletions(-)
> > >>> diff --git a/src/gateway.c b/src/gateway.c
> > >>> index 16c87f83..b2c211e2 100644
> > >>> --- a/src/gateway.c
> > >>> +++ b/src/gateway.c
> > >>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service,
> > >>> is_gateway_config_vpn(
> > >>> new_gateway->ipv4_config);
> > >>> - is_vpn6 = do_ipv4 &&
> > >>> - new_gateway->ipv4_config &&
> > >>> + is_vpn6 = do_ipv6 &&
> > >>> + new_gateway->ipv6_config &&
> > >>> is_gateway_config_vpn(
> > >>> - new_gateway->ipv4_config);
> > >>> + new_gateway->ipv6_config);
> > >>> } else {
> > >>> if (do_ipv4 && new_gateway->ipv4_config)
> > >>> --
> > >>> 2.43.0
> > >>> Gabriel,
> > >>> Great catch on this copy-and-paste typo; thank you!
> > >>> Best,
> > >>> Grant
> > >>
> > >
> >
> >
I’ve picked patches into https://github.com/chewitt/connman/commits/wireguard This is connman HEAD + Gabriel's is_vpn6 patch + my revert patch (to fix routing) + the two series that Jussi posted to the list yesterday. For me this is working fine with no wireguard issues observed since this morning when I’ve rebuilt a LibreELEC image using that branch. I plan to use it myself for a couple of days, then if all good I’ll push changes into LibreELEC nightly images for a while to get some wider testing done. Christian > On 25 Jan 2025, at 3:23 pm, daniel antoine <univac55@gmail.com> wrote: > > I have copy the patches from the dev list and they have all passed ; > The vpn connection continue to drop with in the journalctl > > janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index > 5 operstate 6 <UP> > janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania > janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider > configuration wireguard > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > type 65534 <NONE> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 2 <DOWN> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > 98513 <UP,RUNNING,LOWER_UP> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 0 <UNKNOWN> > janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 2 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > operstate 2 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > > and > > ● connman-vpn.service - ConnMan VPN service > Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service; > enabled; preset: enabled) > Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago > Invocation: c3584a6570fc48deb60efbb589e55903 > Main PID: 1176 (connman-vpnd) > Tasks: 1 (limit: 4915) > Memory: 1.1M (peak: 1.7M) > CPU: 24ms > CGroup: /system.slice/connman-vpn.service > └─1176 /usr/bin/connman-vpnd -n > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > type 65534 <NONE> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 2 <DOWN> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > 98513 <UP,RUNNING,LOWER_UP> > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 0 <UNKNOWN> > janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > operstate 2 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > operstate 2 <DOWN> > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > > There was a question about a reverse patch for the iptable. Does I > have missed it > > Best regards > > Daniel > > > Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit : >> >> Hi Jussi Grant Christian and Gabiel >> >> I have installed first the Gabriel patch and tested but my vpn >> connexion drops after 5 seconds and finally hangs the wifi connexion >> >> I have continued by installing the eleven and twelves jussi patches >> but my compilation failed with the first patch 11-1 >> >> =======> name: connman >> =======> version: 1.43 >> =======> release: 9 >> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist >> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist >> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist >> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist >> =======> Building starting... >> cp allow_group_network.diff /tmp/work/src >> cp vpn6.patch /tmp/work/src >> cp vpn-11-1.patch /tmp/work/src >> cp vpn-11-2.patch /tmp/work/src >> cp vpn-11-3.patch /tmp/work/src >> cp vpn-11-4.patch /tmp/work/src >> cp vpn-11-5.patch /tmp/work/src >> cp vpn-11-6.patch /tmp/work/src >> cp vpn-11-7.patch /tmp/work/src >> cp vpn-11-8.patch /tmp/work/src >> cp vpn-11-9.patch /tmp/work/src >> cp vpn-11-10.patch /tmp/work/src >> cp vpn-11-11.patch /tmp/work/src >> cp vpn-12-1.patch /tmp/work/src >> cp vpn-12-2.patch /tmp/work/src >> cp vpn-12-3.patch /tmp/work/src >> cp vpn-12-4.patch /tmp/work/src >> cp vpn-12-5.patch /tmp/work/src >> cp vpn-12-6.patch /tmp/work/src >> cp vpn-12-7.patch /tmp/work/src >> cp vpn-12-8.patch /tmp/work/src >> cp vpn-12-9.patch /tmp/work/src >> cp vpn-12-10.patch /tmp/work/src >> cp vpn-12-11.patch /tmp/work/src >> cp vpn-12-12.patch /tmp/work/src >> + prepare >> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git >> connman-1.43 >> Cloning into 'connman-1.43'... >> remote: Enumerating objects: 41151, done. >> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151 >> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done. >> Resolving deltas: 100% (31525/31525), done. >> + cd connman-1.43 >> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66 >> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'. >> >> You are in 'detached HEAD' state. You can look around, make experimental >> changes and commit them, and you can discard any commits you make in this >> state without impacting any branches by switching back to a branch. >> >> If you want to create a new branch to retain commits you create, you may >> do so (now or later) by using -c with the switch command. Example: >> >> git switch -c <new-branch-name> >> >> Or undo this operation with: >> >> git switch - >> >> Turn off this advice by setting config variable advice.detachedHead to false >> >> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE >> + patch -Np1 -i /tmp/work/src/allow_group_network.diff >> patching file src/connman-polkit.conf >> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). >> + patch -Np1 -i /tmp/work/src/vpn6.patch >> patching file src/gateway.c >> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch >> patching file src/agent.c >> Hunk #1 FAILED at 201. >> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej >> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed. >> >> I have copy the patches from the e-mail , may be it introduce false >> characters or must i copy them from the dev list >> >> Best regards >> >> Daniel >> >> >> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen >> <jussi.laakkonen@jolla.com> a écrit : >>> >>> Hi Christian, >>> >>> Actually, that commit is in upstream. >>> https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c >>> - the date on the cherry-picked commits is the date of cherry picking (I >>> guess I missed some option while doing this..) but the original commit >>> is there submitted on 2020-07-31. >>> >>> I also pushed the association state and most of the wireguard fixes I've >>> done to the mailing list. Have fun testing and tell me if it works >>> better, we can always improve it if something is still missing. There >>> are few commits I held back as they could be the next patch set, because >>> support for IPv4 and IPv6 addresses, and the route adding fixes are also >>> quite large changes. >>> >>> BR, >>> - Jussi >>> >>> >>> >>> On 1/23/25 13:35, Christian Hewitt wrote: >>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? >>>> >>>> Christian >>>> >>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>> >>>>> Hi Christian, >>>>> >>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >>>>> >>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >>>>> >>>>> Br, >>>>> Jussi >>>>> >>>>> >>>>> On 1/23/25 13:12, Christian Hewitt wrote: >>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>>>>> Christian >>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>>> Hello, >>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>>>>> BR, >>>>>> Jussi >>>>>> On 1/23/25 12:45, daniel antoine wrote: >>>>>> Hi >>>>>> I have opened a ticket for connman-vpn not working with wireguard in >>>>>> April 2024. If you give me the patches I can test them >>>>>> Best regards >>>>>> Daniel >>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>>>>> <gerickson@nuovations.com> a écrit : >>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>>>> I simply changed them to ipv6 and got it working. >>>>>> not related to the patch: >>>>>> I had to manually add ip route so the other devices could be pinged >>>>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>>>> # ip route >>>>>> 1.1.1.1 dev wg0 scope link >>>>>> 8.8.8.8 dev wg0 scope link >>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>>>> 10.42.0.1 dev end1 scope link >>>>>> <vpn host ip> via 10.42.0.1 dev end1 >>>>>> the missing route added manually: >>>>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>>>> an equivalent wireguard file adds it properly (using wg-quick) >>>>>> Is the plugin lacking some implementation? >>>>>> --- >>>>>> src/gateway.c | 6 +++--- >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>> diff --git a/src/gateway.c b/src/gateway.c >>>>>> index 16c87f83..b2c211e2 100644 >>>>>> --- a/src/gateway.c >>>>>> +++ b/src/gateway.c >>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>>>> is_gateway_config_vpn( >>>>>> new_gateway->ipv4_config); >>>>>> - is_vpn6 = do_ipv4 && >>>>>> - new_gateway->ipv4_config && >>>>>> + is_vpn6 = do_ipv6 && >>>>>> + new_gateway->ipv6_config && >>>>>> is_gateway_config_vpn( >>>>>> - new_gateway->ipv4_config); >>>>>> + new_gateway->ipv6_config); >>>>>> } else { >>>>>> if (do_ipv4 && new_gateway->ipv4_config) >>>>>> -- >>>>>> 2.43.0 >>>>>> Gabriel, >>>>>> Great catch on this copy-and-paste typo; thank you! >>>>>> Best, >>>>>> Grant >>>>> >>>> >>> >>>
Hi with wg-quik I can connect the vpn and ping the endpoint 10.0.7.2 the config file in /etc/wireguard (I have modify it for the e-mail) is [Interface] Address = 10.0.7.5/24 PrivateKey = yyyyy [Peer] Endpoint = monsite.fr:51820 PublicKey = xxxxx AllowedIPs = 10.0.7.0/24 PersistentKeepalive = 25 The config file for connman-vpn in /var/lib/connman-vpn [provider_wireguard] Type = WireGuard Name = chezlui Host = monsite.fr WireGuard.Address = 10.0.7.5/24 WireGuard.PrivateKey = yyyyyy WireGuard.PublicKey = xxxxx WireGuard.AllowedIPs = 10.0.7.0/24 WireGuard.EndpointPort = 51820 WireGuard.PersistentKeepalive = 25 Is there something wrong with it? It cause the wifi connexion to drop when I connect the vpn Best regards Daniel Le sam. 25 janv. 2025 à 14:12, Christian Hewitt <christianshewitt@gmail.com> a écrit : > > I’ve picked patches into https://github.com/chewitt/connman/commits/wireguard > > This is connman HEAD + Gabriel's is_vpn6 patch + my revert patch (to fix routing) > + the two series that Jussi posted to the list yesterday. > > For me this is working fine with no wireguard issues observed since this morning > when I’ve rebuilt a LibreELEC image using that branch. I plan to use it myself > for a couple of days, then if all good I’ll push changes into LibreELEC nightly > images for a while to get some wider testing done. > > Christian > > > > On 25 Jan 2025, at 3:23 pm, daniel antoine <univac55@gmail.com> wrote: > > > > I have copy the patches from the dev list and they have all passed ; > > The vpn connection continue to drop with in the journalctl > > > > janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index > > 5 operstate 6 <UP> > > janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania > > janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider > > configuration wireguard > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > > type 65534 <NONE> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > > 98513 <UP,RUNNING,LOWER_UP> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 0 <UNKNOWN> > > janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > > > > and > > > > ● connman-vpn.service - ConnMan VPN service > > Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service; > > enabled; preset: enabled) > > Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago > > Invocation: c3584a6570fc48deb60efbb589e55903 > > Main PID: 1176 (connman-vpnd) > > Tasks: 1 (limit: 4915) > > Memory: 1.1M (peak: 1.7M) > > CPU: 24ms > > CGroup: /system.slice/connman-vpn.service > > └─1176 /usr/bin/connman-vpnd -n > > > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > > type 65534 <NONE> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > > 98513 <UP,RUNNING,LOWER_UP> > > janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 0 <UNKNOWN> > > janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > > operstate 2 <DOWN> > > janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > > > > There was a question about a reverse patch for the iptable. Does I > > have missed it > > > > Best regards > > > > Daniel > > > > > > Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit : > >> > >> Hi Jussi Grant Christian and Gabiel > >> > >> I have installed first the Gabriel patch and tested but my vpn > >> connexion drops after 5 seconds and finally hangs the wifi connexion > >> > >> I have continued by installing the eleven and twelves jussi patches > >> but my compilation failed with the first patch 11-1 > >> > >> =======> name: connman > >> =======> version: 1.43 > >> =======> release: 9 > >> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist > >> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist > >> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist > >> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist > >> =======> Building starting... > >> cp allow_group_network.diff /tmp/work/src > >> cp vpn6.patch /tmp/work/src > >> cp vpn-11-1.patch /tmp/work/src > >> cp vpn-11-2.patch /tmp/work/src > >> cp vpn-11-3.patch /tmp/work/src > >> cp vpn-11-4.patch /tmp/work/src > >> cp vpn-11-5.patch /tmp/work/src > >> cp vpn-11-6.patch /tmp/work/src > >> cp vpn-11-7.patch /tmp/work/src > >> cp vpn-11-8.patch /tmp/work/src > >> cp vpn-11-9.patch /tmp/work/src > >> cp vpn-11-10.patch /tmp/work/src > >> cp vpn-11-11.patch /tmp/work/src > >> cp vpn-12-1.patch /tmp/work/src > >> cp vpn-12-2.patch /tmp/work/src > >> cp vpn-12-3.patch /tmp/work/src > >> cp vpn-12-4.patch /tmp/work/src > >> cp vpn-12-5.patch /tmp/work/src > >> cp vpn-12-6.patch /tmp/work/src > >> cp vpn-12-7.patch /tmp/work/src > >> cp vpn-12-8.patch /tmp/work/src > >> cp vpn-12-9.patch /tmp/work/src > >> cp vpn-12-10.patch /tmp/work/src > >> cp vpn-12-11.patch /tmp/work/src > >> cp vpn-12-12.patch /tmp/work/src > >> + prepare > >> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git > >> connman-1.43 > >> Cloning into 'connman-1.43'... > >> remote: Enumerating objects: 41151, done. > >> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151 > >> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done. > >> Resolving deltas: 100% (31525/31525), done. > >> + cd connman-1.43 > >> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66 > >> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'. > >> > >> You are in 'detached HEAD' state. You can look around, make experimental > >> changes and commit them, and you can discard any commits you make in this > >> state without impacting any branches by switching back to a branch. > >> > >> If you want to create a new branch to retain commits you create, you may > >> do so (now or later) by using -c with the switch command. Example: > >> > >> git switch -c <new-branch-name> > >> > >> Or undo this operation with: > >> > >> git switch - > >> > >> Turn off this advice by setting config variable advice.detachedHead to false > >> > >> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE > >> + patch -Np1 -i /tmp/work/src/allow_group_network.diff > >> patching file src/connman-polkit.conf > >> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). > >> + patch -Np1 -i /tmp/work/src/vpn6.patch > >> patching file src/gateway.c > >> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch > >> patching file src/agent.c > >> Hunk #1 FAILED at 201. > >> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej > >> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed. > >> > >> I have copy the patches from the e-mail , may be it introduce false > >> characters or must i copy them from the dev list > >> > >> Best regards > >> > >> Daniel > >> > >> > >> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen > >> <jussi.laakkonen@jolla.com> a écrit : > >>> > >>> Hi Christian, > >>> > >>> Actually, that commit is in upstream. > >>> https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c > >>> - the date on the cherry-picked commits is the date of cherry picking (I > >>> guess I missed some option while doing this..) but the original commit > >>> is there submitted on 2020-07-31. > >>> > >>> I also pushed the association state and most of the wireguard fixes I've > >>> done to the mailing list. Have fun testing and tell me if it works > >>> better, we can always improve it if something is still missing. There > >>> are few commits I held back as they could be the next patch set, because > >>> support for IPv4 and IPv6 addresses, and the route adding fixes are also > >>> quite large changes. > >>> > >>> BR, > >>> - Jussi > >>> > >>> > >>> > >>> On 1/23/25 13:35, Christian Hewitt wrote: > >>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > >>>> > >>>> Christian > >>>> > >>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >>>>> > >>>>> Hi Christian, > >>>>> > >>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. > >>>>> > >>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. > >>>>> > >>>>> Br, > >>>>> Jussi > >>>>> > >>>>> > >>>>> On 1/23/25 13:12, Christian Hewitt wrote: > >>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> > >>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: > >>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd > >>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). > >>>>>> Christian > >>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >>>>>> Hello, > >>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn > >>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 > >>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. > >>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. > >>>>>> BR, > >>>>>> Jussi > >>>>>> On 1/23/25 12:45, daniel antoine wrote: > >>>>>> Hi > >>>>>> I have opened a ticket for connman-vpn not working with wireguard in > >>>>>> April 2024. If you give me the patches I can test them > >>>>>> Best regards > >>>>>> Daniel > >>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson > >>>>>> <gerickson@nuovations.com> a écrit : > >>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > >>>>>> I was testing connman's wireguard plugin and got a segmentation fault. > >>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > >>>>>> I simply changed them to ipv6 and got it working. > >>>>>> not related to the patch: > >>>>>> I had to manually add ip route so the other devices could be pinged > >>>>>> The plugin adds routes for the WireGuard.DNS configuration setting > >>>>>> # ip route > >>>>>> 1.1.1.1 dev wg0 scope link > >>>>>> 8.8.8.8 dev wg0 scope link > >>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > >>>>>> 10.42.0.1 dev end1 scope link > >>>>>> <vpn host ip> via 10.42.0.1 dev end1 > >>>>>> the missing route added manually: > >>>>>> ip route add 10.33.0.0/16 dev wg0 scope link > >>>>>> an equivalent wireguard file adds it properly (using wg-quick) > >>>>>> Is the plugin lacking some implementation? > >>>>>> --- > >>>>>> src/gateway.c | 6 +++--- > >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>>>>> diff --git a/src/gateway.c b/src/gateway.c > >>>>>> index 16c87f83..b2c211e2 100644 > >>>>>> --- a/src/gateway.c > >>>>>> +++ b/src/gateway.c > >>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > >>>>>> is_gateway_config_vpn( > >>>>>> new_gateway->ipv4_config); > >>>>>> - is_vpn6 = do_ipv4 && > >>>>>> - new_gateway->ipv4_config && > >>>>>> + is_vpn6 = do_ipv6 && > >>>>>> + new_gateway->ipv6_config && > >>>>>> is_gateway_config_vpn( > >>>>>> - new_gateway->ipv4_config); > >>>>>> + new_gateway->ipv6_config); > >>>>>> } else { > >>>>>> if (do_ipv4 && new_gateway->ipv4_config) > >>>>>> -- > >>>>>> 2.43.0 > >>>>>> Gabriel, > >>>>>> Great catch on this copy-and-paste typo; thank you! > >>>>>> Best, > >>>>>> Grant > >>>>> > >>>> > >>> > >>> >
In the connman config "Host” must be an IP address not an FQDN. Christian > On 25 Jan 2025, at 7:12 pm, daniel antoine <univac55@gmail.com> wrote: > > Hi > with wg-quik I can connect the vpn and ping the endpoint 10.0.7.2 > the config file in /etc/wireguard (I have modify it for the e-mail) is > > [Interface] > Address = 10.0.7.5/24 > PrivateKey = yyyyy > > [Peer] > Endpoint = monsite.fr:51820 > PublicKey = xxxxx > AllowedIPs = 10.0.7.0/24 > PersistentKeepalive = 25 > > The config file for connman-vpn in /var/lib/connman-vpn > > [provider_wireguard] > Type = WireGuard > Name = chezlui > Host = monsite.fr > WireGuard.Address = 10.0.7.5/24 > WireGuard.PrivateKey = yyyyyy > WireGuard.PublicKey = xxxxx > WireGuard.AllowedIPs = 10.0.7.0/24 > WireGuard.EndpointPort = 51820 > WireGuard.PersistentKeepalive = 25 > > Is there something wrong with it? It cause the wifi connexion to drop > when I connect the vpn > > Best regards > > Daniel > > Le sam. 25 janv. 2025 à 14:12, Christian Hewitt > <christianshewitt@gmail.com> a écrit : >> >> I’ve picked patches into https://github.com/chewitt/connman/commits/wireguard >> >> This is connman HEAD + Gabriel's is_vpn6 patch + my revert patch (to fix routing) >> + the two series that Jussi posted to the list yesterday. >> >> For me this is working fine with no wireguard issues observed since this morning >> when I’ve rebuilt a LibreELEC image using that branch. I plan to use it myself >> for a couple of days, then if all good I’ll push changes into LibreELEC nightly >> images for a while to get some wider testing done. >> >> Christian >> >> >>> On 25 Jan 2025, at 3:23 pm, daniel antoine <univac55@gmail.com> wrote: >>> >>> I have copy the patches from the dev list and they have all passed ; >>> The vpn connection continue to drop with in the journalctl >>> >>> janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index >>> 5 operstate 6 <UP> >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider >>> configuration wireguard >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 >>> type 65534 <NONE> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags >>> 98513 <UP,RUNNING,LOWER_UP> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 0 <UNKNOWN> >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 >>> >>> and >>> >>> ● connman-vpn.service - ConnMan VPN service >>> Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service; >>> enabled; preset: enabled) >>> Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago >>> Invocation: c3584a6570fc48deb60efbb589e55903 >>> Main PID: 1176 (connman-vpnd) >>> Tasks: 1 (limit: 4915) >>> Memory: 1.1M (peak: 1.7M) >>> CPU: 24ms >>> CGroup: /system.slice/connman-vpn.service >>> └─1176 /usr/bin/connman-vpnd -n >>> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 >>> type 65534 <NONE> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags >>> 98513 <UP,RUNNING,LOWER_UP> >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 0 <UNKNOWN> >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 >>> operstate 2 <DOWN> >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 >>> >>> There was a question about a reverse patch for the iptable. Does I >>> have missed it >>> >>> Best regards >>> >>> Daniel >>> >>> >>> Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit : >>>> >>>> Hi Jussi Grant Christian and Gabiel >>>> >>>> I have installed first the Gabriel patch and tested but my vpn >>>> connexion drops after 5 seconds and finally hangs the wifi connexion >>>> >>>> I have continued by installing the eleven and twelves jussi patches >>>> but my compilation failed with the first patch 11-1 >>>> >>>> =======> name: connman >>>> =======> version: 1.43 >>>> =======> release: 9 >>>> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist >>>> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist >>>> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist >>>> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist >>>> =======> Building starting... >>>> cp allow_group_network.diff /tmp/work/src >>>> cp vpn6.patch /tmp/work/src >>>> cp vpn-11-1.patch /tmp/work/src >>>> cp vpn-11-2.patch /tmp/work/src >>>> cp vpn-11-3.patch /tmp/work/src >>>> cp vpn-11-4.patch /tmp/work/src >>>> cp vpn-11-5.patch /tmp/work/src >>>> cp vpn-11-6.patch /tmp/work/src >>>> cp vpn-11-7.patch /tmp/work/src >>>> cp vpn-11-8.patch /tmp/work/src >>>> cp vpn-11-9.patch /tmp/work/src >>>> cp vpn-11-10.patch /tmp/work/src >>>> cp vpn-11-11.patch /tmp/work/src >>>> cp vpn-12-1.patch /tmp/work/src >>>> cp vpn-12-2.patch /tmp/work/src >>>> cp vpn-12-3.patch /tmp/work/src >>>> cp vpn-12-4.patch /tmp/work/src >>>> cp vpn-12-5.patch /tmp/work/src >>>> cp vpn-12-6.patch /tmp/work/src >>>> cp vpn-12-7.patch /tmp/work/src >>>> cp vpn-12-8.patch /tmp/work/src >>>> cp vpn-12-9.patch /tmp/work/src >>>> cp vpn-12-10.patch /tmp/work/src >>>> cp vpn-12-11.patch /tmp/work/src >>>> cp vpn-12-12.patch /tmp/work/src >>>> + prepare >>>> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git >>>> connman-1.43 >>>> Cloning into 'connman-1.43'... >>>> remote: Enumerating objects: 41151, done. >>>> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151 >>>> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done. >>>> Resolving deltas: 100% (31525/31525), done. >>>> + cd connman-1.43 >>>> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66 >>>> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'. >>>> >>>> You are in 'detached HEAD' state. You can look around, make experimental >>>> changes and commit them, and you can discard any commits you make in this >>>> state without impacting any branches by switching back to a branch. >>>> >>>> If you want to create a new branch to retain commits you create, you may >>>> do so (now or later) by using -c with the switch command. Example: >>>> >>>> git switch -c <new-branch-name> >>>> >>>> Or undo this operation with: >>>> >>>> git switch - >>>> >>>> Turn off this advice by setting config variable advice.detachedHead to false >>>> >>>> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE >>>> + patch -Np1 -i /tmp/work/src/allow_group_network.diff >>>> patching file src/connman-polkit.conf >>>> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). >>>> + patch -Np1 -i /tmp/work/src/vpn6.patch >>>> patching file src/gateway.c >>>> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch >>>> patching file src/agent.c >>>> Hunk #1 FAILED at 201. >>>> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej >>>> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed. >>>> >>>> I have copy the patches from the e-mail , may be it introduce false >>>> characters or must i copy them from the dev list >>>> >>>> Best regards >>>> >>>> Daniel >>>> >>>> >>>> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen >>>> <jussi.laakkonen@jolla.com> a écrit : >>>>> >>>>> Hi Christian, >>>>> >>>>> Actually, that commit is in upstream. >>>>> https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c >>>>> - the date on the cherry-picked commits is the date of cherry picking (I >>>>> guess I missed some option while doing this..) but the original commit >>>>> is there submitted on 2020-07-31. >>>>> >>>>> I also pushed the association state and most of the wireguard fixes I've >>>>> done to the mailing list. Have fun testing and tell me if it works >>>>> better, we can always improve it if something is still missing. There >>>>> are few commits I held back as they could be the next patch set, because >>>>> support for IPv4 and IPv6 addresses, and the route adding fixes are also >>>>> quite large changes. >>>>> >>>>> BR, >>>>> - Jussi >>>>> >>>>> >>>>> >>>>> On 1/23/25 13:35, Christian Hewitt wrote: >>>>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? >>>>>> >>>>>> Christian >>>>>> >>>>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. >>>>>>> >>>>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. >>>>>>> >>>>>>> Br, >>>>>>> Jussi >>>>>>> >>>>>>> >>>>>>> On 1/23/25 13:12, Christian Hewitt wrote: >>>>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> >>>>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: >>>>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd >>>>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). >>>>>>>> Christian >>>>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: >>>>>>>> Hello, >>>>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn >>>>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 >>>>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. >>>>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. >>>>>>>> BR, >>>>>>>> Jussi >>>>>>>> On 1/23/25 12:45, daniel antoine wrote: >>>>>>>> Hi >>>>>>>> I have opened a ticket for connman-vpn not working with wireguard in >>>>>>>> April 2024. If you give me the patches I can test them >>>>>>>> Best regards >>>>>>>> Daniel >>>>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson >>>>>>>> <gerickson@nuovations.com> a écrit : >>>>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: >>>>>>>> I was testing connman's wireguard plugin and got a segmentation fault. >>>>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. >>>>>>>> I simply changed them to ipv6 and got it working. >>>>>>>> not related to the patch: >>>>>>>> I had to manually add ip route so the other devices could be pinged >>>>>>>> The plugin adds routes for the WireGuard.DNS configuration setting >>>>>>>> # ip route >>>>>>>> 1.1.1.1 dev wg0 scope link >>>>>>>> 8.8.8.8 dev wg0 scope link >>>>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 >>>>>>>> 10.42.0.1 dev end1 scope link >>>>>>>> <vpn host ip> via 10.42.0.1 dev end1 >>>>>>>> the missing route added manually: >>>>>>>> ip route add 10.33.0.0/16 dev wg0 scope link >>>>>>>> an equivalent wireguard file adds it properly (using wg-quick) >>>>>>>> Is the plugin lacking some implementation? >>>>>>>> --- >>>>>>>> src/gateway.c | 6 +++--- >>>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>>> diff --git a/src/gateway.c b/src/gateway.c >>>>>>>> index 16c87f83..b2c211e2 100644 >>>>>>>> --- a/src/gateway.c >>>>>>>> +++ b/src/gateway.c >>>>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, >>>>>>>> is_gateway_config_vpn( >>>>>>>> new_gateway->ipv4_config); >>>>>>>> - is_vpn6 = do_ipv4 && >>>>>>>> - new_gateway->ipv4_config && >>>>>>>> + is_vpn6 = do_ipv6 && >>>>>>>> + new_gateway->ipv6_config && >>>>>>>> is_gateway_config_vpn( >>>>>>>> - new_gateway->ipv4_config); >>>>>>>> + new_gateway->ipv6_config); >>>>>>>> } else { >>>>>>>> if (do_ipv4 && new_gateway->ipv4_config) >>>>>>>> -- >>>>>>>> 2.43.0 >>>>>>>> Gabriel, >>>>>>>> Great catch on this copy-and-paste typo; thank you! >>>>>>>> Best, >>>>>>>> Grant >>>>>>> >>>>>> >>>>> >>>>> >>
Hi Thanks a lot Best regards Daniel Le sam. 25 janv. 2025 à 16:22, Christian Hewitt <christianshewitt@gmail.com> a écrit : > > In the connman config "Host” must be an IP address not an FQDN. > > Christian > > > On 25 Jan 2025, at 7:12 pm, daniel antoine <univac55@gmail.com> wrote: > > > > Hi > > with wg-quik I can connect the vpn and ping the endpoint 10.0.7.2 > > the config file in /etc/wireguard (I have modify it for the e-mail) is > > > > [Interface] > > Address = 10.0.7.5/24 > > PrivateKey = yyyyy > > > > [Peer] > > Endpoint = monsite.fr:51820 > > PublicKey = xxxxx > > AllowedIPs = 10.0.7.0/24 > > PersistentKeepalive = 25 > > > > The config file for connman-vpn in /var/lib/connman-vpn > > > > [provider_wireguard] > > Type = WireGuard > > Name = chezlui > > Host = monsite.fr > > WireGuard.Address = 10.0.7.5/24 > > WireGuard.PrivateKey = yyyyyy > > WireGuard.PublicKey = xxxxx > > WireGuard.AllowedIPs = 10.0.7.0/24 > > WireGuard.EndpointPort = 51820 > > WireGuard.PersistentKeepalive = 25 > > > > Is there something wrong with it? It cause the wifi connexion to drop > > when I connect the vpn > > > > Best regards > > > > Daniel > > > > Le sam. 25 janv. 2025 à 14:12, Christian Hewitt > > <christianshewitt@gmail.com> a écrit : > >> > >> I’ve picked patches into https://github.com/chewitt/connman/commits/wireguard > >> > >> This is connman HEAD + Gabriel's is_vpn6 patch + my revert patch (to fix routing) > >> + the two series that Jussi posted to the list yesterday. > >> > >> For me this is working fine with no wireguard issues observed since this morning > >> when I’ve rebuilt a LibreELEC image using that branch. I plan to use it myself > >> for a couple of days, then if all good I’ll push changes into LibreELEC nightly > >> images for a while to get some wider testing done. > >> > >> Christian > >> > >> > >>> On 25 Jan 2025, at 3:23 pm, daniel antoine <univac55@gmail.com> wrote: > >>> > >>> I have copy the patches from the dev list and they have all passed ; > >>> The vpn connection continue to drop with in the journalctl > >>> > >>> janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index > >>> 5 operstate 6 <UP> > >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania > >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider > >>> configuration wireguard > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > >>> type 65534 <NONE> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > >>> 98513 <UP,RUNNING,LOWER_UP> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 0 <UNKNOWN> > >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > >>> > >>> and > >>> > >>> ● connman-vpn.service - ConnMan VPN service > >>> Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service; > >>> enabled; preset: enabled) > >>> Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago > >>> Invocation: c3584a6570fc48deb60efbb589e55903 > >>> Main PID: 1176 (connman-vpnd) > >>> Tasks: 1 (limit: 4915) > >>> Memory: 1.1M (peak: 1.7M) > >>> CPU: 24ms > >>> CGroup: /system.slice/connman-vpn.service > >>> └─1176 /usr/bin/connman-vpnd -n > >>> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6 > >>> type 65534 <NONE> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags > >>> 98513 <UP,RUNNING,LOWER_UP> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 0 <UNKNOWN> > >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6 > >>> operstate 2 <DOWN> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6 > >>> > >>> There was a question about a reverse patch for the iptable. Does I > >>> have missed it > >>> > >>> Best regards > >>> > >>> Daniel > >>> > >>> > >>> Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit : > >>>> > >>>> Hi Jussi Grant Christian and Gabiel > >>>> > >>>> I have installed first the Gabriel patch and tested but my vpn > >>>> connexion drops after 5 seconds and finally hangs the wifi connexion > >>>> > >>>> I have continued by installing the eleven and twelves jussi patches > >>>> but my compilation failed with the first patch 11-1 > >>>> > >>>> =======> name: connman > >>>> =======> version: 1.43 > >>>> =======> release: 9 > >>>> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist > >>>> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist > >>>> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist > >>>> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist > >>>> =======> Building starting... > >>>> cp allow_group_network.diff /tmp/work/src > >>>> cp vpn6.patch /tmp/work/src > >>>> cp vpn-11-1.patch /tmp/work/src > >>>> cp vpn-11-2.patch /tmp/work/src > >>>> cp vpn-11-3.patch /tmp/work/src > >>>> cp vpn-11-4.patch /tmp/work/src > >>>> cp vpn-11-5.patch /tmp/work/src > >>>> cp vpn-11-6.patch /tmp/work/src > >>>> cp vpn-11-7.patch /tmp/work/src > >>>> cp vpn-11-8.patch /tmp/work/src > >>>> cp vpn-11-9.patch /tmp/work/src > >>>> cp vpn-11-10.patch /tmp/work/src > >>>> cp vpn-11-11.patch /tmp/work/src > >>>> cp vpn-12-1.patch /tmp/work/src > >>>> cp vpn-12-2.patch /tmp/work/src > >>>> cp vpn-12-3.patch /tmp/work/src > >>>> cp vpn-12-4.patch /tmp/work/src > >>>> cp vpn-12-5.patch /tmp/work/src > >>>> cp vpn-12-6.patch /tmp/work/src > >>>> cp vpn-12-7.patch /tmp/work/src > >>>> cp vpn-12-8.patch /tmp/work/src > >>>> cp vpn-12-9.patch /tmp/work/src > >>>> cp vpn-12-10.patch /tmp/work/src > >>>> cp vpn-12-11.patch /tmp/work/src > >>>> cp vpn-12-12.patch /tmp/work/src > >>>> + prepare > >>>> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git > >>>> connman-1.43 > >>>> Cloning into 'connman-1.43'... > >>>> remote: Enumerating objects: 41151, done. > >>>> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151 > >>>> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done. > >>>> Resolving deltas: 100% (31525/31525), done. > >>>> + cd connman-1.43 > >>>> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66 > >>>> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'. > >>>> > >>>> You are in 'detached HEAD' state. You can look around, make experimental > >>>> changes and commit them, and you can discard any commits you make in this > >>>> state without impacting any branches by switching back to a branch. > >>>> > >>>> If you want to create a new branch to retain commits you create, you may > >>>> do so (now or later) by using -c with the switch command. Example: > >>>> > >>>> git switch -c <new-branch-name> > >>>> > >>>> Or undo this operation with: > >>>> > >>>> git switch - > >>>> > >>>> Turn off this advice by setting config variable advice.detachedHead to false > >>>> > >>>> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE > >>>> + patch -Np1 -i /tmp/work/src/allow_group_network.diff > >>>> patching file src/connman-polkit.conf > >>>> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines). > >>>> + patch -Np1 -i /tmp/work/src/vpn6.patch > >>>> patching file src/gateway.c > >>>> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch > >>>> patching file src/agent.c > >>>> Hunk #1 FAILED at 201. > >>>> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej > >>>> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed. > >>>> > >>>> I have copy the patches from the e-mail , may be it introduce false > >>>> characters or must i copy them from the dev list > >>>> > >>>> Best regards > >>>> > >>>> Daniel > >>>> > >>>> > >>>> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen > >>>> <jussi.laakkonen@jolla.com> a écrit : > >>>>> > >>>>> Hi Christian, > >>>>> > >>>>> Actually, that commit is in upstream. > >>>>> https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c > >>>>> - the date on the cherry-picked commits is the date of cherry picking (I > >>>>> guess I missed some option while doing this..) but the original commit > >>>>> is there submitted on 2020-07-31. > >>>>> > >>>>> I also pushed the association state and most of the wireguard fixes I've > >>>>> done to the mailing list. Have fun testing and tell me if it works > >>>>> better, we can always improve it if something is still missing. There > >>>>> are few commits I held back as they could be the next patch set, because > >>>>> support for IPv4 and IPv6 addresses, and the route adding fixes are also > >>>>> quite large changes. > >>>>> > >>>>> BR, > >>>>> - Jussi > >>>>> > >>>>> > >>>>> > >>>>> On 1/23/25 13:35, Christian Hewitt wrote: > >>>>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream? > >>>>>> > >>>>>> Christian > >>>>>> > >>>>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >>>>>>> > >>>>>>> Hi Christian, > >>>>>>> > >>>>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features. > >>>>>>> > >>>>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c. > >>>>>>> > >>>>>>> Br, > >>>>>>> Jussi > >>>>>>> > >>>>>>> > >>>>>>> On 1/23/25 13:12, Christian Hewitt wrote: > >>>>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> > >>>>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting: > >>>>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd > >>>>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!). > >>>>>>>> Christian > >>>>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote: > >>>>>>>> Hello, > >>>>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn > >>>>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 > >>>>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc. > >>>>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big. > >>>>>>>> BR, > >>>>>>>> Jussi > >>>>>>>> On 1/23/25 12:45, daniel antoine wrote: > >>>>>>>> Hi > >>>>>>>> I have opened a ticket for connman-vpn not working with wireguard in > >>>>>>>> April 2024. If you give me the patches I can test them > >>>>>>>> Best regards > >>>>>>>> Daniel > >>>>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson > >>>>>>>> <gerickson@nuovations.com> a écrit : > >>>>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote: > >>>>>>>> I was testing connman's wireguard plugin and got a segmentation fault. > >>>>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn. > >>>>>>>> I simply changed them to ipv6 and got it working. > >>>>>>>> not related to the patch: > >>>>>>>> I had to manually add ip route so the other devices could be pinged > >>>>>>>> The plugin adds routes for the WireGuard.DNS configuration setting > >>>>>>>> # ip route > >>>>>>>> 1.1.1.1 dev wg0 scope link > >>>>>>>> 8.8.8.8 dev wg0 scope link > >>>>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83 > >>>>>>>> 10.42.0.1 dev end1 scope link > >>>>>>>> <vpn host ip> via 10.42.0.1 dev end1 > >>>>>>>> the missing route added manually: > >>>>>>>> ip route add 10.33.0.0/16 dev wg0 scope link > >>>>>>>> an equivalent wireguard file adds it properly (using wg-quick) > >>>>>>>> Is the plugin lacking some implementation? > >>>>>>>> --- > >>>>>>>> src/gateway.c | 6 +++--- > >>>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>>>>>>> diff --git a/src/gateway.c b/src/gateway.c > >>>>>>>> index 16c87f83..b2c211e2 100644 > >>>>>>>> --- a/src/gateway.c > >>>>>>>> +++ b/src/gateway.c > >>>>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, > >>>>>>>> is_gateway_config_vpn( > >>>>>>>> new_gateway->ipv4_config); > >>>>>>>> - is_vpn6 = do_ipv4 && > >>>>>>>> - new_gateway->ipv4_config && > >>>>>>>> + is_vpn6 = do_ipv6 && > >>>>>>>> + new_gateway->ipv6_config && > >>>>>>>> is_gateway_config_vpn( > >>>>>>>> - new_gateway->ipv4_config); > >>>>>>>> + new_gateway->ipv6_config); > >>>>>>>> } else { > >>>>>>>> if (do_ipv4 && new_gateway->ipv4_config) > >>>>>>>> -- > >>>>>>>> 2.43.0 > >>>>>>>> Gabriel, > >>>>>>>> Great catch on this copy-and-paste typo; thank you! > >>>>>>>> Best, > >>>>>>>> Grant > >>>>>>> > >>>>>> > >>>>> > >>>>> > >> >
Hi
I have replaced the fqdn by the ipv4 address of the host that is
located on an OVH distributor. I can connect and ping the endpoint but
my wifi connection passed from offline to ready and the vpn connection
is considered as the default. I lose all access to internet discord
etc...
root@grat-os1:/var/lib/connman-vpn# systemctl status connman
● connman.service - Connection service
Loaded: loaded (/usr/lib/systemd/system/connman.service; enabled;
preset: enabled)
Active: active (running) since Mon 2025-01-27 10:59:15 CET; 13min ago
Invocation: 731fc39df2b9456f996e16e9e484036c
Main PID: 573 (connmand)
Tasks: 1 (limit: 4915)
Memory: 3.3M (peak: 3.6M)
CPU: 136ms
CGroup: /system.slice/connman.service
└─573 /usr/bin/connmand -n
janv. 27 11:12:45 grat-os1 connmand[573]: Interface (null) [ vpn ]
state is configuration
janv. 27 11:12:45 grat-os1 connmand[573]: wg0 {update} flags 98513
<UP,RUNNING,LOWER_UP>
janv. 27 11:12:45 grat-os1 connmand[573]: wg0 {newlink} index 7
address 00:00:00:00:00:00 mtu 1420
janv. 27 11:12:45 grat-os1 connmand[573]: wg0 {newlink} index 7
operstate 0 <UNKNOWN>
janv. 27 11:12:45 grat-os1 connmand[573]: wg0 {add} address
10.0.7.5/24 label wg0 family 2
janv. 27 11:12:45 grat-os1 connmand[573]: Interface wg0 [ vpn ] state is ready
janv. 27 11:12:45 grat-os1 connmand[573]: Interface wlan0 [ wifi ]
state is ready
janv. 27 11:12:45 grat-os1 connmand[573]: Interface wg0 [ vpn ] is the default
janv. 27 11:12:45 grat-os1 connmand[573]: Interface wg0 [ vpn ] is the default
janv. 27 11:12:45 grat-os1 connmand[573]: ipconfig state 4 ipconfig method 1
root@grat-os1:/var/lib/connman-vpn# systemctl status connman-vpn
● connman-vpn.service - ConnMan VPN service
Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service;
enabled; preset: enabled)
Active: active (running) since Mon 2025-01-27 11:12:14 CET; 2min 6s ago
Invocation: 28e320a0d50d4e09909da0af332be591
Main PID: 1742 (connman-vpnd)
Tasks: 1 (limit: 4915)
Memory: 1M (peak: 1.5M)
CPU: 22ms
CGroup: /system.slice/connman-vpn.service
└─1742 /usr/bin/connman-vpnd -n
janv. 27 11:12:14 grat-os1 connman-vpnd[1742]: virbr0 {create} index 5
type 1 <ETHER>
janv. 27 11:12:14 grat-os1 connman-vpnd[1742]: virbr0 {update} flags 4099 <UP>
janv. 27 11:12:14 grat-os1 connman-vpnd[1742]: virbr0 {newlink} index
5 address xxxxxxxxxxxxxxxxx mtu 1500
janv. 27 11:12:14 grat-os1 connman-vpnd[1742]: virbr0 {newlink} index
5 operstate 2 <DOWN>
janv. 27 11:12:14 grat-os1 systemd[1]: Started ConnMan VPN service.
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {create} index 7
type 65534 <NONE>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {update} flags 144 <DOWN>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {newlink} index 7
operstate 2 <DOWN>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {update} flags
98513 <UP,RUNNING,LOWER_UP>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {newlink} index 7
operstate 0 <UNKNOWN>
After a certain time the vpn connection stopped and the wifi returns to normal
root@grat-os1:/var/lib/connman-vpn# systemctl status connman-vpn
● connman-vpn.service - ConnMan VPN service
Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service;
enabled; preset: enabled)
Active: active (running) since Mon 2025-01-27 11:12:14 CET; 2min 47s ago
Invocation: 28e320a0d50d4e09909da0af332be591
Main PID: 1742 (connman-vpnd)
Tasks: 1 (limit: 4915)
Memory: 1M (peak: 1.5M)
CPU: 27ms
CGroup: /system.slice/connman-vpn.service
└─1742 /usr/bin/connman-vpnd -n
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {create} index 7
type 65534 <NONE>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {update} flags 144 <DOWN>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {newlink} index 7
operstate 2 <DOWN>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {update} flags
98513 <UP,RUNNING,LOWER_UP>
janv. 27 11:12:45 grat-os1 connman-vpnd[1742]: wg0 {newlink} index 7
operstate 0 <UNKNOWN>
janv. 27 11:14:50 grat-os1 connman-vpnd[1742]: reresolve error limit reached
janv. 27 11:14:50 grat-os1 connman-vpnd[1742]: wg0 {update} flags 32912 <DOWN>
janv. 27 11:14:50 grat-os1 connman-vpnd[1742]: wg0 {newlink} index 7
operstate 2 <DOWN>
janv. 27 11:14:50 grat-os1 connman-vpnd[1742]: wg0 {dellink} index 7
operstate 2 <DOWN>
janv. 27 11:14:50 grat-os1 connman-vpnd[1742]: wg0 {remove} index 7
The reresolve error refers to theses commits
AgeCommit message (Expand)AuthorFilesLines
2020-10-12wireguard: Fix struct sockaddr usage
2020-07-31wireguard: Regular reresolve endpoint address
There is no wireguard DNS if I add one with WireGuard.DNS = 1.1.1.1 in
the config file the VPN connection is longer but failed with a default
route error
Best regards
Daniel
Le sam. 25 janv. 2025 à 16:44, daniel antoine <univac55@gmail.com> a écrit :
>
> Hi
> Thanks a lot
> Best regards
> Daniel
>
> Le sam. 25 janv. 2025 à 16:22, Christian Hewitt
> <christianshewitt@gmail.com> a écrit :
> >
> > In the connman config "Host” must be an IP address not an FQDN.
> >
> > Christian
> >
> > > On 25 Jan 2025, at 7:12 pm, daniel antoine <univac55@gmail.com> wrote:
> > >
> > > Hi
> > > with wg-quik I can connect the vpn and ping the endpoint 10.0.7.2
> > > the config file in /etc/wireguard (I have modify it for the e-mail) is
> > >
> > > [Interface]
> > > Address = 10.0.7.5/24
> > > PrivateKey = yyyyy
> > >
> > > [Peer]
> > > Endpoint = monsite.fr:51820
> > > PublicKey = xxxxx
> > > AllowedIPs = 10.0.7.0/24
> > > PersistentKeepalive = 25
> > >
> > > The config file for connman-vpn in /var/lib/connman-vpn
> > >
> > > [provider_wireguard]
> > > Type = WireGuard
> > > Name = chezlui
> > > Host = monsite.fr
> > > WireGuard.Address = 10.0.7.5/24
> > > WireGuard.PrivateKey = yyyyyy
> > > WireGuard.PublicKey = xxxxx
> > > WireGuard.AllowedIPs = 10.0.7.0/24
> > > WireGuard.EndpointPort = 51820
> > > WireGuard.PersistentKeepalive = 25
> > >
> > > Is there something wrong with it? It cause the wifi connexion to drop
> > > when I connect the vpn
> > >
> > > Best regards
> > >
> > > Daniel
> > >
> > > Le sam. 25 janv. 2025 à 14:12, Christian Hewitt
> > > <christianshewitt@gmail.com> a écrit :
> > >>
> > >> I’ve picked patches into https://github.com/chewitt/connman/commits/wireguard
> > >>
> > >> This is connman HEAD + Gabriel's is_vpn6 patch + my revert patch (to fix routing)
> > >> + the two series that Jussi posted to the list yesterday.
> > >>
> > >> For me this is working fine with no wireguard issues observed since this morning
> > >> when I’ve rebuilt a LibreELEC image using that branch. I plan to use it myself
> > >> for a couple of days, then if all good I’ll push changes into LibreELEC nightly
> > >> images for a while to get some wider testing done.
> > >>
> > >> Christian
> > >>
> > >>
> > >>> On 25 Jan 2025, at 3:23 pm, daniel antoine <univac55@gmail.com> wrote:
> > >>>
> > >>> I have copy the patches from the dev list and they have all passed ;
> > >>> The vpn connection continue to drop with in the journalctl
> > >>>
> > >>> janv. 25 12:12:01 grat-os1 connman-vpnd[1176]: wlan0 {newlink} index
> > >>> 5 operstate 6 <UP>
> > >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Adding configuration vpndania
> > >>> janv. 25 12:13:03 grat-os1 connman-vpnd[1176]: Added provider
> > >>> configuration wireguard
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6
> > >>> type 65534 <NONE>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags
> > >>> 98513 <UP,RUNNING,LOWER_UP>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 0 <UNKNOWN>
> > >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6
> > >>>
> > >>> and
> > >>>
> > >>> ● connman-vpn.service - ConnMan VPN service
> > >>> Loaded: loaded (/usr/lib/systemd/system/connman-vpn.service;
> > >>> enabled; preset: enabled)
> > >>> Active: active (running) since Sat 2025-01-25 12:12:02 CET; 6min ago
> > >>> Invocation: c3584a6570fc48deb60efbb589e55903
> > >>> Main PID: 1176 (connman-vpnd)
> > >>> Tasks: 1 (limit: 4915)
> > >>> Memory: 1.1M (peak: 1.7M)
> > >>> CPU: 24ms
> > >>> CGroup: /system.slice/connman-vpn.service
> > >>> └─1176 /usr/bin/connman-vpnd -n
> > >>>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {create} index 6
> > >>> type 65534 <NONE>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags 144 <DOWN>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {update} flags
> > >>> 98513 <UP,RUNNING,LOWER_UP>
> > >>> janv. 25 12:13:41 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 0 <UNKNOWN>
> > >>> janv. 25 12:15:46 grat-os1 connman-vpnd[1176]: reresolve error limit reached
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {update} flags 32912 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {newlink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {dellink} index 6
> > >>> operstate 2 <DOWN>
> > >>> janv. 25 12:15:47 grat-os1 connman-vpnd[1176]: wg0 {remove} index 6
> > >>>
> > >>> There was a question about a reverse patch for the iptable. Does I
> > >>> have missed it
> > >>>
> > >>> Best regards
> > >>>
> > >>> Daniel
> > >>>
> > >>>
> > >>> Le sam. 25 janv. 2025 à 11:46, daniel antoine <univac55@gmail.com> a écrit :
> > >>>>
> > >>>> Hi Jussi Grant Christian and Gabiel
> > >>>>
> > >>>> I have installed first the Gabriel patch and tested but my vpn
> > >>>> connexion drops after 5 seconds and finally hangs the wifi connexion
> > >>>>
> > >>>> I have continued by installing the eleven and twelves jussi patches
> > >>>> but my compilation failed with the first patch 11-1
> > >>>>
> > >>>> =======> name: connman
> > >>>> =======> version: 1.43
> > >>>> =======> release: 9
> > >>>> =======> WARNING: connman1737741659x86_64.cards.tar.xz already exist
> > >>>> =======> WARNING: connman.man1737741659any.cards.tar.xz already exist
> > >>>> =======> WARNING: connman.devel1737741659any.cards.tar.xz already exist
> > >>>> =======> WARNING: connman.sources1737741659any.cards.tar.xz already exist
> > >>>> =======> Building starting...
> > >>>> cp allow_group_network.diff /tmp/work/src
> > >>>> cp vpn6.patch /tmp/work/src
> > >>>> cp vpn-11-1.patch /tmp/work/src
> > >>>> cp vpn-11-2.patch /tmp/work/src
> > >>>> cp vpn-11-3.patch /tmp/work/src
> > >>>> cp vpn-11-4.patch /tmp/work/src
> > >>>> cp vpn-11-5.patch /tmp/work/src
> > >>>> cp vpn-11-6.patch /tmp/work/src
> > >>>> cp vpn-11-7.patch /tmp/work/src
> > >>>> cp vpn-11-8.patch /tmp/work/src
> > >>>> cp vpn-11-9.patch /tmp/work/src
> > >>>> cp vpn-11-10.patch /tmp/work/src
> > >>>> cp vpn-11-11.patch /tmp/work/src
> > >>>> cp vpn-12-1.patch /tmp/work/src
> > >>>> cp vpn-12-2.patch /tmp/work/src
> > >>>> cp vpn-12-3.patch /tmp/work/src
> > >>>> cp vpn-12-4.patch /tmp/work/src
> > >>>> cp vpn-12-5.patch /tmp/work/src
> > >>>> cp vpn-12-6.patch /tmp/work/src
> > >>>> cp vpn-12-7.patch /tmp/work/src
> > >>>> cp vpn-12-8.patch /tmp/work/src
> > >>>> cp vpn-12-9.patch /tmp/work/src
> > >>>> cp vpn-12-10.patch /tmp/work/src
> > >>>> cp vpn-12-11.patch /tmp/work/src
> > >>>> cp vpn-12-12.patch /tmp/work/src
> > >>>> + prepare
> > >>>> + git clone https://git.kernel.org/pub/scm/network/connman/connman.git
> > >>>> connman-1.43
> > >>>> Cloning into 'connman-1.43'...
> > >>>> remote: Enumerating objects: 41151, done.
> > >>>> remote: Total 41151 (delta 0), reused 0 (delta 0), pack-reused 41151
> > >>>> Receiving objects: 100% (41151/41151), 6.41 MiB | 1.64 MiB/s, done.
> > >>>> Resolving deltas: 100% (31525/31525), done.
> > >>>> + cd connman-1.43
> > >>>> + git checkout 263e151fcfb09134dcf17a4147355b0ee9a5eb66
> > >>>> Note: switching to '263e151fcfb09134dcf17a4147355b0ee9a5eb66'.
> > >>>>
> > >>>> You are in 'detached HEAD' state. You can look around, make experimental
> > >>>> changes and commit them, and you can discard any commits you make in this
> > >>>> state without impacting any branches by switching back to a branch.
> > >>>>
> > >>>> If you want to create a new branch to retain commits you create, you may
> > >>>> do so (now or later) by using -c with the switch command. Example:
> > >>>>
> > >>>> git switch -c <new-branch-name>
> > >>>>
> > >>>> Or undo this operation with:
> > >>>>
> > >>>> git switch -
> > >>>>
> > >>>> Turn off this advice by setting config variable advice.detachedHead to false
> > >>>>
> > >>>> HEAD is now at 263e151f treewide: Fix typo in ARPHRD_PHONET_PIPE
> > >>>> + patch -Np1 -i /tmp/work/src/allow_group_network.diff
> > >>>> patching file src/connman-polkit.conf
> > >>>> Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines).
> > >>>> + patch -Np1 -i /tmp/work/src/vpn6.patch
> > >>>> patching file src/gateway.c
> > >>>> + patch -Np1 -i /tmp/work/src/vpn-11-1.patch
> > >>>> patching file src/agent.c
> > >>>> Hunk #1 FAILED at 201.
> > >>>> 1 out of 1 hunk FAILED -- saving rejects to file src/agent.c.rej
> > >>>> =======> ERROR: Building 'connman.sources1737741659any.cards.tar.xz' failed.
> > >>>>
> > >>>> I have copy the patches from the e-mail , may be it introduce false
> > >>>> characters or must i copy them from the dev list
> > >>>>
> > >>>> Best regards
> > >>>>
> > >>>> Daniel
> > >>>>
> > >>>>
> > >>>> Le ven. 24 janv. 2025 à 20:03, Jussi Laakkonen
> > >>>> <jussi.laakkonen@jolla.com> a écrit :
> > >>>>>
> > >>>>> Hi Christian,
> > >>>>>
> > >>>>> Actually, that commit is in upstream.
> > >>>>> https://git.kernel.org/pub/scm/network/connman/connman.git/log/vpn/plugins/wireguard.c
> > >>>>> - the date on the cherry-picked commits is the date of cherry picking (I
> > >>>>> guess I missed some option while doing this..) but the original commit
> > >>>>> is there submitted on 2020-07-31.
> > >>>>>
> > >>>>> I also pushed the association state and most of the wireguard fixes I've
> > >>>>> done to the mailing list. Have fun testing and tell me if it works
> > >>>>> better, we can always improve it if something is still missing. There
> > >>>>> are few commits I held back as they could be the next patch set, because
> > >>>>> support for IPv4 and IPv6 addresses, and the route adding fixes are also
> > >>>>> quite large changes.
> > >>>>>
> > >>>>> BR,
> > >>>>> - Jussi
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 1/23/25 13:35, Christian Hewitt wrote:
> > >>>>>> Looking here: https://git.kernel.org/pub/scm/network/connman/connman.git/log/ I’m not finding "wireguard: Regular reresolve endpoint address” and the first page of log goes back to December ’23. Are we using the wrong upstream?
> > >>>>>>
> > >>>>>> Christian
> > >>>>>>
> > >>>>>>> On 23 Jan 2025, at 3:22 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote:
> > >>>>>>>
> > >>>>>>> Hi Christian,
> > >>>>>>>
> > >>>>>>> That is actually in upstream, all the commits regarding WireGuard before July 10, 2024 are taken from the latest upstream and the changes after that are new features.
> > >>>>>>>
> > >>>>>>> Well, the vpn.c changes do depend on having the ASSOCIATION state also for VPNs to be implemented, that was proposed in the RFC https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97 as the state transitions depend on that bit. But it does not seem to be depending on the gateway.c/connection.c. Well, I can try to squeeze time to address the issues Daniel earlier raised on that RFC and push them to upstream, then make a big change on the vpn.c and wireguard.c.
> > >>>>>>>
> > >>>>>>> Br,
> > >>>>>>> Jussi
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 1/23/25 13:12, Christian Hewitt wrote:
> > >>>>>>>> You don't often get email from christianshewitt@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
> > >>>>>>>> Ohh.. I would be VERY keen to see support for FQDN’s resolving to dynamic IP’s upstreamed so this looks interesting:
> > >>>>>>>> https://github.com/sailfishos/connman/commit/adb6ab2b49a2b822e6517d703f972b866fdbd8bd
> > >>>>>>>> Is that feature dependent on any other changes? (being lazy.. I didn’t read all the commits in that branch yet!).
> > >>>>>>>> Christian
> > >>>>>>>> On 23 Jan 2025, at 3:06 pm, Jussi Laakkonen <jussi.laakkonen@jolla.com> wrote:
> > >>>>>>>> Hello,
> > >>>>>>>> Regarding WireGuard, I had to make a bunch of changes to the latest version of it to get it running properly on our fork (yes, we upgrade it slowly, now 1.38): https://github.com/sailfishos/connman/commits/master/connman/vpn
> > >>>>>>>> But I haven't had time to figure out all that is needed for upstream to be sent first, like this RFC edit that was forgotten because of... "eastern winds blowing into our direction": https://lore.kernel.org/connman/20221213140707.278313-5-jussi.laakkonen@jolla.com/T/#mbced39d72dd424884fe105a66fea02a83c708f97
> > >>>>>>>> And then the connection.c was modified a lot (and renamed) and I'm not sure if these will work on top of that anymore. Mostly because we have features that may not have been compatible with latest upstream, like adding a support for two different devices to be belonging into one service to facilitate CLAT support https://github.com/sailfishos/connman/commits/master/connman/src/connection.c etc. etc. etc.
> > >>>>>>>> At some point I'll start pushing changes but not sure when I have time. Mostly they could be RFCs as the changes are big.
> > >>>>>>>> BR,
> > >>>>>>>> Jussi
> > >>>>>>>> On 1/23/25 12:45, daniel antoine wrote:
> > >>>>>>>> Hi
> > >>>>>>>> I have opened a ticket for connman-vpn not working with wireguard in
> > >>>>>>>> April 2024. If you give me the patches I can test them
> > >>>>>>>> Best regards
> > >>>>>>>> Daniel
> > >>>>>>>> Le mer. 22 janv. 2025 à 18:01, Grant Erickson
> > >>>>>>>> <gerickson@nuovations.com> a écrit :
> > >>>>>>>> On Jan 13, 2025, at 5:59 AM, Gabriel Sanches <gabriel.sanches@prevas.dk> wrote:
> > >>>>>>>> I was testing connman's wireguard plugin and got a segmentation fault.
> > >>>>>>>> Looking at the backtrace revealed that there are some typos in the `src/gateway.c` file where `is_vpn6` was incorrectly set using ipv4 variables instead of ipv6 regarding vpn.
> > >>>>>>>> I simply changed them to ipv6 and got it working.
> > >>>>>>>> not related to the patch:
> > >>>>>>>> I had to manually add ip route so the other devices could be pinged
> > >>>>>>>> The plugin adds routes for the WireGuard.DNS configuration setting
> > >>>>>>>> # ip route
> > >>>>>>>> 1.1.1.1 dev wg0 scope link
> > >>>>>>>> 8.8.8.8 dev wg0 scope link
> > >>>>>>>> 10.42.0.0/24 dev end1 proto kernel scope link src 10.42.0.83
> > >>>>>>>> 10.42.0.1 dev end1 scope link
> > >>>>>>>> <vpn host ip> via 10.42.0.1 dev end1
> > >>>>>>>> the missing route added manually:
> > >>>>>>>> ip route add 10.33.0.0/16 dev wg0 scope link
> > >>>>>>>> an equivalent wireguard file adds it properly (using wg-quick)
> > >>>>>>>> Is the plugin lacking some implementation?
> > >>>>>>>> ---
> > >>>>>>>> src/gateway.c | 6 +++---
> > >>>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
> > >>>>>>>> diff --git a/src/gateway.c b/src/gateway.c
> > >>>>>>>> index 16c87f83..b2c211e2 100644
> > >>>>>>>> --- a/src/gateway.c
> > >>>>>>>> +++ b/src/gateway.c
> > >>>>>>>> @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service,
> > >>>>>>>> is_gateway_config_vpn(
> > >>>>>>>> new_gateway->ipv4_config);
> > >>>>>>>> - is_vpn6 = do_ipv4 &&
> > >>>>>>>> - new_gateway->ipv4_config &&
> > >>>>>>>> + is_vpn6 = do_ipv6 &&
> > >>>>>>>> + new_gateway->ipv6_config &&
> > >>>>>>>> is_gateway_config_vpn(
> > >>>>>>>> - new_gateway->ipv4_config);
> > >>>>>>>> + new_gateway->ipv6_config);
> > >>>>>>>> } else {
> > >>>>>>>> if (do_ipv4 && new_gateway->ipv4_config)
> > >>>>>>>> --
> > >>>>>>>> 2.43.0
> > >>>>>>>> Gabriel,
> > >>>>>>>> Great catch on this copy-and-paste typo; thank you!
> > >>>>>>>> Best,
> > >>>>>>>> Grant
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>
> >
diff --git a/src/gateway.c b/src/gateway.c index 16c87f83..b2c211e2 100644 --- a/src/gateway.c +++ b/src/gateway.c @@ -3704,10 +3704,10 @@ int __connman_gateway_add(struct connman_service *service, is_gateway_config_vpn( new_gateway->ipv4_config); - is_vpn6 = do_ipv4 && - new_gateway->ipv4_config && + is_vpn6 = do_ipv6 && + new_gateway->ipv6_config && is_gateway_config_vpn( - new_gateway->ipv4_config); + new_gateway->ipv6_config); } else { if (do_ipv4 && new_gateway->ipv4_config)