FreeRTOS Support Archive

The FreeRTOS support forum can be used for active support both from Amazon Web Services
and the community. In return for using our software for
free, we request you play fair and do your bit to help others! Sign up
to receive notifications of new support topics then help where you can.

This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.

FreeRTOS+TCP KeepAlive behaviour

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

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).

...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.