One of the pointers to the PAC buffer was not updated after realloc
and if the realloc ended up returning new pointer, the *pos pointer
was still pointing at the old location (i.e., freed memory at
this point).
When controlling multiple virtual interfaces on the same physical
radio, share the scan results events with sibling interfaces. This
decreases the time it takes to connect many virtual interfaces.
This is currently only supported on Linux with cfg80211-based
drivers when using nl80211 or wext driver interface.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Some drivers are not providing exactly reliable error codes (e.g.,
with WEXT), but others may actually indicate reliable information.
Allow driver wrappers to indicate if that is the case and use
optimizations if so. For now, this improves nl80211 with
NL80211_CMD_CONNECT for a case where connection request fails.
mac80211 can indicate this mainly because of channel selection
conflicts with other vifs. If there is another BSS on another
channel, we should try to connect to it instead.
driver_param=use_p2p_group_interface=1 can now be used to test
nl80211-drivers with separate P2P group interface. In other words,
the main interface (e.g., wlan0) is reserved for P2P management
operations and non-P2P connections and a new group interface (e.g.,
p2p-wlan0-0) is created for the P2P group.
This implementation is very minimal, i.e., it only support address
allocation for a single P2P group interface (if the driver does not
handle this internally). In addition, not all functionality has yet
been tested, so for now, this is disabled by default and needs that
special driver_param to enable.
WPA_DRIVER_FLAGS_P2P_MGMT_AND_NON_P2P flag can now be used to
indicate that the initial interface (e.g., wlan0) is used for
P2P management operations and potentially non-P2P connections.
This is otherwise identical to
WPA_DRIVER_FLAGS_P2P_DEDICATED_INTERFACE, but the possibility of
non-P2P connections makes some operations differ.
This may make it less likely for udev to rename the interface that
would previously have been called wlan0-p2p-# (now: p2p-wlan0-#).
In addition, add some workaround code to handle the case where the
main interface name is close to the IFNAMSIZ length limit to
avoid going over that for the P2P group interface.
In theory, the interface name could be longer than IFNAMSIZ in
some systems, so use the same size buffer for this field as is
used with the main interface name.
Some other dnsmasq users (like libvirt) seem to be binding the DHCP
server to all interfaces which prevents the previously used mechanism
here from working (bind on the DHCP socket fails). If a failure is
noticed, try to start dnsmasq with -z option to avoid that.
Move the previously SME specific optimization code into generic
function that can be used from non-SME code, too, and use it to
handle disconnection events. In other words, allow disconnection
event to trigger similar optimized scanning case to handle a
common load balancing mechanism. If there is another BSS in the
same ESS when we receive a disconnection event, scan only the
known frequencies of such other BSSes on the next attempt to
speed up recovery.
The special case of requiring blacklisting count to be 2 or higher
is only needed when more than a single network is currently enabled.
As such, we should not do that when only a single network is enabled.
This make the station more likely to follow network side load
balancing attempts where the current AP may disassociate us with
an assumption that we would move to another AP.
When authentication or association fails when trying to connect to
a BSS in an ESS that has multiple BSSes based on previous scans,
limit the first recovery scan to only the known channels that has
been seen previously. This speeds up recovery in some of the most
commonly used load balancing mechanisms in enterprise WLAN
networks.
There were various issues in how the SME (i.e., nl80211-based driver
interface) handled various authentication and association timeouts and
failures. Authentication failure was not handled at all (wpa_supplicant
just stopped trying to connect completely), authentication timeout
resulted in blacklisting not working in the expected way (i.e., the same
BSS could be selected continuously), and association cases had similar
problems.
Use a common function to handle all these cases and fix the blacklist
operation. Use smaller delay before trying to scan again during the
initial cycle through the available APs to speed up connection. Add
a special case for another-BSS-in-the-same-ESS being present to
speed up recovery from networks with multiple APs doing load balancing
in various odd ways that are deployed out there.
assoc_freq needs to be cleared when an interface gets disconnected.
This fixes an issue where P2P Action frame transmission may fail
because of missing remain-on-channel operation when using the same
interface for group operations (or non-P2P connections) and P2P
management operations.
Getting rid of these inline functions seems to reduce the code size
quite a bit, so convert the most commonly used hostapd driver ops to
function calls.
This is not needed anymore and just makes things more difficult
to understand, so move the remaining function pointers to direct
function calls and get rid of the struct hostapd_driver_ops.
send_eapol, set_key, read_sta_data, sta_clear_stats,
set_radius_acl_auth, set_radius_acl_expire, and set_beacon
to use inline functions instead of extra abstraction.
Commit bf65bc638f started the path to
add this new abstraction for driver operations in AP mode to allow
wpa_supplicant to control AP mode operations. At that point, the
extra abstraction was needed, but it is not needed anymore since
hostapd and wpa_supplicant share the same struct wpa_driver_ops.
Start removing the unneeded abstraction by converting
send_mgmt_frame() to an inline function, hostapd_drv_send_mlme().
This is similar to the design that is used in wpa_supplicant and
that was used in hostapd in the past (hostapd_send_mgmt_frame()
inline function).
driver.h defines these functions to return 0 on success, not
number of bytes transmitted. Most callers are checking "< 0" for
error condition, but not all. Address this by following the driver
API specification on 0 meaning success.
The wpa_supplicant_event() EVENT_TX_STATUS ack field needs to be
converted to use wpas_send_action_tx_status()
enum p2p_send_action_result in this case, too, to avoid getting
incorrect TX status for P2P processing.
On Linux, verify that the kernel entropy pool is capable of providing
strong random data before allowing WPA/WPA2 connection to be
established. If 20 bytes of data cannot be read from /dev/random,
force first two 4-way handshakes to fail while collecting entropy
into the internal pool in hostapd. After that, give up on /dev/random
and allow the AP to function based on the combination of /dev/urandom
and whatever data has been collected into the internal entropy pool.
wlan0: RADIUS No authentication server configured
MEMLEAK[0x999feb8]: len 1040
WPA_TRACE: memleak - START
[3]: ./hostapd(radius_msg_new+0x33) [0x8074f43]
radius_msg_new() ../src/radius/radius.c:117
[4]: ./hostapd() [0x806095e]
ieee802_1x_encapsulate_radius() ../src/ap/ieee802_1x.c:439
ieee802_1x_aaa_send() ../src/ap/ieee802_1x.c:1496
For example, this error occured when I used WPS hostapd without
"eap_server=1" definition in configuration file.
By default, make hostapd and wpa_supplicant maintain an internal
entropy pool that is fed with following information:
hostapd:
- Probe Request frames (timing, RSSI)
- Association events (timing)
- SNonce from Supplicants
wpa_supplicant:
- Scan results (timing, signal/noise)
- Association events (timing)
The internal pool is used to augment the random numbers generated
with the OS mechanism (os_get_random()). While the internal
implementation is not expected to be very strong due to limited
amount of generic (non-platform specific) information to feed the
pool, this may strengthen key derivation on some devices that are
not configured to provide strong random numbers through
os_get_random() (e.g., /dev/urandom on Linux/BSD).
This new mechanism is not supposed to replace proper OS provided
random number generation mechanism. The OS mechanism needs to be
initialized properly (e.g., hw random number generator,
maintaining entropy pool over reboots, etc.) for any of the
security assumptions to hold.
If the os_get_random() is known to provide strong ramdom data (e.g., on
Linux/BSD, the board in question is known to have reliable source of
random data from /dev/urandom), the internal hostapd random pool can be
disabled. This will save some in binary size and CPU use. However, this
should only be considered for builds that are known to be used on
devices that meet the requirements described above. The internal pool
is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
This adds more time for the system entropy pool to be filled before
requesting random data for generating the WPA/WPA2 encryption keys.
This can be helpful especially on embedded devices that do not have
hardware random number generator and may lack good sources of
randomness especially early in the bootup sequence when hostapd is
likely to be started.
GMK and Key Counter are still initialized once in the beginning to
match the RSN Authenticator state machine behavior and to make sure
that the driver does not transmit broadcast frames unencrypted.
However, both GMK (and GTK derived from it) and Key Counter will be
re-initialized when the first station connects and is about to
enter 4-way handshake.
The example GMK-to-GTK derivation described in the IEEE 802.11 standard
is marked informative and there is no protocol reason for following it
since this derivation is done only on the AP/Authenticator and does not
need to match with the Supplicant. Mix in more data into the derivation
process to get more separation from GMK.
