While the Authenticator state machine conditions are already checking
for sm->EAPOLKeyRequest, it seems clearer to explicitly discard any
EAPOL-Key Request frame that is received unexpectedly during a 4-way
handshake.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to try to process the EAPOL-Key frame if it has an
unexpected Key Descriptor Version value. Move these checks to happen
earlier in the sequence. In adition, use a separate helper function for
this to simplify wpa_receive() a bit.
Signed-off-by: Jouni Malinen <j@w1.fi>
Check that the EAPOL-Key frame Key Descriptor Version value is one of
the defined values explicitly instead of failing to process the Key Data
field later (or end up ignoring the unexpected value if no processing of
Key Data is needed).
Signed-off-by: Jouni Malinen <j@w1.fi>
IEEE Std 802.11-2020 describes the rule based on not-TKIP for value 2
and no pairwise cipher condition on value 3, so use that set of more
generic rules here.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it a bit easier to understand what happens with random
channel selection after radar detection.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It looks like best might be NULL in some cases, so check for this
explicitly before trying to dereference it for a debug print.
Fixes: 733de85680 ("ACS: Fix not selecting the best channel in the segment")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
key_data_buf is already freed on the common exit path, so do not try to
free it here on error.
Fixes: 4abc37e67b ("Support Key Data field decryption for EAPOL-Key msg 2/4 and 4/4")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
src/ap/ap_config.c is not really supposed to call directly into a
function in hostapd/config_file.c. Furthermore, the wrapper through
ap_config.c did not really have any real value since it just called a
function that is within hostapd/*.c and that wrapper was called from
hostapd/*.c.
Instead of the wrapper, just call the function directly within the
hostapd directory.
Fixes: 392114a179 ("FT: Add dynamic reload of RxKH definitions from file")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
If the driver fetch for the current sequency number fails, do not try to
print the value in a debug print without having cleared it.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The TX status handler for DPP Authentication Confirm message might have
resulted in use-after-free if the start of a GAS query were to fail,
e.g., due to being somehow unable to transmit the initial request. Avoid
this by explicitly confirming that the authentication session was not
removed.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When removing the bootstrap info for the PB context, all the possible
pointers to that information needs to be cleared to avoid accesses to
freed memory.
Fixes: 37bccfcab8 ("DPP3: Push button bootstrap mechanism")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use smaller variables when possible and reorder the variables to avoid
unnecessary padding. This drops struct mld_link_info size from 64 to 48
bytes and removes 240 bytes from struct sta_info.
Signed-off-by: Jouni Malinen <j@w1.fi>
This function has been used only within beacon.c and it got accidentally
converted to a global function.
Fixes: 6b5e00a80e ("AP: Use a struct for Probe Response generation in/out params")
Signed-off-by: Jouni Malinen <j@w1.fi>
Replace the fixed length maximum buffer size for STA profile with
dynamically allocated buffers for active links. This reduces struct
mld_link_info size by almost 16 kB and drops the per-STA information in
struct sta_info to a more reasonable size to avoid the almost 10x
increase from MLO support.
In addition, free the resp_sta_profile buffers as soon as the ML element
has bee generated for (Re)Association Response frame since those buffers
are not needed after that.
Signed-off-by: Jouni Malinen <j@w1.fi>
The singleton RADIUS client design did not address the deinit path
properly. Since hapd->radius could be shared with another links, the
pointer on all those other links needs to be cleared before freeing the
RADIUS client context. Without this, deinit path could have ended trying
to use freed memory when clearing STA entries from other links and
trying to flush any pending RADIUS client messages.
Fixes: a213fee11d ("AP: MLO: Make IEEE 802.1X SM, authserv, and RADIUS client singletons")
Signed-off-by: Jouni Malinen <j@w1.fi>
Allow the Timeout Interval Type field in the Timeout Interval element to
be overridden with a different value for testing purposes to be able to
bypass the association comeback processing in mac80211. This allows the
wpa_supplicant internal functionality to be tested.
Signed-off-by: Jouni Malinen <j@w1.fi>
hostapd reads the list of Rx Key Holders from hostapd.conf file.
However, for systems where topology changes dynamically, the update
of RxKHs list is required without reloading the whole configuration.
Introduce a new source of RxKH definition with original syntax:
- rxkh_file - Path to a file containing a list of RxKHs.
In addition, add a control interface command RELOAD_RXKHS to
reload RxKHs definition from the file specified in `rxkh_file`.
This allows hostapd to properly distribute Rx keys even after topology
change (assuming rxkh_file is updated and reload_rxkhs command issued).
Syntax of rxkh_file is the same as extraction of r0kh and r1kh options
from original hostapd.conf file.
```
r0kh=ff:ff:ff:ff:ff:ff * 00112233445566778899aabbccddeeff
r0kh=ff:ff:ff:ff:ff:ff * 00112233445566778899aabbccddeeff
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 00112233445566778899aabbccddeef
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 00112233445566778899aabbccddeef
r1kh=00:00:00:00:00:00 00:00:00:00:00:00 00112233445566778899aabbccddeef
```
Signed-off-by: Dariusz Kopka <dariusz@plume.com>
Now that we have a more advanced check for the differences within the
Key Data field, nonzero Key Data Length case can be determined to be
EAPOL-Key msg 4/4 if there is no RSNE in the Key Data field.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Extend RSN authenticator to be able to process EAPOL-Key msg 2/4 and 4/4
messages in cases where the Key Data field is encrypted using AES key
wrapping (i.e., non-AEAD cipher). While there is not yet any defined
case where such encryption would be used in IEEE Std 802.11-2020,
extensions are considered to be added to use such constructions (e.g.,
in IEEE P802.11bh). As such, it is good to extend the parsing and
processing rules in the authenticator to be ready for such
functionality.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The initial Authenticator implementation depended on the Key Data field
being empty for EAPOL-Key msg 4/4. This worked fine for years in
practice, but in theory, vendor specific elements or KDEs could have
been added inti EAPOL-Key msg 4/4 and that would have broken this
design. In addition, the MLD case did introduce a KDE into EAPOL-Key msg
4/4 and required changes here.
As an initial step to make this more robust for future extensions,
recognize a received EAPOL-Key message as msg 4/4 if it is for RSN
(i.e., not WPAv1), has Secure=1, contains an unencrypted Key Data field,
and does not include RSNE.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow additional elements and KDEs to be added to EAPOL-Key msg 1/4 and
3/4 and allow EAPOL-Key msg 3/4 Key Data field to be not encrypted.
These are for testing purposes to enable a convenient mechanism for
testing supplicant behavior with either potential future extensions or
incorrect Authenticator behavior.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Handle the center frequency to channel mapping more cleanly by skipping
the cases where the center frequencies are not set and verifying that
the mapping succeeds when they are set.
Signed-off-by: Jouni Malinen <j@w1.fi>
seg0 and seg1 variables can have any initial value, but they may cause
the BSS to have a wrong configuration later on in cases where the
separate center frequencies are not set.
Signed-off-by: Baligh Gasmi <gasmibal@gmail.com>
There are multiple redundant MIN macro declarations, some of which are
not protecting against side effects. Move it to common.h instead.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
The dpp_test DPP_TEST_STOP_AT_AUTH_CONF case is supposed to prevent the
GAS exchange from happening. It was possible to bypass that testing
functionality if the TX status event for the Authentication Confirm
message was lost or delayed long enough for the GAS Request to be
proessed first. This could happen at least with UML time travel.
Work around this by checking for the special dpp_test case within GAS
request handling.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
If CONFIG_FILS isn't set, the compiler complains about unused variables.
Fix it.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
When a station tries to authenticate to an AP that is affiliated with an
AP MLD, we need to remove all station instances from all the APs.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
If the station is not an MLO station do not attempt to find the
association station and return false in the ML specific disconnection
processing.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
This avoids unnecessary code duplication and adds the sta->wpa_sm deinit
calls for deauthentication while it was previously done only in the
disassociation case.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Set the current value instead of hardcoded 1.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Commit 31e025c033 ("AP: When sending Action frames, use the AP MLD MAC
address if needed") added this for hostapd_drv_send_action(), but the
A3=BSSID variant of that function needs similar changes for GAS to work
correctly with STAs that are currently associated with MLO.
Signed-off-by: Jouni Malinen <j@w1.fi>
Invert the check on hapd->conf->mld_ap on the affiliated links to
actually call the link specific callback handler. This is needed to set
the STA associated.
Fixes: 55038680a6 ("AP: MLO: Handle association callback")
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to allow RSN operations, like PTK rekeying, to be
completed on the correct STA entry. The previous design worked by
accident since it was using the WLAN_STA_ASSOC flag and the code that
was supposed to set that flag did not work correctly and left it unset
for the interfaces that were not used for the initial 4-way handshake.
That needs to be fixed, so this search need to be extended to be able to
prefer the STA entry that has sta->wpa_sm set instead of just the
WLAN_STA_ASSOC flag.
Signed-off-by: Jouni Malinen <j@w1.fi>
The change to use a helper function for checking he_6ghz_reg_pwr_type
missed the difference between two types of checks for different values:
indoor AP vs. SP AP. Fix this by introducing another helper function to
cover the indoor (i.e., SP and non-SP indoor cases).
Fixes: 121ccadeb4 ("AP: A helper function for determining whether the AP is an SP AP")
Signed-off-by: Jouni Malinen <j@w1.fi>
There are bandwidth 320 MHz-1 and 320 MHz-2 channelization in EHT mode.
When using ACS, user might prefer one of the channelization or both, but
original ACS was unable to take such preference.
Another problem is that the original ACS returns only the ideal channel
but no 320 MHz channelization. The function acs_get_bw_center_chan()
also could not correctly return the center frequency of bandwidth 320
MHz that is decided by ACS.
For example, if ACS decide the ideal channel is channel 37 with
channelization 320 MHz-2 (center frequency 6265 MHz),
acs_get_bw_center_chan() returns 6105 MHz, which is 320 MHz-1.
Extend the support for 320 MHz so that ACS can choose the best channel
according to the user's preference. Also, after calling
acs_find_ideal_chan_mode(), the best channel and bandwidth can be
derived.
The changes are:
- bw_type ACS_BW320 is divided into ACS_BW320_1 and ACS_BW320_2
- in bandwidth 320 MHz, find the best channel and bandwidth according to
user's perference (320 MHz-1, 320 Mhz-2 or both are OK)
- before acs_find_ideal_chan_mode() returns, update bw320_offset in
iface->conf so that the best channel's channelization is recorded.
- get the best center frequency from bw320_offset
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Introduce a new configuration option, "eht_bw320_offset", which enables
devices to specify a preferred channelization for 320 MHz BSSs when
using automatic channel selection (ACS). This option is applicable only
when the channel is not already decided and the bandwidth is set to 320
MHz.
The value and meaning of the option:
0: auto-detected by ACS
1: 320 MHz-1
2: 320 MHz-2
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Fix the following bugs about selecting the best channels in the segment:
1. If the 'update_best' once became false, it never becomes true again.
In other word, if one of the channels in the segment is not usable,
the remaining channels in the segment were never able to be the best
channel.
2. The primary channel in the segment might not be usable due to the
insufficient survey data. Therefore, it cannot be the best channel and
we cannot take its factor/weight into account.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Allow ACS to pick a HT40- channel in the 2.4 GHz band in addition to the
previously hardcoded HT40+ case.
Co-developed-by: Money Wang <money.wang@mediatek.com>
Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
