-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Description
The connection timeout (_sched_connection_timeout()) is only scheduled inside functions and removed when exiting the function, e.g in gnrc_tcp_recv().
That means that if the user timeout supplied is smaller than the connection timeout, the connection timeout will never be generated.
This is a problem if the user timeout is set to a low value for interactive applications.
Those can never detect if the connection is lost.
Expected results
If there was no interaction with the remote within CONFIG_GNRC_TCP_CONNECTION_TIMEOUT_DURATION_MS, the connection must be terminated.
Actual results
The connection is kept open indefinitely.
Steps to reproduce the issue
Consider the telnet server:
while (1) {
res = sock_tcp_read(client, rx_buf, sizeof(rx_buf), 50);
if (res == -ETIMEDOUT) {
/* no character received, try again */
continue;
}
if (res < 0) {
/* break the loop, terminate the connection */
break;
}To ensure interactivity there is a low user timeout (otherwise the sock_tcp_read() call will block until the whole rx_buf is filled). If the remote connection is lost, the connection will be terminated to listen for a new connection, otherwise try to read more bytes.
For easier reproducibility I lowered CONFIG_GNRC_TCP_CONNECTION_TIMEOUT_DURATION_MS to 10s.
I ran examples/telnet_server on same54-xpro. The board has an Ethernet interface, so loss of network connection can be forced by disconnecting the cable.
- connect to the board with e.g
telnet fe80::fec2:3dff:fe23:22df%eno1 - disconnect the Ethernet cable
- close the telnet application
- wait ~10s (or whatever you have set for
CONFIG_GNRC_TCP_CONNECTION_TIMEOUT_DURATION_MS) - connect the ethernet cable again
- try to connect again with e.g.
telnet fe80::fec2:3dff:fe23:22df%eno1- the connection can not be established as the server is still connected to the stale socket