Send connman mailing list submissions to connman@lists.01.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to connman-requ...@lists.01.org
You can reach the person managing the list at connman-ow...@lists.01.org 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 <w...@monom.org> Subject: Re: [PATCH] timeserver: Fix time update manual->auto at startup To: "VAUTRIN Emmanuel (Canal Plus Prestataire)" <emmanuel.vaut...@cpexterne.org> Cc: "connman@lists.01.org" <connman@lists.01.org> Message-ID: <6d2b3916-90d9-8bbd-8119-fdb277091...@monom.org> 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 <w...@monom.org> Subject: Re: [PATCH 06/11] network: Adopt to new IPv6 disabled functionality of ipconfig.c To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <20210406182837.om2ipmlks6rqa...@beryllium.lan> 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 <w...@monom.org> Subject: Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of IPv4 VPN connection To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <20210406184217.s2fkzn37rj7lu...@beryllium.lan> 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 <w...@monom.org> Subject: Re: [PATCH 09/11] service: Change IPv6 support if split routing value changes on IPv4 VPN To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <20210406184914.b42uqvxd5rw4n...@beryllium.lan> 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 -- connman@lists.01.org To unsubscribe send an email to connman-le...@lists.01.org ------------------------------ End of connman Digest, Vol 66, Issue 10 ***************************************