Without this subsequent tests may be affected by hwsim not being
restarted.
Additionally in 4.13 the kernel will not use the registered hwsim
wmedium for wiphys created after the HWSIM_CMD_REGISTER call and
there's no way to re-register it without disconnecting from netlink
which is a bit of work. It's a one line fix in 4.13, I've not yet
checked if this has changed in current git.
When running multiple BSSes in one ESS this solves the communication
between them (called RRB) for purposes like preauthentication,
FT key pull and push and FT-over-DS without complicated bridges. At the
same time we're unlikely to have a scenario where we need the
communication to fail so there's no need for this to be configurable.
The supporting code for multiple hostapd processes is left in place so
that configure_hostapd_instances can decide how many processes to run
based on hw.conf and policies. start_hostapd now uses "-i wln0,..."
which is no longer documented in hostapd manual page or usage() but
still supported in current git and required if interface names are not
provided in the config files (possibly unless -b is used which is also
undocumented.)
After an EAP exchange rsn_info would be uninitialized and in the FT case
we'd use it to generate the step 2 IEs which would cause an RSNE
mismatch during FT handshake.
Until now we'd save the second 32 bytes of the MSK as the PMK and use
that for the PMK-R0 as well as the PMKID calculation. The PMKID
actually uses the first 32 bytes of the PMK while the PMK-R0's XXKey
input maps to the second 32 bytes. Add a pmk_len parameter to
handshake_state_set_pmk to handle that. Update the eapol_eap_results_cb
802.11 quotes to the 2016 version.
handshake_state_install_ptk triggers a call to
netdev_set_pairwise_key_cb which calls netdev_connect_ok, so don't call
netdev_connect_ok after handshake_state_install_ptk. This doesn't fix
any specific problem though.
If the request being cancelled by agent_request_cancel has already been
sent over dbus we need to reset pending_id, the timeout, call l_dbus_cancel
to avoid the agent_receive_reply callback (and crash) and perhaps start
the next request. Alternatively we could only reset the callback and not
free the request, then wait until the agent method to return before starting
the next request.
Move the cancelling of the eapol timeout from the end of step 1 to
step 3 to guard the whole handshake. At the end of step 1 stop the
EAPOL-Start timeout for the case of 802.1X authentication + a cached
PMKSA (not used yet.)
Some APs respond to Neighbor Report Requests with neighbor reports that
have a zero operating class value and a non-zero channel number. This
does not mean that the channel is in the same band that the reporting
AP operates in. Try to guess the band that the channel refers to out of
2.4 and 5GHz -- the bands supported by those APs.
wpa_supplicant also has this workaround in place.
There was an unnecessary l_strsplit call when parsing the verbose
options for test-runner. The verbose options get parsed inside
qemu already, so this call was removed.
Can now pass -V, --valgrind to test-runner to run valgrind on
iwd during autotests. Note: the verbose option for iwd must
also be passed in order to see output (-v iwd).
SA Query procedure is used when an unprotected disassociate frame
is received (with frame protection enabled). There are two code
paths that can occur when this disassociate frame is received:
1. Send out SA Query and receive a response from the AP within a
timeout. This means that the disassociate frame was not sent
from the AP and can be ignored.
2. Send out SA Query and receive no response. In this case it is
assumed that the AP went down ungracefully and is now back up.
Since frame protection is enabled, you must re-associate with
the AP.
Two autotests:
1. Tests SA Query procedure when the AP goes down. In this case the AP
goes down ungracefully, now allowing it to send out any deauth
frames. When the AP comes back up, IWD still thinks its connected.
The AP will then send unprotected disassociate frames so the client
can re-connect. This kicks off the SA Query procedure, which the AP
will not respond to. At this point we can deauth and reconnect to
the AP.
2. Test SA Query procedure when a disassociate frame has been spoofed.
In this case we receive an unprotected disassociate frame and start
SA Query. The AP should then respond to the SA query within the
timeout. We then know the frame was spoofed and can remain
connected.
