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
***************************************
