Add new QCA vendor attribute to configure the driver to enable/disable
the BSS max idle period support. This attribute is used for testing
purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Fixes: f2f8e4f458 ("Add PTKSA cache to hostapd")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
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.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
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.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Introduce a new allow_6ghz parameter to allow 6 GHz channels to be
filtered out when copying channel lists.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
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.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
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.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Extend the previously 5 GHz specific 80 and 160 MHz channels helper
functions to support 6 GHz channels.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Introduce P2P 6 GHz band capable information in Device Capability
Bitmap of P2P Capability sub-attribute.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
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.
Signed-off-by: Gurumoorthi Gnanasambandhan <gguru@codeaurora.org>
This helper function returns enum chan_allowed values, so use it as the
return type instead of unnecessarily generic int.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
LOG: "hostapd : hostapd_handle_dfs_offload: freq 5240 MHz requires
DFS for 4 chans"
Signed-off-by: Hu Wang <huw@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Hu Wang <huw@codeaurora.org>
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 ce6d9ce15b ("hostapd: Add supported
channel bandwidth checking infrastructure").
Signed-off-by: Hu Wang <huw@codeaurora.org>
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>
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 configure the driver which transport mode to
use for sending CFR data to userspace. Currently, relayfs and netlink
event modes are supported.
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Add a QCA vendor attribute to configure the driver to use Data or
Management frames for keep alive data. This attribute is used for
testing purpose.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add QCA vendor attribute to configure the driver to transmit the
Data frames with ER SU PPDU type format. This attribute is used
for testing purpose.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
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.
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Add QCA vendor attribute QCA_WLAN_VENDOR_ATTR_CONFIG_FT_OVER_DS
to configure FT over DS to the driver/firmware.
Signed-off-by: Vinita S. Maloo<vmaloo@codeaurora.org>
Add QCA interface to specify the RSSI thresholds separately for candidate
APs from different bands.
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
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>
This makes it easier for test scripts to track completion of 4-way
handshake from hostapd, e.g., when going through PTK rekeying.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
"REKEY_PTK <STA MAC address>" can now be used to force rekeying of the
PTK for the specified associated STA.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This moves the implementation closer to the current IEEE 802.11 standard
since B15 of Frame Control field was renamed to +HTC to match it newer
uses.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
