Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] timeserver: Fix time update manual->auto at startup
(Daniel Wagner)
2. Re: [PATCH 06/11] network: Adopt to new IPv6 disabled functionality of
ipconfig.c
(Daniel Wagner)
3. Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of IPv4 VPN
connection
(Daniel Wagner)
4. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Daniel Wagner)
----------------------------------------------------------------------
Date: Tue, 6 Apr 2021 20:20:58 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] timeserver: Fix time update manual->auto at
startup
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Emmanuel,
On 05.02.21 10:25, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
>> Well, the ts sync engine is stopped at this point. ts_service is NULL on
>> the initial startup. So why should 'service == ts_service' checks not
>> behave correctly? ts_service = NULL is looks correct. If you think the
>> checks are not correct then we need to review them now. Adding
>> 'ts_service = service' before the timerservers_list check looks bogus
>> and is papering over a problem if 'ts_servce = NULL;' doesn't work.
> In fact, it is the contrary, my goal was not to change the checks.
> If I follow this proposal:
> 1. Starting with a current service and a not empty config timeserver list,
> but in manual mode, we have timerservers_list == NULL
> -> ts_service = NULL
and timeserver_sync_start() is not called, as we bail out.
> 2. Switching to auto mode, we have ts_service == NULL
> -> no synchro in __connman_timeserver_sync()
and since timeserver_sync_start() has never be called nothing will happen.
ts_service should really only be touched right before we call
timeserver_sync_start() and set to NULL as soon we stop the
loop.
The return timeservers_list should contain all server we should poll.
This sounds like __connman_timeserver_get_all() should return
a valid list.
Thanks,
Daniel
------------------------------
Date: Tue, 6 Apr 2021 20:28:37 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 06/11] network: Adopt to new IPv6 disabled
functionality of ipconfig.c
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Tue, Apr 06, 2021 at 04:21:04PM +0300, Jussi Laakkonen wrote:
> I thought that the service can keep its IPv4 configuration.
static void autoconf_ipv6_set(struct connman_network *network)
{
[...]
service = connman_service_lookup_from_network(network);
if (!service)
return;
ipconfig = __connman_service_get_ip6config(service);
if (!ipconfig)
return;
__connman_ipconfig_enable(ipconfig); // a)
__connman_ipconfig_enable_ipv6(ipconfig); // b)
I am talking about this enable in a). If we bail out in b), shouldn't we
undo a)? Anyway, I am confused why we have IPv4 code here. The function
clearly talks about IPv6 only. After starring at it, I am completely
lost.
Thanks,
Daniel
------------------------------
Date: Tue, 6 Apr 2021 20:42:17 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of
IPv4 VPN connection
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Tue, Apr 06, 2021 at 04:44:00PM +0300, Jussi Laakkonen wrote:
> > This disables IPv6 for all VPN tunnels not just for pure IPv4 VPNs. I
> > think you need to check the ipconfig if IPv6 should be disabled. I have
> > actually an IPv4/IPv6 VPN service to test ;)
> >
>
> Oh I must have mistaken something then. I've always understood this that
> each provider can be either IPv4 or IPv6 as the code suggests, and one
> provider = one connection. Or did I now misread your comment..
I think it depends what the VPN is able to do, that is if we are talking
about network layer or transport layer. Mabye I understood you wrong. I
assumed you were talking about an VPN which will only support IPv4. But
that should not exclude a dual protocol VPN IMO. Probably I
misunderstood your initial RFC.
> Yeah, this is one of the things why I first sent the RFC. We do limit to
> having only one connected VPN at a time so I wasn't able to test all
> possible scenarios.
And there is the resource problem. If the VPN server needs to maintain
two session per user, admins will start to scream.
> There is a check for split routing of the VPN, the
> change is not done if the VPN is not going to be the default, i.e., split
> routing is true. But I guess you weren't after this.
My setup is actually a splitted IPv4/IPv6 VPN tunnel which is not the
default route.
> I did confuse myself with this a multiple times already.. So instead of
> relying to provider family there should be a check on which ipconfigs the
> actual VPN service has enabled? I wasn't aware that it was possible to work
> that way as I relied on the family setting. Well, I haven't had any VPNs
> configured as dual-stack either.
I hear you, the code is indeed difficult and confusing.
> I guess that family for the provider should be somehow changed/extended to
> support that as well.
That is also my thinking, maybe instead adding a lot of magic code just
add an explicit setting/config option if IPv6 should be enabled or not.
Thanks,
Daniel
------------------------------
Date: Tue, 6 Apr 2021 20:49:14 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 09/11] service: Change IPv6 support if split
routing value changes on IPv4 VPN
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 06, 2021 at 05:00:23PM +0300, Jussi Laakkonen wrote:
> > > Just expose that facility from core ConnMan and let the VPN providers
> > > use it as they desire.
>
> I actually had this in mind as a next step to have a per provider option to
> really control whether to disable IPv6 or not. Some amount of work goes to
> that as well and I think OpenConnect and WireGuard plugins are ones that are
> capable of both v4 and v6.
>
> What do you Daniel say, should I try to include that per provider option
> here or work it as later, and perhaps amend the TODO on that part?
This makes sense to me. I think we shouldn't encoded the policy into
the core itself. Probably it would be good to have the interface and
config interface sorted out first.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 66, Issue 10
***************************************
