Add support for PKEXv2 core protocol. This defines a new PKEX Exchange
Request message type with protocol negotiation and different rules for
key derivation with PKEXv2 or newer is used.
This does not change existing behavior for PKEX, i.e., the PKEXv1
variant will still be used by default.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow the dpp_test parameter to be used to request the Protocol Version
attributed to be omitted from the Peer Discovery Request/Response
message.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Verify that the Protocol Version attribute is used appropriate in Peer
Discovery Request/Response messages in cases where the signed Connector
includes the version information.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Generate Peer Discovery Request/Response messages using the protected
version from the Connector, if present, instead of the currently
supported protocol version which might be higher than the one that got
included into the signed Connector during provisioning earlier.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Reduced neighbor report has a field to indicate whether unsolicited
Probe Response transmission is active. Add a check to return failure if
both FILS discovery and unsolicited Probe Response are enabled at the
same time to ensure that RNR includes valid data.
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
When a Probe Request frame from a station includes an SSID matching that
of a co-located 6 GHz AP, AP should respond with a Probe Response frame
that includes Reduced Neighbor Report element containing information
regarding the requested BSS.
Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Update 2.4/5 GHz Beacon frames every time Beacon frames for co-located 6
GHz AP(s) are set. This is required for 6 GHz out-of-band discovery so
that lower band Beacon frames will include RNR element with 6 GHz AP
information irrespective of the AP bring-up order. Similarly, RNR is
included in FILS Discovery frames by default in 6 GHz-only mode,
updating the Beacon frames will remove it when co-located 2.4/5 GHz
interfaces are brought up.
This change also ensures that the changes in 6 GHz AP configuration such
as new channel and bandwidth get reflected in the lower bands Beacon
frames.
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Add Reduced Neighbor Report element in Beacon, Probe Response, and FILS
Discovery frames.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Include Reduced Neighbor Report element in Beacon and Probe Response
frames by default if the reporting AP is 2.4/5 GHz and it is co-located
with a 6 GHz AP. Similarly, include RNR by default in FILS Discovery
frames if the AP is a standalone 6 GHz AP.
Signed-off-by: John Crispin <john@phrozen.org>
Co-developed-by: Aloka Dixit <alokad@codeaurora.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Calculate the length and include data for the BSSes active on the same
radio as the reporting BSS in the Reduced Neighbor Report element. This
element is included in Beacon and Probe Response frames.
Signed-off-by: John Crispin <john@phrozen.org>
Co-developed-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Co-developed-by: Muna Sinada <msinada@codeaurora.org>
Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Co-developed-by: Aloka Dixit <alokad@codeaurora.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Include data from the existing neighbor database in the Reduced Neighbor
Report element in Beacon frames if the configuration option 'rnr' is
enabled for the BSS.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Co-developed-by: Aloka Dixit <alokad@codeaurora.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Adds configuration option 'rnr' to enable the reduced neighbor report
elements in Beacon and Probe Response frames.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Add a new field to include BSS Parameter subfield in the neighbor
database as described in IEEE Std 802.11ax-2021, Figure 9-632a (BSS
Parameters subfield format). This field holds information related to
multiple BSSID, access point co-location, and 20 TU probe response
active/inactive state.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Calculate and store short SSID in hostapd_data context during config
load time and in neighbor report.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Aloka Dixit <alokad@codeaurora.org>
Adds the ability to specify the dialog token of a WNM BSS Transition
Management Request frame via the hostapd control interface.
For this, the new 'dialog_token' option can be used with the BSS_TM_REQ
command. It accepts values as an 8 bit unsigned integer. If not
specified, the dialog token is set to 1 like before.
Signed-off-by: David Bauer <mail@david-bauer.net>
Stop the DPP Controller instance, if one is started, when the hostapd
interface that was used to start that Controller is removed. This is
needed to remove the control pointers that point to the soon-to-be-freed
hostapd structures. This fixes an issue where a Controller operation
with multiple interfaces could have resulted in references to freed
memory if an interface is removed without explicitly stopping the DPP
Controller.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The disable_dgaf config field is only available in case hostapd is
compiled with Hotspot 2.0 support (CONFIG_HS20=y), however Proxy-ARP
(CONFIG_PROXYARP=y) does not depend on Hotspot 2.0.
Only add the code related to this config field when Hotspot 2.0 is
enabled to fix compilation with the aformentioned preconditions.
Signed-off-by: David Bauer <mail@david-bauer.net>
Replaced the word "sanity" with the inclusive word "validity". The
comment in acs_survey_interference_factor() was referring a function
that does not exist, so remove it instead of trying rename the function.
Signed-off-by: Arowa Suliman <arowa@chromium.org>
Commit 0cb39f4fd5 ("HE: Extend BSS color support") sets the BSS Color
default value to 1 as "Interoperability testing showed that stations
will require a BSS color to be set even if the feature is disabled."
A new interop issue was observed with hardcoded BSS color value of 1:
- REF device using one interface (e.g., wlan0) to connect to an HE
AP, whose BSS color is enabled and value is 1.
- REF device using another interface (e.g., p2p0) to connect to a
P2P GO using BSS color default settings.
(i.e., BSS color disabled and value is 1).
- REF device checks both AP's and P2P GO's BSS Color values even though
GO's BSS color is disabled. This causes collision of the BSS
color somehow causing RX problems.
For DUT as a P2P GO, its firmware uses default BSS color value 1 from
wpa_supplicant, then triggers a timer (e.g., 120 s) to update its BSS
color values based on its neighboring BSSes. To reduce the likelihood of
BSS color collision with REF device before that, use a random BSS Color
if not defined in the config file.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Channel 100 is a valid channel to choose for 80 MHz operation. However,
it was converted to 5500 MHz, not 5550 MHz, for the 80 MHz case while
the conversion to other bandwidths was done correctly. In fact, there is
no channel assigned to this frequency 5550 MHz.
Fix this obvious typo to allow ACS to select channel 100 for 80 MHz
operation again.
Fixes: bef5eee4f7 ("Convert channel to frequency based selection for AP mode ACS")
Signed-off-by: David Bauer <mail@david-bauer.net>
For the function hostapd_get_sta_tx_rx(), the name
hostapd_get_sta_info() is more appropriate as it is also responsible for
getting many other STA specific params like RSSI, inactive milliseconds
along with TX and RX bytes.
Signed-off-by: Gokul Sivakumar <gokulkumar792@gmail.com>
When a Mesh interface is managed by wpa_supplicant, include the peer
link connected time (secs) in the output of "sta <addr>", "all_sta"
wpa_cli cmds for each peer. This will be helpful to find when the peer
link connection got established. The NL80211_STA_INFO_CONNECTED_TIME
netlink attribute data is used for this purpose if available.
$ wpa_cli -i mesh0 all_sta
02:00:00:00:02:00
flags=[ASSOC][WMM][HT]
aid=1
capability=0x0
listen_interval=0
supported_rates=82 84 8b 96 8c 12 98 24 b0 48 60 6c
timeout_next=NULLFUNC POLL
rx_packets=77
tx_packets=3
rx_bytes=8510
tx_bytes=284
inactive_msec=104
signal=-30
rx_rate_info=65 mcs 0
tx_rate_info=65 mcs 0
ht_mcs_bitmask=ffff0000000000000000
connected_time=24
ht_caps_info=0x103c
The connected_time field in the output of "hostapd_cli -i ap0 all_sta"
cmd is not affected and it will continue to show the connected time
maintained by hostapd for each STA.
Signed-off-by: Gokul Sivakumar <gokulkumar792@gmail.com>
../src/ap/ieee802_11.c: In function ‘pasn_wd_handle_sae_commit’:
../src/ap/ieee802_11.c:2401:60: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
wpa_printf(MSG_DEBUG, "PASN: SAE buffer too short. len=%lu",
~~^
%u
buf_len);
~~~~~~~
../src/ap/ieee802_11.c: In function ‘pasn_wd_handle_sae_confirm’:
../src/ap/ieee802_11.c:2477:60: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
wpa_printf(MSG_DEBUG, "PASN: SAE buffer too short. len=%lu",
~~^
%u
buf_len);
~~~~~~~
../src/ap/ieee802_11.c: In function ‘pasn_wd_handle_fils’:
../src/ap/ieee802_11.c:2707:62: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
wpa_printf(MSG_DEBUG, "PASN: FILS: Buffer too short. len=%lu",
~~^
%u
buf_len);
~~~~~~~
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
When the driver provides a list of supported modes, hostapd ended up
adding channel 6 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.
This is similar to an earlier wpa_supplicant change in commit
8e5739c3ac ("DPP2: Check channel 6 validity before adding it to chirp
channel list").
Signed-off-by: Disha Das <dishad@codeaurora.org>
IEEE Std 802.11-2016, 12.4.7.6 specifies:
An SAE Commit message with a status code not equal to SUCCESS shall
indicate that a peer rejects a previously sent SAE Commit message.
An SAE Confirm message, with a status code not equal to SUCCESS, shall
indicate that a peer rejects a previously sent SAE Confirm message.
Thus when SAE authentication failure happens, authentication transaction
sequence number should not be incremented.
Signed-off-by: Jia Ding <jiad@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>
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>
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>
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>
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>
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>
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.
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Add support for the 6 GHz frequencies using 40, 80, and 160 MHz
bandwidths in the AP mode ACS.
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Convert channel based selection to frequency based selection for AP mode
ACS to accommodate for the 6 GHz band needs.
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
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.
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
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.
Signed-off-by: Lavanya Suresh <lavaks@codeaurora.org>
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.
Signed-off-by: Kani M <kanisumi@codeaurora.org>
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.
Signed-off-by: Disha Das <dishad@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>
