Hi,
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)
TLS_FreeRTOS_Disconnect
Disconnection time = 15 msec
No delay
TLS_FreeRTOS_Disconnect
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?
Hi,
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 ) );
}
else
{
LogError( ( "(Network connection %p) Failed to send TLS close-notify: mbedTLSError= %s : %s.",
pNetworkContext,
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|v10.6.1+fsp.5.2.0.beta.0|
|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?
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?
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…
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?
When checked the wireshark logs. the Network disconnect happens instantly. but the Freertos takes very long time to respond.
Thank you for sharing that. We need to figure out what is causing this delay - can you try to break the code in debugger and see what it is doing in those 45 seconds? Is that task calling TLS_FreeRTOS_Disconnect ready or is it blocked? Which task is running? Also, as I asked before, did you try @kstribrn’s suggestion of adding timestamps to logs?
Another way could be to integrate a tracing tool to figure out what is happening in those 45 seconds.
To build off of what Gaurav is mentioning…Figuring out why this delay occurs is going to happen in a few steps. The first being discovering which function/task/socket is causing the 45 second delay. Once this has been discovered then we can being drilling down.
If you can give us this information we should be able to get you to a solution.