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