Do not use VERSION_STR directly as the format string to printf() since
it is possible for that string to contain '%'.
Signed-off-by: Didier Raboud <odyx@debian.org>
SM Power Save was described in somewhat unclear manner in IEEE Std
802.11n-2009 as far the use of it locally in an AP to save power. That
was clarified in IEEE Std 802.11-2016 to allow only a non-AP STA to use
SMPS while the AP is required to support an associated STA doing so. The
AP itself cannot use SMPS locally and the HT Capability advertisement
for this is not appropriate.
Remove the parts of SMPS support that involve the AP using it locally.
In practice, this reverts the following commits:
04ee647d58 ("HT: Let the driver advertise its supported SMPS modes for AP mode")
8f461b50cf ("HT: Pass the smps_mode in AP parameters")
da1080d721 ("nl80211: Advertise and configure SMPS modes")
Signed-off-by: Jouni Malinen <j@w1.fi>
A driver supports FT if it either supports SME or the
NL80211_CMD_UPDATE_FT_IES command. When selecting AKM suites,
wpa_supplicant currently doesn't take into account whether or not either
of those conditions are met. This can cause association failures, e.g.,
when an AP supports both WPA-EAP and FT-EAP but the driver doesn't
support FT (wpa_supplicant will decide to do FT-EAP since it is unaware
the driver doesn't support it). This change allows an FT suite to be
selected only when the driver also supports FT.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
The new sae_pwe=3 mode can be used to test non-compliant behavior with
SAE Password Identifiers. This can be used to force use of
hunting-and-pecking loop for PWE derivation when Password Identifier is
used. This is not allowed by the standard and as such, this
functionality is aimed at compliance testing.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The 5 GHz channels are stored in one hw_features set with mode
HOSTAPD_MODE_IEEE80211A while the 6 GHz channels will need to be stored
in a separate hw_features set (but with same mode
HOSTAPD_MODE_IEEE80211A) due to possibility of different HT/VHT/HE
capabilities being available between the 5 GHz and 6 GHz bands.
Iterate through all hw_features sets and check and match the band of
channel supported by the hw_features set while getting the hw_features
set in get_mode(). This allows both the 5 GHz and 6 GHz channels to be
found and correct capabilities to be used in cases where the driver
reports different capability values between 5 and 6 GHz channels.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the new set_key() parameter "key_flag" to provide more specific
description of what type of a key is being configured. This is needed to
be able to add support for "Extended Key ID for Individually Addressed
Frames" from IEEE Std 802.11-2016. In addition, this may be used to
replace the set_tx boolean eventually once all the driver wrappers have
moved to using the new key_flag.
The following flag are defined:
KEY_FLAG_MODIFY
Set when an already installed key must be updated.
So far the only use-case is changing RX/TX status of installed
keys. Must not be set when deleting a key.
KEY_FLAG_DEFAULT
Set when the key is also a default key. Must not be set when
deleting a key. (This is the replacement for set_tx.)
KEY_FLAG_RX
The key is valid for RX. Must not be set when deleting a key.
KEY_FLAG_TX
The key is valid for TX. Must not be set when deleting a key.
KEY_FLAG_GROUP
The key is a broadcast or group key.
KEY_FLAG_PAIRWISE
The key is a pairwise key.
KEY_FLAG_PMK
The key is a Pairwise Master Key (PMK).
Predefined and needed flag combinations so far are:
KEY_FLAG_GROUP_RX_TX
WEP key not used as default key (yet).
KEY_FLAG_GROUP_RX_TX_DEFAULT
Default WEP or WPA-NONE key.
KEY_FLAG_GROUP_RX
GTK key valid for RX only.
KEY_FLAG_GROUP_TX_DEFAULT
GTK key valid for TX only, immediately taking over TX.
KEY_FLAG_PAIRWISE_RX_TX
Pairwise key immediately becoming the active pairwise key.
KEY_FLAG_PAIRWISE_RX
Pairwise key not yet valid for TX. (Only usable with Extended Key ID
support.)
KEY_FLAG_PAIRWISE_RX_TX_MODIFY
Enable TX for a pairwise key installed with KEY_FLAG_PAIRWISE_RX.
KEY_FLAG_RX_TX
Not a valid standalone key type and can only used in combination
with other flags to mark a key for RX/TX.
This commit is not changing any functionality. It just adds the new
key_flag to all hostapd/wpa_supplicant set_key() functions without using
it, yet.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
"SET driver_signal_override <BSSID> [<si_signal< <si_avg_signal>
<si_avg_beacon_signal> <si_noise> <scan_level>]" command can now be used
to request wpa_supplicant to override driver reported signal levels for
signal_poll and scan results. This can be used to test roaming behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is targeting the case of MAC address change for an association
which may require the interface to be set down for a short moment.
Previously, this ended up flushing the BSS table that wpa_supplicant
maintained and that resulted in having to scan again if the MAC address
was changed between the previous scan and the connection attempt. This
is unnecessary extra latency, so maintain the BSS entries for 5 seconds
(i.e., the same time that the old scan results are consider valid for a
new connection attempt) after an interface goes down.
Signed-off-by: Jouni Malinen <j@w1.fi>
Do not disconnect on interface deinit when WoWLAN is enabled, so we can
boot the system with WoWLAN after S5 (poweroff).
Signed-off-by: Alfonso Sanchez-Beato <alfonso.sanchez-beato@canonical.com>
If hostapd or wpa_supplicant is started with both -s and -f command line
arguments, debug log ended up being written only into syslog and the log
file was left empty. Change this so that the log entries will be written
to both places. Either -s or -f (or both) results in debug log to stdout
being disabled which was already the case.
Signed-off-by: Jouni Malinen <j@w1.fi>
Using the channel parameter for validating allowed channel combinations
is not scalable to add 6 GHz support in the future since channel numbers
are duplicated between 2.4 GHz / 5 GHz bands and 6 GHz band. Hence use
frequency field for all channel combination validation steps done before
starting AP.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
"SET rsnxe_override_{assoc,eapol} <hexdump>" can now be used to override
RSNXE in (Re)Association Request frames and EAPOL-Key msg 2/4 for
testing purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
"SET extra_sae_rejected_groups <groups>" can now be used to enable test
mode in which wpa_supplicant will report additional groups (configured
as space separated integers) when using SAE H2E.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the new RSNXE into (Re)Association Request frames and EAPOL-Key msg
2/4 when using SAE with hash-to-element mechanism enabled. This allows
the AP to verify that there was no downgrade attack when both PWE
derivation mechanisms are enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If the AP advertises RSN Extension element, it has to be advertised
consistently in the unprotected (Beacon and Probe Response) and
protected (EAPOL-Key msg 3/4) frames. Verify that this is the case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
As part of a connection request, set EDMG parameters for the driver to
use in the association. The EDMG parameters are based on EDMG IE
received from the AP's Probe Response frames, the driver's EDMG
capability, and the EDMG configuration from the configuration.
As part of starting an AP, set EDMG parameters for the driver to use for
AP operation. The EDMG parameters are based on the driver's EDMG
capability and the EDMG configuration from the configuration.
This implementation is limited to CB2 (channel bonding of 2 channels)
and the bonded channels must be adjacent, i.e., the supported values for
edmg_channel are 9..13.
Signed-off-by: Alexei Avshalom Lazar <ailizaro@codeaurora.org>
The MBO and OCE specification require the station to mandate use of PMF
when connecting to an MBO/OCE AP that uses WPA2. The earlier
implementation prevented such misbehaving APs from being selected for
connection completely. This looks like the safest approach to take, but
unfortunately, there are deployed APs that are not compliant with the
MBO/OCE requirements and this strict interpretation of the station
requirements results in interoperability issues by preventing the
association completely.
Relax the approach by allowing noncompliant MBO/OCE APs to be selected
for RSN connection without PMF to avoid the main impact of this
interoperability issue. However, disable MBO/OCE functionality when PMF
cannot be negotiated to try to be as compliant as practical with the
MBO/OCE tech spec requirements (i.e., stop being an MBO/OCE STA for the
duration of such workaround association). Also disable support for BTM
in this workaround state since MBO would expect all BTM frames to be
protected.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The WPS component keeps a copy of the network interface MAC address.
When MAC address is changed the WPS copy was not updated so WPS M1
message contained the old address. Some devices check this field
and fail connection attempts.
Update the WPS MAC address on interface MAC address changes.
Signed-off-by: Mikael Kanstrup <mikael.kanstrup@sony.com>
Update connect params will update auth_alg and fils_hlp_req in
wpa_supplicant structure before calling function
wpas_notify_state_changed(). This could have resulted in triggering
inconsistent state change events and messages in the Android framework.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
These parameters for certificate authentication are identical for the
Phase 1 (EAP-TLS alone) and Phase 2 (EAP-TLS inside a TLS tunnel).
Furthermore, yet another copy would be needed to support separate
machine credential in Phase 2. Clean this up by moving the shared
parameters into a separate data struct that can then be used for each
need without having to define separate struct members for each use.
Signed-off-by: Jouni Malinen <j@w1.fi>
The commit ad9a1bfe78 ("nl80211: Share VHT channel configuration for
HE") always enforced that VHT is enabled when HE was enabled. This broke
the mesh functionality on 2.4 GHz with HE because ibss_mesh_setup_freq()
isn't setting up the VHT parameters for 2.4 GHz.
This problem was resolved for 2.4 GHz by commit df4f959988 ("nl80211:
Don't force VHT channel definition with HE"), but it is still possible
to disable VHT during the mesh/IBSS freq setup on 5 GHz - which would
result in the same problem as seen on 2.4 GHz.
The code enabling HE for IBSS/mesh must now make sure that it doesn't
enable HE when VHT could be enforced by the nl80211 driver code but
disabled by the user.
Fixes: 3459c54ac7 ("mesh: Add support for HE mode")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
A new DH public key is sent through this interface to the driver after
every successful connection/roam to a BSS. This helps to do OWE roaming
to a new BSS with drivers that implement SME/MLME operations during
roaming.
This updated DH IEs are added in the subsequent (Re)Association Request
frame sent by the station when roaming. The DH IE from the roamed AP is
given to wpa_supplicant in the roam result event. wpa_supplicant shall
further process these DH IEs to generate the PMK for the 4-way
handshake.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
PMF capability check is done as part of BSS selection routines, but
those are not used when going through the enforced roaming operation
("ROAM <BSSID>" control interface command). While that mechanism is
mainly for testing purposes, extend it to do the same check for PMF to
prevent cases where forced roaming could end up disabling PMF against
the local profile requirement.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit d896874f86 ("nl80211: Indicate 802.1X 4-way handshake offload
in connect") used the req_key_mgmt_offload flag to indicate to the
driver that it should offload the 802.1X handshake. However, this field
was existing and used for a different offload API. This causes
wpa_supplicant to send a connect request without the WANT_1X_HS flag and
the subsequent set-pmk is rejected causing the connection to fail. Fix
that by introducing a new flag req_handshake_offload so the offloads are
no longer entangled.
Fixes: d896874f86 ("nl80211: Indicate 802.1X 4-way handshake offload in connect")
Reported-by: Stefan Wahren <wahrenst@gmx.net>
Tested-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Mesh points can partially support HE features (when requiring no
controlling STA/AP) as long as hardware supports it. The kernel just
requires support for HE mesh and wpa_supplicant can forward the peer
capabilities to the kernel for further processing.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
The ssid->mode is from type enum wpas_mode and all its constants start
with WPAS_MODE_*. Still some of the code sections used the
IEEE80211_MODE_* defines instead of WPAS_MODE_*.
This should have no impact on the actual code because the constants for
INFRA, IBSS, AP and MESH had the same values.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
Add support to disable/enable BTM support using configuration and
wpa_cli command. This is useful mainly for testing purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The bandwidth values are shared between VHT and HE mode so remove the
VHT specific prefix.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
The new wpa_supplicant network profile configuration parameter
ft_eap_pmksa_caching=1 can be used to enable use of PMKSA caching with
FT-EAP for FT initial mobility domain association. This is still
disabled by default (i.e., maintaining previous behavior) to avoid
likely interoperability issues.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
These cases are for the IEEE 802.11 Status Code and Reason Code and
those fields are unsigned 16 bit values, so use the more appropriate
type consistently. This is mainly to document the uses and to make the
source code easier to understand.
Signed-off-by: Jouni Malinen <j@w1.fi>
Logs involving IEEE 802.11 Reason Codes output the Reason Code value,
but do not provide any explanation of what the value means. This change
provides a terse explanation of each Reason Code using the latter part
of the reason code #define names.
Signed-off-by: Alex Khouderchah <akhouderchah@chromium.org>
In case of drivers that don't use wpa_supplicant as SME, autoscan
feature was never disabled.
Signed-off-by: Wiktor Drewniak <wiktor.drewniak@gmail.com>
For reassociation with the same AP wpa_supplicant attempts to use cached
PMKSA. For this purpose PMKID is passed in RSNE in (Re)Association
Request frame. In the case of SAE AP, open authentication shall be used
during reassociation. Otherwise cached PMKID becomes invalid after full
SAE authentication.
The previous implementation correctly handles SME-in-wpa_supplicant
cases. However SME-in-driver cases, complete SAE authentication is
performed. As a result, first reassociation attempt fails.
Fix SME-in-driver behavior by reseting authentication algorithm to
WPA_AUTH_ALG_OPEN when reassociating with SAE AP with an existing PMKSA
cache entry.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
In case of connection attempt failure, set 'normal_scans'
to zero, as otherwise it is possible that scheduled scan
would be used and not normal scan, which might delay the
next connection attempt.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Properly handle the case where OWE IE is allocated, but
there is no space left to add it in the WPA IE buffer.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
MBO attributes Non-preferred channel list and Cellular capabilities are
updated using WNM-Notification Request frame to the current connected
BSS. These same attributes need to be added in the (Re)Association
Request frame sent by the station when roaming, including the case where
the driver/firmware takes care of SME/MLME operations during roaming, so
we need to update the MBO IE to the driver.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
FT-SAE is considered stronger than FT-PSK, so prefer it over FT-PSK
similarly to how SAE is preferred over WPA-PSK.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it a bit easier to figure out why wpa_supplicant selects a
specific cipher/AKM for association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If both of these AKMs are enabled in the wpa_supplicant network profile
and the target AP advertises support for both, prefer the FT version
over the non-FT version to allow FT to be used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a network profile has both SAE and FT-SAE enabled, SAE was previously
picked (and used incorrectly as explained in the previous commit). This
is not ideal since use of FT protocol can speed up roaming within in
mobility domain. Reorder this checks so that FT-SAE is preferred over
SAE if both are enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
