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: connman/iwd reconnect issues - ongoing (Daniel Wagner)
2. Re: Online check down on IPV4 leading to a full production park crash
(Daniel Wagner)
3. RE: Online check down on IPV4 leading to a full production park crash
(VAUTRIN Emmanuel (Canal Plus Prestataire))
4. Re: Online check down on IPV4 leading to a full production park crash
(Daniel Wagner)
5. Re: Online check down on IPV4 leading to a full production park crash
(Jussi Laakkonen)
6. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Mon, 12 Apr 2021 09:50:15 +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: <20210412075015.26wrtyj6e7ziz...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi KeithG,
On Fri, Apr 09, 2021 at 01:47:27PM -0500, KeithG wrote:
> I only received a partial set of patches in my inbox, but went to the
> web forum and copied and pasted the 4 patches.
I see all the patches on the mailing list. I'd say the mails got
somewhere lost between the mailing list to your inbox. Mabye because I
don't have setup any of DMARC(?) stuff. It's on the ever growing TODO
list.
> I then built against the latest git HEAD.
What about iwd, also HEAD?
> The result is that It does act differently, but
> still does not reconnect. Instead of one shot at scanning, it now
> scans a few times before it gives up but it does not reconnect.
After the initial discovery and setting the AutoConnect flag ConnMan
should not talk to iwd at all.
> I hope
> this is what you wanted me to test. If there is more, let me know.
Can you post the output of 'connmand -n -d plugins/iwd.c'?
Thanks,
Daniel
------------------------------
Date: Mon, 12 Apr 2021 09:56:46 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: Online check down on IPV4 leading to a full production
park crash
To: Robert Tiemann <r...@gmx.de>
Cc: connman@lists.01.org
Message-ID: <20210412075646.bfavsvjx4c5ln...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Fri, Apr 09, 2021 at 05:10:58PM +0200, Robert Tiemann wrote:
> On 4/9/21 2:21 PM, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
> > It seems that the http://ipv4.connman.net/online/status.html is unreachable,
> > contrary to http://ipv6.connman.net/online/status.html.
>
> curl: (28) Failed to connect to ipv4.connman.net port 80: Connection
> timed out
>
> The problem is real and it still persists. It would be great if it
> could be fixed soon.
Works for me again. Do you still have the problem?
------------------------------
Date: Mon, 12 Apr 2021 08:02:44 +0000
From: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Subject: RE: Online check down on IPV4 leading to a full production
park crash
To: Robert Tiemann <r...@gmx.de>, "connman@lists.01.org"
<connman@lists.01.org>
Message-ID: <pr1pr02mb4794528c67f33889c6555d7793...@pr1pr02mb4794.eur
prd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
A return to normal has been observed on Friday.
I think I will propose a patch soon to set these 2 urls customizable via
configuration.
Best Regards,
Emmanuel
------------------------------
Date: Mon, 12 Apr 2021 10:07:38 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: Online check down on IPV4 leading to a full production
park crash
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210412080738.ktdwocxkdayrw...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
On Mon, Apr 12, 2021 at 08:02:44AM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> A return to normal has been observed on Friday.
Okay.
> I think I will propose a patch soon to set these 2 urls customizable via
> configuration.
Check the archive, there was a lot of discussion on this topic.
------------------------------
Date: Mon, 12 Apr 2021 11:18:07 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: Online check down on IPV4 leading to a full production
park crash
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: <8a127055-f42c-127c-81da-4a6cbbf5e...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel and Emmanuel,
On 4/12/21 11:07 AM, Daniel Wagner wrote:
> On Mon, Apr 12, 2021 at 08:02:44AM +0000, VAUTRIN Emmanuel (Canal Plus
> Prestataire) wrote:
>> A return to normal has been observed on Friday.
>
> Okay.
>
>> I think I will propose a patch soon to set these 2 urls customizable via
>> configuration.
>
> Check the archive, there was a lot of discussion on this topic.
To speed up, I had these discussions regarding this change [1] [2] [3]
bookmarked.
I was planning to propose the changes we have been using for long [4]
[5] at one time when task falls to my lap. They need perhaps some fixing
and those commits just portray the old approach and there may be changes
on top - would need to look deeper into those and refer to current state..
It might be useful to have the links as configurable ones since the
different regional firewalls can block access to certain
networks/countries. Also confined environments used for testing may not
have external access.
[1]
https://lists.01.org/hyperkitty/list/connman@lists.01.org/thread/DVJVFWXHLBL3YTCQK2IOHZ6EVACLURM4/
[2] https://www.mail-archive.com/connman@connman.net/msg15605.html
[3]
https://lists.01.org/hyperkitty/list/connman@lists.01.org/message/HH74VLEFWZ35MPWAY6OFTOAYZWXYFHLG/
[4]
https://git.sailfishos.org/mer-core/connman/commit/f3c9364c7088a1592ea4b31768eed12f90d977b0
[5]
https://git.sailfishos.org/mer-core/connman/commit/9f3c3e58a800818fe56b7ff825d094a84035c6a7
Cheers,
Jussi
------------------------------
Date: Mon, 12 Apr 2021 11:28:06 +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: David Woodhouse <dw...@infradead.org>, Daniel Wagner
<w...@monom.org>
Cc: connman@lists.01.org
Message-ID: <7e11a54c-0f9f-2a9b-3fb4-6120eb1ae...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
On 4/9/21 4:22 PM, David Woodhouse wrote:
> On Fri, 2021-04-09 at 15:58 +0300, Jussi Laakkonen wrote:
>> 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.
>
> An IPv6-only network, if it wants to allow connectivity back to the
> 20th century, will do NAT64 and its DNS servers won't return A records
> to the clients.
>
> Or it might not provide direct connectivity (via NAT or otherwise) to
> the outside world at all; it might require all access to go through
> proxies, like the Intel corporate network did last time I was on it.
>
> Either way, that's up to the VPN server configuration. If the VPN wants
> to provide IPv6 connectivity and wants us to block Legacy IP egress
> through the local network, that's a perfectly valid setup just as
> providing Legacy IP and wanting us to block local IPv6 is.
>
>
> And yes, it's also perfectly feasible to have VPN servers which happen
> to be accessible over IPv6, which don't *yet* offer internal IPv6
> connectivity to their clients. As companies finally drag themselves
> into the 21st century, adding IPv6 connectivity on the *border* of
> their network is a very easy first step, long before they manage to
> update legacy systems and network topologies and migrate the *internal*
> network to IPv6.
>
> And even if the company *doesn't* provide IPv6, a client might still
> connect to it over NAT64 from an IPv6-only network. So it's IPv6 for
> the client, even when it's still Legacy IP on the server itself.
>
Thanks for the insight. I need to do/test this later on as a task to be
done in the future. It is just a question of ways of working here.
>> 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.
>
> It'll manipulate the default table, sure. But the rule snippet I showed
> was installing a higher-priority table. The kernel won't touch that one
> even if autoconf is enabled.
>
>>> 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.
>
> That sounds like the route wasn't actually *unreachable*. See RFC6724
> §6, Rule 1.
>
> If the IPv6 target is *unreachable*, the client should fall back
> immediately to Legacy IP. That situation is exactly the same as when
> you don't have IPv6 connectivity or IPv6 global addresses at all.
>
>> 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.
>
> Right, that would definitely not work right, since the routes wouldn't
> be *unreachable*. The address selection mechanism would still prefer
> them, and then they'd fail later — leading to timeouts, failures, etc.
>
> It really does have to be *unreachable*.
>
>
I'll get back to this when I can. I think with this info I can work on this.
Thanks,
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 22
***************************************
