Update wifi libs with below -
1. Break FTM State Machine code into separate functions
2. Use dynamic allocation for FTM session to save memory
3. Add API to get FTM report instead of event based mechanism
4. Add FTM Request retry and comeback support
Make sure that WPS registrar public APIs do not modify supplicant
data in application task context. Execute API functionlity in eloop
context to prevent protential race conditions.
Avoid dereferencing a dangling function pointer in 'eap_server_sm_deinit()'.
This issue arises when hostap unregisteres EAP methods before it removes
the server state machine for station.
1: fixed the incorrect timeing in reporting HCI_Link_Key_Type_Changed.
2: fixed the incorrect iv value during resuming encryption.
3: fixed the incorrect return with hci command rd_stored_link_key.
According to the application note in SD Card Physical Specification:
> The host shall set ACMD41 timeout more than 1 second to abort repeat
of issuing ACMD41 when the card does not indicate ready. The timeout
count starts from the first ACMD41 which is set voltage window
in the argument.
Previously, the timeout was exactly one second, and this caused
certain larger-capacity cards to "time out", because they couldn't
finish initialization process in time.
ACMD41 argument is different between SD mode and SPI mode.
In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD
mode, the bits reflecting the host's OCR should be zero.
Previously, we used to set these bits the same way as for the SD mode.
This has caused certain cards to fail initializing, apparently their
controllers have checked the ACMD41 argument more strictly and refused
to finish initialization, resulting in an error such as
sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107
(Note that this error may have other causes than the one fixed in
this commit. For example, if the card doesn't have a sufficient and
stable power supply, it may also fail to complete the internal
initialization process, and will never clear the busy flag in R1
response.)
Closes https://github.com/espressif/esp-idf/issues/6686
Closes https://github.com/espressif/esp-idf/issues/10542
The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.
Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.
Allow Phase 2 authentication behavior to be configured with a new phase1
configuration parameter option:
'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
tunnel) behavior for PEAP:
* 0 = do not require Phase 2 authentication
* 1 = require Phase 2 authentication when client certificate
(private_key/client_cert) is no used and TLS session resumption was
not used (default)
* 2 = require Phase 2 authentication in all cases
