gcc 12.1 complains about using pointer after realloc as it could
potentially be moved/freed, causing any uses after UB.
Fix this by doing checks before realloc and use those statuses and
update with new BSS.
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
Set WPA_DRIVER_FLAGS2_SAE_OFFLOAD flag if the driver indicates SAE
authentication offload support for STA mode. Allow SAE password to be
provided to the driver in such cases when using the CONNECT command.
Signed-off-by: Chung-Hsien Hsu <chung-hsien.hsu@infineon.com>
Signed-off-by: Daisuke Mizobuchi <mizo@atmark-techno.com>
The key server may be removed due to the ingress packets delay. In this
situation, the endpoint of the key server may not be aware of this
participant who has removed the key server from the peer list. Because
the egress traffic is normal, the key server will not remove this
participant from the peer list of the key server. So in the next MKA
message, the key server will not dispatch a new SAK to this participant.
And this participant cannot be aware of that that is a new round of
communication so that it will not update its MI at re-adding the key
server to its peer list. So we need to update MI to avoid the failure of
re-establishment MKA session.
Signed-off-by: Ze Gan <ganze718@gmail.com>
The key server may not include dist sak and use sak in one packet.
Meanwhile, after dist sak, the current participant (non-key server) will
install SC or SA(s) after decoding the dist sak which may take few
seconds in real physical platforms. Meanwhile, the peer expire time is
always initialized at adding the key server to peer list. The gap
between adding the key server to peer list and processing next use sak
packet may exceed the threshold of MKA_LIFE_TIME (6 s). It will cause an
unexpected cleanup (delete SC and SA(s)), so update the expire timeout
at dist sak also.
Signed-off-by: Ze Gan <ganze718@gmail.com>
Prevent loading arbitrary executable code based on config at runtime,
while allowing libraries to be specified at compile time when they are
known in advance.
Add the ability to configure libraries to load at compile time.
* CONFIG_PKCS11_ENGINE_PATH - pkcs11_engine library location.
* CONFIG_PKCS11_MODULE_PATH - pkcs11_module library location.
* CONFIG_OPENSC_ENGINE_PATH - opensc_engine library location.
Add flags with the ability to set each of the libraries to NULL and
prevent loading them at runtime.
* CONFIG_NO_PKCS11_ENGINE_PATH - prevents loading pkcs11_engine
library.
* CONFIG_NO_PKCS11_MODULE_PATH - prevents loading pkcs11_module
library.
* CONFIG_NO_OPENSC_ENGINE_PATH - prevents loading opensc_engine
library.
* CONFIG_NO_LOAD_DYNAMIC_EAP - prevents loading EAP libraries at
runtime.
Signed-off-by: David Ruth <druth@chromium.org>
Fix the calls to wc_AesEncryptDirect(). Old versions of wolfCrypt FIPS
had wc_AesEncryptDirect() return void instead of int. Fix this build
issue.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
dpp_config_legacy_gen_two_conf_psk and dpp_config_legacy_gen_two_conf
tried to set a DPP parameter before having verified that CONFIG_DPP was
used in the build.
Signed-off-by: Jouni Malinen <j@w1.fi>
Starting a thread to initiate DPP before starting the responder through
sigma_dut can result in unexpected testing behavior since there may not
be enough time to get the responder enabled before timing out som
initiator actions. Wait a second at the beginning of the initiator
thread in dpp_init_conf() similarly to how this was handled in other
initiator-from-thread cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Wait for stdout/stderr in a more robust manner to avoid blocking the
pipes and kill the sigma_dut process if it fails to terminate cleanly.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpas_dpp_connected() is called from wpa_supplicant_set_state(), i.e.,
from the middle of processing of the post 4-way handshake steps. Sending
a DPP Public Action frame at that point can delay other operations, so
allow those steps to be completed first before sending out the DPP
connection status result.
Signed-off-by: Jouni Malinen <j@w1.fi>
Responder receives Authentication Request and Config Request in a
sequence and it is possible for the Config Request to be received before
MGMT_RX_PROCESS has been processed for Authentication Request in the
cases where the test script is in the middle of RX processing. This can
result in DPP-AUTH-SUCCESS being delivered only after the MGMT-RX event
for Config Reques which means that wait_auth_success() would lose that
MGMT-RX event.
Avoid this issue by caching the "extra" MGMT-RX event within
wait_auth_success() and having the caller verify if the Config Request
(GAS Initial Request) has already been received before waiting to
receive it.
This makes dpp_gas, dpp_gas_comeback_after_failure, and
dpp_gas_timeout_handling more robust.
Signed-off-by: Jouni Malinen <j@w1.fi>
It looks like mac80211 ROC handling can end up postponing offchannel TX
operation by the previously started and already canceled wait time if
the new NL80211_CMD_FRAME is issued immediately after
NL80211_CMD_FRAME_WAIT_CANCEL. Make this more robust by waiting for the
driver event that indicates completion of the cancel operation (i.e.,
NL80211_CMD_FRAME_WAIT_CANCEL as an event) before issuing
NL80211_CMD_FRAME for another channel. If the driver event is not
received within 10 ms, start the operation anyway to avoid unexpected
behavior if there are drivers that do not end up notifying end of the
wait.
This fixes some issues with authentication initiation for cases where
multiple channels are iterated. This can also significantly speed up
that process.
Signed-off-by: Jouni Malinen <j@w1.fi>
UML time travel allows the deauthentication event to be processed more
quickly than the delivery of EAP-Success to the client through the test
script, so accept either sequence here.
Signed-off-by: Jouni Malinen <j@w1.fi>
connect_network() tried to make test log more readable with a
dump_monitor() call at the end of the function. However, this could end
up practically dropping an event that arrives more or less immediately
after CTRL-EVENT-CONNECTED. This could happen with UML time travel,
e.g., in suite_b_192_pmksa_caching_roam.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Wait for hostapd connection event before issue HS20_WNM_NOTIF to avoid a
race condition with UML time travel.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The first event could have theoretically been received with reltime
sec=0, so use the helper function to check whether the reltime value is
actually set so that the usec part is checked as well. This is not going
to have a difference in practice, but it was possible to hit this corner
case with mac80211_hwsim testing (ap_cipher_tkip_countermeasures_sta)
using UML and time travel.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for Authentication negotiated over IEEE Std 802.1X
with key derivation function using SHA-384.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Many of the STRUCT_PACKED structs are not within the pragmas resulting
in wrong packing using MSVC. Fix it by moving pragma to EOF to ensure
proper packing.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
When channel 140 is configured in mesh, interface fails to come up due
to channel bond (136,140). Since Channel 136 is not HT40+ capable,
validation for HT channel bonding fails when it checks whether first
channel in the bond (channel 136) is HT40+ capable.
In mesh, during channel setup, secondary channel offset for the
configured channel will be selected as +1 if primary channel is capable
of HT40+. In current code, channel 140 is not allowed as HT40+ and hence
secondary channel offset is selected as -1, which makes 136 as secondary
channel. But channel 136 is not HT40+ supported and fails in channel
bonding validation.
Add 140 to HT40+ allowed list as HT40+ is supported for the channel.
Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com>
Pointer entry->ssid might be passed to owe_trans_ssid_match() function
as argument 3 with NULL value, and it may be dereferenced there. This
looks like a theoretical case that would not be reached in practice, but
anyway, it is better to check entry->ssid != NULL more consistently.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Since wpa_supplicant version 2.10 the extended capabilities MSCS and SCS
are advertised in the (Re)Association Request frames.
This causes the association request to be rejected by several access
points. Issue was observed with:
- D-Link DIR600
- TP-Link AC1900
- Synology MR2200ac
To avoid this issue the extended capabilities MSCS and SCS shall only be
added if the bss also supports them. While this may not follow the exact
behavior described in IEEE 802.11, this is a reasonable compromise to
avoid interoperability issues since these capabilities cannot be used
with an AP that does not support them anyway.
Note: The Extended Capabilities element is only included in the
Association Request frames if the AP also sent its extended capabilities
(see wpas_populate_assoc_ies()) as a workaround for misbehaving APs.
This workaround exists since version 2.1.
Signed-off-by: Sebastian Priebe <sebastian.priebe@konplan.com>
There is a delay between sending Association Response frame after having
received Association Request frame, due to the fact that between
receiving the request and sending the response the Beacon frame contents
is updated, after analyzing inputs from the STA. There may be several
updates if multiple fields need to change. This can cause issues with
some devices in noisy environments with many BSSs and connected STAs.
Optimize this by updating the beacon only once, even if there are
multiple reasons for updates.
Signed-off-by: Jurijs Soloveckis <jsoloveckis@maxlinear.com>
If the number of TBTT info is greater than RNR_TBTT_INFO_COUNT_MAX, the
new Neighbor AP Information field would need to be added in the RNR
element. However, the condition of adding Neighbor AP Information field
does not consider number of TBTT info. That would cause invalid Neighbor
AP Information field (the while loop will fill data by eid pointer) when
setting RNR element.
Signed-off-by: Allen.Ye <allen.ye@mediatek.com>
When it comes to set some BSS's beacon, there are two reasons to
update the beacon of co-located hostapd_iface(s) at the same time:
1. 6 GHz out-of-band discovery
2. MLD operational parameters update
BSS load update is unrelated with the above two reasons, and therefore
is not the case to update beacon for co-location. Moreover, updating
beacon for co-location when BSS load update makes hostapd set beacon too
frequently, which makes hostapd busy setting beacon in a multi-BSS case.
Add a new function to update beacon only for current BSS and use the
function during BSS load update.
Signed-off-by: Michael Lee <michael-cy.lee@mediatek.com>
Signed-off-by: Money Wang <money.wang@mediatek.com>
