mbedTLS + 0/3 examples
SourceVu will show references to mbedtls_ssl_handshake() from the following samples and libraries:
 
Symbols
loading...
Files
loading...
SummarySyntaxArgumentsRelatedExamplesReferencesCall TreeData Use

Return value

\c 0 if successful. #MBEDTLS_ERR_SSL_WANT_READ or #MBEDTLS_ERR_SSL_WANT_WRITE if the handshake is incomplete and waiting for data to be available for reading from or writing to the underlying transport - in this case you must call this function again when the underlying transport is ready for the operation. #MBEDTLS_ERR_SSL_ASYNC_IN_PROGRESS if an asynchronous operation is in progress (see mbedtls_ssl_conf_async_private_cb()) - in this case you must call this function again when the operation is ready. #MBEDTLS_ERR_SSL_CRYPTO_IN_PROGRESS if a cryptographic operation is in progress (see mbedtls_ecp_set_max_ops()) - in this case you must call this function again to complete the handshake when you're done attending other tasks. #MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED if DTLS is in use and the client did not demonstrate reachability yet - in this case you must stop using the context (see below). #MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET if a TLS 1.3 NewSessionTicket message has been received. See the documentation of mbedtls_ssl_read() for more information about this error code. #MBEDTLS_ERR_SSL_RECEIVED_EARLY_DATA if early data, as defined in RFC 8446 (TLS 1.3 specification), has been received as part of the handshake. This is server specific and may occur only if the early data feature has been enabled on server (see mbedtls_ssl_conf_early_data() documentation). You must call mbedtls_ssl_read_early_data() to read the early data before resuming the handshake. Another SSL error code - in this case you must stop using the context (see below).

Notes

If DTLS is in use, then you may choose to handle #MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED specially for logging purposes, as it is an expected return value rather than an actual error, but you still need to reset/free the context. Remarks regarding event-driven DTLS: If the function returns #MBEDTLS_ERR_SSL_WANT_READ, no datagram from the underlying transport layer is currently being processed, and it is safe to idle until the timer or the underlying transport signal a new event. This is not true for a successful handshake, in which case the datagram of the underlying transport that is currently being processed might or might not contain further DTLS records. If #MBEDTLS_USE_PSA_CRYPTO is enabled, the PSA crypto subsystem must have been initialized by calling psa_crypto_init() before calling this function. Otherwise, the handshake may call psa_crypto_init() if a negotiation involving TLS 1.3 takes place (this may be the case even if TLS 1.3 is offered but eventually not selected).

References

from 0/3 examples