FILS: Flush PMKSA entries on FILS connection failure
wpa_supplicant generates both a PMKSA cache entry and ERP keys upon
successful FILS connection and uses FILS authentication algorithm for
subsequent connections when either ERP keys or a PMKSA cache entry is
available.
In some cases, like AP/RADIUS server restart, both ERP keys and PMKSA
becomes invalid. But currently when an AP rejects an association,
wpa_supplicant marks only ERP keys as failed but not clearing PMKSA.
Since PMKSA is not cleared, consecutive connection attempts are still
happening with FILS authentication algorithm and connection attempts are
failing with the same association rejection again instead of trying to
recover from the state mismatch by deriving a new ERP key hierarchy.
Clear PMKSA entries as well on association rejection from an AP to allow
the following connection attempt to go with open authentication to
re-establish a valid ERP key hierarchy. Also, since clearing PMKSA
entries on unprotected (Re)Association Response frames could allow DoS
attack (reduce usability of PMKSA caching), clear PMKSA entries only
when ERP keys exists.
SAE: Report authentication rejection over control interface
CTRL-EVENT-AUTH-REJECT reporting was previously skipped when going
through SAE-specific Authentication frame handling. Add this event here
as well to be more consistent with control interface events.
QCA vendor attribute to use BSSID in Probe Request frame RA
Add a QCA vendor attribute to configure the driver to use scan
request BSSID value in Probe Request frame RA(A1) for scan.
This attribute is used for testing purpose.
The driver saves this configuration and applies this setting to all user
space scan requests until the setting is cleared. If this configuration
is set, the driver uses the BSSID value from the scan request to set the
RA(A1) in the Probe Request frames during the scan, else the broadcast
address is set in the Probe Request frames RA(A1).
Jouni Malinen [Thu, 24 Jun 2021 21:31:03 +0000 (00:31 +0300)]
tests: Fix multi_ap_wps_shared_apdev_csa to remove extra hostapd interface
This test case adds a new AP device (wlan0_ap) with iw and removes it in
the end. However, the hostapd interface for this netdev was only added,
but not removed at the end of the test case. This could result in
consecutive test cases getting confused with the extra interface, e.g.,
if running WPS configuration steps that get applied to all enabled
interfaces.
Jouni Malinen [Thu, 24 Jun 2021 21:20:02 +0000 (00:20 +0300)]
PTKSA: Fix a potential hostapd memory leak during reconfiguration
Some of the reconfiguration cases (e.g., with WPS reconfiguration
enabling WPA/WPA2) might end up calling hostapd_setup_wpa() twice
without calling hostapd_deinit_wpa() in the middle. This would have
resulted in a memory leak since the PTKSA cache was being reinitialized
without freeing previous memory allocation.
Fix this by making PTKSA cachine initialization independent of
hapd->wpa_auth so that reinitialization does not happen in a manner that
would have overridden the old hapd->ptksa pointer without freeing the
referenced resources.
Use WPA3-Personal (SAE+PMF) for P2P connections in the 6 GHz band to
enable the Wi-Fi Display use case on the 6 GHz band without having to
use WPA2-Personal (PSK) on that new band.
P2P: Allow connection on 6 GHz channels if requested
Previously, 6 GHz channels were disabled for P2P operations. Use the new
allow_6ghz parameter with P2P_CONNECT, P2P_GROUP_ADD, and P2P_INVITE
commands for P2P connection on the 6 GHz channels when Wi-Fi Display is
enabled on both the devices.
However, the p2p_6ghz_disable parameter in the configuration takes a
higher precedence.
Indicate P2P 6 GHz band capable information in Device Capability Bitmap
of P2P Capability attribute to indicate the P2P Device is capable of P2P
operation in the 6 GHz band.
P2P: Add allow_6ghz parameter to control interface
Introduce a new allow_6ghz parameter with P2P_CONNECT, P2P_GROUP_ADD,
and P2P_INVITE commands for P2P connection on the 6 GHz channels when
Wi-Fi Display is enabled on both the devices. This commit is only adding
the interface change without changing any actual P2P functionality.
P2P: Allow 6 GHz channels to be included in the P2P_FIND operation
Previously, the 6 GHz channels were disabled for P2P operations.
Introduce a new include_6ghz parameter for the P2P_FIND command to
configure P2P discovery on the 6 GHz channels.
However, the p2p_6ghz_disable parameter in the configuration takes a
higher priority. If the p2p_6ghz_disable parameter is not set in the
configuration, include_6ghz parameter can be used to enable or disable
the discovery operation in the 6 GHz channels for the P2P_FIND command.
P2P: Helper functions to check for WFD capability of a P2P device
P2P operation on the 6 GHz band is supported in the WFD use case.
Introduce helper functions to check for Wi-Fi Display capability of
the local device and a peer device.
WNM: Ignore SSID check for hidden SSID in transition candidates
Do not skip scan results with zero length SSID (i.e., a hidden SSID)
when searching for potential BSS transition candidates since such
entries might be for the same ESS (i.e., for the current SSID). Use only
the BSSID check for such cases.
Hu Wang [Tue, 27 Apr 2021 08:41:13 +0000 (16:41 +0800)]
DFS offload: Use hostapd_is_dfs_required() to check if DFS required
hostapd_handle_dfs_offload() is the DFS handler for the offloaded case,
in which ieee80211_is_dfs() is used to check if the configured frequency
requires DFS or not.
When the configured channel width is not 20 (e.g., 160),
ieee80211_is_dfs() will not checked adjacent freqs, so it possibly makes
wrong conclusion for whether DFS is required.
hostapd_is_dfs_required() does similar thing with ieee80211_is_dfs()
except it supports checking whether the configured frequency and its
adjacent frequencies require DFS. So hostapd_is_dfs_required() is a more
robust and better option than ieee80211_is_dfs() to check DFS.
The issue is hostapd_is_dfs_required() is for non-offload case due to
the check of the configuration parameter ieee80211h. Add a check for
WPA_DRIVER_FLAGS_DFS_OFFLOAD to make it support the DFS offload case
(i.e., ieee80211h=0) as well.
For example, configuring the AP to start at freq=5240 with channel width
160:
- Existing hostapd checks freq=5240 is non-DFS, hence skip DFS CAC and
transition to AP-Enabled which volatiles DFS-RADAR detection.
LOG: "hostapd : hostapd_handle_dfs_offload: freq 5240 MHz does not
require DFS. Continue channel/AP setup"
- This commit checks freq=5240 and its adjacent freqs are DFS required,
hence remains in DFS state until DFS CAC completed.
Jouni Malinen [Wed, 2 Jun 2021 21:11:18 +0000 (00:11 +0300)]
Use a helper function to remove struct wpa_bss_tmp_disallowed entries
It is safer to remove and free these entries with a shared helper
function to avoid issues with potentially forgetting to unregister or
free something if this structure is extended in the future.
Hu Wang [Sat, 22 May 2021 14:00:10 +0000 (22:00 +0800)]
OCE: Remove AP from driver disallow list with sufficient AP RSSI
When a STA makes an association request that is rejected by an OCE AP
due to the RSSI being insufficient, the AP is added to the driver
disallow list by wpa_set_driver_tmp_disallow_list().
Once the AP increases TX power which makes the AP RSSI higher than
Association Rejection RSSI threshold, the AP is supposed to be removed
from the driver disallow list but that was not the case.
wpa_is_bss_tmp_disallowed() is called in the scan result handler, so it
is the best place to put the logic of removing the AP from the driver
disallow list with sufficient AP RSSI.
This is needed with drivers that use the temporarily disallowed BSS list
(which is currently supported only with a QCA vendor command). The
wpa_supplicant internal functionality was already taking care of this
with the wpa_is_bss_tmp_disallowed() return value even for cases where
the entry remaining in the list.
Hu Wang [Tue, 1 Jun 2021 09:52:40 +0000 (17:52 +0800)]
hostapd: Reject 40 MHz channel config if regulatory rules do not allow it
When regulatory rules are configured not to support 40 MHz channels on
the 2.4 GHz band, hostapd_is_usable_chans() still allowed 40 MHz
channels (i.e., 1-9) to be used with ht_capab=[HT40+][HT40-].
Looking into hostapd_is_usable_chans():
1) Validate primary channel using hostapd_is_usable_chan()
2) Try to pick a default secondary channel if hostapd_is_usable_chan()
3) Try to pick a valid secondary channel if both HT40+/HT40- set, and
further validate primary channel's allowed bandwidth mask.
4) Return channel not usable.
For example, for the 2.4 GHz channel 9 in Japan, its default secondary
channel is 13, which is valid per hostapd_is_usable_chan(), so step (2)
returns channel usable.
Add a more strict check to step (2) to clearly reject 40 MHz channel
configuration if regulatory rules do not allow the 40 MHz bandwidth,
which is similarly done in commit ce6d9ce15b07 ("hostapd: Add supported
channel bandwidth checking infrastructure").
Add user configuration he_twt_responder for enabling/disabling TWT
responder role, in addition to checking the driver's capability. The
default configuration is to enable TWT responder role when the driver
supports this.
Signed-off-by: Mohammad Asaad Akram <asadkrm@codeaurora.org>
Android: Pass the vendor events to $(BOARD_HOSTAPD_PRIVATE_LIB)
Introduce a new board configuration via
$(BOARD_HOSTAPD_PRIVATE_LIB_EVENT) rather than reusing
$(BOARD_HOSTAPD_PRIVATE_LIB) to pass vendor events handling in the
hostapd private library. This is to avoid compilation issues for
wpa_driver_nl80211_driver_event() with the already existing private
library implementations defined with $(BOARD_HOSTAPD_PRIVATE_LIB).
This is similar to the existing BOARD_WPA_SUPPLICANT_PRIVATE_LIB_EVENT
parameter for the wpa_supplicant build.
Signed-off-by: Mohammad Asaad Akram <asadkrm@codeaurora.org>
Add QCA vendor interface to transport CFR data using netlink events
Add QCA vendor interface to configure the driver which transport mode to
use for sending CFR data to userspace. Currently, relayfs and netlink
event modes are supported.
FILS authentication derives PMK differently from the EAP cases. The PMK
value does not bind in the MAC addresses of the STAs. As such, the same
PMKID is used with different BSSIDs. Fix both the hostapd and
wpa_supplicant to use the previous PMKID as is for OKC instead of
deriving a new PMKID using an incorrect derivation method when using an
FILS AKM.
Vamsi Krishna [Thu, 20 May 2021 18:47:28 +0000 (00:17 +0530)]
Use estimated throughputs irrespective of RSSI delta for 6 GHz APs
APs in 6 GHz operating with LPI/VLP rules will have significantly lower
SNR values compared to 2.4/5 GHz band APs. Earlier, the estimated
throughputs were used for comparison only when the delta of SNRs between
both the APs was not greater than 7 and as a result for comparing 6 GHz
APs with 2.4/5 GHz APs, estimated throughputs were not getting used.
The estimated throughput calculations takes SNR value also into
consideration, hence remove RSSI delta check if any of the APs are from
the 6 GHz band. This change is limited to the 6 GHz band only in order
to avoid possible regressions with 2.4/5 GHz APs.
Fix documentation for QCA_WLAN_VENDOR_ATTR_TWT_SETUP_MAC_ADDR
Mention that for AP mode this attribute is required in
response for TWT SET, TWT GET, TWT SUSPEND, and TWT
TERMINATE. And is required in request for TWT GET, and
TWT TERMINATE.
For STA mode, the usage of this attribute remains unchanged.
Signed-off-by: Mohammad Asaad Akram <asadkrm@codeaurora.org>
Jouni Malinen [Mon, 1 Feb 2021 14:57:14 +0000 (16:57 +0200)]
Add EAPOL_TX command to extend ext_eapol_frame_io possibilities
This makes it convenient for an external test script to use
ext_eapol_frame_io=1 to delay and/or modify transmission of EAPOL-Key
msg 1/4 without having to use separate frame injection mechanisms.
Jouni Malinen [Mon, 8 Feb 2021 16:38:39 +0000 (18:38 +0200)]
wlantest: TKIP frame reassembly for Michael MIC check in fragmented case
Reassemble the full MSDU when processing TKIP protected fragmented
frames so that the Michael MIC can be validated once the last fragment
has been received.
Jouni Malinen [Sat, 30 Jan 2021 15:28:49 +0000 (17:28 +0200)]
wlantest: Report decrypted TKIP frames even if cannot check Michael MIC
This can be useful for debugging, so return successfully decrypted TKIP
frame even if the Michael MIC cannot be verified (fragment reassembly
not yet supported) or if the Michael MIC value is incorrect. Add a note
in the frame to point out that the Michael MIC was not verified or is
incorrect.
Jouni Malinen [Mon, 10 May 2021 22:03:57 +0000 (01:03 +0300)]
Skip GTK rekeying request if rekeying already in process
Do not start yet another rekeying of GTK when receiving an EAPOL-Key
request frame at the point when the GTK is already being rekeyed. This
fixes issues where the AP might end up configuring a different GTK than
the one it sends to the associated stations.
Vamsi Krishna [Tue, 4 May 2021 13:46:44 +0000 (19:16 +0530)]
Prefer 6 GHz APs for connection in BSS selection
Prefer 6 GHz APs when estimated throughputs are equal with APs from the
2.4/5 GHz bands while selecting APs for connection. Also add a 6 GHz
specific noise floor default value for the 6 GHz band (with the same
value as was used for 5 GHz previously) to make this step clearer.
Vamsi Krishna [Tue, 4 May 2021 13:01:18 +0000 (18:31 +0530)]
Add support to calculate estimated throughputs for HE rates
Add support to consider HE rates while estimating throughputs for the
scan results from HE enabled APs. HE 0.8 usec GI rates are used in all
tables. The minimum SNR values for HE rates (1024-QAM) are derived by
adding the existing minimum SNR values of 256-QAM rates from VHT tables
and the difference between the values of minimum sensitivity levels of
256-QAM rates and 1024-QAM rates defined in Table 27-51 (Receiver
minimum input level sensitivity) in IEEE P802.11ax/D8.0.
Vamsi Krishna [Tue, 4 May 2021 19:34:54 +0000 (01:04 +0530)]
Add support to estimate throughput for VHT 160/80+80 MHz supporting APs
Add support to calculate estimated throughputs for APs which support the
160 MHz (including 80+80 MHz) mode in VHT. The minimum SNR values for
VHT 160 MHz mode are derived from minimum SNR values used for VHT 80 MHz
mode + 3 dBm. The min-SNR values are derived relatively based on the
information that the minimum sensitivity levels defined in Table 21-25
(Receiver minimum input level sensitivity) in IEEE Std 802.11-2020 for
the 160 MHz mode are higher by 3 dBm compared to the values of the 80
MHz mode for each rate.
Vamsi Krishna [Tue, 4 May 2021 19:15:30 +0000 (00:45 +0530)]
Check local supported features for estimating BSS throughputs accurately
Add checks for features supported by the specific hardware mode of the
local device that has the channel for which the throughput is being
estimated instead of assuming the local device supports all optional
features. This is more accurate for cases where the local capabilities
might differ based on the band. In addition, this is in preparation for
extending rate estimates to cover optional VHT and HE features.
Jouni Malinen [Thu, 6 May 2021 20:49:12 +0000 (23:49 +0300)]
tests: Fix eap_proto_sake_server with Session ID = 255
Need to wrap back to 0 when changing value 255 to avoid generating a too
large value to fit an octet field. This was resulting in errors due to a
python exception (likely for about every 256th run).
Jouni Malinen [Thu, 6 May 2021 20:28:27 +0000 (23:28 +0300)]
wlantest: Support HT Control field in QoS Data frames
Extend Data frame processing (and decryption) to handle +HTC frames by
skipping the HT Control field at the end of the frame header. While this
is not an exact match of the rules in IEEE Std 802.11-2020 for when the
HT Control field is present in frames (e.g., no check of the TXVECTOR
value), this is good enough to cover the most likely used cases.
Jouni Malinen [Tue, 4 May 2021 15:19:23 +0000 (18:19 +0300)]
tests: Limit maximum number of frames in fuzzing tests
This limits the EAP-SIM and EAP-AKA tests to 100 test frames to avoid
undesired timeouts in automated fuzz testing. The real world uses are
limited to 50 rounds, so there is not really any point in trying with
thousands of frames.
Determine 6 GHz bandwidth in AP mode ACS using op_class parameter
Determine bandwidth from op_class parameter when set in config. When not
configured, use he_oper_chwidth for determining 80 MHz or 160 MHz. When
both are not set, fall back to 20 MHz by default. This helps in removing
the dependency on op_class parameter in 6 GHz ACS.
6 GHz: Fix operating class in Supported Operating Classes element
Previously, the secondary channel was set only in presence of HT
capabilities based on HT40+ or HT40-. As HT capabilities and
secondary_channel are not present for the 6 GHz bamd, this causes
incorrect operating class indication in the Supported Operating Classes
element.
Fix this by assigning the secondary channel for bandwidths greater than
20 MHz in the 6 GHz band.
Jouni Malinen [Mon, 3 May 2021 17:03:28 +0000 (20:03 +0300)]
tests: Update server and user certificates (2020)
The previous versions expired, so need to re-sign these to fix number of
the EAP test cases. This contains updates from running
tests/hwsim/auth_server/update.sh.
P Praneesh [Mon, 5 Apr 2021 05:45:26 +0000 (11:15 +0530)]
hostapd: Update 160 MHz center freq calculation in 6 GHz
In the 6 GHz Operation Information field, the Channel Center Frequency
Segment 0 field indicates the channel center frequency index for
the 20 MHz, 40 MHz, 80 MHz, or 80+80 MHz channel on which the
BSS operates in the 6 GHz band. If the BSS channel width is 160 MHz
then the Channel Center Frequency Segment 0 field indicates the
channel center frequency index of the primary 80 MHz.
The Channel Center Frequency Segment 1 field indicates the channel
center frequency index of the 160 MHz channel on which the BSS operates
in the 6 GHz band or the channel center frequency of the secondary 80
MHz for the 80+80 MHz channel.
Since Channel Center Frequency Segment 1 was 0 for 160 MHz, 6 GHz STA
associated using 80 MHz. Update seg0 and seg1 fields per standard (IEEE
P802.11ax/D8.0: 9.4.2.249 HE Operation element).
Signed-off-by: P Praneesh <ppranees@codeaurora.org>
When WMM is disabled, HT/VHT/HE capabilities should not be used for any
STA. If any STA advertises these capabilities, hostapd AP disables HT
capabilities in STA flags during STA assoc, but VHT/HE was not handled
similarly. This could allow a STA to associate in VHT/HE mode even in
WMM disable case.
To avoid this, disable VHT/HE capabilities similarly to HT during STA
association, if WMM is not enabled by the STA.
nl80211: Map internal TDLS_PEER_* to NL80211_TDLS_PEER_*
Even though these enum definitions are currently identical, it is better
to explicitly map these bits to the kernel interface instead of using
the internal definition for this. This makes it much clearer that new
enum tdls_peer_capability value needs to be assigned in nl80211 before
they can be added into wpa_supplicant.
Add support to indicate TDLS peer's HE capability to driver
Indicate TDLS peer's capability to driver after processing TDLS setup
response frame. This information can be used by the driver to decide
whether to include HE operation IE in TLDS setup confirmation frame.
Kani M [Thu, 18 Feb 2021 07:25:44 +0000 (12:55 +0530)]
Fix UPDATE_BEACON processing when disabled
The hostapd process crashed when the UPDATE_BEACON control interface
command was issue after the interface was disabled. Check for this case
and return an error if the interface is disabled.
Kani M [Tue, 13 Apr 2021 04:56:47 +0000 (10:26 +0530)]
DPP2: Fix channel 6 inclusion for chirping with non-2 GHz interfaces
When the driver provides a list of supported modes, chan6 ended getting
added even if the 2.4 GHz mode was not included. This resulted in
incorrect behavior of trying to transmit on a not supported channel in
case of 5 GHz only radios.
Fix this by adding the channel 6 by default only if the driver does not
provide a list of supported modes. Whenever the supported modes are
available, only add this channel if it is explicitly listed as an
enabled channel.
Fixes: 8e5739c3ac31 ("DPP2: Check channel 6 validity before adding it to chirp channel list") Signed-off-by: Kani M <kanisumi@codeaurora.org>
Disha Das [Thu, 15 Apr 2021 13:21:06 +0000 (18:51 +0530)]
DPP2: Get DPP Relay Controller context based on hostapd callback context
Get the DPP Relay Controller context from the list of configured
Controllers based on the correct hostapd callback context. This is
needed to pick the correct hostapd interface for sending out the
response over air, e.g., when the same hostapd process controls a 2.4
GHz only and a 5 GHz only interface.
Disha Das [Thu, 11 Feb 2021 08:36:47 +0000 (14:06 +0530)]
DPP2: Close incomplete Relay connections
Add timeout to close incomplete DPP relay connections. This is needed to
avoid getting stuck with old entries that prevent new connections from
getting started.
OpenSSL: Fix compilation for version < 1.1.0 without CONFIG_ECC
When CONFIG_ECC is not defined, openssl/ec.h is not included and EC_KEY
not known. Fix be not defining EVP_PKEY_get0_EC_KEY() when CONFIG_ECC is
not defined.
Signed-off-by: Wolfgang Steinwender <wsteinwender@pcs.com>
Add helper functions for parsing RSNXE capabilities
Simplify the implementation by using shared functions for parsing the
capabilities instead of using various similar but not exactly identical
checks throughout the implementation.
SAE: Remove now unused password identifier argument from non-H2E case
IEEE Std 802.11-2020 mandates H2E to be used whenever an SAE password
identifier is used. While this was already covered in the
implementation, the sae_prepare_commit() function still included an
argument for specifying the password identifier since that was used in
an old test vector. Now that that test vector has been updated, there is
no more need for this argument anymore. Simplify the older non-H2E case
to not pass through a pointer to the (not really used) password
identifier.
Ilan Peer [Thu, 8 Apr 2021 09:06:24 +0000 (12:06 +0300)]
PASN: Change PASN flows to use SAE H2E only
Do so for both wpa_supplicant and hostapd. While this was not explicitly
required in IEEE P802.11az/D3.0, likely direction for the draft is to
start requiring use of H2E for all cases where SAE is used with PASN.
Ilan Peer [Thu, 8 Apr 2021 09:06:20 +0000 (12:06 +0300)]
PASN: Derive KDK only when required
When a PTK derivation is done as part of PASN authentication flow, a KDK
derivation should be done if and only if the higher layer protocol is
supported by both parties.
Fix the code accordingly, so KDK would be derived if and only if both
sides support Secure LTF.
Add vendor reason codes for TWT setup reject on roaming/channel switch
The firmware rejects the TWT setup request when roaming and channel
switch is in progress. Extend enum qca_wlan_vendor_twt_status to
represent new reason codes for these cases.
Sunil Dutt [Thu, 25 Mar 2021 14:17:13 +0000 (07:17 -0700)]
Set last_eapol_matches_bssid=1 on a roam+auth indication from driver
Commit 3ab35a660364 ("Extend EAPOL frames processing workaround for
roaming cases") added a work around to address the issue of EAPOL frame
reception after reassociation replied to with an incorrect destination
address (the BSSID of the old AP). This is due to association events and
EAPOL RX events being reordered for the roaming cases with drivers that
perform BSS selection internally.
This mechanism relies on the fact that the driver always forwards the
EAPOL handshake to wpa_supplicant after the roaming (sets
last_eapol_matches_bssid during the EAPOL processing and resets on the
assoc/reassoc indication).
The above approach does not address the case where the driver does the
EAPOL handshake on the roam, indicating the authorized status to
wpa_supplicant but also forwards the EAPOL handshake to wpa_supplicant
for few other roam attempts. This is because the flag
last_eapol_matches_bssid is not set with the roam+authorized event from
the driver. Thus, the next reorder of roam and EAPOL RX events would
miss this workaround.
Address this by setting last_eapol_matches_bssid=1 on a roam+authorized
event from the driver.
SAE: Increment the Sc counter before generating each Confirm
This changes the Send-Confirm value for the first SAE Confirm message to
be 1 instead of 0 for all cases to match the design shown in IEEE Std
802.11-2020, Figure 12-4 (SAE finite state machine).
Sc is defined to be "the number of SAE Confirm messages that have been
sent" which is a bit vague on whether the current frame is included in
the count or not. However, the state machine is showing inc(Sc)
operation in all cases before the "2" event to build the Confirm.
Yu Wang [Tue, 19 Jan 2021 08:28:28 +0000 (16:28 +0800)]
nl80211: Support larger number of MAC ACL entries
If the maximum size of MAC ACL entries is large enough, the
configuration message may exceed the default buffer size of a netlink
message which is allocated with nlmsg_alloc(), and result in a failure
when putting the attributes into the message.
To fix this, calculate the required buffer size of the netlink message
according to MAC ACL size and allocate a sufficiently large buffer with
nlmsg_alloc_size().
Yu Wang [Tue, 19 Jan 2021 08:28:28 +0000 (16:28 +0800)]
nl80211: Fix the size of the maximum MAC ACL size
NL80211_ATTR_MAC_ACL_MAX is a u32 attribute to advertise the maximum
number of MAC addresses that a device can support for MAC ACL. This was
incorrectly used as a u8 attribute which would not work with any values
larger than 255 or on big endian CPUs. Fix this by moving from
nla_get_u8() to nla_get_u32().
Fixes: 3c4ca36330c0 ("hostapd: Support MAC address based access control list") Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
projects / thirdparty / hostap.git / log
