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 0/1] start online check even if service is not the default
service
(Daniel Wagner)
2. [PATCH] service: Let PreferredTechnologies overrule connected service
sorting
(Daniel Wagner)
3. Re: [PATCH 2/3] wispr: Add online check url config options
(Daniel Wagner)
4. Re: [PATCH] main: Cleanup of vendor class id and wifi config options
(Daniel Wagner)
5. Re: Connman and IWD - Scanning Network - Update? (Daniel Wagner)
6. Re: [RFC connman 1/1] WIP: Add WPA3-SAE support (Daniel Wagner)
7. Re: [RFC connman 1/1] WIP: Add WPA3-SAE support (Daniel Wagner)
8. Re: [PATCH] service: Prevent auto connection during passphrase request
(Daniel Wagner)
9. Re: [RFC connman 1/1] WIP: Add WPA3-SAE support (Marcel Holtmann)
----------------------------------------------------------------------
Date: Thu, 13 May 2021 11:33:48 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH 0/1] start online check even if service is not the
default service
To: Christophe Ronco <c.ro...@kerlink.fr>
Cc: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>, "connman@lists.01.org"
<connman@lists.01.org>
Message-ID: <20210513093348.ob3bqlx4zhakj...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi,
On Tue, May 11, 2021 at 05:21:31PM +0200, Christophe Ronco wrote:
> >> Yes this is a big problem for me. If WiFi service stays online and
> >> Ethernet service stays ready, the default route is on WiFi so all
> >> traffic goes through WiFi instead of wired. This is bad and not what end
> >> user wants when he wrote "PreferredTechnologies = ethernet, wifi,
> >> cellular" in main.conf. WiFi is a backup and must not be used if
> >> Ethernet is OK. Looking at comments in main.conf I see current behavior
> >> (using WiFi service for default route when Ethernet service is working)
> >> as a bug.
> > Your concern makes totally sense.
The problem is that service_compare() is not honoring
PreferredTechnologies when both services are in READY/ONLINE state. I'll
send out a patch.
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 11:42:46 +0200
From: Daniel Wagner <w...@monom.org>
Subject: [PATCH] service: Let PreferredTechnologies overrule connected
service sorting
To: connman@lists.01.org
Cc: VAUTRIN Emmanuel <emmanuel.vaut...@cpexterne.org>, Daniel Wagner
<w...@monom.org>
Message-ID: <20210513094246.22810-1-w...@monom.org>
When both services are in either READY or ONLINE state ConnMan will
always return either the service in ONLINE state (this is the correct
behavior) or when both services are in ONLINE state service_a
first. PreferredTechnologies is ignored in this case.
For configuration such as
PreferredTechnologies = ethernet,wifi
SingleConnectedTechnology = true
ConnMan would almost never sort Ethernet before WiFi, as WiFi is likely
to be in the ONLINE state. Hence the WiFi would stay on forever even
though the Ethernet cable is plugged in (again).
Place the service_compare_preferred() after the service->oder logic as
this is used for split VPN setups which has higher priority in the
sorting.
As we place this call inside the 'is_connected' section where both
service are in either READY or ONLINE state, it overrules the
existing logic where the ONLINE service is preferred over the READY.
---
src/service.c | 40 +++++++++++++++++++++++++++-------------
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/src/service.c b/src/service.c
index 20917a8923a4..f64ba7031e8c 100644
--- a/src/service.c
+++ b/src/service.c
@@ -5316,6 +5316,25 @@ static gint service_compare_vpn(struct connman_service
*a,
return service_compare(transport, service);
}
+static gint service_compare_preferred(struct connman_service *service_a,
+ struct connman_service *service_b)
+{
+ unsigned int *tech_array;
+ int i;
+
+ tech_array = connman_setting_get_uint_list("PreferredTechnologies");
+ if (tech_array) {
+ for (i = 0; tech_array[i]; i++) {
+ if (tech_array[i] == service_a->type)
+ return -1;
+
+ if (tech_array[i] == service_b->type)
+ return 1;
+ }
+ }
+ return 0;
+}
+
static gint service_compare(gconstpointer a, gconstpointer b)
{
struct connman_service *service_a = (void *) a;
@@ -5346,6 +5365,10 @@ static gint service_compare(gconstpointer a,
gconstpointer b)
if (service_a->order < service_b->order)
return 1;
+
+ rval = service_compare_preferred(service_a, service_b);
+ if (rval)
+ return rval;
}
if (state_a != state_b) {
@@ -5376,20 +5399,11 @@ static gint service_compare(gconstpointer a,
gconstpointer b)
return 1;
if (service_a->type != service_b->type) {
- unsigned int *tech_array;
- int i;
-
- tech_array = connman_setting_get_uint_list(
- "PreferredTechnologies");
- if (tech_array) {
- for (i = 0; tech_array[i]; i++) {
- if (tech_array[i] == service_a->type)
- return -1;
+ int rval;
- if (tech_array[i] == service_b->type)
- return 1;
- }
- }
+ rval = service_compare_preferred(service_a, service_b);
+ if (rval)
+ return rval;
if (service_a->type == CONNMAN_SERVICE_TYPE_ETHERNET)
return -1;
--
2.31.1
------------------------------
Date: Thu, 13 May 2021 11:51:07 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH 2/3] wispr: Add online check url config options
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210513095107.asvib3gq55xjm...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Thu, May 06, 2021 at 03:14:52PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> Global config options, which allow to set the urls (IPv4 and IPv6
> respectively) used during the online status check.
> Default values are http://ipv4.connman.net/online/status.html and
> http://ipv6.connman.net/online/status.html respectively.
> ---
> README | 9 +++++++++
> doc/connman.conf.5.in | 13 ++++++++-----
What about moving all the online check documentation into a new file
under doc/online-check.txt and just point in the .conf file to the
documentation. I think we are sprinkling this topic over too many places
and it seems to be of big concern to many users.
> > And if you are going down the road are you going to share your server
> > setup? These days I suspect it would be something with kubernetes :)
>
> Unfortunately, I have just used another URL with a reverse proxy,
> redirecting to the default one. We have no resource to manage the
> server side.
Okay, understood.
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 11:53:54 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] main: Cleanup of vendor class id and wifi config
options
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210513095354.kgl6zpfix7bgb...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Thu, May 06, 2021 at 09:45:01AM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> Ensure homogeneity of config options management by replacing
> connman_option_get_string() by connman_setting_get_string(), and
> removing irrelevant option.h header file.
> Fix a memory leak on vendor class id option.
Nice cleanup. Patch applied.
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 12:45:15 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: Connman and IWD - Scanning Network - Update?
To: stef204 <stef...@yandex.com>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210513104515.og5s4bw2caroi...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi,
On Fri, May 07, 2021 at 05:50:28AM -0600, stef204 wrote:
> Any luck with getting connman with IWD to detect wifi using connmanctl 'scan
> wifi'?
Unfortunately, I don't have your original mail anymore and the mail
archive is also not working.
Anyway, a quick test works for me:
connmanctl> scan wifi
Scan completed for wifi
and I also see the corresponding D-Bus messages
method call time=1620901993.323110 sender=:1.63 -> destination=net.connman
serial=83 path=/net/connman/technology/wifi; interface=net.connman.Technology;
member=Scan
method call time=1620901993.323322 sender=:1.120 -> destination=net.connman.iwd
serial=3637 path=/net/connman/iwd/0/6; interface=net.connman.iwd.Station;
member=Scan
method return time=1620901993.323515 sender=:1.106 -> destination=:1.120
serial=1860 reply_serial=3637
signal time=1620901993.323588 sender=:1.106 -> destination=(null destination)
serial=1861 path=/net/connman/iwd/0/6;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "net.connman.iwd.Station"
array [
dict entry(
string "Scanning"
variant boolean true
)
]
array [
]
[...]
What's the problem with 'connmanctl scan wifi'?
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 12:53:19 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [RFC connman 1/1] WIP: Add WPA3-SAE support
To: Andrej Shadura <andrew.shad...@collabora.co.uk>
Cc: Ariel D'Alessandro <ariel.dalessan...@collabora.com>,
connman@lists.01.org, sven.dembia...@bshg.com, i...@lists.01.org
Message-ID: <20210513105319.7sgih2sbhrdn4...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Andrej,
On Thu, May 13, 2021 at 11:52:32AM +0200, Andrej Shadura wrote:
> On 12/05/2021 19:27, Ariel D'Alessandro wrote:
> > Implement WPA3-SAE authentication on connman side.
> >
> > Based on Tizen project:
> >
> > https://review.tizen.org/git/?p=platform/upstream/connman.git
> >
> > Signed-off-by: Ariel D'Alessandro <ariel.dalessan...@collabora.com>
>
> Based on my understanding how this should work, this looks reasonable to me.
Same here, this looks pretty straightforward. Thanks for picking this
up.
The patch should be spitted into one which adds the SAE to the Security
property of the Service API (please also update the documentation). The
second patch adds the plugins/wifi.c implementation.
I am not really into the WiFi topic anymore, so I am adding the iwd
mailing list. Maybe we get some input for the new SAE Security
property, e.g. how this could work with iwd.
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 12:56:55 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [RFC connman 1/1] WIP: Add WPA3-SAE support
To: Andrej Shadura <andrew.shad...@collabora.co.uk>
Cc: Ariel D'Alessandro <ariel.dalessan...@collabora.com>,
connman@lists.01.org, sven.dembia...@bshg.com, i...@lists.01.org
Message-ID: <20210513105655.3gm3hrgz4b277...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Ariel,
I just realize this patch was not send to the connman (iwd) mailing
list. Could you post it there as well?
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 13:08:48 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Prevent auto connection during
passphrase request
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <20210513110848.7zywjzkv6b26e...@beryllium.lan>
Content-Type: text/plain; charset=us-ascii
Hi Emmanuel,
On Mon, Apr 26, 2021 at 07:10:30PM +0000, VAUTRIN Emmanuel (Canal Plus
Prestataire) wrote:
> Avoid concurrent associations between a user connection to a secure
> service, blocked by an agent passphrase input request, and a starting
> auto connection on a different service of the same interface.
>
> This issue happens when the end-user wants to connect to a new secure
> Wifi network (W2) via an interface where another Wifi network (W1) is
> already connected. When doing that, the following steps happen:
> 1. Disconnection of current network (W1).
> 2. User-connection to W2, held by the passphrase request.
> 3. Auto-connection to a known available Wifi network (W1) succeeding.
> 4. User-connection to W2, reactivated by the passphrase response,
> failing, as another Wifi (W1) is already connected.
> In this configuration, W2 will never be able to connect.
Thanks for adding the commit message.
> DBG("service %p state %s connect reason %s -> %s",
> @@ -6779,6 +6792,13 @@ int __connman_service_connect(struct connman_service
> *service,
> if (service->hidden && err != -EINPROGRESS)
> service->pending = pending;
>
> + if (err == -EINPROGRESS) {
> + index = __connman_service_get_index(service);
> + g_hash_table_replace(passphrase_requested,
> + GINT_TO_POINTER(index),
> + GINT_TO_POINTER(true));
Ah I see you dropped the file descriptor and now you just store a
boolean. In this case you could just add a boolean variable called
passphrase_requested to 'struct service' and you could drop the hash
table completely. So this gets
service->passphrase_requested = true;
and in auto_connect_servcie() a simple
if (service->passphrase_requested)
return true;
is enough.
Thanks,
Daniel
------------------------------
Date: Thu, 13 May 2021 21:01:05 +0200
From: Marcel Holtmann <mar...@holtmann.org>
Subject: Re: [RFC connman 1/1] WIP: Add WPA3-SAE support
To: Daniel Wagner <w...@monom.org>
Cc: Andrej Shadura <andrew.shad...@collabora.co.uk>, Ariel
D'Alessandro <ariel.dalessan...@collabora.com>, connman@lists.01.org,
sven.dembia...@bshg.com, i...@lists.01.org
Message-ID: <386e1ceb-785c-4b14-97e7-396819bbf...@holtmann.org>
Content-Type: text/plain; charset=utf-8
Hi Daniel,
>>> Implement WPA3-SAE authentication on connman side.
>>>
>>> Based on Tizen project:
>>>
>>> https://review.tizen.org/git/?p=platform/upstream/connman.git
>>>
>>> Signed-off-by: Ariel D'Alessandro <ariel.dalessan...@collabora.com>
>>
>> Based on my understanding how this should work, this looks reasonable to me.
>
> Same here, this looks pretty straightforward. Thanks for picking this
> up.
>
> The patch should be spitted into one which adds the SAE to the Security
> property of the Service API (please also update the documentation). The
> second patch adds the plugins/wifi.c implementation.
>
> I am not really into the WiFi topic anymore, so I am adding the iwd
> mailing list. Maybe we get some input for the new SAE Security
> property, e.g. how this could work with iwd.
don’t change the Service API. Even WPA3 Personal is just PSK and so there is no
need to add another security property entry. Actually if you are using iwd,
then the detail between WPA2 and WPA3 is never exposed to ConnMan.
Frankly, if you want good WiFi support, ditch wpa_supplicant and run iwd.
Regards
Marcel
------------------------------
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 67, Issue 7
**************************************
