Mbed TLS is now part of TrustedFirmware.org.

net_sockets.c


Jan 28, 2018 23:17
Fred Wedemeier

I'm incorporating mbed TLS in a non-supported RTOS (Freescale/NXP MQX 4.2), thus must implement socket and platform functions. I have things built to the point that the email example is working correctly, but now need to get error handling up to production quality. Some questions:

  1. Does the mbed library itself ever use non-blocking sockets with TCP?

  2. Am I correct in assuming the callers of mbedtls_net_recv/sendv() retry themselves if fewer bytes are sent/received than expected?

  3. The delivered mbedtls_net_send() function differentiates a connection reset (MBEDTLS_ERR_NET_CONN_RESET) from other errors (MBEDTLS_ERR_NET_SEND_FAILED). How does the library code handle these differently?

  4. Regarding MBEDTLS_ERR_SSL_WANT_READ/WRITE response in mbedtls_net_recv/send(): Ignoring all the details in the delivered code, am I correct in assuming these responses just mean "The recv/send failed, but may succeed if called again?"

  5. A debug trace in my mbedtls_net_recv_timeout() function shows the 'timeout' value always appears to be the value set in mbedtls_ssl_conf_read_timeout(). Does the library code ever call the function with a 'timeout' value different than this?

 
Feb 6, 2018 13:10
Ron Eldor

Hi Fred,

Does the mbed library itself ever use non-blocking sockets with TCP?

Non blocking sockets is supported. It should be set through mbedtls_net_set_block(). As shown in the net_sockets.c reference code, the bio callbacks should return MBEDTLS_ERR_SSL_WANT_READ and MBEDTLS_ERR_SSL_WANT_WRITE in case the socket would have been blocking. It is shown as a call to net_would_block. The TLS stack returns these errors to the caller, which in turn continue to call the handshake function. Of course, you could choose to implement your callback functions to use timed select, thus removing loop iterations by the application.

Am I correct in assuming the callers of mbedtls_net_recv/sendv() retry themselves if fewer bytes are sent/received than expected?

If I understand you correct, this depends whether you are refering to TLS, which uses the reliable TCP connection, or DTLS, which uses the unreliable UDP connection. If using TCP, since it's reliable, there is no need to resend the packets. on UDP, there are several uses cases where the TLS stack resends requests, but it is when timeouts occur.
If you are referring to reading again until the full handshake message is read, then yes, the TLS stack calls the recv callback in a loop, until all the message bytes read. The bio callbacks should receive how much to read\write, and return how much bytes were read\written or error otherwise.

The delivered mbedtls_net_send() function differentiates a connection reset (MBEDTLS_ERR_NET_CONN_RESET) from other errors (MBEDTLS_ERR_NET_SEND_FAILED). How does the library code handle these differently?

These errors are mostly for application use, to understand if the error is because peer closed the connection(gracefull shutdown) or other error occured.

Regarding MBEDTLS_ERR_SSL_WANT_READ/WRITE response in mbedtls_net_recv/send(): Ignoring all the details in the delivered code, am I correct in assuming these responses just mean "The recv/send failed, but may succeed if called again?"

The short answer is yes. The long answer is that these are special error codes, that don't really mean failure. THey mostly mean "try again". Similar in concept to EAGAIN in linux error codes.

A debug trace in my mbedtls_net_recv_timeout() function shows the 'timeout' value always appears to be the value set in mbedtls_ssl_conf_read_timeout(). Does the library code ever call the function with a 'timeout' value different than this?

No. The read timeout is the timeout intended to be used for f_recv_timeout() callback. There is one special case, in DTLS, where the timeout is the retransmit timeout, which is the timout set for DTLS flight retransmission, which is initiated in mbedtls_ssl_conf_handshake_timeout()

Regards,
Mbed TLS Team member
Ron