Re: wpa_supplicant auto reconnect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux