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 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Daniel Wagner)
2. Re: wpa3 support (Daniel Wagner)
3. Re: connman/iwd reconnect issues - ongoing (Daniel Wagner)
4. Online check down on IPV4 leading to a full production park crash
(VAUTRIN Emmanuel (Canal Plus Prestataire))
5. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Fri, 9 Apr 2021 09:02:03 +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: David Woodhouse <dw...@infradead.org>
Cc: connman@lists.01.org
Message-ID: <20210409070203.hnyeeekox2lk5...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi,
On Thu, Apr 08, 2021 at 03:53:27PM +0100, David Woodhouse wrote:
> On Thu, 2021-04-08 at 13:09 +0300, Jussi Laakkonen wrote:
> >
> > As I said, there is no straightforward way to disable IPv4 AFAIK. Using
> > disable_ipv6 with autoconf at this time when ConnMan relies on kernel on
> > IPv6 management seemed to be a proper solution as existing functionality
> > already supported more than half of it.
>
> That's only because you're fixated on this idea of *disabling* it which
> as I've already pointed out is the wrong thing to do anyway. You might
> actually be talking to the VPN server over the protocol that you want
> to disable.
Thanks for explaining why it's not right thing to do in the long run.
> If you stop thinking about "disable", it should be simple enough to do
> using unreachable routes and/or route tables.
>
> ip route add unreachable 0.0.0.0/0 table 16383
> ip route add $VPNGW via $LOCALGW table 16383
> ip rule add from all table 16383
Thinking about it, we have all the necessary code in place to setup such
routing tables. The providers should just tell the core to set such a
route. In fact, we already to this with the default routes. So it is be
fairly natural to push additional routes.
> > I've already spent too much time on this. Some things are good to have,
> > some may be theoretical only and some just work for the specific problem.
>
> I am hearing a lot of "I don't have time to do this properly in a
> correct and protocol-agnostic fashion, so let's just pile in some nasty
> non-future-proof hacks."
>
> My time is also limited; I suppose it's up to Daniel whether he wants
> to accept that kind of thing in ConnMan or whether he expects a higher
> standard. So I'll leave my heckling there for now, with the observation
> that it isn't *hard* to get this right.
I didn't know about ocserver. I've done some work for setting up an
end-to-end test framework (shamelessly stolen form iwd/bluez). Let me
refresh that stuff and see if I am able to get such a test setup
running. This would make things way simpler to test.
Jussi, I know it's frustrating for you. You spend a lot of time writing
and testing this series. I really appreciate this. Through the
discussion between you and David (and my quick testing) it shows the
solution has flaws. I am sorry I didn't figure this out when you were
sending the initial RFC. It sounded like a good plan.
ConnMan already suffers from very complex logic which makes it hard to
maintain. I am reluctant to add more logic which ties the IPv4 code path
to the IPv6 code path (and vise versa).
Thanks,
Daniel
------------------------------
Date: Fri, 9 Apr 2021 09:05:31 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: wpa3 support
To: Andrej Shadura <andrew.shad...@collabora.co.uk>
Cc: connman@lists.01.org
Message-ID: <20210409070531.czpk6uujrcrm3...@beryllium.lan>
Content-Type: text/plain; charset=utf-8
Hi Andrej,
On Thu, Apr 08, 2021 at 10:55:35PM +0200, Andrej Shadura wrote:
> Hi,
>
> > Well not completely true. In case of wpa_supplicant I am sure we need to
> > update the plugins/wifi.c plugin. Just to make it clear, I wont do it
> > due to lack of time. For iwd, I expect only small or even none needed
> > modification on ConnMan side. Maybe ask on the iwd mailing list or on
> > the #iwd IRC channel about the feature.
>
> Apparently Tizen have implemented WPA3 support for connman. I’m planning
> to take their patches, polish them up a bit and submit here. Would you
> review them when they’re ready or should I prod some other member of the
> project?
Ah that's nice to hear. Sure, post the patches and I review them. I am
interested to see what's necessary to support WPA3. I hope most of it is
in plugins/wifi.c :)
Thanks,
Daniel
------------------------------
Date: Fri, 9 Apr 2021 09:16:04 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: connman/iwd reconnect issues - ongoing
To: KeithG <ys3al...@gmail.com>
Cc: connman@lists.01.org
Message-ID: <20210409071604.incgbordob75g...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Mon, Feb 08, 2021 at 07:15:30PM -0600, KeithG wrote:
> I have verified that iwd works fine in standalone mode (internal dhcp)
> or with dhcpcd. If I perform the same test, it reconnects in < 2
> minutes every time. Also in the log it shows that iwd starts scanning
> very soon after it is disconnected and finds the SSID and reconnects
> (like all my other wifi devices). I really want connman to work for
> this project and especially now that tethering works with the brcmfmac
> driver. What can I do to log or help to figure out what is going on?
See my 'Teach autoconnect algorithm native mode' patches. Currently,
ConnMan doesn't disable it's own connect algorithm when iwd's
autoconnect is enabled. They need some more testing/debugging as they
don't work correctly yet.
------------------------------
Date: Fri, 9 Apr 2021 12:21:37 +0000
From: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Subject: Online check down on IPV4 leading to a full production park
crash
To: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <pr1pr02mb479494579075fedc7db09d8d93...@pr1pr02mb4794.eur
prd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello everyone,
It seems that the http://ipv4.connman.net/online/status.html is unreachable,
contrary to http://ipv6.connman.net/online/status.html.
Unfortunately, our set-top-box entire park is impacted, because our WebApp
relies on this online check, displaying a "connection error" screen on failure.
Can you confirm the problem (and reactivate the ipv4 online check url)?
Best Regards,
Emmanuel
------------------------------
Date: Fri, 9 Apr 2021 15:58:58 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 09/11] service: Change IPv6 support if split
routing value changes on IPv4 VPN
To: Daniel Wagner <w...@monom.org>, David Woodhouse
<dw...@infradead.org>
Cc: connman@lists.01.org
Message-ID: <4479021e-3def-6b66-b1cd-ea2169b5f...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel and David,
On 4/9/21 10:02 AM, Daniel Wagner wrote:
> Hi,
>
> On Thu, Apr 08, 2021 at 03:53:27PM +0100, David Woodhouse wrote:
>> On Thu, 2021-04-08 at 13:09 +0300, Jussi Laakkonen wrote:
>>>
>>> As I said, there is no straightforward way to disable IPv4 AFAIK. Using
>>> disable_ipv6 with autoconf at this time when ConnMan relies on kernel on
>>> IPv6 management seemed to be a proper solution as existing functionality
>>> already supported more than half of it.
>>
>> That's only because you're fixated on this idea of *disabling* it which
>> as I've already pointed out is the wrong thing to do anyway. You might
>> actually be talking to the VPN server over the protocol that you want
>> to disable.
Do you David think I haven't tested or considered other options?
So a VPN service provides IPv4 setup for the VPN but is originally
connected via IPv6? I just simply see this a bit theoretical.
If the VPN has in its config IPv6.Method as "Off" then it does not have
IPv6 ipconfig -> this would disable IPv6. I think in those cases the VPN
config should then have IPv6 enabled.
>
> Thanks for explaining why it's not right thing to do in the long run.
>
Sorry but I'm not convinced after I've tested almost all options I could
think of. Well anyways, I rather protect our customers when they are
using VPN to not to have any of their data leaked out of the secure
connection.
>> If you stop thinking about "disable", it should be simple enough to do
>> using unreachable routes and/or route tables.
>>
>> ip route add unreachable 0.0.0.0/0 table 16383
>> ip route add $VPNGW via $LOCALGW table 16383
>> ip rule add from all table 16383
>
Maybe for blocking IPv4, yes, but every service has an IPv4 address or
support for it such as Facebook has, but not every service has IPv6 yet.
This just culminates itself with DNS. If IPv4 is disabled, some of the
services cease to work, whereas telling the OS not to use IPv6 has less
breakages in general level. If you add unreachable route to elsewhere
than to the VPN server, for instance, what you guess would happen with
DNS when the server also serves AAAA requests? I saw problems when
attempting that.
Furthermore, as the routing tables are not managed yet by ConnMan (?)
for IPv6 kernel can then just manipulate them when new information on
routes arrives.
> Thinking about it, we have all the necessary code in place to setup such
> routing tables. The providers should just tell the core to set such a
> route. In fact, we already to this with the default routes. So it is be
> fairly natural to push additional routes.
>
I did test almost similar setup with adding undefined routes for IPv6
and the results were not good on connection establishment. Especially in
those cases when the VPN server's DNS returns back with AAAA records.
With the internal dnsproxy.c without explicitly telling which IP family
to use (e.g., with simply using ping) the functionality is questionable
to say the least if IPv6 has an undefined route, for example. Other
apps, such as Qt enabled ones, had long delays in connecting to a web
service when IPv6 routes led nowhere.
Any other viable method I could think of was to simply utilize firewall,
iptables in our case, to reject all connection attempts to IPv6, which
would allow excluding certain addresses, such as in the specific
scenarios David presented. This would make it possible to instantly
reject all attempts. But did not go very far with that either yet.
>>> I've already spent too much time on this. Some things are good to have,
>>> some may be theoretical only and some just work for the specific problem.
>>
>> I am hearing a lot of "I don't have time to do this properly in a
>> correct and protocol-agnostic fashion, so let's just pile in some nasty
>> non-future-proof hacks."
Savid: Ok, wow. I'll leave it to that.
>>
>> My time is also limited; I suppose it's up to Daniel whether he wants
>> to accept that kind of thing in ConnMan or whether he expects a higher
>> standard. So I'll leave my heckling there for now, with the observation
>> that it isn't *hard* to get this right.
>
> I didn't know about ocserver. I've done some work for setting up an
> end-to-end test framework (shamelessly stolen form iwd/bluez). Let me
> refresh that stuff and see if I am able to get such a test setup
> running. This would make things way simpler to test.
>
> Jussi, I know it's frustrating for you. You spend a lot of time writing
> and testing this series. I really appreciate this. Through the
> discussion between you and David (and my quick testing) it shows the
> solution has flaws. I am sorry I didn't figure this out when you were
> sending the initial RFC. It sounded like a good plan.
Well in our use this does seem to be valid and many in our community
have been attempting similar approach without any success because how
kernel manages IPv6. Working with a closed-ish lower layer is not easy.
Time consuming? Yes. Frustrating? No. Sometimes I'm kind of amused how
these things go.
Anyways, I think we're going to keep this in our fork and see what are
the implications on a wider use. I modified the RFC version quite a bit
after your comments Daniel and tested that by myself mainly. AFAIK
OpenVPN and VPNC seem to be the most used ones with us, and they support
only IPv4 as of now. And once we get OpenFortiVPN plugin updated a bit
and to solve some other issues that could be upstreamed as well.
>
> ConnMan already suffers from very complex logic which makes it hard to
> maintain. I am reluctant to add more logic which ties the IPv4 code path
> to the IPv6 code path (and vise versa).
>
The basic framework is there then, all that is to be replaced is the
actual IPv6 disabling logic in service.c, small checks in provider.c and
the parts from ipconfig.c not to touch autoconf when IPv6 is set to be
managed completely by ConnMan.
But yeah, this actually seemed to me as the least complex solution. DNS
record filtering is good on idea-level but there were some odd things
and probably things not considered with the early approach. Anyways, I'm
going to return to my DNS filtering WIP PR one day, if you want to take
a look: https://git.sailfishos.org/mer-core/connman/merge_requests/307
(at the moment it is just for the default service, not accounting for
multiple connected techs.)
Cheers,
Jussi
------------------------------
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 19
***************************************
