Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

FreeRTOS+TCP KeepAlive behaviour

Posted by benzer350 on October 16, 2017

For a TCP connection socket, when disconnecting the other device, the stack sends 3 keepalive packets then closes the socket which is great. The problem happens when the device itself is disconnected from the switch (pulled cable out - link down). The IP task detects the link down successfuly then calls the driver initialization function and blocks there until link up (this is the recommended behavior per a comment in the stack code): from FreeRTOSIP line 1332: if( xNetworkInterfaceInitialise() != pdPASS ) { /* Ideally the network interface initialisation function will only return when the network is available. In case this is not the case, wait a while before retrying the initialisation. */ vTaskDelay( ipINITIALISATIONRETRYDELAY ); FreeRTOSNetworkDown(); }

The problem with that is that the task is blocked here and as a result the keep alive counters are stopped and the connection never closes. 
Is this the intent? Am I missing  some concept? I would like the connection to timeout after such an event so the server is free again for another device

FreeRTOS+TCP KeepAlive behaviour

Posted by heinbali01 on October 17, 2017

Hi Ben,

What platform are you using?

For a TCP connection socket, when disconnecting the other device, the stack sends 3 keepalive packets then closes the socket which is great.

Just to make it clear, you mean physically disconnecting. The remote device is unplugged and it will no longer respond to the keep-alive messages. After a third message, the socket gets into a eCLOSE_WAIT state, i.e. the socket shall be closed by the application (without shutting it down).

In source code:

~~~ BaseTypet rc = FreeRTOSrecv( xSocket, pucBuffer, sizeof( pucBuffer ), 0 ); if( rc == -pdFREERTOSERRNOENOTCONN ) { // The socket is not connected any more FreeRTOS_closesocket( xSocket ); xSocket = NULL; } ~~~

And now you unplug your +TCP device from the LAN:

...pulled cable out - link down. The IP task detects the link down successfully then calls the driver initialization function and blocks there until link up (this is the recommended behavior per a comment in the stack code)

This was indeed how the IP-stack used to work, but since we have keep-alive packets, I tend not to use FreeRTOS_NetworkDown() any more. Once the +TCP stack is up, let it stay up.

It is important that xNetworkInterfaceOutput() does not attempt to send data as long as the Link Status is low. That would lead to delays and errors.


FreeRTOS+TCP KeepAlive behaviour

Posted by benzer350 on October 18, 2017

Thanks Hein, Keeping the stack up seems to solve this. When the link is down I make xNetworkInterfaceOutput() return a _FALSE after releasing the packet buffer.


FreeRTOS+TCP KeepAlive behaviour

Posted by heinbali01 on October 18, 2017

When the link is down I make xNetworkInterfaceOutput() return a FALSE after releasing the packet buffer

After checking the value of bReleaseAfterSend, I suppose:

~~~ if( bReleaseAfterSend != pdFALSE ) { vReleaseNetworkBufferAndDescriptor( pxDescriptor ); } ~~~

xNetworkInterfaceOutput() is called from four different places, and the return value is never tested.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS