Extend the NAN Subscribe and Publish methods to allow p2p=1 to be
specified to include P2P attributes in a P2P IE to be added into the NAN
Element Container attribute. In addition, use the P2P Device Address for
the NAN SDFs for the P2P cases.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
When wpa_supplicant needed to update the internal BSS table with the
latest scan results from the driver, it fetched all BSSs and processed
them all. This is unnecessary for cases where an update is needed only
for a specific BSS. Optimize this by filtering out the unnecessary
entries from the results.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use of wpa_s->p2p_go_no_pri_sec_switch needs to be conditional on
CONFIG_P2P being defined for the build to avoid a compilation error and
ssid->p2p_group to avoid using this for non-P2P AP mode case in
wpa_supplicant. Furthermore, it is better to clear this flag when
stopping a P2P GO to reduce risk of this getting used for a separate
instance of starting a GO.
Fixes: b18d957593 ("P2P: Disable pri/sec channel switch for GO with forced frequency")
Signed-off-by: Jouni Malinen <j@w1.fi>
When wpa_supplicant receives a request to start a P2P group owner on a
fixed frequency with bandwidth wider than 20 MHz, wpa_supplicant scans
for neighboring BSSs prior to starting the GO. This is done to switch
the primary/secondary channels if there are any other networks which are
operating on the same secondary channel. Though this logic is defined
for 20/40 MHz coexistence and might improve throughput, there are P2P
use cases where this logic causes problem:
1. The file transfer use case takes time to start the file transfer or
even fails when the 20/40 coex scan repeatedly fails due to an
ongoing externally triggered scan happening in the system.
2. wpa_supplicant overrides the channel which is selected by the
application based on the best channel it derived by looking into
the channel conditions. This degrades the expected throughput.
3. Latency sensitive applications experience long time to
start the group owner which gives a bad user experience.
So do not allow 40 MHz co-ex PRI/SEC switch to force a change to
Autonomous GO PRI channel when the P2P group add is called with a forced
frequency.
Test: Tested autonomous GO and confirmed from the logs that
P2P GO is not triggering 20/40 coex scan.
Signed-off-by: Sunil Ravi <sunilravi@google.com>
This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
Link ID needs to be specified for MLD case when doing channel switch.
Add it to the driver command.
Signed-off-by: Chenming Huang <quic_chenhuan@quicinc.com>
Some kind of race condition seemed to be hit at least in test sequence
"p2p_ext_vendor_elem_invitation pasn_comeback_after_0_sae" where the P2P
invitation response could have been received just after having scheduled
a new p2p-listen radio work, but before that work had been started. In
the case of accepted invitation, this could result in unnecessary extra
delay when that p2p-listen work ended up getting started at the exact
time that the local device was starting GO.
Avoid this race condition by removing the pending p2p-listen radio work
when P2P listen is stopped.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_drv_get_pref_freq_list() may fail and the 6 GHz channel removal
should not be done unless the operation actually succeeded. The previous
implementation ended up processing uninitialized data. This did not
really result in any observable misbehavior since the result was not
used, but this showed up as a failed test case when running tests with
valgrind.
Fixes: f0cdacacb3 ("P2P: Allow connection on 6 GHz channels if requested")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
wpa_supplicant could crash due to dereferencing freed memory in a corner
case. When a reestablished P2P GO group gets removed because the
hardware mode is not supported when switching from 2.4 to 5 GHz. Group
removal in wpas_p2p_group_delete() forget to clean wpa_s->last_ssid due
to the missing wpas_notify_network_removed() call before removing the
network with wpa_config_remove_network().
That could cause a crash when flushing old BSSs which age out in
wpa_bss_flush_by_age() which uses wpa_s->last_ssid in some cases.
Fix this by invoking wpas_notify_network_removed() to clean
wpa_s->last_ssid when removing a temporary P2P group network.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The flags that indicate that a channel is allowed for 80/160 MHz use
are divided according to the position of the control channel (e.g.,
HOSTAPD_CHAN_VHT_10_70, HOSTAPD_CHAN_VHT_30_50, etc.).
However, the position of the control channel does not add any extra
regulatory information because when trying to use a 80/160 MHz channel
all the desired bandwidth has to be allowed for 80/160 MHz use,
regardless of the control channel position.
In addition, these flags are set only if the driver reports one
regulatory rule that allows the entire 80/160 MHz bandwidth.
However, even when a 80/160 MHz channel is allowed, in some cases the
bandwidth will be split into several regulatory rules because
different segments of the bandwidth differ in other flags (that don't
affect the use of the bandwidth for VHT channels). So, in such cases
these flags will not be set, although VHT channels are allowed.
As the result, VHT channels will not be used although they are allowed
by the regulatory domain.
Fix this by introducing new flags that indicate if a 2 0MHz channel is
allowed to be used as a part of a wider (80/160 MHz) channel.
The new flags are set for each 20 MHz channel independently and thus
will be set even if the regulatory rules for the bandwidth are split.
A 80/160 MHz channel is allowed if all its 20 MHz sub-channels are
allowed for 80/160 MHz usage.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Allow clients to specify the BSSID of an auto GO. If the auto GO has been
discovered on another interface, optimize scan frequency by performing
a single channel scan first. Android and ChromeOS use this to streamline
auto GO discovery.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Move the logic of picking the best driver pref freq into a separate
function, and use this to extend the functionality for invitation
process.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Both P2P GO and client always save key_mgmt = WPA_KEY_MGMT_PSK in the
configuration when storing a persistent group. Next time, when a GO is
started as an autonomous GO on a 6 GHz channel, it will change key_mgmt
to SAE and use hash-to-element mechanism, but the P2P client doesn't
change the parameter even if the group it wants to join is operating on
a 6 GHz channel. The P2P connection will be failed due to reason 'reject
due to mismatch with WPA/WPA2'.
Enable SAE-H2E for P2P client in this case.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Commit ace0fbdb69 ("P2P: Fix segfault when PBC overlap is detected")
removed the external calls to this function, but did not mark it static.
Mark it static now to clarify expected uses through the
wpas_p2p_pbc_overlap_cb() timer handler.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow specifying preferred GO band in addition to frequency. If a band
is specified, the first two scans will be limited to only non-DFS
channels to shorten scan times, and the next two will scan the entire
band.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
As P2P GOs are not expected to be collocated, i.e., they are not
expected to be announced in the RNR element of other APs, they can
operate only on preferred scanning channels (PSCs).
When performing a full scan for P2P discovery, include only the 6 GHz
PSCs (if supported) to avoid scanning channels on which P2P GOs are not
expected to reside.
While at it also fix couple of places that missed including 60 GHz
channels in P2P full scan.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When scanning for a new connection, we currently optimize by scanning
all frequencies only when our MCC capabilities will allow an additional
operating frequency, and scan only the existing operating frequencies
otherwise. This is problematic when there the current operating
frequency singularly accounts for one of the shared radio frequencies
because we should be able to switch operating frequencies without adding
to the channel count. Fix this.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Scans are allowed on the current interface for group formation only when
in the P2P_SEARCH, P2P_IDLE, or P2P_PROVISIONING state. But Extended
Listen timeout being enabled moves to the P2P_LISTEN_ONLY state. Due to
this P2P connection fails if the GO is not found with scans triggerred
before Extended Listen timeout. To avoid this skip Extended Listen
timeout to allow scans during group formation on the current interface.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Clone sae_pwe configuration value when creating a new P2P group
interface. This is needed to avoid P2P connection failure at the P2P
Client side due to SAE H2E being disabled in the 6 GHz band operation
when a new group interface is created for the connection.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
For the 6 GHz opclass 132, ch for loop only allows non-PSC channels { 1,
9, 17, 25, 33, 41, 49,... } to be used. This does not match the IEEE Std
802.11ax-2021 expectation of a 6 GHz-only AP "should set up the BSS with
a primary 20 MHz channel that coincides with a preferred scanning
channel".
Increase ch by 4 to allow PSC channel to be used for 6 GHz BW40.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This allows the P2P client to fast associate if the GO is already in the
scan cache without doing a full scan.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Move from this type of constructions:
switch (val) {
case 1:
something;
break;
}
default-action;
into following:
switch (val) {
case 1:
something;
break;
default:
default-action;
break
}
for cases where the switch statement is not expected to contain a full
set of enum values and as such, does not lose value from not having the
default target.
This makes the intent of default behavior clearer for static analyzers like
gcc with -Wswitch-default.
Signed-off-by: Chaoli Zhou <quic_zchaoli@quicinc.com>
IEEE Std 802.11-2020, 11.8.8 (Selecting and advertising a new channel)
doesn't restrict switching to a channel which is not in the same band as
the current band. But at the same time, there are some issues in
switching between the 2.4/5 GHz bands and the 6 GHz band. So limit the
check to consider the critical use case of switching from a 5 GHz channel
to a 2.4 GHz channel.
Signed-off-by: Sunil Ravi <sunilravi@google.com>
wpas_p2p_optimize_listen_channel() checks for the state and current ssid
of the interface calling this function. This check prevents the function
from setting the optimized listen channel. Since the listen channel is
stored in global P2P configuration data, do not check the state and
current interface of the caller.
Signed-off-by: Sunil Ravi <sunilravi@google.com>
P2P connections in the 6 GHz band should be limited to preferred
scanning channels since AP/GO discovery cannot depend on 2.4/5 GHz
discovery.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Move most of CHANWIDTH_* definitions from ieee80211_defs.h to defs.h as
the definitions are getting used mostly for internal purpose only. Also
change prefix of the definitions to CONF_OPER_CHWIDTH_* and update in
all the files accordingly.
Leave the couple of VHT-specific exceptions to use the old defines (the
reason why they were originally added as VHT values), to avoid use of
clearly marked configuration values in information elements. In
addition, use the defines instead of magic values where appropriate.
Signed-off-by: Aleti Nageshwar Reddy <quic_anageshw@quicinc.com>
Previously, the driver could optionally (using QCA vendor command)
provide a preferred channel list to wpa_supplicant for channel selection
during the GO negotiation. Channel selection process can be more
efficient with the information of weights and flags of the preferred
channel list that can be provided by the driver. Use a weighted
preferred channel list provided by the driver for channel selection
during GO negotiation if such a list is available.
Signed-off-by: Sreeramya Soratkal <quic_ssramya@quicinc.com>
Couple of the WPS/P2P/RADIUS-PSK cases were freeing heap memory
allocations without explicitly clearing the PSK value. Add such clearing
for these to avoid leaving the PSK in memory after it is not needed
anymore.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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>
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>
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>
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>
Enable (and require) the management frame protection for the P2P GO if
it is started on a 6 GHz channel.
Signed-off-by: Sreeramya Soratkal <ssramya@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 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. This commit is only adding
the interface change without changing any actual P2P functionality.
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>
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>
This helper function returns enum chan_allowed values, so use it as the
return type instead of unnecessarily generic int.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
For an autonomous P2P group on the 5 GHz band, a channel was picked only
from the operating class 115 which is not available in the EU region
anymore. As a result, an autonomous group creation would always fail in
this generic 5 GHz channel case.
There are more possible available channels for the 5 GHz currently.
Especially in the EU region, the operating class 115 channels are no
longer available, but SRD channels (the operating class 124) are
available. Allow them to be used here if they are marked as allowed for
P2P GO use.
In addition, iterate through all the potential options instead of just
checking the first randomly picked channel. Start this iteration from
random position to maintain some randomness in this process.
Signed-off-by: Jimmy Chen <jimmycmchen@google.com>
Add option 2 to the p2p_device_random_mac_addr configuration option to
support device drivers which use by default random MAC adresses when
creating a new P2P Device interface (for instance, the BCM2711 80211
wireless device driver included in Raspberry Pi 4 Model B). In such
case, this option allows to create the P2P Device interface correctly
when using P2P permanent groups, enabling wpa_supplicant to reuse the
same MAC address when re-invoking a P2P permanent group.
update_config=1 is required.
Signed-off-by: Ircama <amacri@tiscali.it>
Currently, the external_scan_running flag is not reset when an interface
is removed. Thus, if a connection attempt is made on another iface, it
will fail due to wpa_supplicant incorrectly assuming the radio is still
busy due to the ongoing scan.
To fix this, convert external_scan_running to a pointer to the interface
that started the scan. If this interface is removed, also reset the
pointer to NULL so that other operations may continue on this radio.
Test:
1. Start scan on wlan0
2. Remove wlan0
3. Can connect to a network on wlan1
Signed-off-by: David Su <dysu@google.com>
Add support for new channels 173 and 177 in the operating classes 125 to
130 as defined in draft IEEE P802.11ax/D8.0.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
When an external scan is in progress on the same radio, delay the P2P
search operation based on configuration parameter p2p_search_delay. The
"search_delay" configuration done through p2p_find always takes
precedence over this delay value set due to an external scan trigger.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
