Wait for the configuration step to complete before forcefully
terminating DPP listen. Previous version was causing failures for this
test case sequence:
dpp_qr_code_auth_initiator_enrollee dpp_pkex_config2
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
DPP tech spec changed the contents of these frames by replacing the
public key hash attributes with a Transaction ID attribute that gets
copied from the request to the response to identify the transaction in a
simpler manner.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use the SSL_get_SSL_CTX() helper instead of dereferencing SSL* since
struct ssl_st is not exposed in public header files anymore.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This is an event indicating to the user space that the driver has
detected an internal failure. The driver is expected to recover from
such a failure automatically, e.g., by resetting the device. This event
carries the information indicating the reason that triggered this
detection.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previous implementation was able to parse arrays of objects, but not
arrays of other types of items.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
hostapd allows arbitrary AP PIN to be used in WPS. This means that
setting ap_pin to a zero length string ends up enabling AP PIN so that
external registrars can use this specific zero lenth ap_pin value. There
are apparently some APs that have used this invalid configuration with
unintended results. While the proper fix for that is to fix the
component that generates the invalid configuration, hostapd can also
reject such values since the likelihood of a real world use case for
zero length AP PIN (Device Password) is minimal.
Start interpreting zero length ap_pin parameter value as a request to
"unset" the previously set value in hostapd.conf (or if not previously
set, leave it unset). With this, a hostapd.conf file including the
"ap_pin=" line will end up getting interpretted just like that same file
with the ap_pin parameter completely removed, i.e., with AP PIN being
disabled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The two channel width bits in the VHT capability field can be decoded in
following values (IEEE Std 802.11ac-2013 8.4.2.160.2 VHT Capabilities
Info field):
* 0: no 160 or 80+80 MHz support
* 1: 160 MHz support
* 2: 160 and 80+80 MHz support
* 3: (reserved)
The check must therefore not be done bitwise but instead it must checked
whether the capabilities announced by the driver are at least the ones
requested by the user.
Fixes: c781eb8428 ("hostapd: Verify VHT capabilities are supported by driver")
Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
On slow machines or inside VM it may take some time for "DISCONNECTED"
event to arrive. Since the retry delay counter is started already, it
may result in less than 5 seconds time between "DISCONNECTED" and
"CONNECTED" events.
Fix the test by taking more accurate timestamps between the events.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Previously, CONFIG_WNM enabled build that supports WNM for both
station mode and AP mode. However, in most wpa_supplicant cases only
station mode WNM is required and there is no need for AP mode WNM.
Add support to differentiate between station mode WNM and AP mode
WNM in wpa_supplicant builds by adding CONFIG_WNM_AP that should be
used when AP mode WNM support is required in addition to station mode
WNM. This allows binary size to be reduced for builds that require
only the station side WNM functionality.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When setting the frequencies for beacon report request scan, it is
possible that a frequency is added twice (e.g., when the same channel
appears both in the channel field and in the AP channel report
subelement). This may cause the scan request to fail.
Make sure the frequencies array contains no duplications before
requesting the scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Send Radio Measurement response with measurement mode set to reject
in the following cases:
1. Reporting conditions is not supported.
2. No valid channels found for the measurement
Sending a response with an incapable indication will stop the AP from
sending other measurement requests of the same type as specified
in IEEE Std 802.11-2016, 11.11.6.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When failing to trigger scan for beacon report (e.g., when the
requested duration is not supported by the driver), send a
Radio Measurement response with the mode set to refused and don't
retry the scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
IEEE Std 802.11-2016, 11.11.6 specifies that a station that is unable to
make a requested measurement or refuses to make a measurement shall
respond only if the measurement request was received within an
individually addressed radio measurement request frame, but shall not
respond if such a request was received in a group addressed frame.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
X509_ALGOR_get0() was modified to use const ** pointer as the first
argument in OpenSSL 1.1.0, so need to use different type here to avoid
compilation issues.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, the pointer to strdup passwd was left in OpenSSL library
default_passwd_cb_userdata and even the default_passwd_cb was left set
on an error path. To avoid unexpected behavior if something were to
manage to use there pointers, clear them explicitly once done with
loading of the private key.
Signed-off-by: Jouni Malinen <j@w1.fi>
Since OpenSSL version 1.1.0f, SSL_use_PrivateKey_file() uses the
callback from the SSL object instead of the one from the CTX, so let's
set the callback on both SSL and CTX. Note that
SSL_set_default_passwd_cb*() is available only in 1.1.0.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Add a build option to select different default ciphers for OpenSSL
instead of the hardcoded default "DEFAULT:!EXP:!LOW".
This new option is useful on distributions where the security level
should be consistent for all applications, as in Fedora [1]. In such
cases the new configuration option would be set to "" or
"PROFILE=SYSTEM" to select the global crypto policy by default.
[1] https://fedoraproject.org/wiki/Changes/CryptoPolicy
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Add OCE IE in Beacon, Probe Response, and (Re)Association Response
frames if OCE is enabled in the configuration.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Check if device supports OCE STA/STA-CFON/AP specific mandatory
features. This commit includes checking based on the QCA vendor
attributes.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If an AP is not FILS capable and wpa_supplicant has a saved network
block for the network with FILS key management and a saved erp info,
wpa_supplicant might end up issuing a FILS connection to a non-FILS AP.
Fix this by looking for the presence of FILS AKMs in wpa_s->key_mgmt,
i.e., after deciding on the AKM suites to use for the current
connection.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This request ID was wrongly referred from the REQUEST_ID in
enum qca_wlan_vendor_attr_gscan_config_params which is mapped to
QCA_WLAN_VENDOR_ATTR_PNO_PASSPOINT_LIST_PARAM_NUM in PNO Config.
Hence define a different attribute to represent the request ID
for PNO Config.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
In case that an mbo object is allocated, but there is a failure
to resize the wpabuf, need to free the mbo object.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Scan results with parent TSF older than the scan start TSF are not added
to the beacon report since they are considered as scan results from
previous scans. However, for drivers that report the scan start TSF but
not the parent TSF of each scan result, the parent TSF will be zero so
valid scan results will be dropped.
Fix this by filtering scan results by the parent TSF only if the
driver supports reporting the parent TSF for each scan result.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
In case of incorrect HT40 configuration as part of an attempt to create
a 80 MHz AP, iface->conf->vht_oper_centr_freq_seg0_idx and
iface->conf->vht_oper_centr_freq_seg1_idx are zero'ed, but
iface->conf->vht_oper_chwidth remains VHT_CHANWIDTH_80MHZ. This causes
the logic in dfs_get_start_chan_idx to fail.
Fix this by setting iface->conf->vht_oper_chwidth to
VHT_CHANWIDTH_USE_HT when zero'ing the center frequency parameters.
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Previously p2p_channel_drv_pref_* tests would fail
if dedicated P2P device is used, since the SET commands
were sent to incorrect interface.
Fix this by using a global control interface instead.
Signed-off-by: Adiel Aloni <adiel.aloni@intel.com>
Clear the get_pref_freq_list_override in p2p_ctrl_flush(). This fixes
the case when a dedicated P2P device interface is used.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
We capture the dmesg that contains everything, but if a test
causes a kernel crash we will miss all logging at higher levels
like debug. Change the printk level to catch all of that too.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
