From owner-freebsd-hackers Sun Oct 4 23:13:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA14971 for freebsd-hackers-outgoing; Sun, 4 Oct 1998 23:13:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from msf1.swe.ids.dps.casa.es (h025108.nexo.es [195.235.25.108]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA14937 for ; Sun, 4 Oct 1998 23:12:47 -0700 (PDT) (envelope-from jlfreniche@acm.org) Received: from hpswe.swe.ids.dps.casa.es (hpswe.swe.ids.dps.casa.es [172.16.50.100]) by msf1.swe.ids.dps.casa.es (8.8.8/8.8.8) with ESMTP id LAA00365; Fri, 2 Oct 1998 11:16:44 +0200 (CEST) (envelope-from jlfreniche@acm.org) Received: from hpswe.swe.ids.dps.casa.es (localhost [127.0.0.1]) by hpswe.swe.ids.dps.casa.es with SMTP (8.7.6/8.7.3) id LAA03370; Fri, 2 Oct 1998 11:14:04 +0200 (METDST) Message-ID: <36149958.47B1@acm.org> Date: Fri, 02 Oct 1998 11:14:00 +0200 From: "Juan L. Freniche" X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX B.10.20 9000/879) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG CC: Ian Dowse Subject: Invalid ACKs in SYN-SENT and T/TCP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Recently I sent this message to freebsd-net and got no response. May be that the message never arrived so I try again. But somebody recommended me to send it to this list. Note that Ian Dowse already reported the same. We have two FreeBSD 2.2.7 boxes connected through Ethernet, both with T/TCP enabled. We have noted the following behaviour: 1 Assume A started several normal TCP connections to B. Client connections in A use local ports selected in the command line when the client is launched. After a while, leave only one such connection in Established. 2 Unplug the Ethernet cable from Box A and reboot Box A. Reason to unplug is to avoid that the RSTs sent by A reach the connection in B. 3 Launch again several connections from A to B, but using a different local port than the old still-established socket in B. Finish them now normally. The reason of the above is to build, in A, a TAO cache for B. 4 Launch a connection from A to B but using the same local port than the old still-established socket in B. If tcpdump is used for tracing, we will see: - A sends a SYN to B. This new connection is in SYN-SENT in A. - B responds with an ACK, probabilistic invalid because it is the old still-established socket who is responding. - A does not respond with a RST, instead the SYN is retransmitted after the retransmission timeout. - B again responds with an ACK, invalid. - and so on, until the SYN retransmissions are exhausted. RFC 793 (TCP) states in page 66 that a RST must be send if an invalid ACK is received in SYN-SENT (as the received ACK has not the RST bit). Instead, A is ignoring such invalid ACKs, and then retransmitting the SYN. Nothing is said about this in the T/TCP RFCs 1379 and 1644 (at least, I could'nt find this case). I consulted the Stevens book, vol 3, the figure that is identical to the source code (file /usr/src/sys/netinet/tcp_input.c): case TCPS_SYN_SENT: if ((taop = tcp_gettaocache(inp)) == NULL) { taop = &tao_noncached; bzero(taop, sizeof(*taop)); } if ((tiflags & TH_ACK) && (SEQ_LEQ(ti->ti_ack, tp->iss) || SEQ_GT(ti->ti_ack, tp->snd_max))) { /* * 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; This explain why A didn't sent RSTs when receiving invalid ACKs: A has a valid TAO cache for B, so the invalid ACK is ignored. My question is: is this behaviour what it was intended? The comment in the code covers one case, but aborting connections and loosing its RST is not so unlikely. Should A come back to RFC 793? -- Juan L. Freniche To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message