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