Found using x86_64-cros-linux-gnu-clang (Chromium OS
12.0_pre416183_p20210305-r3 clang version 12.0.0):
radius_client.c:818:24: warning: cast to smaller integer ...
RadiusType msg_type = (RadiusType) sock_ctx;
Signed-off-by: Joshua Emele <jemele@chromium.org>
Add support to receive and process SCS Response frames from the AP and
indicate the status to upper layers.
Signed-off-by: Vinita S. Maloo <vmaloo@codeaurora.org>
Commit 0b8889d8e5 ("P2P: Do not stop Listen state if it is on
correct channel") added a optimization to use Listen state's
remain-on-channel to send out GO Negotiation response frame quickly.
But in Listen state, if GO Negotiation request frame is received before
the remain-on-channel started event from the driver, the above
optimization is not triggered. This showed up in following manner in the
debug log:
p2p0: Starting radio work 'p2p-listen'@0xb4000070ae22d420 after 0.000114 second wait
nl80211: Remain-on-channel cookie 0x100 for freq=2412 MHz duration=204
P2P: Received GO Negotiation Request from 6e:fa:a7:86:e5:e5(freq=2412)
P2P: GO Negotiation with 6e:fa:a7:86:e5:e5
P2P: Stopping find
P2P: Clear timeout (state=WAIT_PEER_CONNECT)
P2P: State WAIT_PEER_CONNECT -> IDLE
nl80211: Cancel remain-on-channel with cookie 0x100
p2p0: Radio work 'p2p-listen'@0xb4000070ae22d420 done in 0.074348 seconds
p2p0: radio_work_free('p2p-listen'@0xb4000070ae22d420): num_active_works --> 0
P2P: State IDLE -> GO_NEG
P2P: Sending GO Negotiation Response
Off-channel: Send action frame: freq=2412 dst=6e:fa:a7:86:e5:e5 src=da:3c:83:7d:70:2b bssid=da:3c:83:7d:70:2b len=196
nl80211: Remain-on-channel event (cancel=0 freq=2412 channel_type=0 duration=400 cookie=0x100 (match))
nl80211: Remain-on-channel event (cancel=1 freq=2412 channel_type=0 duration=0 cookie=0x100 (match))
P2P: GO Negotiation Response (failure) TX callback: success=0
Fix this by adding p2p->pending_listen_freq == freq condition for the
optimization so that the case where the remain-on-channel command has
already been issued to the driver, but the start event has not yet been
received, is covered as well.
Fixes: 0b8889d8e5 ("P2P: Do not stop Listen state if it is on correct channel")
Signed-off-by: Hu Wang <huw@codeaurora.org>
Add QCA new status vendor attribute
QCA_WLAN_VENDOR_TWT_STATUS_POWER_SAVE_EXIT_TERMINATE
to indicate the TWT session termination due to power save
exit request from userspace.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the following vendor attribute to indicate the bandwidth to be used
for spectral scan operation:
- QCA_WLAN_VENDOR_ATTR_SPECTRAL_SCAN_CONFIG_BANDWIDTH
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Enhance QCA_NL80211_VENDOR_SUBCMD_THERMAL_CMD to fetch thermal
statistics for different temperature levels from the driver to
userspace. The statistics will be stored in the driver/firmware for
predefined temperature levels and will be reported to userspace when
QCA_NL80211_VENDOR_SUBCMD_THERMAL_CMD is sent with the command type
QCA_WLAN_VENDOR_ATTR_THERMAL_CMD_TYPE_GET_THERMAL_STATS.
The thermal statistics can be cleared from userspace by sending a
QCA_NL80211_VENDOR_SUBCMD_THERMAL_CMD command with the type
QCA_WLAN_VENDOR_ATTR_THERMAL_CMD_TYPE_CLEAR_THERMAL_STATS.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
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>
Add QCA vendor attributes to configure the driver to enable/disable the
Broadcast TWT support and Rx Control Frame To MultiBSS support in HE
capabilities information field. This attribute is used for testing
purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Update QCA_WLAN_VENDOR_ATTR_TWT_SETUP_WAKE_TIME_TSF
TWT attribute to use it in TWT setup command to pass TSF value.
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
Add QCA vendor interface for userspace to get information of usable
channels for different interface types from the driver/firmware.
Signed-off-by: Vamsi Krishna <vamsin@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>
