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: [PATCH] service: Prevent auto connection during passphrase request
(VAUTRIN Emmanuel (Canal Plus Prestataire))
3. RE: [PATCH] timeserver: Fix time update manual->auto at startup
(VAUTRIN Emmanuel (Canal Plus Prestataire))
4. Re: [PATCH] iwd: Fix disabling tethering not working for brcmfmac
(Jonathan Liu)
----------------------------------------------------------------------
Date: Sun, 18 Apr 2021 14:59:21 +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: Jussi Laakkonen <jussi.laakko...@jolla.com>
Cc: connman@lists.01.org
Message-ID: <20210418125921.a7bpprcp5fykr...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi,
On Fri, Apr 09, 2021 at 03:58:58PM +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.
>
> 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.
This is why I think we need to set ipv6_accept_ra to 0 and do the RA
part as well. My first attempt to get this working was very frustrating
as the IPv6 ConnMan code is hard to follow and understand.
> > 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.
Obviously, if the IPv6 is not properly setup things wont work.
> 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.
If your changes work in your setup, that's fine. For upstream I'd like
to get IPv6 RA first fixed so that ConnMan starts to control the routing
correctly. Not sure at this point which is the best way forward. I was
playing with the idea to start over and use ELL as base. There is
already code in ELL for IPv6 and sharing the code with other projects is
a good idea in my book.
Thanks,
Daniel
------------------------------
Date: Sun, 18 Apr 2021 22:47:21 +0000
From: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Subject: RE: [PATCH] service: Prevent auto connection during
passphrase request
To: Daniel Wagner <w...@monom.org>, "connman@lists.01.org"
<connman@lists.01.org>
Message-ID: <pr1pr02mb4794150f46d1f8e9bac97c0293...@pr1pr02mb4794.eur
prd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Thank you Daniel for your answer.
> It seems you didn't understand my explenation, here what I think is
> the way to go. Just use the service pointer direcltly and remove the
> entry at the end.
In fact, it was clear, I was involving the interface (represented by service
index) in purpose.
Let me illustrate with the following case:
The end-user has 2 Wifi networks and wants to connect to both.
The involved device has only one Wifi interface, 1 frequency.
1. He connects successfully to Wifi 1, which is not secure.
2. He tries to connect to Wifi 2 which is secure.
When doing that, the following steps happen:
A. ConnMan disconnect Wifi 1
B. It tries to user connect to Wifi 2, but is paused by the passphrase
request.
C. Then, it auto connects to Wifi 1, which is available and succeeds.
D. The passphrase entered, it tries to user connect to Wifi 2
but unfortunately, another Wifi (1) is already connected, so it fails.
It will never be possible in this configuration for Wifi 2 to be connected.
The same issue also occurs if Wifi 1 is secure, as the passphrase is known.
Best Regards,
Emmanuel
------------------------------
Date: Sun, 18 Apr 2021 23:13:45 +0000
From: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Subject: RE: [PATCH] timeserver: Fix time update manual->auto at
startup
To: Daniel Wagner <w...@monom.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <pr1pr02mb4794cea5701487731565511d93...@pr1pr02mb4794.eur
prd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Daniel,
> This does the same thing as your last patch version.
Not exactly, it only sets the ts_service, for future use.
> When the timerserver_list is empty the timer server sync
> code is supposed to be off as well. If this is not the case,
> it's a bug and needs to be fixed. So that's why I am saying
> assigning ts_service a valid service and at the same time
> timerservers_list is NULL is just wrong.
Let me just illustrate, with the following case:
1. The device boots, in manual mode (even if a timer list is
provided, timerservers_list will be NULL, the default time
/etc/timestamp is used.
2. After a while, the user switches to auto, to synchronize.
__connman_timeserver_conf_update is called, but,
unfortunately, ts_service is NULL, and differs from
service. ts_reset is not called, nothing happens, the
default time keeps being used instead being synchronized,
as expected.
Best Regards,
Emmanuel
------------------------------
Date: Mon, 19 Apr 2021 15:20:09 +1000
From: Jonathan Liu <net...@gmail.com>
Subject: Re: [PATCH] iwd: Fix disabling tethering not working for
brcmfmac
To: connman@lists.01.org
Message-ID:
<CANwerB3i1BB9jmxXg4Zh8rc1FS=rybce6zhucdyrfcpvbaf...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
I haven't had time to work on a V2 so if anyone wants to have a go at
it, feel free.
Thanks.
Regards,
Jonathan
On Mon, 15 Mar 2021 at 17:59, Jonathan Liu <net...@gmail.com> wrote:
>
> Hi,
>
> It seems there are issues with this patch. Will follow up with a V2.
>
> Regards,
> Jonathan
>
> On Mon, 15 Mar 2021 at 17:00, Jonathan Liu <net...@gmail.com> wrote:
> >
> > For Broadcom BCM4356 chipset with brcmfmac driver, changing from AP mode
> > to station mode returns -EBUSY if the wireless interface is a member of
> > a bridge.
> >
> > To resolve the issue, the wireless interface is removed from the tether
> > bridge before changing the mode rather than after.
> >
> > Fixes: 648ed549f0ac ("iwd: Add support for tethering")
> > ---
> > plugins/iwd.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/plugins/iwd.c b/plugins/iwd.c
> > index 0a25fabf..02f358ef 100644
> > --- a/plugins/iwd.c
> > +++ b/plugins/iwd.c
> > @@ -758,10 +758,6 @@ static void tech_disable_tethering_cb(const DBusError
> > *error, void *user_data)
> > iwdap->index = -1;
> > iwdap->bridge = NULL;
> > iwdap->tech = NULL;
> > -
> > - if (!connman_inet_remove_from_bridge(cbd->index, cbd->bridge))
> > - goto out;
> > -
> > connman_technology_tethering_notify(cbd->tech, false);
> >
> > if (!g_dbus_proxy_method_call(iwdap->proxy, "Stop",
> > @@ -790,6 +786,9 @@ static int cm_change_tethering(struct iwd_device *iwdd,
> > if (index < 0)
> > return -ENODEV;
> >
> > + if (!enabled && !connman_inet_remove_from_bridge(index, bridge))
> > + return -EIO;
> > +
> > cbd = g_new(struct tech_cb_data, 1);
> > cbd->iwdd = iwdd;
> > cbd->path = g_strdup(iwdd->path);
> > --
> > 2.30.1
> >
------------------------------
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 27
***************************************
