Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Feb 2001 01:28:36 +0000
From:      Tony Finch <dot@dotat.at>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/24962: properly delay acks in half-closed TCP connections
Message-ID:  <E14R2MW-0002gK-00@hand.dotat.at>

next in thread | raw e-mail | index | archive | help

>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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14R2MW-0002gK-00>