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>
Allow sae_pwe parameter to be configured per-network and enforce the
SAE hash-to-element mechanism for the P2P GO if it is started on
a 6 GHz channel.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Existing logic to disable HE in hostapd_set_freq_params() is to check
he_cap != NULL, but this is not correct as he_cap is defined as a stack
member of hostapd_hw_modes which can't be NULL. Add one more check
!he_cap->he_supported to make sure HE can be disabled if the driver not
support it.
This fixes a case where a driver does not support HE, but hostapd.conf
enables HE/HT40 on the 2.4 GHz band and hostapd failed to start with
error '40 MHz channel width is not supported in 2.4 GHz'.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add a QCA vendor attribute to indicate agile spectral scan support for
320 MHz mode. Add another attribute to indicate the number of detectors
used for spectral scan in 320 MHz mode.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
After roaming from WPA2-AP (group=CCMP) to WPA-AP (group=TKIP) using
driver-based SME and roaming trigger, GTK renewal failures are observed
for the currently associated WPA-AP because of group cipher mismatch,
resulting in deauthentication with the AP.
Update the group cipher and pairwise cipher values in wpa_sm from
association event received from the driver in case of SME offload to the
driver to address GTK renewal failures (and similar issues) that could
happen when the driver/firmware roams between APs with different
security profiles.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Introduce a new vendor command QCA_NL80211_VENDOR_SUBCMD_ROAM_EVENTS
that aims to configure/trigger the roam events from the driver.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add an explicit check for msg->channel_list != NULL instead of depending
on msg->channel_list_len > 0 implying that. This is to silence invalid
static analyzer reports.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add an explicit check for modes != NULL instead of depending on
num_modes > 0 implying that. This is to silence invalid static analyzer
reports.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Support adding/deleting vendor elements dynamically for AP mode while it
is started by wpa_supplicant instead of hostapd which already supported
this. This adds ap_assocresp_elements global parameter and UPDATE_BEACON
control interface command to take the changed values into effect.
Usage in wpa_cli:
Add vendor IE for (Re)Association Response frames
> set ap_assocresp_elements=xxxx
Add vendor IE for Beacon/Probe Response frames
> set ap_vendor_elements=xxxx
Delete vendor IE from (Re)Association Response frames
> set ap_assocresp_elements
Delete vendor IE from Beacon/Probe Response frames
> set ap_vendor_elements
To make vendor IE changes take effect
> update_beacon
Signed-off-by: Chaoli Zhou <zchaoli@codeaurora.org>
Add support to send DSCP Policy Query frame using a new control
interface command DSCP_QUERY. This includes support for a wildcard DSCP
query and a DSCP query with a single Domain Name attribute.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Add support to parse WFA Capabilities element from the (Re)Association
Response frame. Also register a timeout for the station to wait before
sending a new DSCP query if requested by AP.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Indicate DSCP Policy capability by including a WFA Capabilities element
containing the relevant bit set to 1 in the (Re)Association Request
frames when enabled by user.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Add support to prepare and send DSCP response action frame to the
connected AP in response to a new control interface command DSCP_RESP.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Add support to parse received DSCP Policy Request frames and send the
request details as control interface events.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
The DSCP policy capability is disabled by default. The user frameworks
which have support for handling DSCP policy request messages need to
enable this capability explicitly to allow wpa_supplicant to advertise
the capability to the AP and allow the related frames to be processed.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
This function is not specific to GAS, so make it available throughout
wpa_supplicant without requiring CONFIG_GAS.
Signed-off-by: Jouni Malinen <jouni@codeaurora.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>
This new vendor command aims to indicate the driver to enable the
monitor mode for an interface on which this command is issued. Once
enabled, the frames (both TX and RX) on this interface are sent to an
active coexisting monitor interface.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add new attributes for supporting MBSSID multi groups notifications
to qca_wlan_vendor_attr_mbssid_tx_vdev_status
(QCA_NL80211_VENDOR_SUBCMD_MBSSID_TX_VDEV_STATUS).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
QCA_ROAM_REASON_USER_TRIGGER was wrongly documented as
QCA_ROAM_REASON_EXPLICIT_REQUEST, so correct it.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Enhance the P2P_GROUP_ADD command to support DFS channel with 80 and 160
MHz bandwidth to be used for autonomous GO when using offloaded DFS.
For example, 'P2P_GROUP_ADD freq=5500 max_oper_chwidth=80 ht40 vht'
- Previous behavior: AP fallback to channel 100 using 20 MHz with
"No VHT higher bandwidth support for the selected channel 100"
- Enhanced behavior: AP starts on channel 100 using 80 MHz with
"VHT center channel 106 for 80 or 80+80 MHz bandwidth"
This functionality is on top of the driver's capability to offload DFS,
which is advertized through WPA_DRIVER_FLAGS_DFS_OFFLOAD.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add QCA vendor interface support for configuring background scan related
parameters to the driver/firmware.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit 45c3e72952 ("Add frequency to operating class determination
for 5 GHz 100..140") extends ieee80211_freq_to_channel_ext() with
knowledge of the operating classes for the 5 GHz channels 100..140.
Per "Table E-4 - Global operating classes" in IEEE Std 802.11-2020, 5
GHz channel 144 also maps to same operating classes, so update hostapd
code to reflect the change.
This issue is found when OCV enabled and 4-way-handshake failed due
to client OCI includes op_class 0 for channel 144. This showed
up in following manner in the debug log:
WPA: OCI KDE in EAPOL-Key - hexdump(len=9): dd 07 00 0f ac 0d 00 90 00
Error interpreting OCI: unrecognized opclass/channel pair (0/144)
Signed-off-by: Hu Wang <huw@codeaurora.org>
Enable support for P2P connection in 6 GHz with the channel width of 40
MHz, 80 MHz, and 160 MHz. The flag max_oper_chwidth is used to configure
the maximum channel width for P2P connection in 6 GHz with the commands
P2P_CONNECT, P2P_INVITE, and P2P_GROUP_ADD.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Current definition of wpas_p2p_get_ht40_mode() determines secondary
offset in the 5 GHz band. Enhance the functionality of this function to
determine offset to support 6 GHz channels also.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Clone pmf and p2p_6ghz_disable configuration values when creating a new
P2P group interface. PMF is required in 6 GHz band operation.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Add a new attribute into qca_wlan_vendor_attr_ll_stats_results to
support getting interface time slicing duty cycle info.
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>
Align the p2p_buf_add_pref_channel_list() prototype and definition in
p2p_build.c and p2p_i.h. Use unsigned int over u32 as it is actully
called with an unsigned int parameter.
This removes compilation warning on platform where u32 != unsigned int.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
IEEE Std 802.11ax-2021 added channel 177 into global operating class 125
and consequently channel 173 in global operating class 126 (HT40+) and
channel 177 in global operating class 127 (HT40-).
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
Skip the test of HE PHY capability bit "Support for a 40 MHz and 80 MHz
channel width" when starting an AP with a 20 MHz channel on the 5 GHz
band.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
Currently while selecting a preferred frequency when no preference is
known, p2p_no_go_freq is not considered for 5 GHz and 60 GHz channels.
This results in starting GO on the channels that are configured not to
allow the local device as GO.
Use wpas_p2p_supported_freq_go api to check if the p2p_no_go_freq
configuration before selecting the preferred frequency for GO.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
For some 6 GHz operating class like 134, there is a possibility where
the ch variable used for channel iterator overflows when it is
incremented. Fix this by updating the datatype of ch variable to
avoid integer overflow while incrementing.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
