Add a QCA vendor subcommand QCA_NL80211_VENDOR_SUBCMD_ADD_STA_NODE with
attributes qca_wlan_vendor_attr_add_sta_node_params to add STA peer
entries in AP mode. This vendor sub command is used in FT roaming
scenario to send STA node information from application/service to
driver/firmware. The attributes defined in enum
qca_wlan_vendor_attr_add_sta_node_params are used to deliver the
parameters.
Signed-off-by: Shiva Sankar Gajula <sgajula@codeaurora.org>
The OEM data binary blobs from application/service will be routed to the
appropriate device based on this attribute value. This optional
attribute is used to specify whether the device type is virtual or
physical. This attribute can be omitted when the command is for a
virtual device.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Some chipsets don't have the capability to run agile spectral scan with
160/80+80 MHz modes. Add separate agile spectral scanning capability
flags for 160, 80+80, and non-160 MHz modes to cover such cases.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
In the SME-in-driver case, wpa_supplicant used only the selected SAE
auth_alg value as the trigger for enabling external authentication
support for SAE. This prevented the driver from falling back to full SAE
authentication if PMKSA caching was attempted (Open auth_alg selected)
and the cached PMKID had been dropped.
Enable external auth based on SAE/FT-SAE key_mgmt, rather than doing
this based on SAE auth_alg, so that the driver can go through full SAE
authentication in cases where PMKSA caching is attempted and it fails.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When operating on the 6 GHz band, add 6 GHz Operation Information inside
the HE Operation element and don't publish HT/VHT IEs.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
- Replace HOSTAPD_MODE_IEEE80211AX mode checks with is_6ghz_op_class()
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Add support for new hardware mode for 6 GHz band. 6 GHz operation is
defined in IEEE P802.11ax/D4.3. 6 GHz band adds global operating classes
131-135 that define channels in frequency range from 5940 MHz to 7105
MHz.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
- Remove HOSTAPD_MODE_IEEE80211AX mode
- Replace check for HOSTAPD_MODE_IEEE80211AX with is_6ghz_freq()
- Move center_idx_to_bw_6ghz() to ieee802_11_common.c file
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
This is needed to allow the 6 GHz operating classes to be compared
against the driver support channels since the channel numbers are not
really unique identifiers of a channel even within a single band.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Verify behavior with sae_pwe configuration values 0..2, i.e., test the
new hash-to-element mechanism for deriving PWE and negotiation for which
method to use.
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>
If hostapd is configured to enable only the hash-to-element version of
SAE PWE derivation (sae_pwe=1), advertise BSS membership selector to
indicate this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This parameter can be used to specify which PWE derivation mechanism(s)
is enabled. This commit is only introducing the new parameter; actual
use of it will be address in separate commits.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This parameter can be used to specify which PWE derivation mechanism(s)
is enabled. This commit is only introducing the new parameter; actual
use of it will be address in separate commits.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
These are the defined values/identifiers for SAE hash-to-element
mechanism from IEEE P802.11-REVmd/D3.0.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The initial crypto wrapper implementation for wolfSSL seems to have
included a copy-paste error in crypto_bignum_sub() implementation that
was identical to crypto_bignum_add() while mp_sub() should have been
used instead of mp_add().
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The logic for displaying the message about no configuration being
available for the Enrollee was reversed when support for multiple Config
Objects was added. This was supposed to be shown only if the first
Config Object fails (i.e., when no configuration is available); not when
second attempt fails (since the first one had already been successful in
that case).
Fixes: 7eb06a3369 ("DPP2: Allow multiple Config Objects to be build on Configurator")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
hostapd is by default waiting STA to send SAE Confirm before sending the
SAE Confirm. This can now be configured with sae_confirm_immediate=1
resulting in hostapd sending out SAE Confirm immediately after sending
SAE Commit.
These are the two different message sequences:
sae_confirm_immediate=0
STA->AP: SAE Commit
AP->STA: SAE Commit
STA->AP: SAE Confirm
AP->STA: SAE Confirm
STA->AP: Association Request
AP->STA: Association Response
sae_confirm_immediate=1
STA->AP: SAE Commit
AP->STA: SAE Commit
AP->STA: SAE Confirm
STA->AP: SAE Confirm
STA->AP: Association Request
AP->STA: Association Response
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There is no need for #ifdef/#else/#endif construction in
network_fields[] to cover "mode" (which is completely independent of
CONFIG_MESH) or two separate conditional blocks for mesh related network
fields, so move these into a single conditionally included block.
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>