send_iface_detach_request() can fail and that resulted in skipping a
call to restore_reg_domain() and leaving unexpected country
configuration for following test cases. This could result in failures,
e.g., in this sequence: fst_proto wpas_mesh_open_5ghz
Fix this by ignoring exceptions from send_iface_detach_request() and
continuing to restore regulatory domain.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
atheros_set_opt_ie() needs to be called before freeing drv->wpa_ie to
avoid hitting double-free on the deinit path. Similarly,
drv->wps_beacon_ie and drv->wps_probe_resp_ie could have been used after
being freed. Fix these be moving the atheros_set_opt_ie() call in
atheros_deinit().
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for a driver to support sufficient number of channels to
hit the previous limit of 200 characters for the "nl80211: Scan included
frequencies:" debug message. Increase the maximum buffer length to 300
characters to allow more complete list of scanned frequencies to be
written into the debug log. This limit is more in line with the
MAX_REPORT_FREQS (50) limit.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
In addition to the PTK length increasing, the length of the PMK was
increased (from 256 to 384 bits) for the 00-0f-ac:12 AKM. This part was
missing from the initial implementation and a fixed length (256-bit) PMK
was used for all AKMs.
Fix this by adding more complete support for variable length PMK and use
384 bits from MSK instead of 256 bits when using this AKM. This is not
backwards compatible with the earlier implementations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previous implementation used an obsolete sm->eapol_key_crypt pointer
which was not set anywhere (i.e., was always NULL). In addition, the
condition of sm->eap_if->eapKeyAvailable was not valid here since this
is the case of MSK from an external authentication server and not the
internal EAP server. Consequently, the wpa_auth_pmksa_add() call here
was never used.
The PMKSA cache was still added, but it happened at the completion of
the 4-way handshake rather than at the completion of EAP authentication.
That later location looks better, so delete the unreachable code in
Access-Accept handling. In addition, remove the now complete unused
struct eapol_state_machine eapol_key_* variables.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
With driver wrappers that implement set_privacy(), set_generic_elem(),
set_ieee8021x(), or set_ap_wps_ie(), it was possible to hit a NULL
pointer dereference in error cases where interface setup failed and
the network configuration used WPA/WPA2, IEEE 802.1X, or WPS.
Fix this by skipping the driver operations in case the driver interface
is not initialized.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
I modified this test case for commit
eabf083984 ('tests: P2PS channel
handling') to use dev[2] instead of dev[0], but forgot to update the
p2ps_connect_p2ps_method() dev list to match that. Fix this to actually
use a concurrent connection.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add a global D-Bus handler ExpectDisconnect for setting
wpa_s->own_disconnect_req flag. This flag will prevent wpa_supplicant
from adding blacklists and requesting incomplete scan upon the incoming
disconnection. This is mainly meant for a case where suspend/resume is
used and some external component knows about that and can provide the
information to wpa_supplicant before the disconnection happens.
Signed-off-by: Ningyuan Wang <nywang@google.com>
It was possible for the dbus_interface test case to leave the P2P
channel lists with 5 GHz channels enabled due to the special driver=none
case. This could make the following P2P test case fail due to selecting
an unexpected channel. Fix this by forcing P2P channel list update at
the end of the dbus_interface test case.
This was triggering with the following hwsim test case sequence:
dbus_interface p2ps_connect_adv_go_p2ps_method_group_iface.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for wpa_s->own_disconnect_req to be left set to 1 from a
disconnection attempt from a prior connection. This could then prevent
proper connection failure processing with the new connection in
wpas_connection_failed(). This was triggered by the following hwsim test
case sequence: wpas_mesh_secure sae_no_ffc_by_default. In this sequence,
the SAE failure due to unsupported group did not result in proper
wpas_connection_failed() processing and retry.
Fix this by clearing wpa_s->own_disconnect_req in
wpa_supplicant_associate() before starting a new connection.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use a dynamic HWSimRadio in p2ps_channel_sta_connected_disallow_freq_mcc
to allow MCC test case to be executed in default setting (MCC disabled
for the default radios).
Signed-off-by: Jouni Malinen <j@w1.fi>
Stop the pending P2P_LISTEN operation priot to issuing P2P_GROUP_ADD to
start a GO. This avoids excessively long wait for the previous Listen
step to complete before being able to start the GO. This makes
p2ps_connect_adv_go_persistent take significantly less time.
Signed-off-by: Jouni Malinen <j@w1.fi>
The combination of starting P2P extended listen and issuing
P2P_ASP_PROVISION_RESP almost immediately after that while in P2P_LISTEN
state resulted in caes where the advertiser could end up going back to a
long listen state while trying to retransmit PD Request. This resulted
in p2ps_provision() timing out while waiting for P2PS-PROV-DONE
especially in p2ps_feature_capability_* test cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Don't add unnecessary P2PS follow-on PD Request attributes when
the request status is not P2P_SC_SUCCESS_DEFERRED.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
When one peer doesn't include a persistent group info in PD Request
the other peer shouldn't report a persistent group usage with this
peer even if such a persistent group exists locally. This condition
could be violated in the previous implementation.
In case a local persistent group exists and the
wpas_p2ps_prov_complete() function is called with persist_ssid parameter
set to NULL, wpa_supplicant reported P2PS-PROV-DONE with persist=<idx>
instead of conncap=<role> parameter.
This happened because the wpas_p2p_get_persistent() function was called
without verification whether the persist_ssid was set to NULL. In this
case the wpas_p2p_get_persistent() returns the first existing persistent
group matching the P2P Device Address without verifying the group's
SSID. After that the group ID is used as persist=<idx> parameter of
P2PS-PROV-DONE event.
Fix the issue by adding persist_ssid and persist_ssid_size verification
as a condition for the wpas_p2p_get_persistent() call.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
In P2PS PD Request processing in some error case scenarios, such as
verification of the WPS config method, the flow aborts before saving
mandatory P2PS PD Request attributes. This in turn causes the control
interface notification events to be sent with invalid parameters.
Fix this by changing the order of verification and processing steps of
the PD Request message handling.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
On successful P2P PD, report the chosen frequency in case the local
device is going to be the P2P GO, so in can later be used to instantiate
the new P2P GO, etc.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
In case the P2PS PD Response includes the P2P Channel List attribute,
update the peer device supported channels and verify that the local
device has common channels with the peer (only a sanity check).
If the Operating Channel attribute is included in the response, check
that it is included in the intersection and store it as the peer's
operating frequency (so it could later be used in the join flow, etc.).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
In case the P2PS PD Request includes the P2P Channel List attribute,
update the peer device supported channels and check if we have common
channels with the peer that can be used for the connection establishment
based on the connection capabilities:
1. In case of P2PS PD Request with no common channels, defer
the flow unless auto accept equals true and the connection
capabilities equals NEW (in which case the channels would be
negotiated in the GO Negotiation).
2. In case of Follow up P2PS PD Request with no common channels,
reject the request unless the connection capability is NEW.
In addition, in case of a successful P2PS PD, save the device
operating frequency (so it can be later used for join flow, etc.).
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add operating channel selection and channel list processing similar to
that done when building GO Negotiation Request, i.e., consider the
currently used channels, configured channels, etc.
P2PS introduces a flow where a responder needs to provide channel data
without being previously aware of the current constraints, i.e., the
channels currently in use by other interfaces. To handle this, extend
the get_group_capability() callback to also handle channel selection
aspects of group capabilities.
In case there is an active P2P GO that is going to be used for the P2PS
PD, force its current operating frequency in the PD attributes.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
If a Provision Discovery Request is received for an unknown peer, a new
device entry is being added, but the flow continues without updating the
local p2p_device pointer, requiring to check the pointer value before
every access.
1. Change this, so once a device is added, the flow updates the local
p2p_device pointer and avoids the checks later in the flow.
2. If the device is not known even after adding it, skip the processing,
send the PD Response, and return.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
It is possible that p2p_build_prov_disc_resp() is called with a NULL
device entry, which might be dereferenced when calling
p2p->cfg->get_persistent_group() for the P2PS with persistent group
case. Fix this by checking the device pointer before accessing it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Write a text version of the content type and handshake type in debug log
to make it easier to follow TLS exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
The utf8_string_len comparison was off by one and ended up accepting a
truncated three-byte encoded UTF-8 character at the end of the string if
the octet was missing. Since the password string gets null terminated in
the configuration, this did not result in reading beyond the buffer, but
anyway, it is better to explicitly reject the string rather than try to
use an incorrectly encoded UTF-8 string as the password.
Signed-off-by: Jouni Malinen <j@w1.fi>
Verify OCSP stapling response that is signed by the CA rather than a
separate OCSP responder. In addition, verify that invalid signer
certificate (missing OCSP delegation) gets rejected.
Signed-off-by: Jouni Malinen <j@w1.fi>
BoringSSL has dropped OpenSSL functionality that was used in the EST
implementation. For now, disable EST with BoringSSL to allow
hs20-osu-client to be built.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
BoringSSL has removed the OpenSSL OCSP implementation (OCSP_*()
functions) and instead, provides only a minimal mechanism for include
the status request extension and fetching the response from the server.
As such, the previous OpenSSL-based implementation for OCSP stapling is
not usable with BoringSSL.
Add a new implementation that uses BoringSSL to request and fetch the
OCSP stapling response and then parse and validate this with the new
implementation within wpa_supplicant. While this may not have identical
behavior with the OpenSSL-based implementation, this should be a good
starting point for being able to use OCSP stapling with BoringSSL.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was already possible to use longer values through the control
interface SET command, but the configuration file parser was still
limited to 512 byte lines. Increase this to 4096 bytes since some of the
configuration parameters (e.g., anqp_elem) can be longer.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Validate that all the required attributes appear in a P2PS PD Request,
and in addition, in the case of follow-on PD Request, check that the
given values match those of the original PD Request.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Change the connection capability handling so that in case there are no
active roles, the peer has an active GO, and the advertisement supports
operation as a client, the returned connection capability is set to
client.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
The code was iterating all the interfaces, and for each interface
iterated all the network blocks to count active P2P GO and P2P Client
interfaces.
Change the code to reuse wpas_p2p_get_go_group() to get a P2P GO
interface and add wpas_p2p_get_cli_group() and use it to find a
P2P Client interface, and use these objects when evaluating the
group capability.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Re-factor wpas_p2p_get_go_group() to:
1. Skip the dedicated P2P Device management interface if it is used.
2. Instead of iterating all the interface configured networks,
only access the current_ssid pointer to check if the current
interface is acting as a persistent P2P GO.
To avoid code duplication, also re-factor wpas_p2p_group_go_ssid()
to call wpas_p2p_get_go_group().
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add a test case verifying deferred P2PS provision discovery when an
advertiser sends the status 11 (Fail: reject by user) in the follow-on
PD Request.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
When a follow-on PD request is received, peer should not send a
follow-on PD response except the case when the PD request status value
is 12 (Success: accepted by user). Previously, the wpa_supplicant
implementation behaved differently sending the follow-on PD Response on
any follow-on PD Request.
Fix the issue by adding the following changes:
1. Don't send PD Response if the follow-on PD Request status is
different than 12 (seeker side).
2. Don't wait for the follow-on PD Response if the follow-on PD
Request was sent with the status different than 12 (advertiser
side).
3. If the follow-on PD Request was sent with the status different
than 12 use the follow-on PD Request ACK as PD completion event
(advertiser side).
4. Notify ASP about the PD completion by sending P2PS-PROV-DONE with
the PD Request status (advertiser side).
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
