In highly congested network (BSSes almost on every channel
within ESS) we have hit a bug when wpa_supplicant become
completly irresponsive, infinite looping on while loop.
When probe_idx was equal 0 and we are not able to probe
new frequency, following condition were never fulfilled:
"if (!in_array(freqs, data->supp_freqs[idx]))"
Signed-hostap: Pawel Kulakowski <pawel.kulakowski@tieto.com>
The hardware feature data is required in several different places
throughout the code. Previously, the data was acquired and freed on
demand, but with this patch wpa_supplicant will keep a single copy
around at runtime for everyone to use.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Commit 9ff80a10e8009c0dc65a4b7e08dcf1655cd2a483 forgot to include the
new scan variable in the coded copied from bgscan_simple.c. Add that
here to fix the build.
The driver is likely to indicate an immediate signal event when the
threshold value is configured. Since we do this immediately after
association, there is not much point in requesting a new scan to be
started based on this event.
Store list of all discovered BSSes in the ESS and on which frequencies
they have been seen. Use this information to dynamically generated the
list of channels for background scans.
