P2P connections in the 6 GHz band use SAE authentication algorithm after
getting credentials with WPS connection. During WPS connection as it
doesn't use SAE, SAE PT is not derived. After getting SAE credentials,
the STA connects to the same SSID using SAE auth algorithm. Earlier, SAE
H2E PT was not derived while connecting to the same SSID to which the
STA is connected last time. Due to this, the P2P group formation fails
for 6 GHz channels when H2E is enabled as the PT will not be setup by
the P2P client before proceeding to the SAE authentication. Same could
happen with infrastructure WPS when wps_cred_add_sae=1 is used.
Set up the SAE H2E PT while connecting to the same SSID again also to
make sure that the H2E PT is set up in the STA to derive the PWE for
successful SAE authentication. The PT derivation will be skipped in
wpa_s_setup_sae_pt() if PT is already available for that SSID.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Though both 5 GHz channels and 6 GHz channels report the mode as
HOSTAPD_MODE_IEEE80211A, there is a possibility of different HT/VHT/HE
capabilities being available between these bands. Use get_mode() to
obtain correct capabilities to cover cases where the driver reports
different capability values for the 5 GHz and 6 GHz channels.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Determine if the TDLS peer supports TDLS in 6 GHz band based on the HE 6
GHz Band Capabilities element received in the TDLS Setup Response frame.
Indicate the peer's HE 6 GHz capabilities to the driver through
sta_add().
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
External applications can store PMKSA entries persistently and
reconfigure them to wpa_supplicant after restart. This can result in
wpa_supplicant having a PMKSA for FILS authentication without having
matching ERP keys for it which would prevent the previously added
mechanism for dropping FILS PMKSA entries to recover from rejected
association attempts.
Fix this by clearing PMKSA entries configured by external applications
upon FILS connection failure even when ERP keys are not available.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
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.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
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.
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>
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>
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>
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>
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>
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>
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>
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>
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: 8e5739c3ac ("DPP2: Check channel 6 validity before adding it to chirp channel list")
Signed-off-by: Kani M <kanisumi@codeaurora.org>
Simplify the implementation by using shared functions for parsing the
capabilities instead of using various similar but not exactly identical
checks throughout the implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
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.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Commit 3ab35a6603 ("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.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wpa_supplicant_ctrl_iface_deinit() was executed only if the
per-interface control interface initialization had been completed. This
is not the case if driver initialization fails and that could result in
leaving behind references to the freed wpa_s instance in a corner case
where control interface messages ended up getting queued.
Fix this by calling wpa_supplicant_ctrl_iface_deinit() in all cases to
cancel the potential eloop timeout for wpas_ctrl_msg_queue_timeout with
the reference to the wpa_s pointer. In addition, flush any pending
message from the global queue for this interface since such a message
cannot be of use after this and there is no need to leave them in the
queue until the global control interface gets deinitialized.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is a 2 octet field, so need to use WPA_GET_LE16() here instead of
using only the first octet of the value.
Fixes: bbd3178af4 ("MSCS: Add support to process MSCS Response frames")
Signed-off-by: Jouni Malinen <j@w1.fi>
Process the received comeback cookie and retry automatically if the AP
allows this. Otherwise, provide the cookie to upper layers to allow a
later attempt with the cookie.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
The new wpa_supplicant control interface command "PASN_DEAUTH
bssid=<BSSID>" can now be used to flush the local PTKSA cache for the
specified BSS and to notify the AP to request it to drop its PTKSA as
well.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
For testing purposes, add support for corrupting the MIC in PASN
Authentication frames for both wpa_supplicant and hostapd.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When a public key is included in the PASN Parameters element, it should
be encoded using the RFC 5480 conventions, and thus the first octet of
the Ephemeral Public Key field should indicate whether the public key is
compressed and the actual key part starts from the second octet.
Fix the implementation to properly adhere to the convention
requirements for both wpa_supplicant and hostapd.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
An EAPOL frame may be pending when wpa_supplicant requests to
deauthenticate. At this stage the EAP SM cache is already cleaned by
calling eapol_sm_invalidate_cached_session(). Since at this stage the
wpa_supplicant's state is still set to associated, the EAPOL frame is
processed and results in a crash due to NULL dereference.
This wasn't seen previously as nl80211 wouldn't process the
NL80211_CMD_CONTROL_PORT_FRAME, since wpa_driver_nl80211_mlme() would
set the valid_handler to NULL. This behavior was changed in commit
ab89291928 exposing this race.
Fix it by ignoring EAPOL frames while the deauthentication is in
progress.
Fixes: ab89291928 ("nl80211: Use process_bss_event() for the nl_connect handler")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Add the address family when manually constructing IPv4 addresses in
eapol_test on Windows. Otherwise other functions, like hostapd_ip_txt()
in src/utils/ip_addr.c, that rely on addr->af being set fail miserably.
The non-Windows option uses hostapd_parse_ip_addr() which does this as
part of the helper function.
Signed-off-by: Stefan Paetow <oss@eons.net>
This adds new control interface commands TWT_SETUP and TWT_TEARDOWN. For
now, these are only for testing purposes to be able to trigger
transmission of the TWT Action frames without configuring any local
behavior for TWT in the driver.
Signed-off-by: Ben Greear <greearb@candelatech.com>
The roam D-Bus and ROAM control itnerface commands flip the reassociate
bit before calling wpa_supplicant_connect(). wpa_supplicant connect
eventually aborts ongoing scans (if any), which causes scan results to
be reported. Since the reassociate bit is set, this will trigger a
connection attempt based on the aborted scan's scan results and cancel
the initial connetion request. This often causes wpa_supplicant to
reassociate to the same AP it is currently associated to instead of the
explicitly requested roaming target.
Add a roam_in_progress flag to indicate that we're currently attempting
to roam via an explicitly request to a specific BSS so that we don't
initiate another connection attempt based on the possibly received scan
results from a scan that was in progress at the time the roam command
was received.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
The wpa_ie buffer is now allocated here and needs to be freed before
returning from the function.
Fixes: d2ba0d719e ("Move assoc param setting into a helper function")
Signed-off-by: Jouni Malinen <j@w1.fi>
Use a shared code path for freeing the wpa_ie buffer to avoid
unnecessary complexity with a separate return for the non-FILS case.
Signed-off-by: Jouni Malinen <j@w1.fi>
Build eap_*.so into the wpa_supplicant similarly with the wpa_supplicant
binary and include the shared helper functions from additional files
into the builds. This got broken at some point with the build system
changes.
Signed-off-by: Jouni Malinen <j@w1.fi>
These frames are used for verifying that a specific SA and protected
link is in functional state between two devices. The IEEE 802.11
standard defines only a case that uses individual MAC address as the
destination. While there is no explicit rule on the receiver to ignore
other cases, it seems safer to make sure group-addressed frames do not
end up resulting in undesired behavior. As such, drop such frames
instead of interpreting them as valid SA Query Request/Response.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
For an autonomous P2P group on the 5 GHz band, a channel was picked only
from the operating class 115 which is not available in the EU region
anymore. As a result, an autonomous group creation would always fail in
this generic 5 GHz channel case.
There are more possible available channels for the 5 GHz currently.
Especially in the EU region, the operating class 115 channels are no
longer available, but SRD channels (the operating class 124) are
available. Allow them to be used here if they are marked as allowed for
P2P GO use.
In addition, iterate through all the potential options instead of just
checking the first randomly picked channel. Start this iteration from
random position to maintain some randomness in this process.
Signed-off-by: Jimmy Chen <jimmycmchen@google.com>
Determine if the TDLS peer is HE capable based on HE Capability element
received in the TDLS Setup Response frame. Indicate the peer's HE
capabilities to the driver through sta_add().
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
