TLS_FreeRTOS_Disconnect takes more than 30 secs if a delay is not provided before the function call

I have a code where after completing the operations, want to disconnect an established TLS connection with TLS_FreeRTOS_Disconnect

The issue is:
Delay (>10 msec)
Disconnection time = 15 msec

No delay
Disconnection time = 45 secs

is the delay required? if so can you please help me with the documentation/explanation for why the delay is required?

Apologies but you will have to provide more information before anybody can suggest a solution.

What is being disconnected? Is it an existing TLS connection?

Which TCP/IP stack are you using, and which version? How is this function implemented?

Where is the delay - is it something you are measuring? Or a delay you are adding into the code?


So sorry if I wasn’t clear with my question.

Let me put a piece of code to explain the scenario in detail

            APP_PRINT("before TLS_FreeRTOS_Disconnect\r\n");
            R_BSP_SoftwareDelay(50, BSP_DELAY_UNITS_MILLISECONDS);
            gpt_init_data_process(0,1);               - Starts the timer
            TLS_FreeRTOS_Disconnect (&xNetworkContext);
            gpt_init_data_process(1,1);                - Stops the timer and calculate the elapsed time
            APP_PRINT(" after TLS_FreeRTOS_Disconnect\r\n");

With the above peice of code the execution time of TLS_FreeRTOS_Disconnect function takes 15 ms

>             APP_PRINT("before TLS_FreeRTOS_Disconnect\r\n");
>             gpt_init_data_process(0,1);           - Starts the timer
>             TLS_FreeRTOS_Disconnect (&xNetworkContext);
>             gpt_init_data_process(1,1);           - Stops the timer and calculate the elapsed time
>             APP_PRINT(" after TLS_FreeRTOS_Disconnect\r\n");

With no delay before TLS_FreeRTOS_Disconnect the execution time increases to 45 secs

PN: TLS_FreeRTOS_Connect function executes successfully and we are able to connect to the server too.

Here is the implementation for TLS_FreeRTOS_Disconnect

void TLS_FreeRTOS_Disconnect( NetworkContext_t * pNetworkContext )
    TlsTransportParams_t * pTlsTransportParams = NULL;
    BaseType_t tlsStatus = 0;

    if( ( pNetworkContext != NULL ) && ( pNetworkContext->pParams != NULL ) )
        pTlsTransportParams = pNetworkContext->pParams;
        /* Attempting to terminate TLS connection. */
        tlsStatus = ( BaseType_t ) mbedtls_ssl_close_notify( &( pTlsTransportParams->sslContext.context ) );

        /* Ignore the WANT_READ and WANT_WRITE return values. */
        if( ( tlsStatus != ( BaseType_t ) MBEDTLS_ERR_SSL_WANT_READ ) &&
            ( tlsStatus != ( BaseType_t ) MBEDTLS_ERR_SSL_WANT_WRITE ) )
            if( tlsStatus == 0 )
                LogInfo( ( "(Network connection %p) TLS close-notify sent.",
                           pNetworkContext ) );
                LogError( ( "(Network connection %p) Failed to send TLS close-notify: mbedTLSError= %s : %s.",
                            mbedtlsHighLevelCodeOrDefault( tlsStatus ),
                            mbedtlsLowLevelCodeOrDefault( tlsStatus ) ) );

        /* Call socket shutdown function to close connection. */
        TCP_Sockets_Disconnect( pTlsTransportParams->tcpSocket );

        /* Free mbed TLS contexts. */
        sslContextFree( &( pTlsTransportParams->sslContext ) );

The versions are specific to renesas

|FreeRTOS - Memory Management - Heap 4|v10.6.1+fsp.5.2.0.beta.0|
|Arm mbed TLS|v3.4.0+renesas.5.fsp.5.2.0.beta.0|
|AWS PKCS11 to mbedTLS|v3.5.0+fsp.5.2.0.beta.0|

post obsoleted, can not delete

My apologies, It is 45 seconds if we don’t add the delay

45 seconds, or milliseconds?

I would guess the delay is because the connection is completing something before the disconnect operation can proceed. Putting the delay in just happens to ensure whatever that operation is completes before the disconnect operation starts. That could explain a 45ms delay, but not a 45 second delay. What is happening on the socket before you attempt to disconnect it?

1 Like

How many other tasks do you have at the same priority as the one calling TLS_FreeRTOS_Disconnect? Can you try increasing the priority of this task? Also, is it possible to capture network trace to see when the actual disconnect is sent?

1 Like

Another idea would be to place timestamped logs (you could even use the FreeRTOS tick count) around various calls made in TLS_FreeRTOS_Disconnect. This might shed some light onto which call is taking 45 seconds. If the calling task is not being pre-empted or interrupted then this will could be a simple way to figure out which function call to research further.

45 seconds is quite the delay though…

1 Like

I did increase the priority with no affect.

Did you try @kstribrn’s suggestion of adding timestamps to logs? Are you able to capture network trace?