phase1 parameters dhgroup, encr, prf, and mac can now be used to specify
which algorithm proposal is selected, e.g., with phase1="dhgroup=3
encr=1 prf=1 mac=1" selecting the mandatory-to-implement case. This is
mainly for testing purposes, but can also be used to enforce stronger
algorithms to be used.
Signed-hostap: Jouni Malinen <j@w1.fi>
These information elements are not really used anywhere in hostapd or
wpa_supplicant nor is there any plan to use them. As such, there is no
need to keep the code here either, so save couple of bytes here.
Signed-hostap: Jouni Malinen <j@w1.fi>
This driver event was used separately for some Action frames, but all
the driver wrappers converted to this from information that would have
been enough to indicate an EVENT_RX_MGMT event. In addition, the
received event was then converted back to a full IEEE 802.11 management
frame for processing in most cases. This is unnecessary complexity, so
get rid of the extra path and use EVENT_RX_MGMT for Action frames as
well as other management frame subtypes.
Signed-hostap: Jouni Malinen <j@w1.fi>
This can be used to silence compiler warnings in cases where #ifdef
blocks can leave some variables or functions unused and there is no
cleaner way of avoiding the warnings.
Signed-hostap: Jouni Malinen <j@w1.fi>
Commit 88b32a99d3 added support for using
some Action frame processing in hostapd for drivers that handle most of
SME/MLME internally (it added FT, this has since be extended for SA
Query and WNM). However, this was added in a way that ended up getting
both the hostapd_rx_action() and hostapd_action_rx() called for Action
frames. This could result in an attempt to process FT, SA Query, and WNM
Action frames twice.
There is need for more significant cleanup in Action frame processing in
hostapd depending on the driver type, but as a simple step to avoid
issues, skip the hostapd_action_rx() call if hostapd_rx_action()
processed the frame.
Signed-hostap: Jouni Malinen <j@w1.fi>
Even though this is a short timeout, it is at least theoretically
possible for the interface to be removed while waiting for
reconfiguration to start. Avoid issues with this by cancelling the
timeout on any WPS interface deinit. In theory, this should be postponed
until interface removal, but that does not fit very nicely to the
current wps_hostapd.c style.
Signed-hostap: Jouni Malinen <j@w1.fi>
Previously, wps_version_number was used only to test extensibility to
newer version numbers, but it can also be used to enable testing of
older versions (1.0), e.g., to avoid hitting some 2.0 specific
validation steps.
Signed-hostap: Jouni Malinen <j@w1.fi>
It is fine to try to cancel a registration that does not exist, so there
is no need to have the duplicated checks for eloop timeout and socket
registration.
Signed-hostap: Jouni Malinen <j@w1.fi>
It was already possible to configure hostapd and wpa_supplicant to use
FT-SAE for the key management, but number of places were missing proper
AKM checks to allow FT to be used with the new AKM.
Signed-hostap: Jouni Malinen <j@w1.fi>
The actual data connection does not seem to work with mac80211_hwsim, so
the hwsim_test results are ignored for now.
Signed-hostap: Jouni Malinen <j@w1.fi>
Action frame RX report through EVENT_RX_ACTION did not indicate whether
the frame was protected or not even though that information is available
in mlme_event_mgmt(). hostapd_rx_action() has a workaround for setting
the protected flag for SA Query frames, but that did not apply for other
frames, like FT Action. This broke FT-over-DS when PMF is enabled with
newer kernel versions (i.e., the ones that do not use monitor interface
for receiving management frames).
Signed-hostap: Jouni Malinen <j@w1.fi>
NOTE: Actual use of the direct link (DLS) is not supported in
mac80211_hwsim, so this operation fails at setting the keys after
successfully completed 4-way handshake. This test case does allow the
key negotiation part to be tested for coverage, though.
Signed-hostap: Jouni Malinen <j@w1.fi>
The earlier changes to buffer EAPOL frames when not associated to avoid
race conditions (especially commit
3ab35a6603 but maybe something even before
that) broke PeerKey 4-way handshake. Fix this by using a separate check
before the race condition workaround to process PeerKey 4-way handshake
EAPOL-Key messages differently.
Signed-hostap: Jouni Malinen <j@w1.fi>
PeerKey entries need to be removed on disassociation and this needs to
be done in a way that cancels the possibly pending eloop timeout.
Signed-hostap: Jouni Malinen <j@w1.fi>
This is not really needed for anything and the standard does not require
such validation step to be made for Authentication frame transmission.
Signed-hostap: Jouni Malinen <j@w1.fi>
