Linux error - TCP connect () with ETIMEDOUT

Question

To call TCP client connect () to a TCP server.

Richard Stevens's UNIX® Network Programming book states the following:

If client TCP does not receive a response to its SYN segment, ETIMEDOUT is returned. 4.4BSD, for example, sends one SYN when a connection is called, after another 6 seconds, and another 24 seconds later (p. 828 from TCPv2). If no response is received after 75 seconds, an error is returned.

On Linux, I would like to know what the repetition mechanism is (how many times and how far apart). Request, because to call TCP client connect () I get an ETIMEDOUT error. This socket has the O_NONBLOCK option and is controlled by epoll () for events.

If someone can tell me where in the code this repetition logic is implemented, that would be useful too. I tried to start a little with tcp_v4_connect () from net / ipv4 / tcp_ipv4.c, but soon lost my way.

Answer 1

The timeout is scaled based on the measured round trip time.

tcp_connect() sets the timer:

  /* Timer for repeating the SYN until an answer. */ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, inet_csk(sk)->icsk_rto, TCP_RTO_MAX); 

icsk_rto will use the redirect timeout; if previous metrics from the destination are available from previous connections, it is reused. (For details, see the tcp_no_metrics_save discussion in tcp(7) .) If the metrics are not saved, the kernel will revert to the standard RTO values:

 #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) #define TCP_TIMEOUT_INIT ((unsigned)(1*HZ)) /* RFC2988bis initial RTO value */ #define TCP_TIMEOUT_FALLBACK ((unsigned)(3*HZ)) /* RFC 1122 initial RTO value, now * used as a fallback RTO for the * initial data transmission if no * valid RTT sample has been acquired, * most likely due to retrans in 3WHS. */ 

tcp_retransmit_timer() has some code at the bottom for recalculating the delay:

  inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX); if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1, 0, 0)) __sk_dst_reset(sk); 

retransmits_timed_out() will do a linear delay first and then an exponential trip.

I think it’s long and short that you can reasonably expect about 120 seconds before getting an ETIMEDOUT error from connect(2) if the kernel has no reason to suspect that the remote peer should have answered earlier.

Answer 2

A typical reason for ETIMEOUT is a firewall that simply swallows packets instead of an ICMP Destination Unreachable response .

This is a common setting that allows hackers to probe the network for hosts.