Sorry the delay, I was out of office.
On Fri, Aug 11, 2017 at 4:24 PM, Jonah Petri <email@example.com> wrote:
> On Aug 11, 2017, at 2:43 AM, Jose Blanquicet <firstname.lastname@example.org> 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
variant string "active"
variant array [
array of bytes "Testing-AP"
array of bytes "Colombian-AP"
variant array [
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
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.
> 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?