If we haven’t set a read timeout and the Ethernet link disconnection happens at the other peer, in your case the PC side, by default there isn’t a way the other TCP peer can know the connection is active or not, as there is no way the other peer can communicate the connection has been dropped, as the link disconnection happens abruptly. If read timeout is not set for xConnectedSocket, the default read timeout is the read timeout of the server socket that was listening for incoming TCP connections. If you haven’t configured a read timeout for the listening server socket then the default read timeout will be the one used and is defined by ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME. By default this macro is defined to portMAX_DELAY, so unless you have redefined this macro in the FreeRTOSIPConfig.h the block time is indefinite.
You can check if you redefined ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME in FreeRTOSIPConfig.h.
In the case of link disconnection from the other end, there is a mechanism provided by TCP to detect dormant connection using keep-alive messages. You can read more about it here, note that this feature needs to be enabled explicitly by enabling the macro - ipconfigTCP_KEEP_ALIVE.
Also, instead of relying on the return value of FreeRTOS_recv, another alternate approach is to signal your TCP tasks that the connection has been dropped, maybe by a task notification or semaphore from the vApplicationIPNetworkEventHook_Multi whenever a network down event happens; that would be a faster way to know the link disconnection, and then you can reconfigure your connection.