1:49 p.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