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