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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
