This is needed in cases the hexlify() output is used to concatenate with
a string or used in string comparisons.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Signed-off-by: Jouni Malinen <j@w1.fi>
This is a regression test case for FT-over-DS that got broken on
mac80211-based drivers when the extra key reinstallation checks were
added.
Signed-off-by: Jouni Malinen <j@w1.fi>
ap_ft_oom seemed to depend on undesired wpa_supplicant behavior of
trying to do FT protocol even without being ready for reassociation.
This is going to be fixed in wpa_supplicant which would make this test
case fail, so split it into separate test cases for each failure item to
be able to avoid incorrect test failures.
Signed-off-by: Jouni Malinen <j@w1.fi>
This verifies that radio measurement capabilities are negotiated
correctly for the reassociation cases with and without FT.
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation changes in hostapd FT error path handling in the
follow commit would result in ap_ft_ap_oom7 test case failing. This is
triggered partially by PMF protections and SA Query attempts, so it
looks like it is easier to split each failure case into a separate test
case.
Signed-off-by: Jouni Malinen <j@w1.fi>
time.sleep() in run_roams() is required because the target AP sets the
key once the station was associated. There are races, when the station
processes the (Re)Association Response frame AND the test suite starts
FT_DS before the AP processes its local confirmation and thus
wpa_auth_sm_event(ASSOC_FT). Therefore, the ActionFrame will be lost, as
the AP driver is missing the key.
Since this is this speed is highly synthetic, wait a few milliseconds
before roaming back.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Fix problem when running ap_ft test cases with real HW using remote
tests and hwsim wrapper by using the newer hostapd.app_ap() API.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
This updates the AP-to-AP keys to the longer form and OOM test case
functions to match the new implementation.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Local key generation for FT-PSK does not use the AP-to-AP protocol and
as such, setting pmk_r1_push=1 is a bit confusing here since it gets
ignored in practice. Remove it to keep the test case easier to
understand.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
After successfully passing the 525 tests on a remote setup mark the
tests as remote compatible.
Signed-off-by: Jonathan Afek <jonathanx.afek@intel.com>
Pass the full apdev to the add_ap() function instead of just ifname.
This allows us to handle also remote hosts while we can check
apdev['hostname'], apdev['port'].
This step (1) converts the cases where apdev[#]['ifname'] was used as
the argument to hostapd.add_ap().
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
A malicious station could try to do FT-over-DS with a non WPA-enabled
BSS. When this BSS is located in the same hostapd instance, internal RRB
delivery will be used and thus the FT Action Frame will be processed by
a non-WPA enabled BSS. This processing used to crash hostapd as
hapd->wpa_auth is NULL.
This test implements such a malicious request for regression testing.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
This is needed to fix ap_wpa2_eap_psk_oom, ap_wpa2_eap_sim_oom,
eap_proto_psk_errors, and ap_ft_oom with the new OpenSSL dynamic memory
allocation design.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The decrypted copy of a GTK from EAPOL-Key is cleared from memory only
after having sent out CTRL-EVENT-CONNECTED. As such, there was a race
condition on the test case reading the wpa_supplicant process memory
after the connection. This was unlikely to occur due to the one second
sleep, but even with that, it would be at least theorically possible to
hit this race under heavy load (e.g., when using large number of VMs to
run parallel testing). Avoid this by running a PING command to make sure
wpa_supplicant has returned to eloop before reading the process memory.
This should make it less likely to report false positives on GTK being
found in memory.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like it is possible for the GTK to be found from memory every
now and then. This makes these test cases fail. Write the memory
addresses in which the GTK was found to the log to make it somewhat
easier to try to figure out where the key can be left in memory.
Signed-off-by: Jouni Malinen <j@w1.fi>
