Add the `sae_check_mfp` global option to limit SAE when PMF will
not be selected for the connection.
With this option SAE is avoided when the hardware is not capable
of PMF due to missing ciphers.
With this option SAE is avoided on capable hardware when the AP
does not enable PMF.
Allows falling back to PSK on drivers with the
WPA_DRIVER_FLAGS_SAE capability but do not support the BIP cipher
necessary for PMF. This enables configurations that can fall back
to WPA-PSK and avoid problems associating with APs configured
with `sae_require_mfp=1`.
Useful when `pmf=1` and `sae_check_mfp=1` are enabled and networks
are configured with ieee80211w=3 (default) and key_mgmt="WPA-PSK SAE".
In this configuration if the device is unable to use PMF due to
lacking BIP group ciphers it will avoid SAE and fallback to
WPA-PSK for that connection.
Signed-off-by: Jeffery Miller <jefferymiller@google.com>
When these are issued while associated, scanning all channels can take a
significant amount of time. That happened to work for existing test
cases somewhat by accident since the scan was sometimes limited to only
the current operating channel. However, that is now changing and the
following two test cases started failing with the change, so make them
wait longer:
sigma_dut_sae_pw_id_ft sigma_dut_ft_rsnxe_used_mismatch
Signed-off-by: Jouni Malinen <j@w1.fi>
Add a new P2P persistent group formation, re-invocation, and cancel test
to verify that P2P_EXT_LISTEN is avoided and the scan is performed in
the P2P Client role to find the P2P GO for the ongoing P2P persistent
group formation on the current interface.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
This makes sigma_dut_ap_dpp_qr* test cases with SAE more robust by
avoiding unexpected behavior. This was found with the following test
sequence:
mesh_sae_anti_clogging sigma_dut_ap_dpp_qr_sae
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is needed to avoid surprises in the following test cases. This was
found with a failure in the following test sequence:
wpas_ap_vendor_elems p2p_ext_discovery_go
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Clear the dpp_connector_privacy_default parameter value that sigma_dut
set in wpa_supplicant at the end of the test case to avoid surprising
behavior for the following test cases. This was found with a failure in
the following test sequence:
sigma_dut_dpp_qr_mutual_resp_enrollee_connector_privacy
sigma_dut_dpp_proto_peer_disc_req
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Since the kernel actually passes the command-line parameters
as environment variables to the init script, there's no need
to parse them out of /proc/cmdline.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It can be useful to configure a different module directory, so you don't
need to install the kernel modules in the host /lib/modules/ location.
Allow configuring it in the config file.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If cfg80211 is built into the kernel, then it may/will have
loaded the regdb before we mount our own /lib/firmware. This
may result in using the wrong regulatory data. Fix this by
using iw to reload the regdb after mounting it.
Fixes: a29c2399a7 ("tests: Add regulatory database to VMs")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The part about checking the supported curves from the peer depends on
CONFIG_DPP3 and this test case needs to be skipped without that.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Prepare for an implementation change for the PB discovery channel list.
Move the standlone (not an AP) PB Configurators to a preferred channel
and enable Configurator connectivity indication in APs that act as PB
Configurators.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Configurator station seems to be unable to get the first Authentication
Request frame transmitted through mac80211_hwsim for some reason. It is
not really clear why this happens and why it started happening now, but
as a temporary workaround, wait a second here since that seems to avoid
this for some unknown reason.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This test case assumed that the p2p_pref_chan 128:44 parameter would
have resulted in channel 44 (5220 MHz) being selected. That does not
work anymore since that channel was marked to require DFS/radar
detection in regdb. Fix the text case by changing to use another country
with rules that match the test case expectations.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It looks like some test cases could fail due to timeouts since the 10
second wait may not be sufficient to cover some cases where 6 GHz
channels get scanned. Increase the timeouts to avoid hitting such cases.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It looks like the host update of regulatory information can still get
through somehow, so add alternative expected values for the supported
operating classes for cases where 6 GHz frequencies were added recently.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is in preparation to allow the implementation in hostapd to be
changed to accept removal of PKEX information without indicating an
error after it have been automatically removed at the successful
completion of PKEX.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This started failing with the OCV implementation change to ignore the
second segment when using a 160 MHz channel.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Try to avoid an exception while processing an exception that indicates
the test case failed. Explicit DISCONNECT command here can avoid the
undesired FAIL-BUSY from cleanup SCAN.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
