FreeRTOS TCP/IP in case FreeRTOS_send sends 0 byte

Libraries
1

I have a small question that relates to FreeRTOS TCP/IP in case FreeRTOS_send sends 0byte.

As my understanding, FreeRTOS_send function will return 0 when nothing could be sent. In that case, xMbedTLSBioTCPSocketsWrapperSend will return 0 . When performing the TLS handshake, due to the return of xMbedTLSBioTCPSocketsWrapperSend = 0, the performance fails for sure.
And then, mbedtlsError = TLS_TRANSPORT_HANDSHAKE_FAILED, and system requires reconnecting by TLSConnect. It wastes time to wait until reconnecting.
Is that good for FreeRTOS TCP/IP?

Do we need concern to cover xMbedTLSBioTCPSocketsWrapperSend in case 0 as following example :slight_smile: ?

image
image607Ă—547 13.1 KB

2

So essentially want mbedTLS to retry when FreeRTOS_Send fails to send. How would you differentiate between a dead connection and a legitimate timeout? Wouldn’t a better solution be to set a send timeout for the socket?

3

I added timeout to send for the socket already. So, here is my understanding, if FreeRTOS TCP/IP allows sending 0byte, a reconnection will happen. In some cases, if can not send anything in a short period (sending 0byte), mbedTLS does not retry and execute the reconnetion on FreeRTOS_Connect.

Im designing a solution that can improve it by retying in mbedTLS in other connectivities. I can differentiate between a dead connection and error while transfering data as well. Because transfering data can be back in short period ( slow network case ), I appied by covering 0 byte case in xMbedTLSBioTCPSocketsWrapperSend.

So i just want to know, FreeRTOS TCP/IP supported or not.

4

There are two possibilities in case of a 0 return value:

  1. A retry will succeed.
  2. A retry will NOT succeed.

As long as you are able to differentiate between the two or you can bound the number of retries, you are good.

1 Like
5

When FreeRTOS_send API is called on a valid socket (non-null, bounded, TCP socket) with the length of the data being zero, it returns zero and does nothing else.

1 Like
6

it returns zero and does nothing else.

So what happen with mbedTLS? It will return TLS_TRANSPORT_HANDSHAKE_FAILED and reconnect right?
In this case, can we change it to MBEDTLS_ERROR_SSL_WANT_WRITE to continue retying to perform handshake? Is it a better solution?

7

Thanks. In ethernet case, do we need improve FreeRTOS/FreeRTOS-Plus/Source/Application-Protocols/network_transport/mbedtls_bio_tcp_sockets_wrapper.c at 5fc7a750a0d603c1c68d554226d91d44ba922173 · FreeRTOS/FreeRTOS · GitHub when return value is zero?

8

You can do that. The assumption in that is retries will eventually succeed OR there is an upper bound on the number of retries in mbedTLS.

This is an example and you are free to update it as per your application needs. As I mentioned before, I am not sure that it is necessarily a better solution and therefore, I’d avoid changing it in our example.

1 Like
9

Let me summarize what I understood in this box.

For FreeRTOS TCP/IP, FreeRTOS_send can send 0 byte. There are two possibilities in case of a 0 return value:

  • A retry will succeed.
  • A retry will NOT succeed. (dead connection)

Currently, if FreeRTOS_send has a 0 return value, mbedTLS just returns 0 and reconnection.
In case I want to return MBEDTLS_ERROR_SSL_WANT_WRITE, just make sure that “retries will eventually succeed OR there is an upper bound on the number of retries in mbedTLS” as you mentioned before.

10

Yes, looks good! I’d also suggest to increase the send timeout value for the socket and see if that solves your problem.

1 Like