wpa_supplicant auto reconnect

[Arend Van Spriel]

On 7-4-2017 18:03, Luca Coelho wrote:
> On Fri, 2017-04-07 at 11:59 +0200, Arend Van Spriel wrote:
>> On 27-3-2017 16:02, Jouni Malinen wrote:
>>> On Thu, Mar 16, 2017 at 09:48:12PM -0500, Dan Williams wrote:
>>>> The bug here is probably that the supplicant doesn't set a wakeup timer
>>>> for when the temporary disablement expires, and then clear the
>>>> disablement and retry the connection.
>>>
>>> That's indeed the real issue here. This works fine with the internal
>>> scan iterations in wpa_supplicant, but apparently not with sched_scan
>>> offload.. In other words, the expected behavior here is that there would
>>> indeed be another scan iteration at some point after that 77 second
>>> back-off period and that would then result in yet another connection
>>> attempt.
>>>
>>> It is not exactly clear how sched_scan should work here, though.
>>> wpa_supplicant does request the driver to report scan results for the
>>> specific SSID here and one does get reported 30 seconds after the
>>> sched_scan has started, but that's still within the temporary disabled
>>> period.. After that, the driver did not report the scan results again.
>>
>> I think the kernel side is not very clear about this. At least I did not
>> find an explicit statement on what is expected. From recent experience
>> with our devices/firmware I know that it will send a notification when a
>> specified SSID is found and indeed if we are in a static environment it
>> will do the scans according the specified scan interval, but it will not
>> give another notification for that SSID.
> 
> Originally the intention was that the results would continue being sent
> at every interval when the configured SSID was found, regardless of
> whether that SSID had been reported before or not.

Ok. The question what device Jake is using did not come up in this
thread. Now I took a look at the log file and noticed vendor command id
0x1018 which is Broadcom OUI. So that explains him seeing the same behavior.

>>> I guess it might be reasonable to add a new timeout within
>>> wpa_supplicant to stop and restart ongoing sched_scan at the point the
>>> temporary disablement of a network (that is part of that sched_scan
>>> operation) times out.. Or alternatively, set a timeout for the
>>> sched_scan to handle this as part of the existing mechanism to run
>>> continuous sched_scan operations when needing to search for more SSIDs
>>> than the driver supports in the offload case.
>>
>> Not sure I understand the alternative here. You mean adding a
>> ATTR_SCHED_SCAN_TIMEOUT after which the schedule scan state in
>> driver/firmware is reset and a notification will be sent again?
> 
> I don't think this would add much value.  Why can't wpa_s wake up and
> restart the sched_scan when the timeout is reached?

Please note that wpa_s does not have that timeout as adding that is the
proposal on the table here. The timeout in driver/firmware being the
alternative, ie. instead of timeout in wpa_s.

> A third alternative would be for wpa_s to stop the sched scan for this
> SSID when it gets disabled (or restart the sched scan without it, if
> there are other SSIDs still enabled).  And then start it again when it
> gets enabled again? I don't see the point in still searching for this
> SSID if it's disabled at wpa_s level.

Anyway, this 3rd alternative is my favorite. Let hear what opinion Jouni
has on this idea.

Regards,
Arend

> --
> Cheers,
> Luca.
>