- If internet connectivity weakened or disappeared suddenly while we were
in the TLS handshake stage, the app got stuck at that point indefinitely.
- This was because when timeout was not explicitly specified in esp_tls_cfg_t,
the default timeout was set at the wrong place. This causes the sockets to be
setup with zero timeout, hence the indefinite wait.
- Added a config option to set the minimum Certificate Verification
mode to Optional
- When this option is enabled, the peer (the client) certificate
is checked by the server, however the handshake continues even if
verification failed.
- By default, the peer certificate is not checked and ignored by the server.
Closes https://github.com/espressif/esp-idf/issues/8664
- Can be used to get connection or client information (SSL context)
- E.g. Client certificate, Socket FD, Connection state, etc.
- Added example callback for getting client certificate information in 'https_server/simple' example
Closes https://github.com/espressif/esp-idf/issues/7479
Also added parameter checks if used from as a public API
and updated the `is_plein_tcp` description that it's possible to connect
directly using plain tcp transport with the new API.
Current code applies keep_alive_enable setting to TCP_KEEPIDLE, fix it.
Fixes: 2d25252746 ("esp-tls: Rework tcp_connect() to use more subroutines")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
wolfSSL error codes are mostly positive numbers, but esp-tls potentially
non-block API (read/write) returns ssize_t, i.e. bytes read/written if
>0, errorcode otherwise. To comply with this API we have to conditionate
the wolfssl return codes to negative numbers, preferably the same codes
as mbedTLS codes.
Refactored the esp_tcp_connect() functionality to break it down to
* dns-resolution + socket creation
* set configured socket options
* set/reset non-block mode
* the actual connection in non-blocking mode
Transport's error_handle is used to capture different types of errors
including esp_err_t from esp-tls and socket/system errors.
This change adds the following error codes for TCP transport:
* connection closed by a FIN flag (clean closure from server)
* DNS resolution problem
* connection timeout
These errors are already defined in esp-tls component and since this
component will be used in the future for both TCP and SSL transport, we
currently report these issues in transport::error_handle::esp_tls_last_error
of standard esp error type (esp_err_t)
Closes https://github.com/espressif/esp-mqtt/issues/182
purpose)
By default esp-tls client will now return error if no server verify option
is provided, earlier it used to skip the verification by
default.
Added config option to skip server verification by default (for testing
purpose)
Updated required docs
* Target components pull in xtensa component directly
* Use CPU HAL where applicable
* Remove unnecessary xtensa headers
* Compilation changes necessary to support non-xtensa gcc types (ie int32_t/uint32_t is no
longer signed/unsigned int).
Changes come from internal branch commit a6723fc
