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

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.

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.

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.