From owner-freebsd-bugs Thu Feb 8 17:30:26 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A6F0537B65D for ; Thu, 8 Feb 2001 17:30:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f191U3x51964; Thu, 8 Feb 2001 17:30:03 -0800 (PST) (envelope-from gnats) Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id BF01437B4EC for ; Thu, 8 Feb 2001 17:28:42 -0800 (PST) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14R2MW-0002gK-00 for FreeBSD-gnats-submit@freebsd.org; Fri, 09 Feb 2001 01:28:36 +0000 Message-Id: Date: Fri, 09 Feb 2001 01:28:36 +0000 From: Tony Finch Reply-To: Tony Finch To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/24962: properly delay acks in half-closed TCP connections Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 24962 >Category: kern >Synopsis: properly delay acks in half-closed TCP connections >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 08 17:30:03 PST 2001 >Closed-Date: >Last-Modified: >Originator: Tony Finch >Release: FreeBSD 4.2-STABLE i386 >Organization: Covalent Technologies, Inc. >Environment: FreeBSD hand.dotat.at 4.2-STABLE FreeBSD 4.2-STABLE #2: Thu Feb 8 08:45:48 GMT 2001 fanf@hand.dotat.at:/FreeBSD/obj/FreeBSD/releng4/sys/DELL-Latitude-CSx i386 >Description: On page 47 of TCP/IP Illustrated, Volume 3, Stevens says: ``One question is why does the client immediately ACK the first two of the three server replies, since they arrive in a short amount of time (44ms)? The answer is in the TCP_REASS macro (p. 908 in Volume 2), which is invoked for each segment of data received by the client. Since the client's end of the connection enters the FIN_WAIT_2 state then segment 4 is processed, the test in TCP_REASS for whether the state is ESTABLISHED fails, causing an immediate ACK instead of a delayed ACK. This "feature" is not unique to T/TCP but can be seen with the Net/3 code whenever one end half-closes a TCP connection and enters the FIN_WAIT_1 or FIN_WAIT_2 state. From that point on, every segment of data from the peer is immediately ACKed. The test for the ESTABLISHED state in the TCP_REASS macro prevents data from being passed to the application before the three-way handshake completes. There is no need to immediately ACK in-sequence data when the connection state is greater than ESTABLISHED (i.e. this test should be changed).'' >How-To-Repeat: >Fix: Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.4 diff -u -r1.107.2.4 tcp_input.c --- tcp_input.c 2000/08/16 06:14:23 1.107.2.4 +++ tcp_input.c 2001/02/08 22:58:38 @@ -176,7 +176,7 @@ #define TCP_REASS(tp, th, tlenp, m, so, flags) { \ if ((th)->th_seq == (tp)->rcv_nxt && \ LIST_EMPTY(&(tp)->t_segq) && \ - (tp)->t_state == TCPS_ESTABLISHED) { \ + (tp)->t_state >= TCPS_ESTABLISHED) { \ if (tcp_delack_enabled) \ callout_reset(tp->tt_delack, tcp_delacktime, \ tcp_timer_delack, tp); \ >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message