wpa_supplicant auto reconnect

[Jake Magee]

Would it also be possible to allow the back-off period to be
configurable?  77 seconds is fine for me right now, but I can foresee
someone down the road requesting this to be 1 minute, or 5 minutes,
etc.

- jake

On Mon, Mar 27, 2017 at 9:02 AM, Jouni Malinen <j at w1.fi> wrote:
> On Thu, Mar 16, 2017 at 09:48:12PM -0500, Dan Williams wrote:
>> On Thu, 2017-03-16 at 15:39 -0500, Jake Magee wrote:
>> > So I think the log is too big to send (400K)... here is a link to it.
>> >
>> > https://drive.google.com/file/d/0B3BKPLtbQtZrZnNlaHRvb3BJZDQ/view?usp
>> > =sharing
>
>> Yeah, so changing the password gets you into trouble.  The supplicant
>> keeps trying to connect and keeps failing, so it starts backing off:
>
> Well.. Changing the password (or any similar difference that looks like
> the network does not accept the station anymore) does indeed result in
> backing off from connection attempts and I would not call this part the
> one that is getting into trouble; this is very much by design..
>
>> 1489691439.907335: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0
>> ssid="AndroidAP" auth_failures=4 duration=77 reason=CONN_FAILED
>
>> Where the supplicant has decided to ignore your AP for 77 seconds
>> because the connection failed 4 times.  It then does a scheduled scan
>> (asks the driver to notify it when the AP shows up again) and basically
>> goes to sleep.
>>
>> 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 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.
>
> --
> Jouni Malinen                                            PGP id EFC895FA