Socket Send function is not working as expected

[mayankpatel-cell]

We are working on a Wi-Fi gateway project that sends data through a secure TCP socket.

The data we are sending is put into a queue. A separate thread fetches data from that queue and sends it over the TCP socket using the POSIX send() function.

When the send() function fails, it returns -1 with an EAGAIN error. In this case, we put the message (let's call it message1) back into the queue and then attempt to send the next message (message2).

When we try to send message2, the send() function reports success and returns the number of bytes sent. The problem is that while the function reports success for message2, it actually sends message1—the message that failed in the previous attempt. As a result, message2 is lost.

Initially, we thought this was an issue with our queue implementation. However, after adding logs, we discovered the problem lies with the send() function itself. We are using nRF Connect SDK v2.5.2 and have also tested this on v2.9.1; the problem persists on both versions. The send() function always returns -1 on failure and never indicates that a partial message was sent.

[rlubos]

I think this might be a limitation in the mbed TLS itself, the mbedtls_ssl_write() documentation says:

 * \note           When this function returns #MBEDTLS_ERR_SSL_WANT_WRITE/READ,
 *                 it must be called later with the *same* arguments,
 *                 until it returns a value greater than or equal to 0. When
 *                 the function returns #MBEDTLS_ERR_SSL_WANT_WRITE there may be
 *                 some partial data in the output buffer, however this is not
 *                 yet sent.

This basically means, that if a socket returns EAGAIN (when the socket is non-blocking or timeout has been configured), the next call from the application should contatin the same data to comply with mbed TLS requirements. And to be honest I don't really see a workaround for this in the stack if we want to support non-blocking sockets, will likely need to document this behavior.