Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Connect to any access point which has WPS activated
(Jose Blanquicet)
2. Re: [PATCH 0/3] Fixes and extensions for WPS support
(Jose Blanquicet)
3. Re: Connect to any access point which has WPS activated
(Robert Tiemann)
4. [PATCH v2 0/3] Fixes and extensions for WPS support
(Robert Tiemann)
5. [PATCH v2 1/3] service: Indicate which wifi network has WPS,
activated. (Robert Tiemann)
6. Re: Connect to any access point which has WPS activated
(Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Jan 2018 00:05:27 +0100
From: Jose Blanquicet <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected]
Subject: Re: Connect to any access point which has WPS activated
Message-ID:
<cafc8ijjzb8xoygttl2y+q6qf2yhh-b136+sjcnr+fga0abu...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Robert,
On Wed, Jan 10, 2018 at 11:08 AM, Robert Tiemann <[email protected]> wrote:
> What I am trying to achieve is to connect automatically to *any*
> access point which has WPS activated (push button method), and use the
> agent API to accept any connection. The target network should not have
> to be preselected by the user. It would be very nice if ConnMan would
> offer such functionality over D-Bus, but I could not find anything
> like this.
>
> As far as I can see, what I have to do instead is to check all wifi
> services for WPS capabilities (net.connman.Manager.GetServices()),
> then try to connect to each of them directly, one by one
> (net.connman.Service.Connect()), and then wait for agent API requests
> to come in or for some timeout to expire.
I will give a label to APs in order to refer to them easily later.
> This works, sort of, but only if the first wifi service tried is also
> the one which has WPS activated. If the first service tried does *not*
> have WPS activated, then I get an error for that service,
Let's label it AP1, service -> wifi_XXX_AP1.
> but at the
> same time I can also see in the logs that a connection has actually
> been established via WPS with a different access point which *does*
> have WPS activated.
This is AP2.
> That latter access point reports a successful WPS
> connection and WPS gets disabled there, thinking the client is
> alright. Immediately after the connection has been made, it is
> disconnected again (probably by ConnMan). Then, when I am trying to
> connect to the access point which used to have WPS activated, the
> connection attempt fails because WPS has already been deactivated
> after the preceding successful connect.
>
> It is actually possible to reproduce this with connmanctl. Connecting
> to some "wrong" access point causes WPS to be started with another
> access point which has WPS activated, which I think is kind of weird.
That "weird" behaviour can be explained but it is still wrong. When
you execute "connect wifi_XXX_AP1" with WPS parameters for
push-button, this request will become in a call to wpa_supplicant's
method Interface.WPS.Start(). Such method is not associated to any AP.
Therefore, it could result in an association with any AP in range
where as been pushed the WPS-button, in your example AP2.
After that connection, ConnMan will verify if AP to which it got
associated is actually the one user called in the "connect
wifi_XXX_AP1". If it is not, like in your case, then ConnMan will not
let this association go on. And that's why you saw that
disassociation. The main problem is that starting a WPS session should
not require to select a service as ConnMan does, it should be a simple
StartWPS(pin/push-button) and that's it.
I saw the patch series you sent, it looks fine, using it we could
still fall in the above situation but at least we will have the
possibility to avoid that by choosing the service corresponding to the
AP that is actually advertising WPS. It is a good start but somehow I
am afraid that we are just moving the problem to the layer above
ConnMan.
Many thanks for working on this!
Jose Blanquicet
------------------------------
Message: 2
Date: Mon, 15 Jan 2018 00:42:46 +0100
From: Jose Blanquicet <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected], Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/3] Fixes and extensions for WPS support
Message-ID:
<CAFC8iJLYr=66+7gabqn+w8o-k4aobsz-evuo8veituoy_ut...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Robert,
On Fri, Jan 12, 2018 at 12:58 PM, Daniel Wagner <[email protected]> wrote:
>> Allow clients to identify WPS registrars.
>>
>> Note that I am actually not quite happy with patch 3 because I have
>> copied some parts from network_added() to network_changed() in
>> plugins/wifi.c. Maybe it would be good to refactor it later to avoid
>> code duplication.
>
> Apart the two nitpicks from me, the code looks good. Pretty neat
> actually :) Nice work.
Same for me :) I will test it a little bit more tomorrow.
I would just suggest, as usual, to check the patch with checkpatch.pl
for style errors like "line over 80 characters" and others. We use
Linux kernel coding style.
Thanks,
Jose Blanquicet
------------------------------
Message: 3
Date: Mon, 15 Jan 2018 09:11:43 +0100
From: Robert Tiemann <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: [email protected]
Subject: Re: Connect to any access point which has WPS activated
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 01/15/2018 12:05 AM, Jose Blanquicet wrote:
> Hi Robert,
Hi!
> ... And that's why you saw that disassociation.
OK, understood, thanks for explanation. I am by no means a WiFi expert
and didn't know much about how WPS is supposed to work before I had it
failing on me.
> The main problem is that starting a WPS session should
> not require to select a service as ConnMan does, it should be a simple
> StartWPS(pin/push-button) and that's it.
Yes, this is exactly the functionality I was looking for.
> I saw the patch series you sent, it looks fine, using it we could
> still fall in the above situation but at least we will have the
> possibility to avoid that by choosing the service corresponding to the
> AP that is actually advertising WPS. It is a good start but somehow I
> am afraid that we are just moving the problem to the layer above
> ConnMan.
My patches keep some of the burden to connect via WPS in client code,
they only enable clients to make a good decision which service to try
(and when) so that it may pass ConnMan's filter.
A simple command to just do everything automatically would be a great
thing to have. I actually received an off-list reply to my first email
with the recommendation to add a new command to connect via WPS on top
of the wpa_supplicant fi.w1.wpa_supplicant1.Interface.WPS.Start
method. This is what I would prefer to have, but I didn't really know
where to start. I guess adding such a command would require much more
knowledge about ConnMan internals than just adding in the small bits
I've contributed.
Maybe this could be the next step?
> Jose Blanquicet
Robert
------------------------------
Message: 4
Date: Mon, 15 Jan 2018 10:15:19 +0100
From: Robert Tiemann <[email protected]>
To: [email protected]
Subject: [PATCH v2 0/3] Fixes and extensions for WPS support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Allow clients to identify WPS registrars.
Note that I am actually not quite happy with patch 3 because I have
copied some parts from network_added() to network_changed() in
plugins/wifi.c. Maybe it would be good to refactor it later to avoid
code duplication.
v2:
- Improve commit message.
- Fix warnings reported by checkpatch.pl.
Robert Tiemann (3):
service: Indicate which wifi network has WPS activated.
gsupplicant: Fix WPS capabilities updates.
gsupplicant: Report changes of network WPS capabilities.
gsupplicant/supplicant.c | 22 +++++++++++++++++++++-
plugins/wifi.c | 40 ++++++++++++++++++++++++++++++++++++----
src/network.c | 5 +++++
src/service.c | 18 ++++++++++++++++--
4 files changed, 78 insertions(+), 7 deletions(-)
--
1.9.1
------------------------------
Message: 5
Date: Mon, 15 Jan 2018 10:17:14 +0100
From: Robert Tiemann <[email protected]>
To: [email protected]
Subject: [PATCH v2 1/3] service: Indicate which wifi network has WPS,
activated.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
---
plugins/wifi.c | 2 ++
src/network.c | 5 +++++
src/service.c | 18 ++++++++++++++++--
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index f99340d..e8e66d0 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2813,6 +2813,8 @@ static void network_added(GSupplicantNetwork
*supplicant_network)
connman_network_set_strength(network,
calculate_strength(supplicant_network));
connman_network_set_bool(network, "WiFi.WPS", wps);
+ connman_network_set_bool(network, "WiFi.WPSAdvertising",
+ wps_advertizing);
if (wps) {
/* Is AP advertizing for WPS association?
diff --git a/src/network.c b/src/network.c
index f3e422f..8c5979f 100644
--- a/src/network.c
+++ b/src/network.c
@@ -97,6 +97,7 @@ struct connman_network {
char *private_key_passphrase;
char *phase2_auth;
bool wps;
+ bool wps_advertizing;
bool use_wps;
char *pin_wps;
} wifi;
@@ -1927,6 +1928,8 @@ int connman_network_set_bool(struct connman_network
*network,
network->roaming = value;
else if (g_strcmp0(key, "WiFi.WPS") == 0)
network->wifi.wps = value;
+ else if (g_strcmp0(key, "WiFi.WPSAdvertising") == 0)
+ network->wifi.wps_advertizing = value;
else if (g_strcmp0(key, "WiFi.UseWPS") == 0)
network->wifi.use_wps = value;
@@ -1947,6 +1950,8 @@ bool connman_network_get_bool(struct connman_network
*network,
return network->roaming;
else if (g_str_equal(key, "WiFi.WPS"))
return network->wifi.wps;
+ else if (g_str_equal(key, "WiFi.WPSAdvertising"))
+ return network->wifi.wps_advertizing;
else if (g_str_equal(key, "WiFi.UseWPS"))
return network->wifi.use_wps;
diff --git a/src/service.c b/src/service.c
index e72b6f3..f743997 100644
--- a/src/service.c
+++ b/src/service.c
@@ -126,6 +126,7 @@ struct connman_service {
char **excludes;
char *pac;
bool wps;
+ bool wps_advertizing;
int online_check_count;
bool do_split_routing;
bool new_service;
@@ -1664,6 +1665,12 @@ static void append_security(DBusMessageIter *iter, void
*user_data)
case CONNMAN_SERVICE_SECURITY_8021X:
break;
}
+
+ if (service->wps_advertizing) {
+ str = "wps_advertising";
+ dbus_message_iter_append_basic(iter,
+ DBUS_TYPE_STRING, &str);
+ }
}
}
@@ -4878,6 +4885,7 @@ static void service_initialize(struct connman_service
*service)
service->provider = NULL;
service->wps = false;
+ service->wps_advertizing = false;
}
/**
@@ -7022,8 +7030,11 @@ static void update_from_network(struct connman_service
*service,
str = connman_network_get_string(network, "WiFi.Security");
service->security = convert_wifi_security(str);
- if (service->type == CONNMAN_SERVICE_TYPE_WIFI)
+ if (service->type == CONNMAN_SERVICE_TYPE_WIFI) {
service->wps = connman_network_get_bool(network, "WiFi.WPS");
+ service->wps_advertizing = connman_network_get_bool(network,
+ "WiFi.WPSAdvertising");
+ }
if (service->strength > strength && service->network) {
connman_network_unref(service->network);
@@ -7191,8 +7202,11 @@ void __connman_service_update_from_network(struct
connman_network *network)
DBUS_TYPE_STRING, &service->name);
}
- if (service->type == CONNMAN_SERVICE_TYPE_WIFI)
+ if (service->type == CONNMAN_SERVICE_TYPE_WIFI) {
service->wps = connman_network_get_bool(network, "WiFi.WPS");
+ service->wps_advertizing = connman_network_get_bool(network,
+ "WiFi.WPSAdvertising");
+ }
strength = connman_network_get_strength(service->network);
if (strength == service->strength)
--
1.9.1
------------------------------
Message: 6
Date: Mon, 15 Jan 2018 10:17:21 +0100
From: Jose Blanquicet <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: [email protected]
Subject: Re: Connect to any access point which has WPS activated
Message-ID:
<cafc8ijjmrxmy7hqp16djb2yxhrxrbvcazkkt_qireqh_myh...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Robert,
On Mon, Jan 15, 2018 at 9:11 AM, Robert Tiemann <[email protected]> wrote:
> OK, understood, thanks for explanation. I am by no means a WiFi expert
> and didn't know much about how WPS is supposed to work before I had it
> failing on me.
Don't worry, you did indeed a great work. I did not consider myself a
WiFi expert, I just have played with ConnMan from a while :)
>> The main problem is that starting a WPS session should
>> not require to select a service as ConnMan does, it should be a simple
>> StartWPS(pin/push-button) and that's it.
>
> Yes, this is exactly the functionality I was looking for.
Me too, we started this discussion long time ago because we were
looking to get WPS WiFi Alliance certification for one of our products
so we started working on a new WPS implementation for ConnMan.
Unfortunately, I was requested to move to another project and I did
not have enough time to finish that implementation. It was out of my
hands :(
>> I saw the patch series you sent, it looks fine, using it we could
>> still fall in the above situation but at least we will have the
>> possibility to avoid that by choosing the service corresponding to the
>> AP that is actually advertising WPS. It is a good start but somehow I
>> am afraid that we are just moving the problem to the layer above
>> ConnMan.
>
> My patches keep some of the burden to connect via WPS in client code,
> they only enable clients to make a good decision which service to try
> (and when) so that it may pass ConnMan's filter.
>
> A simple command to just do everything automatically would be a great
> thing to have. I actually received an off-list reply to my first email
> with the recommendation to add a new command to connect via WPS on top
> of the wpa_supplicant fi.w1.wpa_supplicant1.Interface.WPS.Start
> method. This is what I would prefer to have, but I didn't really know
> where to start. I guess adding such a command would require much more
> knowledge about ConnMan internals than just adding in the small bits
> I've contributed.
>
> Maybe this could be the next step?
We started working on this but when you have to deal with
wpa_supplicant everything becomes much more complex. Here our initial
proposal at that time: [1] [2] [3]. After that proposal we still
worked on that implementation but as I said we could not finish it so
I did not share with the community the latest implementation we
developed.
If you really want to go in this direction, it could also be worth to
have a look into IWD implementation as Marcel said.
[1] https://lists.01.org/pipermail/connman/2016-August/000917.html
[2] https://lists.01.org/pipermail/connman/2016-July/000858.html
[3] https://lists.01.org/pipermail/connman/2016-July/000859.html
Thanks,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 27, Issue 9
**************************************
