Date: Thu, 24 Sep 1998 17:56:05 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-net@FreeBSD.ORG Subject: SYN-SENT/out-of-sequence ACK problem Message-ID: <9809241756.aa25260@salmon.maths.tcd.ie>
next in thread | raw e-mail | index | archive | help
I'm seeing a rare problem where an attempt to open a tcp connection between two FreeBSD machines times out, dispite all packets getting through. The problem occurs after a short network outage, when the server side of a connection is still in state ESTABLISHED, but the client has timed out while transmitting, and closed its end of the connection. When network connectivity returns, an attempt to set up the same connection (same client port) will repeatedly time out. The code used to handle out-of-sequence ACKs when in state SYN-SENT is: /* * If we have a cached CCsent for the remote host, * hence we haven't just crashed and restarted, * do not send a RST. This may be a retransmission * from the other side after our earlier ACK was lost. * Our new SYN, when it arrives, will serve as the * needed ACK. */ if (taop->tao_ccsent != 0) goto drop; else goto dropwithreset; When the client tries to re-connect, the server responds with an out-of-sequence ACK as expected. However I think the above code is dropping the ACK without sending a RST because the client has a cached rfc1644 CCsent from the server machine. Without a RST, the server end of the connection never leaves state ESTABLISHED so retransmissions of the SYN do no good, and the client connection times out. I presume that changing the above code to send a RST always will fix the problem, but at the expense of a few extra RST packets in other situations. Or maybe there's a better condition that could be tested? I couldn't find any information in rfc1644 about handling ACKs in SYN-SENT, so presumably the current behaviour isn't standard. Turning off rfc1644 extensions would almost certainly work around the problem of course. Ian [tcpdump of attempt to set up connection] 10:53:43.789324 client.1019 > server.ssh: S 958006397:958006397(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 2339298 0,nop,nop,cc 138368> (DF) (ttl 64, id 14098) 10:53:43.841958 server.ssh > client.1019: . ack 16878888 win 17280 <nop,nop,timestamp 12732297 2339298,nop,nop,cc 6363788> (DF) [tos 0x10] (ttl 58, id 41090) 10:53:46.498057 client.1019 > server.ssh: S 958006397:958006397(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 2339303 0,nop,nop,cc 138368> (DF) (ttl 64, id 14171) 10:53:46.588893 server.ssh > client.1019: . ack 1 win 17280 <nop,nop,timestamp 12732303 2339303,nop,nop,cc 6363788> (DF) [tos 0x10] (ttl 58, id 41167) 10:53:52.498455 client.1019 > server.ssh: S 958006397:958006397(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 2339315 0,nop,nop,cc 138368> (DF) (ttl 64, id 14191) 10:53:52.560653 server.ssh > client.1019: . ack 1 win 17280 <nop,nop,timestamp 12732315 2339315,nop,nop,cc 6363788> (DF) [tos 0x10] (ttl 58, id 41265) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <9809241756.aa25260>