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: [RFC 2/8] network: Support ipconfig.c changes for IPv6 force option (Jussi Laakkonen) 2. Re: [PATCH] service: Allow only user connection after WiFi failure (Jussi Laakkonen) 3. Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method restore and refactor (Daniel Wagner) 4. Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method restore and refactor (Daniel Wagner) 5. Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6 network(s) (Daniel Wagner) ---------------------------------------------------------------------- Date: Mon, 29 Mar 2021 12:37:55 +0300 From: Jussi Laakkonen <jussi.laakko...@jolla.com> Subject: Re: [RFC 2/8] network: Support ipconfig.c changes for IPv6 force option To: Daniel Wagner <w...@monom.org> Cc: connman@lists.01.org Message-ID: <28d71e5b-671e-2afa-e148-3de11d98b...@jolla.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi Daniel, On 3/27/21 4:09 PM, Daniel Wagner wrote: > Hi Jussi, > > On Fri, Mar 26, 2021 at 05:58:19PM +0200, Jussi Laakkonen wrote: >> Add "false" to all functions using >> __connman_ipconfig_{enable,disable}_ipv6() except with >> __connman_network_enable_ipconfig(), in which the parameter is set by >> the caller. This is passed to autoconf_ipv6_set() to get IPv6 properly >> enabled again, when requested. Utilize the input force value with >> FIXED, MANUAL, DHCP and AUTO ipconfig method types when enabling >> ipconfig via network.c. > > If I read it correctly the only case where you need to force is > in set_disconnected() and there you could use a force function. > I'd prefer not adding a parameter to all functions which is > in almost all cases the same value. Wouldn't > > __connman_ipconfig_force_[enable|disable]_ipv6() > > work? > Yeah, now that you pointed it out that change does sound a bit bad. I guess my focus was lost on smaller things as the bigger picture needed so many different attempts to get it working. I'll remove the force from the enable function and I guess __connman_ipconfig_set_force_ipv6(struct connman_ipconfig *, bool) might be the way. Thanks. Cheers, Jussi ------------------------------ Date: Mon, 29 Mar 2021 12:56:20 +0300 From: Jussi Laakkonen <jussi.laakko...@jolla.com> Subject: Re: [PATCH] service: Allow only user connection after WiFi failure To: Daniel Wagner <w...@monom.org>, "VAUTRIN Emmanuel (Canal Plus Prestataire)" <emmanuel.vaut...@cpexterne.org> Cc: "connman@lists.01.org" <connman@lists.01.org> Message-ID: <c7886d51-ca03-cfc4-c275-15f9c5c79...@jolla.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi Emmanuel and Daniel On 3/27/21 3:03 PM, Daniel Wagner wrote: > Hi Emmanuel, > > On Fri, Mar 26, 2021 at 04:59:04PM +0000, VAUTRIN Emmanuel (Canal Plus > Prestataire) wrote: >>> We have our own implementation of the WiFi plugin and I haven't tried >>> with the plugin upstream has so this is just a guess/concern from my part. >> It is important to share you concern, but I think you should face the >> same behavior, with or without it. The easiest way is to test it. > > The trick is that 'reason' should be auto in case we do normal > reconnects. Well, this is almost like the original idea. My argument > still applies that we might retry to login into a network with stale > credentials. I don't know how likely this is. I assume more serious > setups are using certificates anyway and don't rely on user/password > these days. So let's try this out and see what happens. > Ok, right. Thanks for both describing the context a bit more. I guess it is of no issue then. I just did not get the whole picture from the commit message. Cheers, Jussi ------------------------------ Date: Mon, 29 Mar 2021 11:59:55 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method restore and refactor To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <2d5e6cbd-e08b-afb0-6ae6-c8f069565...@monom.org> Content-Type: text/plain; charset=utf-8; format=flowed On 29.03.21 11:32, Jussi Laakkonen wrote: > Yes I can take a look on those. I guess the code explains itself but > please feel free to elaborate more :). https://github.com/igaw/connman/pull/new/ipv6-routing-2020-12-11 The more finished patches have a proper commit message but there are a couple patches just in the 'wip' state. Though I am not sure if this approach is likely to be fruitful as this is all just somehow through code at the current userland implementation and see what helps. I really struggled to understand what is happening in these paths. I was wondering if it wouldn't be better to reimplement a new full IPv6 stack. I haven't checked yet what ell/iwd has to offer but I think it might help to team up and get one proper implementation developed maintained and integrate it into ConnMan. ------------------------------ Date: Mon, 29 Mar 2021 12:01:42 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: [RFC 1/8] ipconfig: Add disabling of IPv6, support method restore and refactor To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <4cba0770-0d34-2e8f-0670-7ca65766d...@monom.org> Content-Type: text/plain; charset=utf-8; format=flowed On 29.03.21 11:59, Daniel Wagner wrote: > On 29.03.21 11:32, Jussi Laakkonen wrote: >> Yes I can take a look on those. I guess the code explains itself but >> please feel free to elaborate more :). > > https://github.com/igaw/connman/pull/new/ipv6-routing-2020-12-11 https://github.com/igaw/connman/tree/ipv6-routing-2020-12-11 ------------------------------ Date: Mon, 29 Mar 2021 12:15:46 +0200 From: Daniel Wagner <w...@monom.org> Subject: Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6 network(s) To: Jussi Laakkonen <jussi.laakko...@jolla.com> Cc: connman@lists.01.org Message-ID: <20210329101546.724vizfyayq6m...@beryllium.lan> Content-Type: text/plain; charset=us-ascii On Mon, Mar 29, 2021 at 12:29:50PM +0300, Jussi Laakkonen wrote: > Yeah we have been noticing some oddities here and there. What were your > plans exactly? We noticed some issue with DUID which we have as an WIP > solution that should be just tested more. In general it works but there may > be corner cases with different setups, though. I'm glad we're on the same > page here, that disabling IPv6 for the IPv4 VPN will not be an issue :) Sure, I prefer simple solutions :) > > > If multiple connected technologies is enabled and a new service connects > > > then > > > in this case it cannot first establish an IPv6 connection at all but if > > > the > > > particular service then ranks over the current service the VPN will be > > > disconnected, IPv6 is re-enabled and the new service starts to establish > > > an > > > IPv6 connection. Otherwise the new service remains with IPv4 > > > connectivity only - but if it is IPv6 only the service cannot connect and > > > this > > > is expected (might it be good to have this feature as a configurable > > > option?). > > > > Good question. It sounds a bit like a corner case scenario. Do you think > > it's likely we need to support it? If not I'd say we document it and > > leave it away for the time being. No need to make things more complex > > than necessary. > > Yes that IPv6 only is a corner case. I think it only concerns direct > connection request via D-Bus, with autoconnect that should not be an issue. > But currently I don't have such connection at my disposal (my ISP does not > even provide IPv6 on vDSL in 2021!) so it is hard to test what the real > implication on enabling such connection would even be. I have an IPv6 DS-Lite setup here but no IPv6 endpoint with a VPN server on it. It's really tricky to test stuff indeed. > But anyways, if IPv6 is to be revisited/fixed in general I guess this might > be good to add to TODO list as well? And to document as well of > course. Yes, let's try to solve one problem at the time. I think we need to look at the IPv6 implementation anyway soon. > > > To be future-proof it may be better to have the new services to have > > > their IPv6 > > > network not enabled but forcefully disabled in case at the time of > > > connection > > > an IPv4 VPN is connected. Not only due to the fact that an IPv6 address > > > is not > > > attempted to be retrieved with the current approach for a newly connected > > > network. Alternative would be to call > > > __connman_provider_set_ipv6_for_connected() in case the default service > > > is an > > > IPv4 VPN to get the service list traversed. But in that case IPv6 > > > connectivity > > > may have been established and there might be a small timeframe for leaking > > > traffic. > > > > Hmm, it's a valid point but I have no idea if this is just another > > corner case which makes things very complex. As I said currently ConnMan > > doesn't do IPv6 correctly, this includes the routing. It relies heavily > > on the IPv6 stack in the kernel. > > With my tests using our implementation of the ofono plugin this approach > allowed mobile data to connect in the background with IPv4 only even though > it had IPv6 enabled as a dual-stack connection. So IPv6 remains in OFF state > and as the old method is not saved at VPN disconnect that connection will > get set to AUTO and IPv6 is established. Yes, a bit complex but improves > functionality as the connection does not produce an error in network.c > making the connection to fail but just sets IPv6 to be simply off. > > Well to understand how this should work was a quite complex process itself > thus, I decided to send this as an RFC first despite our internal reviewing > and testing. I changed direction so many times with this that I lost count > on how many times I did that. I did have stateful and stateless networks > with and without DHCPv6 at my disposal but all of them were dual-stack > connections. > > I think one issue I forgot to raise is that should ConnMan also manage the > autoconf value when disabling/enabling IPv6? As that tells kernel whether to > assign address for the interface, effectively controlling whether IPv6 is > usable or not. With different devices there were different behavior on this > if the autoconf was not set, using the system wide all/disable_ipv6 worked > on some but not on others and not being an expert on IPv6 (yet) I just > suspected that based on incoming traffic kernel does its things as ConnMan, > as you said, does not manage all IPv6 as of now. Yes, we should track per interface if the IPv6 enabling/disabling settings, e.g see 'ipconfig: Disable accept_ra on managed interfaces' in my IPv6 patches. But this needs a lot more of work :( ------------------------------ 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 65, Issue 13 ***************************************