> Take a look at /proc/tcp, what does it say in the timer fields for
> these sockets?
The timeout field is 0 (actually, it is 0 for _all_ sockets) :
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0808C289:100B 32B967CB:0077 02 00000000:00000000 00:00000000 00000000 600 0 150979
The socket is thus in SYN_SENT, and the corresponding process is
sleeping in inet_stream_connect :
(thomas@melchior) ~ $ ps axl|grep testhost
0 600 15864 15810 0 0 868 404 inet_stream S 2 0:00 testhost
Here is a tcpdump of a case where the problem happens :
14:03:32.823914 cuivre.rezel.enst.fr.4128 > 203.103.185.50.119: S 3306112089:3306112089(0) win 31856 <mss 1460,sackOK,timestamp 26073678[|tcp]> (DF)
14:03:38.823752 cuivre.rezel.enst.fr.4128 > 203.103.185.50.119: S 3306112089:3306112089(0) win 31856 <mss 1460,sackOK,timestamp 26074278[|tcp]> (DF)
14:03:39.441452 203.103.185.50.119 > cuivre.rezel.enst.fr.4128: . ack 3306112090 win 17376 <nop,nop,timestamp 2046099 26074278> (DF)
14:03:39.441554 cuivre.rezel.enst.fr.4128 > 203.103.185.50.119: R 3306112090:3306112090(0) win 0
It looks to me like the 3rd packet (from the remote host, 203.103.185.50)
should have SYN, and so it is legitimate that we reset the connection.
but then, we should time out in inet_stream connect if we cannot
properly accomplish the TCP handshake.
--
Thomas.Quinot@Cuivre.FR.EU.ORG <URL:http://Web.FdN.FR/~tquinot/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu