This is needed to get proper P2P group removal processing for some test
cases. discovery_group_client followed by nfc_p2p_client was able to hit
a case where the P2P group idle timeout survived to the next group
instance because of the FLUSH command not clearing the group and this
timeout properly.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the local driver indicated a peer candidate event when the peer had
already initiated peering exchange in open mesh case, we used to force a
new exchange to be started instead of allowing the previously started
exchange to complete. This is not desirable, so make this initiation of
the new exchange conditional on there not being an already started (or
successfully completed) exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the local driver event for a new peer candidate arrived only after
the peer had already initiated the peering exchange, we used to clear
the link state. This resulted in the already completed (or in progress)
exchange getting abandoned and a new exchange initiated. This is not
desirable since the already started (or even completed) exchange can be
used. Clear the link state only when adding the new STA entry for the
first time, i.e., use the same !sta->my_lid condition in handling the
driver event similarly to how the peer initiated cases were already
handled.
Signed-off-by: Jouni Malinen <j@w1.fi>
The messages were sent out with wpa_msg_ctrl() so they were not visible
in the debug log. However, these would be quite helpful strings to
search for in the debug log, so change these messages to use wpa_msg().
Signed-off-by: Jouni Malinen <j@w1.fi>
This was reported to fail with Windows 2012r2 with "Invalid Compound_MAC
in cryptobinding TLV". It turns out that the server decided to go
through inner EAP method (EAP-MSCHAPv2 in the reported case) even when
using PEAP fast-reconnect. This seems to be against the [MS-PEAP]
specification which claims that inner EAP method is not used in such a
case. This resulted in a different CMK being derived by the server (used
the version that used ISK) and wpa_supplicant (used the version where
IPMK|CMK = TK without ISK when using fast-reconnect).
Fix this interop issue by making wpa_supplicant to use the
fast-reconnect version of CMK derivation only when using TLS session
resumption and the server having not initiated inner EAP method before
going through the cryptobinding exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous behavior of bursting out all retry attempts of an SD Query
frame during a single search/listen iteration does not look very helpful
in the case where the peer does not ACK the query frame. Since the peer
was found in the search, but is not ACKing frames anymore, it is likely
that it left its listen state and we might as well do something more
useful to burst out a significant number of frames in hopes of seeing
the peer.
Modify the SD Query design during P2P Search to send out only a single
attempt (with likely multiple link-layer retries, if needed) per
search/listen iteration to each peer that has pending SD queries. Once
no more peers with pending queries remain, force another Listen and
Search phase to go through before continuing with the pending SD
queries.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the FLUSH command to trigger auto connect mechanism
to schedule a new scan in 100 ms. This is not desired since all the
network profiles will be removed immediately and the scan or an attempt
to reconnect would not be of any benefit here. Such a scan in 100 ms can
cause issues for cases where multiple test sequences are run back to
back, so prevent this by clearing wpa_supplicant state to DISCONNECTED
(which avoids scheduling of the 100 ms scan trigger on disconnection) if
the state was AUTHENTICATING or higher when the FLUSH command was
issued.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The test cases discovery_ctrl_char_in_devname and discovery_group_client
tried to allow three P2P_FIND instances to be used before reporting an
error. However, this did not really work properly since the second and
third attempts would likely fail to start the initial special P2P_FIND
scan due to an already ongoing p2p_scan operation. Fix this by stopping
the previous P2P_FIND and waiting for the scan to complete if a retry is
needed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds notes on how wpa_supplicant can be configured for OSEN for a
link-layer protected online signup connection and how network profiles
can be set for a Hotspot 2.0 data connection when using external
Interworking network selection.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This verifies that there is no NULL pointer dereference when the AP code
processes Probe Request and (Re)Association Request frames with a P2P IE
in case P2P support is explicitly disabled on the AP mode interface.
This is a regression test case for the fixes in the previous commit.
Signed-off-by: Jouni Malinen <j@w1.fi>
If P2P support is included in wpa_supplicant build (CONFIG_P2P=y), but
P2P functionality is explicitly disabled (e.g., "P2P_SET disabled 1"),
couple of AP management frame processing steps did not check against
hapd->p2p_group being NULL and could end up dereferencing a NULL pointer
if a Probe Request frame or (Re)Association Request frame was received
with a P2P IE in it. Fix this by skipping these steps if hapd->p2p_group
is NULL.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit e6dd8196e5 ('Work around Linux
packet socket regression') forgot to add the l2_packet_init_bridge()
wrapper for l2_packet_pcap.c while updating all the other l2_packet
options. This resulted in wpa_supplicant build failing due to missing
l2_packet_init_bridge() function when using CONFIG_L2_PACKET=pcap in
wpa_supplicant/.config. Fix this by adding the wrapper function.
Signed-off-by: Jouni Malinen <j@w1.fi>
The new wps_force_{auth,encr}_types parameters can be used in test build
(CONFIG_WPS_TESTING) to force wpa_supplicant to use the specified value
in the Authentication/Encryption Type flags attribute. This can be used
to test AP behavior on various error cases for which there are
workarounds to cover deployed device behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
Some deployed implementations seem to advertise incorrect information in
this attribute. A value of 0x1b (WPA2 + WPA + WPAPSK + OPEN, but no
WPA2PSK) has been reported to be used. Add WPA2PSK to the list to avoid
issues with building Credentials that do not use the strongest actually
supported authentication option (that device does support WPA2PSK even
when it does not claim it here).
Signed-off-by: Jouni Malinen <j@w1.fi>
It was possible for the Registrar code to generate a Credential with
auth type WPAPSK (i.e., WPA v1) with encr type AES if the Enrollee
claimed support for WPAPSK and not WPA2PSK while the AP was configured
in mixed mode WPAPSK+WPA2PSK regardless of how wpa_pairwise (vs.
rsn_pairwise) was set since encr type was selected from the union of
wpa_pairwise and rsn_pairwise. This could result in the Enrollee
receiving a Credential that it could then not use with the AP.
Fix this by masking the encryption types separately on AP based on the
wpa_pairwise/rsn_pairwise configuration. In the example case described
above, the Credential would get auth=WPAPSK encr=TKIP instead of
auth=WPAPSK encr=AES.
Signed-off-by: Jouni Malinen <j@w1.fi>
Couple of waits for this event used the "GO-NEG-FAILURE" string instead
of the full event prefix. While this worked in the tests due to a
substring matching, it is better to use the full event prefix here.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the dump_monitor() call to drop a P2P-GO-NEG-FAILURE
event that was indicated quickly after the P2P_CONNECT command was
issued. This could result in grpform_reject test case failing to see the
expected event and fail the test due to "Rejection not reported".
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes it somewhat easier for the station to be able to receive and
process the encrypted WNM-Notification frames that the AP previously
sentt immediately after receiving EAPOL-Key msg 4/4. While the station
is supposed to have the TK configured for receive before sending out
EAPOL-Key msg 4/4, not many actual implementations do that. As such,
there is a race condition in being able to configure the key at the
station and the AP sending out the first encrypted frame after EAPOL-Key
4/4. The extra 100 ms time here makes it more likely for the station to
have managed to configure the key in time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add SSL_SESSION_get_master_key() compatibility wrapper for older OpenSSL
versions to be able to use the new openssl_tls_prf() implementation for
OpenSSL 1.1.0 with all supported versions.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
SSL_get_client_random() and SSL_get_server_random() will be added in
OpenSSL 1.1.0. Provide compatibility wrappers for older versions to
simplify the tls_connection_get_random() implementation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The OpenSSL project will not support version 1.0.0 anymore. As there
won't be even security fixes for this branch, it is not really safe to
continue using 1.0.0 and we might as well drop support for it to allow
cleaning up the conditional source code blocks.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The OpenSSL project will not support version 0.9.8 anymore. As there
won't be even security fixes for this branch, it is not really safe to
continue using 0.9.8 and we might as well drop support for it to allow
cleaning up the conditional source code blocks.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
rsn_ie_proto_eap_sta followed by eap_ttls_mschapv2_session_resumption
showed a failure case where the special RSNE from rsn_ie_proto_eap_sta
ended up remaining in a wpa_supplicant BSS entry and the SELECT_NETWORK
command used the previous scan results without checking for changed AP
configuration. This resulted in test failure due to RSN IE being claimed
to be different in EAPOL-Key msg 3/4. This is not really a real world
issue, but try to avoid false failure reports by explicitly clearing the
BSS table at the end of rsn_ie_proto_eap_sta.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This verifies that the previous commit works correctly by forcing a
P2P_LISTEN command execution to be interupted by a P2P_FIND command
timed in a manner that forces it to show up before the kernel ROC has
started for the Listen.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the p2p->pending_listen_freq to be left indicating
that there is a pending ROC for a listen operation if a P2P_FIND command
was timed to arrive suitably between a previous Listen operation issuing
a ROC request and the kernel code starting that request. This could
result in the P2P state machine getting stuck unable to continue the
find ("P2P: p2p_listen command pending already").
Fix this by clearing p2p->pending_listen_freq when starting P2P_FIND
command execution.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This verifies that P2P_STOP_FIND stops a pending offchannel TX wait in
the kernel by checking that a listen operation can be started in less
than a second after stopping a pending Action frame TX. This verifies
that the optimization introduced in the previous commit works properly.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously it was possible for the pending Action frame TX to be
cleared, but the offchannel TX operation being left in wait state in the
kernel. This would delay start of the next operation (e.g., that listen
operation requested by P2P_LISTEN) until the wait time for the
previously pending Action frame had expired.
Optimize this by explicitly stopping any pending offchannel Action frame
TX when clearing the internal offchannel TX state in
wpas_p2p_clear_pending_action_tx().
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This reverts commit be9fe3d8af. While I
did manage to complete multiple test runs without failures, it looks
like this change increases full test run duration by about 30 seconds
when using seven VMs. The most visible reason for that seems to be in
"breaking" active scanning quite frequently with the Probe Response
frame coming out about 40 ms (or more) after the Probe Request frame
which is long enough for the station to already have left the channel.
Since this logging change is not critical, it is simplest to revert it
for now rather than make changes to huge number of test cases to allow
more scan attempts to be performed before timing out.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previously used 10 second timeout allowed only two scan attempts
(five seconds between scans) and it was possible to hit a failure every
now and then when running under heavy load and the Probe Response frame
got delayed by 40 ms or so twice in a row. Add more time for one more
scan attempt to reduce the likelihood of this happening.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
These test caases depended on a single active scan round finding the AP.
It is possible for the Probe Response frame to get delayed sufficiently
to miss the response especially when testing under heavy load with
multiple parallel VMs. Allow couple of scan retries to avoid reporting
failures from these test cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use the group SSID (if known) when requesting a join operation. This
makes some of the P2PS test cases more robust in cases where previously
executed tests have added older groups into the cached scan results with
the same MAC addresses and an incorrect BSS could have been picked
previously.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new optional ssid=<hexdump> argument to P2P_CONNECT can be used to
make P2P Client operations during join-an-existing-group more robust by
filtering out scan results based on the SSID in addition to the P2P
Device/Interface Address. This can help if the same MAC address has been
used in multiple groups recently and the cached scan results may still
include an older BSS.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
At least one of the wpas_p2p_connect() callers (NFC join case) already
had access to the Group SSID. Pass that information through
wpas_p2p_connect() to wpas_p2p_join() so that the join operation can
filter out incorrect groups more easily.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Accept only a BSS entry matching the SSID when trying to find the
operating channel of a GO during join operation for which the SSID was
already specified. Previously, it could have been possible to pick an
incorrect BSS entry if the new GO was not found in the latest scan and
there was an older cached scan entry for the same BSSID.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was already possible to limit join operation to accept only a
specific SSID. However, this constraint was not used when starting a P2P
Client interface as a WPS Enrollee without going through a Provision
Discovery exchange.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Use wpa_bss_get() with the specific Group SSID instead of
wpa_bss_get_bssid_latest() if the SSID is already known. This makes the
P2P join operations more robust in case the frequency of the group was
not yet known and the same P2P Interface Address may have been used in
multiple group instances with an older group entry still present in the
cached scan results.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This allows the cases where a specific group SSID is known to filter out
groups on the P2P Client even if the specific BSS entry for the target
group is not yet available.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new optional group_ssid=<hexdump> argument in the P2PS-PROV-DONE
event can be used to help in identifying the exact group if there have
been multiple groups with the same P2P Interface Address in short period
of time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes it less likely to hit issues with running out of control
interface TX queue when running multiple FST test in a row. Number of
the FST operation sequences seemed to leave quite a few event messages
pending in one of the attached control interface sockets for wlan5 which
could result in test failure if the buffer space ran out and some of the
wpa_supplicant events were not delivered.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It is better to get these messages into the actual debug log instead of
hoping they will be noticed from stdout.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This test case used to leave the dynamically added wlan5 interface in a
state where it was still trying to reconnect to a network. This could
result in the following test cases being unable to clear the cfg80211
scan cache. Avoid this type of issues by explicitly stopping the
connection attempt and making sure that there are no scan results in the
cache at the end of connect_cmd_disconnect_event.
The following test case sequence triggered a failure due to the
remaining BSS table entry:
connect_cmd_disconnect_event connect_cmd_wep ap_hs20_random_mac_addr
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When we receive FST Setup Request when session already exists, the
following validations take place:
1. we drop the frame if needed according to MAC comparison
2. we drop the frame if the session is "not pending", i.e., if FST
Setup Response was already exchanged (sent or received).
There are two issues with the above:
1. MAC comparison is relevant only before the Setup Response exchange.
In other words, Setup Request should not be dropped due to MAC
comparison after Setup Response has been exchanged.
2. Receiving Setup Request after Setup Response exchange most likely
means that FST state machine is out of sync with the peer. Dropping
the Setup Request will not help solve this situation.
The fix is:
1. do MAC comparison only if session is "pending", i.e., Setup Response
was not yet exchanged.
2. In case Setup Response was already exchanged, reset our session and
handle the Setup Request as if it arrived when session doesn't exist.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
