aboutsummaryrefslogtreecommitdiffstats
path: root/hostapd
diff options
context:
space:
mode:
authorEyal Shapira <eyal@wizery.com>2012-11-12 13:51:35 +0200
committerEyal Shapira <eyal@wizery.com>2012-11-12 16:40:40 +0200
commit8975c166e26ccda2b89eb8b7d3d796eb4ee0e186 (patch)
treed7b72cf52ee01b04443feb8f8f9471120d551abc /hostapd
parentb1ce8a6945f52737f2c62ec6c3a5c54f87d16b3d (diff)
downloadexternal_wpa_supplicant_8_ti-8975c166e26ccda2b89eb8b7d3d796eb4ee0e186.zip
external_wpa_supplicant_8_ti-8975c166e26ccda2b89eb8b7d3d796eb4ee0e186.tar.gz
external_wpa_supplicant_8_ti-8975c166e26ccda2b89eb8b7d3d796eb4ee0e186.tar.bz2
Avoid sched scan flood in case of mismatched security (UPSTREAM)
Current sched scan in the kernel is limited to SSID matching. A rare corner case is when an AP with a matching SSID but unmatching security to a saved profile is in the vicinity. In such a case sched scan results will immediately be returned after initiating sched scan however no match will be found due to the security mismatch. This goes on in a tight loop which is bad as it will effectively prevent the host from suspending and scan results will eventually contain the single AP matched by the sched scan due to expiration of other APs scanned in normal scans which are less frequent. Avoid this by stopping sched scan after detecting sched scan results were received but no matched network. Don't start another sched scan immediately but wait for the next normal scan without any results to restart it. This prevents the tight loop. Signed-off-by: Eyal Shapira <eyal@wizery.com>
Diffstat (limited to 'hostapd')
0 files changed, 0 insertions, 0 deletions