[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: connect() does not return ETIMEDOUT

I had to set connect to do non blocking connections in order to
avoid this problem, the 4 minutes timeout and use getsockopt for low level
error check on the socket.

-----Original Message-----
From: Manfred Bartz []
Sent: Wednesday, August 15, 2001 11:34 AM
Subject: Re: connect() does not return ETIMEDOUT

Andi Kleen <> writes:

> It works correct here (2.4.7-something)

Ok, after running tcpdump, it now looks the problem is not with
connect() but elsewhere. Linux 2.4.8, same results on 2.4.2

The programs which demonstrate the problem, pcap file and
other files are at <>.

My experimental server will accept() two connections and the
backlog is set to 1 (one) in the call to listen().

My experimental client will open up to 100 connections to
the server. The first 6 connections succeed immediately.
Subsequent connections succeed at a rate of 2 connections
every 9 seconds.

Under Solaris, the client succeeds with 4 connections,
the 5th connect() gives ETIMEDOUT after about 4 minutes.

server side:
/* tcp socket bound to port 7000 */
listen(listen_fd, 1); /* backlog set to 1 */
accept() called twice only.

commented and compacted tcpdump:

The server has now accept()ed 2 connections and does no
further calls to accept().

Connection 3, backlog, ok
10:22:01.258195 > S
10:22:01.258283 > S ack
10:22:01.258970 > . ack

10:22:01.024577 Connection[3] established. connect()==0

Connection 4, ?
10:22:01.265549 > S
10:22:01.265634 > S ack
10:22:01.266324 > . ack

10:22:01.031926 Connection[4] established. connect()==0

The backlog was set to one, but it completes and queues
two connections. Is that because the kernel maintains two
queues (one each for incomplete and complete connections)?

Connection 5, ? should fail
10:22:01.272881 > S
10:22:01.272958 > S ack
10:22:01.273650 > . ack

10:22:01.039251 Connection[5] established. connect()==0

10:22:04.866558 > S ack
10:22:10.866629 > S ack
10:22:22.866793 > S ack

Connection 6, ? should fail
10:22:01.280139 > S
10:22:01.280223 > S ack
10:22:01.280917 > . ack

10:22:01.046514 Connection[6] established. connect()==0

10:22:05.666558 > S ack
10:22:11.666637 > S ack
10:22:23.666789 > S ack

etc. etc...

connect() keeps returning 0 (success) because the client
side sees the full 3-way handshake.


Once the backlog is exhausted, shouldn't the server side
TCP stop sending SYNs and either be quiet or perhaps send
an appropriate ICMP response?

Why does the server side keep sending SYNs after the connection
handshake was apparently completed?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.043 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site