8:10 a.m.
Hello,
I want to report an issue with connman. We set BackgroundScanning = false in main.conf.
However, I have found that this also causes connman to give an erroneous empty response to
the Scan() dbus call, potentially permanently disabling the device.
The key preconditions seem to be:
1) wpa_supplicant reports a max_ssids > 1
2) the computer must have been previously associated to a SSID which is no longer visible
3) as above, BackgroundScanning must be set to false
This causes the logic of wifi.c:wifi_scan() to fail. In particular:
1) wifi_scan_simple is not used, due to the above preconditions.
2) connman requests an active scan via wpa_supplicant for the ssids returned by
get_latest_connections.
3) connman does not request a followup passive scan, as BackgroundScanning is turned off,
which causes start_autoscan() to exit early.
This means that in the scenario above, connman will never see any wifi networks. Scan()
will always return an empty list, even if other SSIDs are available. This is potentially
fatal for embedded systems, so in my view this is a very serious issue.
This issue affects at least connman 1.33 and 1.34. I cannot test older versions due to
other dependencies.
One workaround is to enable BackgroundScanning.
Best,
Jonah
8:22 a.m.
________________________________________
From: connman <connman-bounces(a)lists.01.org> on behalf of Jonah Petri
<jonah(a)sense.com>
Sent: 08 August 2017 16:10
To: connman(a)lists.01.org
Subject: When BackgroundScanning = false, connman's Scan() dbus method is broken
I want to report an issue with connman. We set BackgroundScanning = false in main.conf.
However, I have found that this also causes connman to give an erroneous empty response to
the Scan() dbus call, potentially permanently disabling the device.
_______________________________________________
connman mailing list
connman(a)lists.01.org
https://lists.01.org/mailman/listinfo/connman
Hello,
I can reproduce this issue. We wanted to disable BackgroundScanning as we support
a few wireless drivers that experience disruption to the connection when scanning
occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
reports of users unable to find any WiFi networks.
Sam
2:15 a.m.
On 08/08/2017 05:22 PM, Sam Nazarko wrote:
________________________________________
From: connman <connman-bounces(a)lists.01.org> on behalf of Jonah Petri
<jonah(a)sense.com>
Sent: 08 August 2017 16:10
To: connman(a)lists.01.org
Subject: When BackgroundScanning = false, connman's Scan() dbus method is broken
I want to report an issue with connman. We set BackgroundScanning = false in main.conf.
However, I have found that this also causes connman to give an erroneous empty response to
the Scan() dbus call, potentially permanently disabling the device.
_______________________________________________
connman mailing list
connman(a)lists.01.org
https://lists.01.org/mailman/listinfo/connman
Hello,
I can reproduce this issue. We wanted to disable BackgroundScanning as we support
a few wireless drivers that experience disruption to the connection when scanning
occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
reports of users unable to find any WiFi networks.
This worked in an older version of ConnMan? 1.33? This information would
help to identify the commit which broke the feature.
Thanks,
Daniel
7:08 a.m.
On Aug 9, 2017, at 5:15 AM, Daniel Wagner <wagi(a)monom.org>
wrote:
This worked in an older version of ConnMan? 1.33? This information would help to identify
the commit which broke the feature.
I don't know of a version of connman where this worked, but I have only tested 1.33
and 1.34, as I mentioned in my original message.
Jonah
8:12 a.m.
On 08/09/2017 04:08 PM, Jonah Petri wrote:
> On Aug 9, 2017, at 5:15 AM, Daniel Wagner <wagi(a)monom.org>
wrote:
>
> This worked in an older version of ConnMan? 1.33? This information would help to
identify the commit which broke the feature.
I don't know of a version of connman where this worked, but I have only tested 1.33
and 1.34, as I mentioned in my original message.
I hoped that Sam is has some input on this. Sorry for the confusion.
11:28 a.m.
I hoped that Sam is has some input on this. Sorry for the confusion.
Hi,
Unfortunately we only tested this with 1.34.
Therefore I can't comment on when the issue was introduced and whether it was a
recent regression.
We do want to get this working soon though, so I'll see if I can get a chance to look
at this next week and find a way to reliably reproduce the issue.
Sam
1:25 a.m.
Hi Sam,
On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko <email(a)samnazarko.co.uk> wrote:
I can reproduce this issue. We wanted to disable BackgroundScanning
as we support
a few wireless drivers that experience disruption to the connection when scanning
occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
reports of users unable to find any WiFi networks.
What you need is to disable specifically what I explained as
Background-Scan for roaming proposes.
Here we could think to divide "BackgroundScanning" into two different
properties, one for Background-Scan another for Auto-Scan. What do
people think?
Regards,
Jose Blanquicet
1:50 a.m.
Hi Jose,
On 08/10/2017 10:25 AM, Jose Blanquicet wrote:
On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko
<email(a)samnazarko.co.uk> wrote:
> I can reproduce this issue. We wanted to disable BackgroundScanning as we support
> a few wireless drivers that experience disruption to the connection when scanning
> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
> reports of users unable to find any WiFi networks.
What you need is to disable specifically what I explained as
Background-Scan for roaming proposes.
Here we could think to divide "BackgroundScanning" into two different
properties, one for Background-Scan another for Auto-Scan. What do
people think?
Not sure how to address this. I personally get confused by the terms background
scan and auto scan. The name 'auto' and 'background' are like synonyms in
my ears.
Furthermore, we should be careful to add main.conf config options which are
wpa_supplicant specific. We had this discussion already for other scenarios.
Adding low level config options it to main section of main.conf should be
avoided if you ask me. We have already a bunch of them.
The only idea I have so far to allow low-level plugin specific configuration
files. We would need to move of the connnman_config_*() bits around to the
public header files. Then plugins could use such function as:
char *__connman_config_get_string(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
char **__connman_config_get_string_list(GKeyFile *key_file,
const char *group_name, const char *key, gsize *length, GError **error);
bool __connman_config_get_bool(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
The reason why I suggest to allow plugins to open the keyfiles directly is that
I don't want to read all config data in the core and then pass it to
the plugin.
Sorry this is slightly detour but I think we could make use of these
changes to factor out the wpa_supplicant config hell from main.conf.
Thanks,
Daniel
2:55 a.m.
Hi,
On Thu, Aug 10, 2017 at 8:50 AM, Daniel Wagner <wagi(a)monom.org> wrote:
On 08/10/2017 10:25 AM, Jose Blanquicet wrote:
> On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko <email(a)samnazarko.co.uk> wrote:
>> I can reproduce this issue. We wanted to disable BackgroundScanning as we
support
>> a few wireless drivers that experience disruption to the connection when
scanning
>> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
>> reports of users unable to find any WiFi networks.
>
> What you need is to disable specifically what I explained as
> Background-Scan for roaming proposes.
>
> Here we could think to divide "BackgroundScanning" into two different
> properties, one for Background-Scan another for Auto-Scan. What do
> people think?
Not sure how to address this. I personally get confused by the terms background
scan and auto scan. The name 'auto' and 'background' are like synonyms in
my ears.
I know, it is indeed confusing.
Furthermore, we should be careful to add main.conf config options
which are
wpa_supplicant specific. We had this discussion already for other scenarios.
Adding low level config options it to main section of main.conf should be
avoided if you ask me. We have already a bunch of them.
The only idea I have so far to allow low-level plugin specific configuration
files. We would need to move of the connnman_config_*() bits around to the
public header files. Then plugins could use such function as:
char *__connman_config_get_string(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
char **__connman_config_get_string_list(GKeyFile *key_file,
const char *group_name, const char *key, gsize *length, GError **error);
bool __connman_config_get_bool(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
The reason why I suggest to allow plugins to open the keyfiles directly is that
I don't want to read all config data in the core and then pass it to
the plugin.
Sorry this is slightly detour but I think we could make use of these
changes to factor out the wpa_supplicant config hell from main.conf.
Got it and I think you are completely right, let's keep wpa_supplicant
configuration far away from there.
Well, what we could do is to restrict the behavior of
"BackgroundScanning" to exactly how it is described in main.conf thus
only auto-scan when we are not connected. If one wants to keep
autoscan enabled and only disable background scanning for roaming
because of issues like Sam's one then one should only keep
"CONFIG_BGSCAN_SIMPLE=y" commented (As is done by default) in .config
of wpa_supplicant and there should not be need of touch main.conf at
all.
Sam, could you please try following patch, keep BackgroundScanning =
true and keep CONFIG_BGSCAN_SIMPLE=y commented for wpa_s? It should
work in your case.
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16dfd4486..193267d9f398 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2083,8 +2083,7 @@ static void ssid_init(GSupplicantSSID *ssid,
struct connman_network *network)
ssid->use_wps = connman_network_get_bool(network, "WiFi.UseWPS");
ssid->pin_wps = connman_network_get_string(network, "WiFi.PinWPS");
- if (connman_setting_get_bool("BackgroundScanning"))
- ssid->bgscan = BGSCAN_DEFAULT;
+ ssid->bgscan = BGSCAN_DEFAULT;
}
static int network_connect(struct connman_network *network)
Regards,
Jose Blanquicet
3:35 a.m.
Hi
I added Jose to the list. He did some larger work in the recent days and
might have an idea where the problem is.
On 08/08/2017 05:10 PM, Jonah Petri wrote:
Hello,
I want to report an issue with connman. We set BackgroundScanning = false in main.conf.
However, I have found that this also causes connman to give an erroneous empty response to
the Scan() dbus call, potentially permanently disabling the device.
The key preconditions seem to be:
1) wpa_supplicant reports a max_ssids > 1
2) the computer must have been previously associated to a SSID which is no longer visible
'previously asscioated' is from a previous run? ConnMan has been
restarted but not wpa_supplicant? Or the whole box has been restarted?
3) as above, BackgroundScanning must be set to false
This causes the logic of wifi.c:wifi_scan() to fail. In particular:
1) wifi_scan_simple is not used, due to the above preconditions.
2) connman requests an active scan via wpa_supplicant for the ssids returned by
get_latest_connections.
3) connman does not request a followup passive scan, as BackgroundScanning is turned off,
which causes start_autoscan() to exit early.
autoscan is supposed to emulate the background scanning in ConnMan.
According the following comment it should even be removed eventually:
/**
* Used for autoscan "emulation".
* Should be removed when wpa_s autoscan support will be by default.
*/
struct autoscan_params {
int base;
int limit;
int interval;
unsigned int timeout;
};
But it looks like it also used for the active scanning these days. If
this true maybe the following patch might help (shot into the dark):
From 6cff224046d80c71ad65eee3d2aae8cb8c22e4b5 Mon Sep 17 00:00:00 2001
From: Daniel Wagner <wagi(a)monom.org>
Date: Wed, 9 Aug 2017 12:30:08 +0200
Subject: [PATCH] wifi: Setup autoscan independent of BackgroundScanning
The autoscan infrastructre is used to do active scan these
days. Because we don't initialize the default values for the algorithm
when BackgroundScanning is set to false, the autoscan algorithm wont
run at all (start_autoscan() checks for valid parameters).
Reported by Jonah Petri <jonah(a)sense.com>.
---
plugins/wifi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16dfd4486..d351ac0f0c9a 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1442,8 +1442,6 @@ static void setup_autoscan(struct wifi_data *wifi)
{
if (!wifi->autoscan)
wifi->autoscan = parse_autoscan_params(AUTOSCAN_DEFAULT);
-
- start_autoscan(wifi->device);
}
static void finalize_interface_creation(struct wifi_data *wifi)
@@ -1457,13 +1455,15 @@ static void finalize_interface_creation(struct
wifi_data *wifi)
connman_device_set_powered(wifi->device, true);
+ setup_autoscan(wifi);
+
if (!connman_setting_get_bool("BackgroundScanning"))
return;
if (wifi->p2p_device)
return;
- setup_autoscan(wifi);
+ start_autoscan(wifi->device);
}
static void interface_create_callback(int result,
--
2.9.4
7:24 a.m.
Hi Daniel,
Thanks for having a look. Comments below.
On Aug 9, 2017, at 6:35 AM, Daniel Wagner <wagi(a)monom.org>
wrote:
Hi
I added Jose to the list. He did some larger work in the recent days and might have an
idea where the problem is.
On 08/08/2017 05:10 PM, Jonah Petri wrote:
> Hello,
> I want to report an issue with connman. We set BackgroundScanning = false in
main.conf. However, I have found that this also causes connman to give an erroneous empty
response to the Scan() dbus call, potentially permanently disabling the device.
> The key preconditions seem to be:
> 1) wpa_supplicant reports a max_ssids > 1
> 2) the computer must have been previously associated to a SSID which is no longer
visible
'previously asscioated' is from a previous run? ConnMan has been restarted but
not wpa_supplicant? Or the whole box has been restarted?
In my case, the whole box has been restarted. But, from code examination, if
get_latest_connections() doesn't return empty, then the #2 precondition is satisfied.
I'm not sure all the ways that could become the case, but at least the following
works: associating with a network, unplugging the device, unplugging the AP, then booting
the device.
> 3) as above, BackgroundScanning must be set to false
> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
> 1) wifi_scan_simple is not used, due to the above preconditions.
> 2) connman requests an active scan via wpa_supplicant for the ssids returned by
get_latest_connections.
> 3) connman does not request a followup passive scan, as BackgroundScanning is turned
off, which causes start_autoscan() to exit early.
autoscan is supposed to emulate the background scanning in ConnMan. According the
following comment it should even be removed eventually:
/**
* Used for autoscan "emulation".
* Should be removed when wpa_s autoscan support will be by default.
*/
struct autoscan_params {
int base;
int limit;
int interval;
unsigned int timeout;
};
But it looks like it also used for the active scanning these days. If this true maybe the
following patch might help (shot into the dark):
Thanks! I see what you're doing there. Isn't that change equivalent to always
setting BackgroundScanning to true? If so, that doesn't seem like the right thing.
Better to deprecate and ignore BackgroundScanning, I would think. I'll await
Jose's comments as well.
Best,
Jonah
8:20 a.m.
On 08/09/2017 04:24 PM, Jonah Petri wrote:
Hi Daniel,
Thanks for having a look. Comments below.
> On Aug 9, 2017, at 6:35 AM, Daniel Wagner <wagi(a)monom.org> wrote:
>
> Hi
>
> I added Jose to the list. He did some larger work in the recent days and might have
an idea where the problem is.
>
> On 08/08/2017 05:10 PM, Jonah Petri wrote:
>> Hello,
>> I want to report an issue with connman. We set BackgroundScanning = false in
main.conf. However, I have found that this also causes connman to give an erroneous empty
response to the Scan() dbus call, potentially permanently disabling the device.
>> The key preconditions seem to be:
>> 1) wpa_supplicant reports a max_ssids > 1
>> 2) the computer must have been previously associated to a SSID which is no longer
visible
>
> 'previously asscioated' is from a previous run? ConnMan has been restarted
but not wpa_supplicant? Or the whole box has been restarted?
In my case, the whole box has been restarted. But, from code examination, if
get_latest_connections() doesn't return empty, then the #2 precondition is satisfied.
I'm not sure all the ways that could become the case, but at least the following
works: associating with a network, unplugging the device, unplugging the AP, then booting
the device.
Okay, the state (already connected to some network) is preserved
somewhere persistently.
>> 3) as above, BackgroundScanning must be set to false
>> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
>> 1) wifi_scan_simple is not used, due to the above preconditions.
>> 2) connman requests an active scan via wpa_supplicant for the ssids returned by
get_latest_connections.
>> 3) connman does not request a followup passive scan, as BackgroundScanning is
turned off, which causes start_autoscan() to exit early.
>
> autoscan is supposed to emulate the background scanning in ConnMan. According the
following comment it should even be removed eventually:
>
> /**
> * Used for autoscan "emulation".
> * Should be removed when wpa_s autoscan support will be by default.
> */
> struct autoscan_params {
> int base;
> int limit;
> int interval;
> unsigned int timeout;
> };
>
> But it looks like it also used for the active scanning these days. If this true maybe
the following patch might help (shot into the dark):
>
Thanks! I see what you're doing there. Isn't that change equivalent to always
setting BackgroundScanning to true? If so, that doesn't seem like the right thing.
Better to deprecate and ignore BackgroundScanning, I would think. I'll await
Jose's comments as well.
Yeah, quite likely that my patch is not working. It should not be labled
as PATCH, FAIL would match it better :)
This code is horrible complex and quite hard to debug. It is a while
since I looked at this code. I am still wondering how the active scan is
supposed to work here.
Thanks,
Daniel
9:58 a.m.
Hi,
On Wed, Aug 9, 2017 at 3:20 PM, Daniel Wagner <wagi(a)monom.org> wrote:
On 08/09/2017 04:24 PM, Jonah Petri wrote:
>
> Hi Daniel,
>
> Thanks for having a look. Comments below.
>
>> On Aug 9, 2017, at 6:35 AM, Daniel Wagner <wagi(a)monom.org> wrote:
>>
>> Hi
>>
>> I added Jose to the list. He did some larger work in the recent days and
>> might have an idea where the problem is.
>>
>> On 08/08/2017 05:10 PM, Jonah Petri wrote:
>>>
>>> Hello,
>>> I want to report an issue with connman. We set BackgroundScanning =
>>> false in main.conf. However, I have found that this also causes connman to
>>> give an erroneous empty response to the Scan() dbus call, potentially
>>> permanently disabling the device.
>>> The key preconditions seem to be:
>>> 1) wpa_supplicant reports a max_ssids > 1
>>> 2) the computer must have been previously associated to a SSID which is
>>> no longer visible
>>
>>
>> 'previously asscioated' is from a previous run? ConnMan has been
>> restarted but not wpa_supplicant? Or the whole box has been restarted?
>
>
> In my case, the whole box has been restarted. But, from code examination,
> if get_latest_connections() doesn't return empty, then the #2 precondition
> is satisfied. I'm not sure all the ways that could become the case, but at
> least the following works: associating with a network, unplugging the
> device, unplugging the AP, then booting the device.
Okay, the state (already connected to some network) is preserved somewhere
persistently.
>>>
>>> 3) as above, BackgroundScanning must be set to false
>>> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
>>> 1) wifi_scan_simple is not used, due to the above preconditions.
>>> 2) connman requests an active scan via wpa_supplicant for the ssids
>>> returned by get_latest_connections.
>>> 3) connman does not request a followup passive scan, as
>>> BackgroundScanning is turned off, which causes start_autoscan() to exit
>>> early.
>>
>>
>> autoscan is supposed to emulate the background scanning in ConnMan.
>> According the following comment it should even be removed eventually:
>>
>> /**
>> * Used for autoscan "emulation".
>> * Should be removed when wpa_s autoscan support will be by default.
>> */
>> struct autoscan_params {
>> int base;
>> int limit;
>> int interval;
>> unsigned int timeout;
>> };
>>
>> But it looks like it also used for the active scanning these days. If
>> this true maybe the following patch might help (shot into the dark):
>>
>
> Thanks! I see what you're doing there. Isn't that change equivalent to
> always setting BackgroundScanning to true? If so, that doesn't seem like
> the right thing. Better to deprecate and ignore BackgroundScanning, I would
> think. I'll await Jose's comments as well.
Yeah, quite likely that my patch is not working. It should not be labled as
PATCH, FAIL would match it better :)
This code is horrible complex and quite hard to debug. It is a while since I
looked at this code. I am still wondering how the active scan is supposed to
work here.
I will try to have a look at this tomorrow. I think I know what is
going on here, or at least I could help you to understand what is
happening.
Best regards,
Jose Blanquicet
10:01 a.m.
On 08/09/2017 06:58 PM, Jose Blanquicet wrote:
> This code is horrible complex and quite hard to debug. It is a
while since I
> looked at this code. I am still wondering how the active scan is supposed to
> work here.
I will try to have a look at this tomorrow. I think I know what is
going on here, or at least I could help you to understand what is
happening.
Excellent! Thank a lot!
cheers,
Daniel
1:19 a.m.
Good morning,
On Wed, Aug 9, 2017 at 3:20 PM, Daniel Wagner <wagi(a)monom.org> wrote:
>>> I want to report an issue with connman. We set
BackgroundScanning =
>>> false in main.conf. However, I have found that this also causes connman to
>>> give an erroneous empty response to the Scan() dbus call, potentially
>>> permanently disabling the device.
First of all, I think we need to clarify the differences between
Background-Scan (Roaming) and Auto-Scan. Background-Scan is a
parameter used to ask wpa_supplicant to perform background scans when
we are connected for the purpose of roaming within an ESS, i.e. within
a single network block with all the APs using the same SSID. You also
need to have defined CONFIG_BGSCAN_SIMPLE=y in .config before
compiling wpa_supplicant to enable this. On the other hand, Auto-Scan
is indeed what is described in the main.conf as "BackgroundScanning"
property and takes place when we are NOT connected:
"... Background scanning will start every 5 minutes unless the scan
list is empty. In that case, a simple backoff mechanism starting from
10s up to 5 minutes will run."
However, "BackgroundScanning" property is used to enable/disable both
features Background-Scan and Auto-Scan thus it creates confusion:
52efb07a99e5 ('wifi: Specify bgscan parameters according to main.conf settings')
616abe0abcbe ('wifi: Setup autoscan according to the main.conf settings')
It is important also to remark that the mentioned backoff mechanism is
only triggered after a Technology.Scan(). It is not true such
mechanism is triggered when scan list is empty, if
"BackgroundScanning" is disabled then the scan list will remain empty
until you actively perform a Scan(), instead if you enable it the
backoff mechanism will take place. This could be Jonah's problem.
>>> The key preconditions seem to be:
>>> 1) wpa_supplicant reports a max_ssids > 1
This value is directly reported by your WiFi driver and could be 0 or
greater than 2 according to what was done in 6af0579c4340
('gsupplicant: Return zero for max scan SSID parameter').
>>> 2) the computer must have been previously associated to a
SSID which is
>>> no longer visible
>>
>>
>> 'previously asscioated' is from a previous run? ConnMan has been
>> restarted but not wpa_supplicant? Or the whole box has been restarted?
>
>
> In my case, the whole box has been restarted. But, from code examination,
> if get_latest_connections() doesn't return empty, then the #2 precondition
> is satisfied. I'm not sure all the ways that could become the case, but at
> least the following works: associating with a network, unplugging the
> device, unplugging the AP, then booting the device.
Okay, the state (already connected to some network) is preserved somewhere
persistently.
Yeah, get_latest_connections() reads the information of the latest
connections from folders {STOREDIR}/connman/wifi_* and those are
indeed persistent. Therefore, this condition is satisfied once you
have got connected to one WiFi network since you have installed
ConnMan.
>>> 3) as above, BackgroundScanning must be set to false
>>> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
>>> 1) wifi_scan_simple is not used, due to the above preconditions.
>>> 2) connman requests an active scan via wpa_supplicant for the ssids
>>> returned by get_latest_connections.
>>> 3) connman does not request a followup passive scan, as
>>> BackgroundScanning is turned off, which causes start_autoscan() to exit
>>> early.
So far I can follow you.
>>> This means that in the scenario above, connman will never
see any wifi networks. Scan() will always return an empty list, even if other SSIDs are
available. This is potentially fatal for embedded systems, so in my view this is a very
serious issue.
I could not reproduce this or at least not what I understood you are
suffering. From 802.11-2012 std: "Active scanning involves the
generation of Probe request frames and the subsequent processing of
received Probe Response frames" and from what I understood it should
not affect the results of the scanning, you should get the same
results.
The question here is: if you perform a D-Bus call for
Technology.Scan() from your client (Or connmanclt) you do not get any
service as result or instead what you mean is that when you call
Manger.GetServices() you do not get any service? Because these two
things are very different according to what I explained at the
beginning: If you disable "BackgroundScanning" and you do not actively
make a Technology.Scan() call, the service list after a while will be
empty and will remains so until you ask for another scan.
Best regards,
Jose Blanquicet
7:51 a.m.
Hello!
On Aug 10, 2017, at 4:19 AM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
Good morning,
On Wed, Aug 9, 2017 at 3:20 PM, Daniel Wagner <wagi(a)monom.org> wrote:
>>>> I want to report an issue with connman. We set BackgroundScanning =
>>>> false in main.conf. However, I have found that this also causes connman
to
>>>> give an erroneous empty response to the Scan() dbus call, potentially
>>>> permanently disabling the device.
First of all, I think we need to clarify the differences between
Background-Scan (Roaming) and Auto-Scan. Background-Scan is a
parameter used to ask wpa_supplicant to perform background scans when
we are connected for the purpose of roaming within an ESS, i.e. within
a single network block with all the APs using the same SSID. You also
need to have defined CONFIG_BGSCAN_SIMPLE=y in .config before
compiling wpa_supplicant to enable this. On the other hand, Auto-Scan
is indeed what is described in the main.conf as "BackgroundScanning"
property and takes place when we are NOT connected:
"... Background scanning will start every 5 minutes unless the scan
list is empty. In that case, a simple backoff mechanism starting from
10s up to 5 minutes will run."
However, "BackgroundScanning" property is used to enable/disable both
features Background-Scan and Auto-Scan thus it creates confusion:
52efb07a99e5 ('wifi: Specify bgscan parameters according to main.conf settings')
616abe0abcbe ('wifi: Setup autoscan according to the main.conf settings')
It is important also to remark that the mentioned backoff mechanism is
only triggered after a Technology.Scan(). It is not true such
mechanism is triggered when scan list is empty, if
"BackgroundScanning" is disabled then the scan list will remain empty
until you actively perform a Scan(), instead if you enable it the
backoff mechanism will take place. This could be Jonah's problem.
This is really great info to have. Thanks!
I am definitely performing a Scan() request, and the active scan request is being sent to
wpa_supplicant, but the result list is still empty. See below for dbus logs.
>>>> The key preconditions seem to be:
>>>> 1) wpa_supplicant reports a max_ssids > 1
This value is directly reported by your WiFi driver and could be 0 or
greater than 2 according to what was done in 6af0579c4340
('gsupplicant: Return zero for max scan SSID parameter').
>>>> 3) as above, BackgroundScanning must be set to false
>>>> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
>>>> 1) wifi_scan_simple is not used, due to the above preconditions.
>>>> 2) connman requests an active scan via wpa_supplicant for the ssids
>>>> returned by get_latest_connections.
>>>> 3) connman does not request a followup passive scan, as
>>>> BackgroundScanning is turned off, which causes start_autoscan() to exit
>>>> early.
So far I can follow you.
>>>> This means that in the scenario above, connman will never see any wifi
networks. Scan() will always return an empty list, even if other SSIDs are available.
This is potentially fatal for embedded systems, so in my view this is a very serious
issue.
I could not reproduce this or at least not what I understood you are
suffering. From 802.11-2012 std: "Active scanning involves the
generation of Probe request frames and the subsequent processing of
received Probe Response frames" and from what I understood it should
not affect the results of the scanning, you should get the same
results.
What I see empirically is that with the brcmfmac driver on a bcm 43430 chip, on linux
4.1.15, the max_ssids is reported as 10. I am definitely a novice when it comes to
anything below wpa_supplicant, but could it be that active scan only probes for the
specifically-mentioned networks? From my reading, this active scanning mechanism seems to
be intended for finding specific SSIDs, e.g. hidden SSIDs. However, empirically in my
case, if the MAC can't see the requested network, it does not report any scan results
at all.
The question here is: if you perform a D-Bus call for
Technology.Scan() from your client (Or connmanclt) you do not get any
service as result or instead what you mean is that when you call
Manger.GetServices() you do not get any service? Because these two
things are very different according to what I explained at the
beginning: If you disable "BackgroundScanning" and you do not actively
make a Technology.Scan() call, the service list after a while will be
empty and will remains so until you ask for another scan.
Seemingly both return empty. Setup here is as follows:
* "BackgroundScanning = false" in main.conf
* Create a SSID ('SenseTest' in this case)
* Associate with network via connman
* Halt device
* Unplug SSID's AP
* Boot device
root:~# connmanctl scan wifi
method call time=1478194644.760560 sender=:1.18 -> destination=net.connman serial=2
path=/net/connman/technology/wifi; interface=net.connman.Technology; member=Scan
method call time=1478194644.760745 sender=:1.2 -> destination=fi.w1.wpa_supplicant1
serial=228 path=/fi/w1/wpa_supplicant1/Interfaces/10;
interface=fi.w1.wpa_supplicant1.Interface; member=Scan
array [
dict entry(
string "Type"
variant string "active"
)
dict entry(
string "SSIDs"
variant array [
array of bytes "SenseTest"
]
)
dict entry(
string "Channels"
variant array [
struct {
uint32 2437
uint32 0
}
]
)
]
method return time=1478194644.761180 sender=:1.3 -> destination=:1.2 serial=214
reply_serial=228
signal time=1478194644.800336 sender=:1.3 -> destination=(null destination) serial=215
path=/fi/w1/wpa_supplicant1/Interfaces/10; interface=org.freedesktop.DBus.Properties;
member=PropertiesChanged
string "fi.w1.wpa_supplicant1.Interface"
array [
dict entry(
string "Scanning"
variant boolean true
)
]
array [
]
signal time=1478194644.800806 sender=:1.3 -> destination=(null destination) serial=216
path=/fi/w1/wpa_supplicant1/Interfaces/10; interface=fi.w1.wpa_supplicant1.Interface;
member=PropertiesChanged
array [
dict entry(
string "Scanning"
variant boolean true
)
]
signal time=1478194644.849944 sender=:1.3 -> destination=(null destination) serial=217
path=/fi/w1/wpa_supplicant1/Interfaces/10; interface=fi.w1.wpa_supplicant1.Interface;
member=ScanDone
boolean true
method call time=1478194644.850835 sender=:1.2 -> destination=fi.w1.wpa_supplicant1
serial=229 path=/fi/w1/wpa_supplicant1/Interfaces/10;
interface=org.freedesktop.DBus.Properties; member=Get
string "fi.w1.wpa_supplicant1.Interface"
string "BSSs"
method return time=1478194644.851439 sender=:1.3 -> destination=:1.2 serial=218
reply_serial=229
variant array [
]
signal time=1478194644.851594 sender=:1.3 -> destination=(null destination) serial=219
path=/fi/w1/wpa_supplicant1/Interfaces/10; interface=org.freedesktop.DBus.Properties;
member=PropertiesChanged
string "fi.w1.wpa_supplicant1.Interface"
array [
dict entry(
string "Scanning"
variant boolean false
)
]
array [
]
signal time=1478194644.851968 sender=:1.3 -> destination=(null destination) serial=220
path=/fi/w1/wpa_supplicant1/Interfaces/10; interface=fi.w1.wpa_supplicant1.Interface;
member=PropertiesChanged
array [
dict entry(
string "Scanning"
variant boolean false
)
]
Scan completed for wifi
A few things to note on that sequence:
* As expected from the code, there is a SSID returned by get_latest_connections(), and
max_ssids = 10, thus an active scan is performed.
* The result is empty.
* There is no followup passive scan.
* Additionally, connmanctl reports an empty services list afterwards:
root@:~# connmanctl services
root@:~#
My 2¢: If "Active" scanning will indeed only return results for the SSIDs
mentioned in the scan parameters, then I think connman should *always* schedule a passive
scan afterwards, perhaps by just calling wifi_scan_simple() in the scan_callback() of an
active scan.
Thoughts?
Jonah
11:43 p.m.
Good morning Jonah,
I think I got something.
On Thu, Aug 10, 2017 at 4:51 PM, Jonah Petri <jonah(a)sense.com> wrote:
What I see empirically is that with the brcmfmac driver on a bcm
43430
chip, on linux 4.1.15, the max_ssids is reported as 10. I am definitely a
novice when it comes to anything below wpa_supplicant, but could it be that
active scan only probes for the specifically-mentioned networks? From my
reading, this active scanning mechanism seems to be intended for finding
specific SSIDs, e.g. hidden SSIDs. However, empirically in my case, if the
MAC can't see the requested network, it does not report any scan results at
all.
I missed something here. In active scan request we are asking
wpa_supplicant to look for specific SSIDs in specific channels. In my case,
I had a lot of "known-services" then basically the active request includes
a lot of channels and that's what I continue seeing many APs in range. To
confirm this theory, I let only one folder in {STOREDIR}/connman/wifi_* and
I modified the settings file of that remaining services by changing the
frequency to a 5GHz channel. Then I forced ConnMan to handle only an
interface which I know only supports 2.4GHz. Doing so ConnMan would ask an
active scan only in that 5GHz channel and then the scan result should be
empty. The results confirmed this idea and I could reproduce this issue,
scan list was empty.
So, according to the your dbus logs, there should not exist any AP using
2437 in your range, is it true? Try to do what I did and modify the
settings file of your "known-service" to a frequency you are sure there are
APs in your range. Doing so you should be able see them now. Remember to
kill ConnMan before modifying that settings file then re-launch ConnMan or
just reboot your system to get the changes applied.
My 2¢: If "Active" scanning will indeed only return results
for the SSIDs
mentioned in the scan parameters, then I think ConnMan should
*always*
schedule a passive scan afterwards, perhaps by just calling
wifi_scan_simple() in the scan_callback() of an active scan.
Thoughts?
That sounds reasonable. You should just take into account the timing, you
cannot immediately ask wpa_supplicant for another scan because it could
just be discarded due to there is another ongoing. That second passive scan
needs to be done once you are sure the active scan has finished. You could
try to implement this, I will think if this is the best we can do. Then we
can test and discuss the options.
As always comments/suggestions are welcomed.
Regards,
Jose Blanquicet
7:24 a.m.
Good morning, Jose!
Thanks for checking into this.
On Aug 11, 2017, at 2:43 AM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
]So, according to the your dbus logs, there should not exist any AP using 2437 in your
range, is it true? Try to do what I did and modify the settings file of your
"known-service" to a frequency you are sure there are APs in your range. Doing
so you should be able see them now. Remember to kill ConnMan before modifying that
settings file then re-launch ConnMan or just reboot your system to get the changes
applied.
There are 6 other networks using 2437 in range. I am in a downtown area with LOTS of APs.
So that's not it.
> My 2¢: If "Active" scanning will indeed only return
results for the SSIDs mentioned in the scan parameters, then I think ConnMan should
*always* schedule a passive scan afterwards, perhaps by just calling wifi_scan_simple() in
the scan_callback() of an active scan.
>
> Thoughts?
That sounds reasonable. You should just take into account the timing, you cannot
immediately ask wpa_supplicant for another scan because it could just be discarded due to
there is another ongoing. That second passive scan needs to be done once you are sure the
active scan has finished. You could try to implement this, I will think if this is the
best we can do. Then we can test and discuss the options.
Can you say more about the expected behavior of wpa_supplicant? The wpa_s dbus docs say
nothing about scans being ignored, so now I'm worried that I can't trust them.
https://w1.fi/wpa_supplicant/devel/dbus.html
<https://w1.fi/wpa_supplicant/devel/dbus.html>
Best,
Jonah
11:37 p.m.
Good morning,
Sorry the delay, I was out of office.
On Fri, Aug 11, 2017 at 4:24 PM, Jonah Petri <jonah(a)sense.com> wrote:
On Aug 11, 2017, at 2:43 AM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
]So, according to the your dbus logs, there should not exist any AP using
2437 in your range, is it true? Try to do what I did and modify the
settings
file of your "known-service" to a frequency you are sure
there are APs in
your range. Doing so you should be able see them now. Remember to kill
ConnMan before modifying that settings file then re-launch ConnMan or just
reboot your system to get the changes applied.
There are 6 other networks using 2437 in range. I am in a downtown area
with LOTS of APs. So that's not it.
I cannot reproduce exactly what you are suffering and unfortunately I am
not sure what precisely is the correct driver's behaviour. What your driver
replies is different than what I am seeing here. I recreated the scenario
you described with the following results:
* "MaxScanSSID" = 4, reported from wpa_supplicant
* "BackgroundScanning = false" in main.conf
* Connect to a WiFi Network
* Turn off AP
* Reboot device
When system is up again, after doing "connmanctl scan wifi":
method call sender=:1.67 -> dest=net.connman serial=9
path=/net/connman/technology/wifi; interface=net.connman.Technology;
member=Scan
method call sender=:1.65 -> dest=fi.w1.wpa_supplicant1 serial=62
path=/fi/w1/wpa_supplicant1/Interfaces/11;
interface=fi.w1.wpa_supplicant1.Interface; member=Scan
array [
dict entry(
string "Type"
variant string "active"
)
dict entry(
string "SSIDs"
variant array [
array of bytes "Testing-AP"
array of bytes "Colombian-AP"
...
]
)
dict entry(
string "Channels"
variant array [
struct {
uint32 2437
uint32 0
}
struct {
uint32 2462
uint32 0
}
]
)
]
Next, I can see the signals "PropertiesChanged" with (Scanning -> true),
some "BSSAdded" and then the "ScanDone". After that I see:
method call sender=:1.65 -> dest=fi.w1.wpa_supplicant1 serial=67
path=/fi/w1/wpa_supplicant1/Interfaces/11;
interface=org.freedesktop.DBus.Properties; member=Get
string "fi.w1.wpa_supplicant1.Interface"
string "BSSs"
method return sender=:1.44 -> dest=:1.65 reply_serial=67
variant array [
object path "/fi/w1/wpa_supplicant1/Interfaces/11/BSSs/0"
object path "/fi/w1/wpa_supplicant1/Interfaces/11/BSSs/1"
object path "/fi/w1/wpa_supplicant1/Interfaces/11/BSSs/2"
object path "/fi/w1/wpa_supplicant1/Interfaces/11/BSSs/3"
]
Where all those BSSs use only frequencies 2437 or 2462. That's what I asked
you if there were not more APs in range using 2437, according to your dbus
logs.
In any case, we need to be prepared for all driver's behaviour. So, let's
try to solve this.
> My 2¢: If "Active" scanning will indeed only return
results for the SSIDs
> mentioned in the scan parameters, then I think ConnMan should *always*
> schedule a passive scan afterwards, perhaps by just calling
> wifi_scan_simple() in the scan_callback() of an active scan.
>
> Thoughts?
That sounds reasonable. You should just take into account the timing, you
cannot immediately ask wpa_supplicant for another scan because it could
just
be discarded due to there is another ongoing. That second passive
scan
needs
to be done once you are sure the active scan has finished. You could
try
to
implement this, I will think if this is the best we can do. Then we
can
test
and discuss the options.
I was thinking and maybe this is not the best way to solve this issue.
The active scan is useful in order to perform a fast scan looking for the
WiFi networks we have got connected in the past. I think this is
particularly helpful to speed up auto-connect procedure at the start-up of
the system. Instead, when user asks for scanning I think it should always
be a passive scan because users want to see all WiFi networks available in
range. Therefore, I propose to make ConnMan ask wpa_supplicant for an
active scan only at star-up of the system and passive scan when it is
directly asked from users through a Technology.Scan() D-Bus call. Both
things no matter BackgroundScanning's value.
What do all you think?
Regards,
Jose Blanquicet
10:33 a.m.
Hi Jose,
On Aug 17, 2017, at 2:37 AM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
>> My 2¢: If "Active" scanning will indeed only return results for the
SSIDs
>> mentioned in the scan parameters, then I think ConnMan should *always*
>> schedule a passive scan afterwards, perhaps by just calling
>> wifi_scan_simple() in the scan_callback() of an active scan.
>>
>> Thoughts?
>
> That sounds reasonable. You should just take into account the timing, you
> cannot immediately ask wpa_supplicant for another scan because it could just
> be discarded due to there is another ongoing. That second passive scan needs
> to be done once you are sure the active scan has finished. You could try to
> implement this, I will think if this is the best we can do. Then we can test
> and discuss the options.
I was thinking and maybe this is not the best way to solve this issue.
The active scan is useful in order to perform a fast scan looking for the WiFi networks
we have got connected in the past. I think this is particularly helpful to speed up
auto-connect procedure at the start-up of the system. Instead, when user asks for scanning
I think it should always be a passive scan because users want to see all WiFi networks
available in range. Therefore, I propose to make ConnMan ask wpa_supplicant for an active
scan only at star-up of the system and passive scan when it is directly asked from users
through a Technology.Scan() D-Bus call. Both things no matter BackgroundScanning's
value.
What do all you think?
(Now it was my turn to be on vacation! Sorry for the delay.)
Great idea. This is fine for my use case, and the behavior you propose is what I expected
given what Technology.Scan() claims to do.
Jonah
7:48 a.m.
Hi,
On Thu, Aug 24, 2017 at 7:33 PM, Jonah Petri <jonah(a)sense.com> wrote:
> The active scan is useful in order to perform a fast scan looking
for the WiFi networks we have got connected in the past. I think this is particularly
helpful to speed up auto-connect procedure at the start-up of the system. Instead, when
user asks for scanning I think it should always be a passive scan because users want to
see all WiFi networks available in range. Therefore, I propose to make ConnMan ask
wpa_supplicant for an active scan only at star-up of the system and passive scan when it
is directly asked from users through a Technology.Scan() D-Bus call. Both things no matter
BackgroundScanning's value.
>
> What do all you think?
>
(Now it was my turn to be on vacation! Sorry for the delay.)
Don't worry, welcome back!
Great idea. This is fine for my use case, and the behaviour you
propose is what I expected given what Technology.Scan() claims to do.
Well, the scan algorithm is quite complex but I think I finally
understood how it works and there is something we should change from
this idea.
We can resume our scenario as following:
* WiFi Driver support active scanning, it means "MaxScanSSID" is greater than
1.
* User has successfully connected to at least one WiFi network in the
past so the service's information is present in
{STOREDIR}/connman/wifi_* but none of those networks are currently in
range, let's call them "known-services".
Under these assumptions, when user asks for scanning the algorithm
will perform an active scan looking for those known-services in their
specific frequencies, this kind of scanning is generally faster than a
passive one which allows to speed up auto-connection procedure.
However, we have seen that some drivers reply with all the networks in
the specified frequencies and some other does not reply any network.
From this point forward, the behaviour changes based on
"BackgroundScanning" value:
* Enabled: A simple backoff mechanism starting from 10s up to 5
minutes will run. Of course, using passive scan thus at the end driver
will reply with all networks in range, as user expects after scanning.
* Disabled: Nothing else is done. Any additional scan will be
executed, resulting in a possible empty scan results forever, Johan's
case.
In my initial idea I proposed to perform passive scan, no matter the
BackgroundScanning value, when user performs a Scan() D-Bus call to
ensure all networks are found. However, while trying to implement it
and due to the reasons I explained before, I realized that it could
also increase the auto-connection procedure with the default ConnMan's
configuration, i.e. BackgroundScanning enabled. Therefore, I am now
limiting this change to users who manually disabled
BackgroundScanning.
Patrik, Daniel, what do you think?
Jonah, please test this patch:
diff --git a/include/device.h b/include/device.h
index 9ac800a..5375a3a 100644
--- a/include/device.h
+++ b/include/device.h
@@ -120,7 +120,7 @@ struct connman_device_driver {
int (*enable) (struct connman_device *device);
int (*disable) (struct connman_device *device);
int (*scan)(enum connman_service_type type,
- struct connman_device *device,
+ struct connman_device *device, bool requested,
const char *ssid, unsigned int ssid_len,
const char *identity, const char* passphrase,
const char *security, void *user_data);
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16df..0b3ee28 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1784,7 +1784,7 @@ static int p2p_find(struct connman_device *device)
* hidden AP first time. It is not used when system autoconnects to hidden AP.
*/
static int wifi_scan(enum connman_service_type type,
- struct connman_device *device,
+ struct connman_device *device, bool requested,
const char *ssid, unsigned int ssid_len,
const char *identity, const char* passphrase,
const char *security, void *user_data)
@@ -1876,7 +1876,8 @@ static int wifi_scan(enum connman_service_type type,
return 0;
}
- } else if (wifi->connected) {
+ } else if ((requested &&
!connman_setting_get_bool("BackgroundScanning")) ||
+ wifi->connected) {
g_supplicant_free_scan_params(scan_params);
return wifi_scan_simple(device);
} else {
diff --git a/src/device.c b/src/device.c
index a563f46..8bdf828 100644
--- a/src/device.c
+++ b/src/device.c
@@ -591,7 +591,7 @@ int connman_device_set_powered(struct
connman_device *device,
if (device->driver && device->driver->scan)
device->driver->scan(CONNMAN_SERVICE_TYPE_UNKNOWN, device,
- NULL, 0, NULL, NULL, NULL, NULL);
+ false, NULL, 0, NULL, NULL, NULL, NULL);
return 0;
}
@@ -610,7 +610,7 @@ static int device_scan(enum connman_service_type type,
if (!device->powered)
return -ENOLINK;
- return device->driver->scan(type, device, NULL, 0,
+ return device->driver->scan(type, device, true, NULL, 0,
NULL, NULL, NULL, NULL);
}
@@ -1104,7 +1104,7 @@ int __connman_device_request_hidden_scan(struct
connman_device *device,
return -EINVAL;
return device->driver->scan(CONNMAN_SERVICE_TYPE_UNKNOWN,
- device, ssid, ssid_len, identity,
+ device, false, ssid, ssid_len, identity,
passphrase, security, user_data);
}
Best regards,
Jose Blanquicet
7:01 a.m.
Hi Jose,
On Aug 27, 2017, at 10:48 AM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
In my initial idea I proposed to perform passive scan, no matter the
BackgroundScanning value, when user performs a Scan() D-Bus call to
ensure all networks are found. However, while trying to implement it
and due to the reasons I explained before, I realized that it could
also increase the auto-connection procedure with the default ConnMan's
configuration, i.e. BackgroundScanning enabled. Therefore, I am now
limiting this change to users who manually disabled
BackgroundScanning.
Patrik, Daniel, what do you think?
Jonah, please test this patch:
Thanks for your efforts thinking through the code, and getting the patch put together!
I tested the patch you provided, and it does appear to solve the problem as described.
I'll promote that patch into my dev fleet, and let you know if I notice any other bad
behaviors.
Best,
Jonah
12:17 p.m.
Hi Jose,
> On Aug 27, 2017, at 10:48 AM, Jose Blanquicet
<blanquicet(a)gmail.com <mailto:blanquicet@gmail.com>> wrote:
>
> In my initial idea I proposed to perform passive scan, no matter the
> BackgroundScanning value, when user performs a Scan() D-Bus call to
> ensure all networks are found. However, while trying to implement it
> and due to the reasons I explained before, I realized that it could
> also increase the auto-connection procedure with the default ConnMan's
> configuration, i.e. BackgroundScanning enabled. Therefore, I am now
> limiting this change to users who manually disabled
> BackgroundScanning.
>
> Patrik, Daniel, what do you think?
>
> Jonah, please test this patch:
>
Thanks for your efforts thinking through the code, and getting the patch put together!
I tested the patch you provided, and it does appear to solve the problem as described.
I'll promote that patch into my dev fleet, and let you know if I notice any other bad
behaviors.
I tested the patch you posted. While I never saw any dbus-requested scans failing, I did
notice an increase in the number of my dev units falling offline after a reboot. In each
case I've tested, as soon as dbus Scan() was initiated, the previously associated
network was seen and joined. While I haven't looked for exactly where, I am guessing
that there is some hole in the connman startup logic where it needs to request a wpa_s
Passive scan as well.
Perhaps it would be best to always follow an active scan with a passive one? Or perhaps
BackgroundScanning should just be forced to 'true'?
It seems that connman may be depending too much on somewhat undocumented behaviors of
wpa_supplicant and the cfg80211 driver layers, and it's being exposed to these bugs.
I'm curious for your thoughts! For now, I'm reverting to BackgroundScanning =
true.
Best,
Jonah
11:58 a.m.
Hi Jonah,
On Fri, Sep 22, 2017 at 9:17 PM, Jonah Petri <jonah(a)sense.com> wrote:
I tested the patch you provided, and it does appear to solve the
problem as
described. I'll promote that patch into my dev fleet, and let you know if I
notice any other bad behaviors.
I tested the patch you posted. While I never saw any dbus-requested scans
failing, I did notice an increase in the number of my dev units falling
offline after a reboot.
Sorry, I am not sure I got what you mean here :(. Could you please
rephrase this and give me more details?
In each case I've tested, as soon as dbus Scan()
was initiated, the previously associated network was seen and joined. While
I haven't looked for exactly where, I am guessing that there is some hole in
the connman startup logic where it needs to request a wpa_s Passive scan as
well.
I assume you mean that at the start-up you see a D-Bus scan call from
ConnMan to wpa_s and a successive re-connection to a known WiFi
network? If so, yes, that's desired start-up procedure.
Perhaps it would be best to always follow an active scan with a
passive one?
Or perhaps BackgroundScanning should just be forced to 'true'?
Follow an active scan with only one passive scan in case
BackgroundScanning='false' is indeed the best solution. I thought I
would be able to find time to work on that solution but it haven't
yet, it has not been an ease time. This is the idea I have in mind:
Current behaviour with BackgroundScanning='True' is:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
9 seconds -> Launch passive scan
27 seconds -> Launch passive scan
81 seconds -> Launch passive scan
243 seconds -> Launch passive scan
300 seconds -> Launch passive scan
300 seconds -> Launch passive scan
...
Continue each 300 seconds unless you perform a new D-Bus scan call
which will cause the procedure to restart from 3 seconds.
With BackgroundScanning='False' the idea would be:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
Stop. No more scanning: 3 seconds would be enough for ConnMan to
reconnect to a known service in case there is one of them in range.
New D-Bus scan request from user
Launch an active scan
3 seconds -> Launch passive scan
Stop.
It seems that connman may be depending too much on somewhat
undocumented
behaviors of wpa_supplicant and the cfg80211 driver layers, and it's being
exposed to these bugs.
Unfortunately, yes. wpa_s is the current way to communicate with the
WiFi chip thus we have to deal with it. There are a bunch of things
could have been implemented better in wpa_s. For example, this
scanning logic should be something completely managed by the WiFi
daemon and not by ConnMan.
Best regards,
Jose Blanquicet
11:13 a.m.
Hi Jonah,
On Mon, Sep 25, 2017 at 8:58 PM, Jose Blanquicet <blanquicet(a)gmail.com> wrote:
Follow an active scan with only one passive scan in case
BackgroundScanning='false' is indeed the best solution. I thought I
would be able to find time to work on that solution but it haven't
yet, it has not been an ease time. This is the idea I have in mind:
Current behaviour with BackgroundScanning='True' is:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
9 seconds -> Launch passive scan
27 seconds -> Launch passive scan
81 seconds -> Launch passive scan
243 seconds -> Launch passive scan
300 seconds -> Launch passive scan
300 seconds -> Launch passive scan
...
Continue each 300 seconds unless you perform a new D-Bus scan call
which will cause the procedure to restart from 3 seconds.
With BackgroundScanning='False' the idea would be:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
Stop. No more scanning: 3 seconds would be enough for ConnMan to
reconnect to a known service in case there is one of them in range.
New D-Bus scan request from user
Launch an active scan
3 seconds -> Launch passive scan
Stop.
I implemented a patch following above description. In addition, the
patch takes into account that ConnMan will only ask for an active scan
if user has connected to at least one WiFi network in the past and the
WiFi chipset support active scanning. If those conditions are not
true, ConnMan will always ask for a passive scan. Given that:
Current behaviour with BackgroundScanning='True' is:
D-Bus scan request or at start-up of system
Launch a passive scan
3 seconds -> Launch passive scan
..
300 seconds -> Launch passive scan
... Continue each 300 seconds unless you perform a new D-Bus scan call
which will cause the procedure to restart from 3 seconds.
With BackgroundScanning='False' the idea is:
D-Bus scan request or at start-up of system
Launch one passive scan
Stop.
New D-Bus scan request from user
Launch one passive scan
Stop.
I tested the four cases and ConnMan is doing what I described above. I
will keep the patch applied in my systems and I would like to ask
Daniel to do it too in order to check everything continue working as
it should :)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16df..206c05e 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -64,7 +64,8 @@
#define FAVORITE_MAXIMUM_RETRIES 2
#define BGSCAN_DEFAULT "simple:30:-45:300"
-#define AUTOSCAN_DEFAULT "exponential:3:300"
+#define AUTOSCAN_EXPONENTIAL "exponential:3:300"
+#define AUTOSCAN_SINGLE "single:3"
#define P2P_FIND_TIMEOUT 30
#define P2P_CONNECTION_TIMEOUT 100
@@ -83,6 +84,12 @@ enum wifi_ap_capability{
WIFI_AP_NOT_SUPPORTED = 2,
};
+enum wifi_scanning_type {
+ WIFI_SCANNING_UNKNOWN = 0,
+ WIFI_SCANNING_PASSIVE = 1,
+ WIFI_SCANNING_ACTIVE = 2,
+};
+
struct hidden_params {
char ssid[32];
unsigned int ssid_len;
@@ -143,7 +150,7 @@ struct wifi_data {
* autoscan "emulation".
*/
struct autoscan_params *autoscan;
-
+ enum wifi_scanning_type scanning_type;
GSupplicantScanParams *scan_params;
unsigned int p2p_find_timeout;
unsigned int p2p_connection_timeout;
@@ -831,13 +838,13 @@ static void reset_autoscan(struct connman_device *device)
autoscan = wifi->autoscan;
- if (autoscan->timeout == 0 && autoscan->interval == 0)
+ autoscan->interval = 0;
+
+ if (autoscan->timeout == 0)
return;
g_source_remove(autoscan->timeout);
-
autoscan->timeout = 0;
- autoscan->interval = 0;
connman_device_unref(device);
}
@@ -1363,6 +1370,21 @@ static gboolean autoscan_timeout(gpointer data)
throw_wifi_scan(wifi->device, scan_callback_hidden);
+ /*
+ * In case BackgroundScanning is disabled, interval will reach the
+ * limit exactly after the very first passive scanning. It allows
+ * to ensure at most one passive scan is performed in such cases.
+ */
+ if (!connman_setting_get_bool("BackgroundScanning") &&
+ interval == autoscan->limit) {
+ g_source_remove(autoscan->timeout);
+ autoscan->timeout = 0;
+
+ connman_device_unref(device);
+
+ return FALSE;
+ }
+
set_interval:
DBG("interval %d", interval);
@@ -1409,19 +1431,25 @@ static struct autoscan_params
*parse_autoscan_params(const char *params)
int limit;
int base;
- DBG("Emulating autoscan");
+ DBG("");
list_params = g_strsplit(params, ":", 0);
if (list_params == 0)
return NULL;
- if (g_strv_length(list_params) < 3) {
+ if (!g_strcmp0(list_params[0], "exponential") &&
+ g_strv_length(list_params) == 3) {
+ base = atoi(list_params[1]);
+ limit = atoi(list_params[2]);
+ } else if (!g_strcmp0(list_params[0], "single") &&
+ g_strv_length(list_params) == 2)
+ base = limit = atoi(list_params[1]);
+ else {
g_strfreev(list_params);
return NULL;
}
- base = atoi(list_params[1]);
- limit = atoi(list_params[2]);
+ DBG("Setup %s autoscanning", list_params[0]);
g_strfreev(list_params);
@@ -1440,10 +1468,37 @@ static struct autoscan_params
*parse_autoscan_params(const char *params)
static void setup_autoscan(struct wifi_data *wifi)
{
- if (!wifi->autoscan)
- wifi->autoscan = parse_autoscan_params(AUTOSCAN_DEFAULT);
+ /*
+ * If BackgroundScanning is enabled, setup exponential
+ * autoscanning if it has not been previously done.
+ */
+ if (connman_setting_get_bool("BackgroundScanning")) {
+ wifi->autoscan = parse_autoscan_params(AUTOSCAN_EXPONENTIAL);
+ return;
+ }
- start_autoscan(wifi->device);
+ /*
+ * On the contrary, if BackgroundScanning is disabled, update autoscan
+ * parameters based on the type of scanning that is being performed.
+ */
+ if (wifi->autoscan) {
+ g_free(wifi->autoscan);
+ wifi->autoscan = NULL;
+ }
+
+ switch (wifi->scanning_type) {
+ case WIFI_SCANNING_PASSIVE:
+ /* Do not setup autoscan. */
+ break;
+ case WIFI_SCANNING_ACTIVE:
+ /* Setup one single passive scan after active. */
+ wifi->autoscan = parse_autoscan_params(AUTOSCAN_SINGLE);
+ break;
+ case WIFI_SCANNING_UNKNOWN:
+ /* Setup autoscan in this case but we should never fall here. */
+ wifi->autoscan = parse_autoscan_params(AUTOSCAN_SINGLE);
+ break;
+ }
}
static void finalize_interface_creation(struct wifi_data *wifi)
@@ -1457,13 +1512,13 @@ static void finalize_interface_creation(struct
wifi_data *wifi)
connman_device_set_powered(wifi->device, true);
- if (!connman_setting_get_bool("BackgroundScanning"))
- return;
-
if (wifi->p2p_device)
return;
- setup_autoscan(wifi);
+ if (!wifi->autoscan)
+ setup_autoscan(wifi);
+
+ start_autoscan(wifi->device);
}
static void interface_create_callback(int result,
@@ -1691,10 +1746,29 @@ static int get_latest_connections(int max_ssids,
return num_ssids;
}
+static void wifi_update_scanner_type(struct wifi_data *wifi,
+ enum wifi_scanning_type new_type)
+{
+ DBG("");
+
+ if (!wifi || wifi->scanning_type == new_type)
+ return;
+
+ wifi->scanning_type = new_type;
+
+ setup_autoscan(wifi);
+}
+
static int wifi_scan_simple(struct connman_device *device)
{
+ struct wifi_data *wifi = connman_device_get_data(device);
+
reset_autoscan(device);
+ /* Distinguish between devices performing passive and active scanning */
+ if (wifi)
+ wifi_update_scanner_type(wifi, WIFI_SCANNING_PASSIVE);
+
return throw_wifi_scan(device, scan_callback_hidden);
}
@@ -1887,6 +1961,9 @@ static int wifi_scan(enum connman_service_type type,
}
}
+ /* Distinguish between devices performing passive and active scanning */
+ wifi_update_scanner_type(wifi, WIFI_SCANNING_ACTIVE);
+
connman_device_ref(device);
reset_autoscan(device);
Thanks,
Jose Blanquicet
5:14 p.m.
Jose,
On Oct 1, 2017, at 2:13 PM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
Hi Jonah,
I implemented a patch following above description. In addition, the
patch takes into account that ConnMan will only ask for an active scan
if user has connected to at least one WiFi network in the past and the
WiFi chipset support active scanning. If those conditions are not
true, ConnMan will always ask for a passive scan.
This approach seems useful to me. Can I also request a clarification on the
BackgroundScanning section of connman.conf(5)?
I would suggest something like:
BackgroundScanning=true|false
Enable background scanning. Default is true. Background
scanning will start every 5 minutes unless the scan list
is empty. In that case, a simple backoff mechanism
starting from 10s up to 5 minutes will run.
+ When BackgroundScanning is false, ConnMan will not actively
+ scan for or configured networks, even when disconnected,
+ unless it is explicitly requested via a Scan() invocation
+ via D-Bus.
Many thanks for your work on this!
Jonah
4:28 a.m.
Hi Jose,
On 10/01/2017 08:13 PM, Jose Blanquicet wrote:
I tested the four cases and ConnMan is doing what I described above.
I
will keep the patch applied in my systems and I would like to ask
Daniel to do it too in order to check everything continue working as
it should :)
Can you resend the patch. I got it white space damaged and with my hand
editing it didn't get any better :)
Maybe you could also pick up Jonah's doc update too and send it as
proper patch series.
Thanks,
Daniel
3:28 p.m.
Hi Daniel,
On Tue, Oct 3, 2017 at 1:28 PM, Daniel Wagner <wagi(a)monom.org> wrote:
Hi Jose,
On 10/01/2017 08:13 PM, Jose Blanquicet wrote:
>
> I tested the four cases and ConnMan is doing what I described above. I
> will keep the patch applied in my systems and I would like to ask
> Daniel to do it too in order to check everything continue working as
> it should :)
Can you resend the patch. I got it white space damaged and with my hand
editing it didn't get any better :)
Yes, sure!
Maybe you could also pick up Jonah's doc update too and send it
as proper
patch series.
I agree.
Thanks,
Jose Blanquicet
5:07 p.m.
Hi Jose,
Apologies for the delay!
On Sep 25, 2017, at 2:58 PM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
Hi Jonah,
On Fri, Sep 22, 2017 at 9:17 PM, Jonah Petri <jonah(a)sense.com> wrote:
> I tested the patch you provided, and it does appear to solve the problem as
> described. I'll promote that patch into my dev fleet, and let you know if I
> notice any other bad behaviors.
>
>
> I tested the patch you posted. While I never saw any dbus-requested scans
> failing, I did notice an increase in the number of my dev units falling
> offline after a reboot.
Sorry, I am not sure I got what you mean here :(. Could you please
rephrase this and give me more details?
I applied the patch, and ran it for some days on a fleet of testing devices. As a part of
the testing, I rebooted the devices regularly, under various wifi conditions, and noted
that some of them did not re-associate with the wifi network successfully upon reboot.
> In each case I've tested, as soon as dbus Scan()
> was initiated, the previously associated network was seen and joined. While
> I haven't looked for exactly where, I am guessing that there is some hole in
> the connman startup logic where it needs to request a wpa_s Passive scan as
> well.
I assume you mean that at the start-up you see a D-Bus scan call from
ConnMan to wpa_s and a successive re-connection to a known WiFi
network? If so, yes, that's desired start-up procedure.
That’s not what I meant, sorry! To clarify, I did see connman send a scan request to
wpa_s, but it was an active scan. This scan (likely because of environmental conditions)
did not find the desired network. In that case, the unit apparently did not do any sort
of followup scans. Later, I manually issued a Scan() call to connman, which (as your
patch specified) issued a passive scan to wpa_s. This scan happened to yield the desired
network, and connman immediately associated with it.
> Perhaps it would be best to always follow an active scan with a passive one?
> Or perhaps BackgroundScanning should just be forced to 'true'?
Follow an active scan with only one passive scan in case
BackgroundScanning='false' is indeed the best solution. I thought I
would be able to find time to work on that solution but it haven't
yet, it has not been an ease time. This is the idea I have in mind:
Current behaviour with BackgroundScanning='True' is:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
9 seconds -> Launch passive scan
27 seconds -> Launch passive scan
81 seconds -> Launch passive scan
243 seconds -> Launch passive scan
300 seconds -> Launch passive scan
300 seconds -> Launch passive scan
...
Continue each 300 seconds unless you perform a new D-Bus scan call
which will cause the procedure to restart from 3 seconds.
With BackgroundScanning='False' the idea would be:
D-Bus scan request or at start-up of system
Launch an active scan
3 seconds -> Launch passive scan
Stop. No more scanning: 3 seconds would be enough for ConnMan to
reconnect to a known service in case there is one of them in range.
New D-Bus scan request from user
Launch an active scan
3 seconds -> Launch passive scan
Stop.
Ah, maybe I have misinterpreted the meaning of BackgroundScanning!
I thought it meant that connman would not issue scans when it was already connected to a
WiFi network. I had assumed that it would continue to scan for the requested WiFi network
when not connected. From your description above, it seems I was wrong! If that’s the
case, I think I really do want BackgroundScanning, as networks can be down from time to
time, and I would want my devices to recover by detecting the configured network when it
becomes available again, and reconnecting to it.
> It seems that connman may be depending too much on somewhat undocumented
> behaviors of wpa_supplicant and the cfg80211 driver layers, and it's being
> exposed to these bugs.
Unfortunately, yes. wpa_s is the current way to communicate with the
WiFi chip thus we have to deal with it. There are a bunch of things
could have been implemented better in wpa_s. For example, this
scanning logic should be something completely managed by the WiFi
daemon and not by ConnMan.
Agreed, but yes, we must just deal with these things. :D
Jonah
3:27 p.m.
Hi Jonah,
On Tue, Oct 3, 2017 at 2:07 AM, Jonah Petri <jonah(a)sense.com> wrote:
> On Sep 25, 2017, at 2:58 PM, Jose Blanquicet
<blanquicet(a)gmail.com> wrote:
I applied the patch, and ran it for some days on a fleet of testing devices. As a part
of the testing, I rebooted the devices regularly, under various wifi conditions, and noted
that some of them did not re-associate with the wifi network successfully upon reboot.
That's bad! Let's see if that happens again with the second patch I
will send. Just for confirmation, could you please perform the same
tests without the patch and check you successfully re-associate with
the WiFi network at each reboot? We need to be sure whether the patch
is who introduces this issue or not. Thanks!
> Follow an active scan with only one passive scan in case
> BackgroundScanning='false' is indeed the best solution. I thought I
> would be able to find time to work on that solution but it haven't
> yet, it has not been an ease time. This is the idea I have in mind:
>
> Current behaviour with BackgroundScanning='True' is:
> D-Bus scan request or at start-up of system
> Launch an active scan
> 3 seconds -> Launch passive scan
> 9 seconds -> Launch passive scan
> 27 seconds -> Launch passive scan
> 81 seconds -> Launch passive scan
> 243 seconds -> Launch passive scan
> 300 seconds -> Launch passive scan
> 300 seconds -> Launch passive scan
> ...
> Continue each 300 seconds unless you perform a new D-Bus scan call
> which will cause the procedure to restart from 3 seconds.
>
> With BackgroundScanning='False' the idea would be:
> D-Bus scan request or at start-up of system
> Launch an active scan
> 3 seconds -> Launch passive scan
> Stop. No more scanning: 3 seconds would be enough for ConnMan to
> reconnect to a known service in case there is one of them in range.
> New D-Bus scan request from user
> Launch an active scan
> 3 seconds -> Launch passive scan
> Stop.
Ah, maybe I have misinterpreted the meaning of BackgroundScanning!
I thought it meant that connman would not issue scans when it was already connected to a
WiFi network. I had assumed that it would continue to scan for the requested WiFi network
when not connected. From your description above, it seems I was wrong! If that’s the
case, I think I really do want BackgroundScanning, as networks can be down from time to
time, and I would want my devices to recover by detecting the configured network when it
becomes available again, and reconnecting to it.
Yes, I thing you misinterpreted the meaning but don't worry, it is
indeed complex.
Well, if you want ConnMan performs auto-scanning following the
procedure I described above when you are not connected but does not
perform background scanning when you are connected, then keep
BackgroundScanning = true in ConnMan and comment
#CONFIG_BGSCAN_SIMPLE=y in .config of wpa_supplicant SHOULD be enough.
However, take into account that remove CONFIG_BGSCAN_SIMPLE from
wpa_supplicant configuration you are also disabling the WiFi roaming
within a ESS.
Best regards,
Jose Blanquicet
12:31 a.m.
Hi Jose,
On 08/27/2017 04:48 PM, Jose Blanquicet wrote:
Hi,
On Thu, Aug 24, 2017 at 7:33 PM, Jonah Petri <jonah(a)sense.com> wrote:
>> The active scan is useful in order to perform a fast scan looking for the WiFi
networks we have got connected in the past. I think this is particularly helpful to speed
up auto-connect procedure at the start-up of the system. Instead, when user asks for
scanning I think it should always be a passive scan because users want to see all WiFi
networks available in range. Therefore, I propose to make ConnMan ask wpa_supplicant for
an active scan only at star-up of the system and passive scan when it is directly asked
from users through a Technology.Scan() D-Bus call. Both things no matter
BackgroundScanning's value.
>>
>> What do all you think?
>>
> (Now it was my turn to be on vacation! Sorry for the delay.)
Don't worry, welcome back!
> Great idea. This is fine for my use case, and the behaviour you propose is what I
expected given what Technology.Scan() claims to do.
Well, the scan algorithm is quite complex but I think I finally
understood how it works and there is something we should change from
this idea.
We can resume our scenario as following:
* WiFi Driver support active scanning, it means "MaxScanSSID" is greater than
1.
* User has successfully connected to at least one WiFi network in the
past so the service's information is present in
{STOREDIR}/connman/wifi_* but none of those networks are currently in
range, let's call them "known-services".
Under these assumptions, when user asks for scanning the algorithm
will perform an active scan looking for those known-services in their
specific frequencies, this kind of scanning is generally faster than a
passive one which allows to speed up auto-connection procedure.
However, we have seen that some drivers reply with all the networks in
the specified frequencies and some other does not reply any network.
From this point forward, the behaviour changes based on
"BackgroundScanning" value:
* Enabled: A simple backoff mechanism starting from 10s up to 5
minutes will run. Of course, using passive scan thus at the end driver
will reply with all networks in range, as user expects after scanning.
* Disabled: Nothing else is done. Any additional scan will be
executed, resulting in a possible empty scan results forever, Johan's
case.
In my initial idea I proposed to perform passive scan, no matter the
BackgroundScanning value, when user performs a Scan() D-Bus call to
ensure all networks are found. However, while trying to implement it
and due to the reasons I explained before, I realized that it could
also increase the auto-connection procedure with the default ConnMan's
configuration, i.e. BackgroundScanning enabled. Therefore, I am now
limiting this change to users who manually disabled
BackgroundScanning.
Patrik, Daniel, what do you think?
This behavior is wpa_s specific, right? IIRC,
iwd handles all this stuff
on its own.
Anyway it's sound reasonably to me with the assumption that
BackgroundScanning is enabled on most system.
Thanks,
Daniel
12:02 p.m.
Hi Daniel,
On Mon, Sep 4, 2017 at 9:31 AM, Daniel Wagner <wagi(a)monom.org> wrote:
On 08/27/2017 04:48 PM, Jose Blanquicet wrote:
> On Thu, Aug 24, 2017 at 7:33 PM, Jonah Petri <jonah(a)sense.com> wrote:
> In my initial idea I proposed to perform passive scan, no matter the
> BackgroundScanning value, when user performs a Scan() D-Bus call to
> ensure all networks are found. However, while trying to implement it
> and due to the reasons I explained before, I realized that it could
> also increase the auto-connection procedure with the default ConnMan's
> configuration, i.e. BackgroundScanning enabled. Therefore, I am now
> limiting this change to users who manually disabled
> BackgroundScanning.
>
> Patrik, Daniel, what do you think?
This behavior is wpa_s specific, right? IIRC, iwd handles all this stuff on
its own.
Yes, it is. And yes, AFAIK iwd does; in fact the wifi plugin is the
only one who implements scan function, that's why I could modify its
parameters without affecting any other plugin. Maybe we should avoid
to modify the connman_device_driver and keep this modifications inside
wifi plugin which makes the patch simpler and we must mention in
documentation that by disabling this feature it could increase the
auto-connection time by very few seconds (because active scanning
method will not be use). I am not sure whether we should include the
last part within parenthesis or not.
Anyway it's sound reasonably to me with the assumption that
BackgroundScanning is enabled on most system.
Yes, but unfortunately I have to say that this is not the "ideal"
solution (Which would be much more complex). To do so, we should let
the current management of active and passive scanning as it is and
launch a delayed passive scan after the active one when user asks for
scanning. The rough steps would be:
1. User asks for scanning through a Technology.Scan() D-Bus call
2. ConnMan performs an active scan looking for the knwon-services read
from {STOREDIR}/connman/wifi_*
3. Give enough time to ConnMan in order to start auto-connect
procedure in case any of the knwon-services it was looking for is in
range. This step is the most important one because if we launch a new
scan right after then the previous scan is useless because its aim is
to perform a fast scan looking specifically for those knwon-services
and speed up the reconnection.
4. Otherwise, if ConnMan does not get connected (Any known-service is
in rage) then launch a passive scan.
6. Do not launch any additional scan until step (1) occurs again.
What do you suggest?
Best regards,
Jose Blanquicet
1:53 a.m.
Hi Jose,
Jose Blanquicet <blanquicet(a)gmail.com> writes:
On Mon, Sep 4, 2017 at 9:31 AM, Daniel Wagner <wagi(a)monom.org>
wrote:
> On 08/27/2017 04:48 PM, Jose Blanquicet wrote:
>> On Thu, Aug 24, 2017 at 7:33 PM, Jonah Petri <jonah(a)sense.com> wrote:
>> In my initial idea I proposed to perform passive scan, no matter the
>> BackgroundScanning value, when user performs a Scan() D-Bus call to
>> ensure all networks are found. However, while trying to implement it
>> and due to the reasons I explained before, I realized that it could
>> also increase the auto-connection procedure with the default ConnMan's
>> configuration, i.e. BackgroundScanning enabled. Therefore, I am now
>> limiting this change to users who manually disabled
>> BackgroundScanning.
>>
>> Patrik, Daniel, what do you think?
>
> This behavior is wpa_s specific, right? IIRC, iwd handles all this stuff on
> its own.
Yes, it is. And yes, AFAIK iwd does; in fact the wifi plugin is the
only one who implements scan function, that's why I could modify its
parameters without affecting any other plugin. Maybe we should avoid
to modify the connman_device_driver and keep this modifications inside
wifi plugin which makes the patch simpler and we must mention in
documentation that by disabling this feature it could increase the
auto-connection time by very few seconds (because active scanning
method will not be use). I am not sure whether we should include the
last part within parenthesis or not.
Agree, those wpa_s specific changes should not leak into the common code
of ConnMan.
> Anyway it's sound reasonably to me with the assumption that
> BackgroundScanning is enabled on most system.
Yes, but unfortunately I have to say that this is not the "ideal"
solution (Which would be much more complex). To do so, we should let
the current management of active and passive scanning as it is and
launch a delayed passive scan after the active one when user asks for
scanning. The rough steps would be:
1. User asks for scanning through a Technology.Scan() D-Bus call
2. ConnMan performs an active scan looking for the knwon-services read
from {STOREDIR}/connman/wifi_*
3. Give enough time to ConnMan in order to start auto-connect
procedure in case any of the knwon-services it was looking for is in
range. This step is the most important one because if we launch a new
scan right after then the previous scan is useless because its aim is
to perform a fast scan looking specifically for those knwon-services
and speed up the reconnection.
4. Otherwise, if ConnMan does not get connected (Any known-service is
in rage) then launch a passive scan.
6. Do not launch any additional scan until step (1) occurs again.
What do you suggest?
It is a bit confusing with all the different strategies. Your
suggenstion makes sense since it should fix the initial bug report. The
tricky part will be step 3. How long is 'enough time' :)
Thanks,
Daniel
1281
days inactive
1342
days old
32 comments
4 participants
participants (4)
-
Daniel Wagner -
Jonah Petri -
Jose Blanquicet -
Sam Nazarko