This was not really supported by any of the included driver wrappers. If
this functionality is desired in the future, this (or something similar)
can be added with the changes needed into a driver wrapper to use the
mechanism.
Instead of adding a new driver_ops for fetching neighbor BSS data (that
nl80211 driver interface had to scan during initialization), share the
same scan operations that wpa_supplicant is using. This gets rid of
duplicated scan code in driver_nl80211.c (and better yet, removes large
part of old WEXT code).
hostapd interface initialization is now completed in a callback, if
needed, i.e., he_features channel/hw_mode selection can use as much time
as needed. This can also help with radar detection in the future.
Try to match PRI/SEC channel with neighboring 20/40 MHz BSSes per
IEEE 802.11n/D7.0 11.14.3.2. This is not yet complete implementation,
but at least some parts of the 40 MHz coex are improved.
40 MHz operation maybe rejected (i.e., fall back to using 20 MHz) or
pri/sec channels may be switched if needed.
driver.h contains the definitions needed in driver wrapper
implementations (driver_*.c) and driver_i.h contains the definitions
that are used in core hostapd code to interact with the driver wrappers.
This code was originally added as a mechanism to handle long waits
during channel selection and/or radar detection. It is not currently
really used and makes the setup sequence nearly impossible to
understand. Let's get rid of the unwanted complexity. This needs to be
redesigned if it is ever needed again.
If the driver wrapper does not implement passive_scan handler, do not try
to use strerror() to figure out what the error meant. This is not really an
error that the user should be notified about.
(e.g., via driver_nl80211 when using mac80211) instead of using hostapd as
the source of the regulatory information (i.e., information from CRDA is
now used with mac80211); this allows 5 GHz channels to be used with hostapd
(if allowed in the current regulatory domain).
