From dillon@flash.noc.best.net  Mon Oct  6 16:25:03 1997
Received: from flash.noc.best.net (flash.noc.best.net [205.149.163.43])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA07751
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 6 Oct 1997 16:24:57 -0700 (PDT)
          (envelope-from dillon@flash.noc.best.net)
Received: (from dillon@localhost)
	by flash.noc.best.net (8.8.5/8.8.5) id QAA00389;
	Mon, 6 Oct 1997 16:26:28 -0700 (PDT)
Message-Id: <199710062326.QAA00389@flash.noc.best.net>
Date: Mon, 6 Oct 1997 16:26:28 -0700 (PDT)
From: Matthew Dillon <dillon@flash.noc.best.net>
Reply-To: dillon@flash.noc.best.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: TCP stack bug
X-Send-Pr-Version: 3.2

>Number:         4712
>Category:       kern
>Synopsis:       After setting larger tcp buffer sizes with sysctl, tcp protocol connection lockup can occur
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct  6 16:30:00 PDT 1997
>Closed-Date:    Tue Oct 7 14:17:13 PDT 1997
>Last-Modified:  Tue Oct  7 14:19:31 PDT 1997
>Originator:     Matthew Dillon
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
Best Internet Communications
>Environment:

	

>Description:

    Included below are two tcpdump's.  The first tcpdump is a 
    'telnet www.erols.com 80' and 'GET /' prior to any sysctl's.  The second 
    tcpdump is a 'telnet www.erols.com 80' and 'GET /' after the specified
    sysctl's.  Note that the lockup involves a delay that erols happened to be
    generating between the SYN and SYN-ACK.

    I have been able to reproduce the same bug with other WWW sites as well as
    with other local FreeBSD machines.  With other FreeBSD machines, rather
    then locking up, a long delay between the first block of data and
    subsequent blocks of data occurs where the machine making the request
    waits for a prove from the www server.  The remote www server under FreeBSD
    sends a window probe with at least 1 byte, which seems to unstick the
    connection.  Remote NON-FreeBSD boxes often send window probes with 0
    bytes, which does not unstick the connection.

    See below for additional comments.

16:10:46.196059 205.149.163.43.1031 > 205.252.116.184.80: S 84382581:84382581(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]
16:10:46.342111 205.252.116.184.80 > 205.149.163.43.1031: S 2082101445:2082101445(0) ack 84382582 win 31744 <mss 1460>
16:10:46.342225 205.149.163.43.1031 > 205.252.116.184.80: . ack 1 win 17520 (DF) [tos 0x10]
16:10:48.042558 205.149.163.43.1031 > 205.252.116.184.80: P 1:8(7) ack 1 win 17520 (DF) [tos 0x10]
16:10:48.204531 205.252.116.184.80 > 205.149.163.43.1031: . 1:1461(1460) ack 8 win 31744 (DF) [tos 0x10]
16:10:48.205971 205.252.116.184.80 > 205.149.163.43.1031: . 1461:2921(1460) ack 8 win 31744 (DF) [tos 0x10]
16:10:48.207793 205.149.163.43.1031 > 205.252.116.184.80: . ack 2921 win 17520 (DF) [tos 0x10]
16:10:48.312987 205.252.116.184.80 > 205.149.163.43.1031: . 4381:5841(1460) ack 8 win 31744 [tos 0x10]
16:10:48.313094 205.149.163.43.1031 > 205.252.116.184.80: . ack 2921 win 17520 (DF) [tos 0x10]
16:10:48.314425 205.252.116.184.80 > 205.149.163.43.1031: . 5841:7301(1460) ack 8 win 31744 [tos 0x10]
16:10:48.314505 205.149.163.43.1031 > 205.252.116.184.80: . ack 2921 win 17520 (DF) [tos 0x10]
16:10:48.324025 205.252.116.184.80 > 205.149.163.43.1031: . 2921:4381(1460) ack 8 win 31744 [tos 0x10]
	...  continues to completion

sysctl -w net.inet.tcp.sendspace=65536
sysctl -w net.inet.tcp.recvspace=65536
sysctl -w net.inet.tcp.keepidle=3600
sysctl -w net.inet.tcp.always_keepalive=1
route -n change default -sendpipe 65536 -recvpipe 65536

(NOTE: make sure route to telnet destination has the new sendpipe/recvpipe 
values correct.  FreeBSD sometimes doesn't pick up the change)

    Note that the screwup appears to occur when www.erols.com delays sending 
    it's ack.  This causes the FREEBSD box to send an initial small WINDOW 
    (164 bytes!!) in packet #3.  The remote box sends the 164 bytes, and the
    freebsd box then gets locked up and always replies with a 0 window, even
    though the 164 bytes were read by telnet and displayed in the window.

16:14:58.112451 205.149.163.43.1043 > 205.252.116.217.80: S 133560210:133560210(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]
16:14:58.240605 205.252.116.217.80 > 205.149.163.43.1043: S 704725219:704725219(0) ack 133560211 win 31744 <mss 1460>
16:14:58.240714 205.149.163.43.1043 > 205.252.116.217.80: . ack 1 win 164 (DF) [tos 0x10]
16:14:59.241901 205.149.163.43.1043 > 205.252.116.217.80: P 1:8(7) ack 1 win 164 (DF) [tos 0x10]
16:15:00.470076 205.149.163.43.1043 > 205.252.116.217.80: P 1:8(7) ack 1 win 164 (DF) [tos 0x10]
16:15:02.356504 205.252.116.217.80 > 205.149.163.43.1043: . 1:165(164) ack 8 win 31744 (DF) [tos 0x10]
16:15:02.370079 205.149.163.43.1043 > 205.252.116.217.80: . ack 165 win 0 (DF) [tos 0x10]
16:15:08.498257 205.252.116.217.80 > 205.149.163.43.1043: . ack 8 win 31744 [tos 0x10]
16:15:08.498341 205.149.163.43.1043 > 205.252.116.217.80: . ack 165 win 0 (DF) [tos 0x10]
16:15:20.625433 205.252.116.217.80 > 205.149.163.43.1043: . ack 8 win 31744 [tos 0x10]
16:15:20.625544 205.149.163.43.1043 > 205.252.116.217.80: . ack 165 win 0 (DF) [tos 0x10]
  	.... retries forever, connection is hung  ...


>How-To-Repeat:

	

>Fix:
	
	I believe the bug is in netinet/tcp_output.c somewhere, possibly
	where it zero's the window when checking for silly-window syndrome:

    if (win < (long)(so->so_rcv.sb_hiwat / 4) && win < (long)tp->t_maxseg)
	    win = 0;

	I have NOT attempted to hack the code or anything, so I do not
	know if this is where the bug is.  It is just a guess.

>Release-Note:
>Audit-Trail:

From: Bill Fenner <fenner@parc.xerox.com>
To: dillon@flash.noc.best.net
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/4712: TCP stack bug 
Date: Mon, 6 Oct 1997 17:59:04 PDT

 Although the tcpdump was truncated (use "-s 200" to make sure you've
 captured all the headers), it seems most likely that this is because
 our offer of window scaling gets refused.  If you use *pipe=65535,
 instead of 65536, what happens?
 
   Bill

From: Matt Dillon <dillon@best.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: kern/4712
Date: Mon, 6 Oct 1997 19:48:59 -0700 (PDT)

     I also reproduced the bug with a smaller window size, which I include
     at the very end.   See notes in section 3 below.
 
     Section I:	prior to Bill Fenner's quick patch to me
     Section II:	after Bill Fenner's quick patch to me (bug no longer exists)
     Section III: additional test done prior to Bill Fenner's patch.
 
     The test consisted of a 'telnet -d www.erols.com 80' and a 'GET /'.
 
 					-Matt
 
 :Actually, although I didn't reproduce the hang, I did reproduce the
 :strangely-sized window locally and think I have a fix.  Try this and
 :see if it fixed your hang too.
 :
 :  Bill
 :
 :--- tcp_output.c.orig	Mon Oct  6 18:46:03 1997
 :...
 
     Matthew Dillon   Engineering, BEST Internet Communications, Inc.
 		    <dillon@best.net>
     [always include a portion of the original email in any response!]
 
 
 	BEFORE FIX
 
 
 19:36:03.170980 205.149.163.43.1025 > 205.252.116.242.80: S 10843074:10843074(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 107 0,nop,nop,ccnew 3> (DF) [tos 0x10]
 19:36:03.277683 205.252.116.242.80 > 205.149.163.43.1025: S 3478916915:3478916915(0) ack 10843075 win 31744 <mss 1460>
 19:36:03.282294 205.149.163.43.1025 > 205.252.116.242.80: . ack 1 win 164 (DF) [tos 0x10]
 19:36:05.705198 205.149.163.43.1025 > 205.252.116.242.80: P 1:8(7) ack 1 win 164 (DF) [tos 0x10]
 19:36:05.847542 205.252.116.242.80 > 205.149.163.43.1025: . 1:165(164) ack 8 win 31744 (DF) [tos 0x10]
 19:36:05.982352 205.149.163.43.1025 > 205.252.116.242.80: . ack 165 win 0 (DF) [tos 0x10]
 19:36:07.302774 205.252.116.242.80 > 205.149.163.43.1025: . ack 8 win 31744 [tos 0x10]
 19:36:07.307393 205.149.163.43.1025 > 205.252.116.242.80: . ack 165 win 0 (DF) [tos 0x10]
 19:36:09.845744 205.252.116.242.80 > 205.149.163.43.1025: . ack 8 win 31744 [tos 0x10]
 19:36:09.850396 205.149.163.43.1025 > 205.252.116.242.80: . ack 165 win 0 (DF) [tos 0x10]
 19:36:14.809946 205.252.116.242.80 > 205.149.163.43.1025: . ack 8 win 31744 [tos 0x10]
 19:36:14.814576 205.149.163.43.1025 > 205.252.116.242.80: . ack 165 win 0 (DF) [tos 0x10]
 19:36:17.329149 205.149.163.43.1025 > 205.252.116.242.80: P 8:10(2) ack 165 win 0 (DF) [tos 0x10]
 19:36:17.448915 205.252.116.242.80 > 205.149.163.43.1025: R 3478917080:3478917080(0) win 0
 MARK
 Oct  6 19:36:03 flash /kernel: 0xf201d400 SYN_SENT:output [a573c2..a573de)@0, urp=0<SYN> -> SYN_SENT
 Oct  6 19:36:03 flash /kernel: 	rcv_(nxt,wnd,up) (0,0,0) snd_(una,nxt,max) (a573c2,a573c3,a573c3)
 Oct  6 19:36:03 flash /kernel: 	snd_(wl1,wl2,wnd) (0,0,0)
 Oct  6 19:36:03 flash /kernel: 0xf201d400 CLOSED:user CONNECT -> SYN_SENT
 Oct  6 19:36:03 flash /kernel: 	rcv_(nxt,wnd,up) (0,0,0) snd_(una,nxt,max) (a573c2,a573c3,a573c3)
 Oct  6 19:36:03 flash /kernel: 	snd_(wl1,wl2,wnd) (0,0,0)
 Oct  6 19:36:03 flash /kernel: 0xf201d400 SYN_SENT:input cf5c0f33@a573c3, urp=0<SYN,ACK> -> ESTABLISHED
 Oct  6 19:36:03 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0f34,100a4,cf5c0f34) snd_(una,nxt,max) (a573c3,a573c3,a573c3)
 Oct  6 19:36:03 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573c3,7c00)
 Oct  6 19:36:03 flash /kernel: 0xf201d400 ESTABLISHED:output a573c3@cf5c0f34, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:03 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0f34,100a4,cf5c0f34) snd_(una,nxt,max) (a573c3,a573c3,a573c3)
 Oct  6 19:36:03 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573c3,7c00)
 Oct  6 19:36:05 flash /kernel: 0xf201d400 ESTABLISHED:output [a573c3..a573ca)@cf5c0f34, urp=0<ACK,PUSH> -> ESTABLISHED
 Oct  6 19:36:05 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0f34,100a4,cf5c0f34) snd_(una,nxt,max) (a573c3,a573ca,a573ca)
 Oct  6 19:36:05 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573c3,7c00)
 Oct  6 19:36:05 flash /kernel: 0xf201d400 ESTABLISHED:user SEND -> ESTABLISHED
 Oct  6 19:36:05 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0f34,100a4,cf5c0f34) snd_(una,nxt,max) (a573c3,a573ca,a573ca)
 Oct  6 19:36:05 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573c3,7c00)
 Oct  6 19:36:05 flash /kernel: 0xf201d400 ESTABLISHED:input [cf5c0f34..cf5c0fd8)@a573ca, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:05 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0f34) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:05 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573ca,7c00)
 Oct  6 19:36:05 flash /kernel: 0xf201d400 ESTABLISHED:user RCVD -> ESTABLISHED
 Oct  6 19:36:05 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0f34) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:05 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573ca,7c00)
 Oct  6 19:36:05 flash /kernel: 0xf201d400 ESTABLISHED:output a573ca@cf5c0fd8, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:05 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0f34) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:05 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0f34,a573ca,7c00)
 Oct  6 19:36:07 flash /kernel: 0xf201d400 ESTABLISHED:input cf5c0fd7@a573ca, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:07 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:07 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:07 flash /kernel: 0xf201d400 ESTABLISHED:output a573ca@cf5c0fd8, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:07 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:07 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:09 flash /kernel: 0xf201d400 ESTABLISHED:input cf5c0fd7@a573ca, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:09 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:09 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:09 flash /kernel: 0xf201d400 ESTABLISHED:output a573ca@cf5c0fd8, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:09 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:09 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:14 flash /kernel: 0xf201d400 ESTABLISHED:input cf5c0fd7@a573ca, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:14 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:14 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:14 flash /kernel: 0xf201d400 ESTABLISHED:output a573ca@cf5c0fd8, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:36:14 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573ca,a573ca)
 Oct  6 19:36:14 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:17 flash /kernel: 0xf201d400 ESTABLISHED:output [a573ca..a573cc)@cf5c0fd8, urp=0<ACK,PUSH> -> ESTABLISHED
 
 
 	(somewhere around here I hit a key that generated a sigpipe since the
 	remote WWW server had shutdown it's input channel.
 
 Oct  6 19:36:17 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573cc,a573cc)
 Oct  6 19:36:17 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:17 flash /kernel: 0xf201d400 ESTABLISHED:user SEND -> ESTABLISHED
 Oct  6 19:36:17 flash /kernel: 	rcv_(nxt,wnd,up) (cf5c0fd8,100a4,cf5c0fd8) snd_(una,nxt,max) (a573ca,a573cc,a573cc)
 Oct  6 19:36:17 flash /kernel: 	snd_(wl1,wl2,wnd) (cf5c0fd7,a573ca,7c00)
 Oct  6 19:36:17 flash /kernel: ???????? drop cf5c0fd8@0, urp=0<RST>
 
 
 
 
 ------------------------------------------------------------------------------
 
 	AFTER FIX
 
 
 19:39:54.694887 205.149.163.43.1027 > 205.252.116.242.80: S 13189984:13189984(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 135 0,nop,nop,ccnew 5> (DF) [tos 0x10]
 19:39:54.846613 205.252.116.242.80 > 205.149.163.43.1027: S 447599909:447599909(0) ack 13189985 win 31744 <mss 1460>
 19:39:54.851251 205.149.163.43.1027 > 205.252.116.242.80: . ack 1 win 65535 (DF) [tos 0x10]
 19:39:56.047669 205.149.163.43.1027 > 205.252.116.242.80: P 1:8(7) ack 1 win 65535 (DF) [tos 0x10]
 19:39:56.177840 205.252.116.242.80 > 205.149.163.43.1027: . ack 8 win 31744 (DF) [tos 0x10]
 19:39:56.888723 205.252.116.242.80 > 205.149.163.43.1027: . 1:1461(1460) ack 8 win 31744 (DF) [tos 0x10]
 19:39:56.906924 205.252.116.242.80 > 205.149.163.43.1027: . 1461:2921(1460) ack 8 win 31744 (DF) [tos 0x10]
 19:39:56.972682 205.149.163.43.1027 > 205.252.116.242.80: . ack 2921 win 65535 (DF) [tos 0x10]
 19:39:57.089630 205.252.116.242.80 > 205.149.163.43.1027: . 2921:4381(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.091183 205.252.116.242.80 > 205.149.163.43.1027: . 4381:5841(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.111032 205.149.163.43.1027 > 205.252.116.242.80: . ack 5841 win 65535 (DF) [tos 0x10]
 19:39:57.240131 205.252.116.242.80 > 205.149.163.43.1027: P 7301:8193(892) ack 8 win 31744 (DF) [tos 0x10]
 19:39:57.244486 205.252.116.242.80 > 205.149.163.43.1027: . 8193:9653(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.245430 205.149.163.43.1027 > 205.252.116.242.80: . ack 5841 win 65535 (DF) [tos 0x10]
 19:39:57.250404 205.149.163.43.1027 > 205.252.116.242.80: . ack 5841 win 65535 (DF) [tos 0x10]
 19:39:57.259879 205.252.116.242.80 > 205.149.163.43.1027: . 9653:11113(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.265192 205.149.163.43.1027 > 205.252.116.242.80: . ack 5841 win 65535 (DF) [tos 0x10]
 19:39:57.384232 205.252.116.242.80 > 205.149.163.43.1027: . 5841:7301(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.385627 205.252.116.242.80 > 205.149.163.43.1027: . 11113:12573(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.389558 205.149.163.43.1027 > 205.252.116.242.80: . ack 11113 win 60428 (DF) [tos 0x10]
 19:39:57.399365 205.149.163.43.1027 > 205.252.116.242.80: . ack 12573 win 62040 (DF) [tos 0x10]
 19:39:57.412281 205.252.116.242.80 > 205.149.163.43.1027: . 12573:14033(1460) ack 8 win 31744 [tos 0x10]
 19:39:57.414337 205.149.163.43.1027 > 205.252.116.242.80: . ack 12573 win 65112 (DF) [tos 0x10]
 19:39:57.527026 205.252.116.242.80 > 205.149.163.43.1027: P 14033:14522(489) ack 8 win 31744 (DF) [tos 0x10]
 19:39:57.573919 205.149.163.43.1027 > 205.252.116.242.80: . ack 14522 win 65535 (DF) [tos 0x10]
 19:39:58.296191 205.252.116.242.80 > 205.149.163.43.1027: F 14522:14522(0) ack 8 win 31744 [tos 0x10]
 19:39:58.300873 205.149.163.43.1027 > 205.252.116.242.80: . ack 14523 win 65535 (DF) [tos 0x10]
 19:39:58.303496 205.149.163.43.1027 > 205.252.116.242.80: F 8:8(0) ack 14523 win 65535 (DF) [tos 0x10]
 19:39:58.413627 205.252.116.242.80 > 205.149.163.43.1027: . ack 9 win 31744 (DF) [tos 0x10]
 
 
 Oct  6 19:39:57 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0bf6,100a4,1aadebf6) snd_(una,nxt,max) (c94368,c94368,c94368)
 Oct  6 19:39:57 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aadfada,c94368,7c00)
 Oct  6 19:39:57 flash /kernel.tst: 0xf2021c00 ESTABLISHED:user RCVD -> ESTABLISHED
 Oct  6 19:39:57 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0ddf,100a4,1aadebf6) snd_(una,nxt,max) (c94368,c94368,c94368)
 Oct  6 19:39:57 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aadfada,c94368,7c00)
 Oct  6 19:39:57 flash /kernel.tst: 0xf2021c00 ESTABLISHED:output c94368@1aae0ddf, urp=0<ACK> -> ESTABLISHED
 Oct  6 19:39:57 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0ddf,100a4,1aadebf6) snd_(una,nxt,max) (c94368,c94368,c94368)
 Oct  6 19:39:57 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aadfada,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: 0xf2021c00 ESTABLISHED:input 1aae0ddf@c94368, urp=0<ACK,FIN> -> CLOSE_WAIT
 Oct  6 19:39:58 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0de0,100a4,1aae0ddf) snd_(una,nxt,max) (c94368,c94368,c94368)
 Oct  6 19:39:58 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aae0ddf,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: 0xf2021c00 CLOSE_WAIT:output c94368@1aae0de0, urp=0<ACK> -> CLOSE_WAIT
 Oct  6 19:39:58 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0de0,100a4,1aae0ddf) snd_(una,nxt,max) (c94368,c94368,c94368)
 Oct  6 19:39:58 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aae0ddf,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: 0xf2021c00 LAST_ACK:output c94368@1aae0de0, urp=0<ACK,FIN> -> LAST_ACK
 Oct  6 19:39:58 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0de0,100a4,1aae0ddf) snd_(una,nxt,max) (c94368,c94369,c94369)
 Oct  6 19:39:58 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aae0ddf,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: 0xf2021c00 CLOSE_WAIT:user DISCONNECT -> LAST_ACK
 Oct  6 19:39:58 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0de0,100a4,1aae0ddf) snd_(una,nxt,max) (c94368,c94369,c94369)
 Oct  6 19:39:58 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aae0ddf,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: 0xf2021c00 LAST_ACK:user DETACH -> LAST_ACK
 Oct  6 19:39:58 flash /kernel.tst: 	rcv_(nxt,wnd,up) (1aae0de0,100a4,1aae0ddf) snd_(una,nxt,max) (c94368,c94369,c94369)
 Oct  6 19:39:58 flash /kernel.tst: 	snd_(wl1,wl2,wnd) (1aae0ddf,c94368,7c00)
 Oct  6 19:39:58 flash /kernel.tst: ???????? drop 1aae0de0@c94369, urp=0<ACK>
 
 ------------------------------------------------------------------------------
 
     Reproduction of bug with initial window size of 16384.  However, note that
     the window size was original set to 65536.  I then did 'route change'
     and sysctl's to set it back to 16384.
 
     This is WITHOUT the patch.  I don't have a tcpdebug available for this.
     
     Question:  Does that bug fix solve this situation too ?  I believe it
     does.
 
 
 19:15:59.200994 205.149.163.43.1031 > 205.252.116.184.80: S 63543536:63543536(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 663 0,nop,nop,ccnew 9> (DF) [tos 0x10]
 19:15:59.333205 205.252.116.184.80 > 205.149.163.43.1031: S 311276215:311276215(0) ack 63543537 win 31744 <mss 1460>
 19:15:59.333325 205.149.163.43.1031 > 205.252.116.184.80: . ack 311276216 win 164 (DF) [tos 0x10]
 19:16:00.107882 205.149.163.43.1031 > 205.252.116.184.80: P 63543537:63543544(7) ack 311276216 win 164 (DF) [tos 0x10]
 19:16:00.250022 205.252.116.184.80 > 205.149.163.43.1031: . ack 63543544 win 31744 (DF) [tos 0x10]
 19:16:00.250338 205.252.116.184.80 > 205.149.163.43.1031: . 311276216:311276380(164) ack 63543544 win 31744 (DF) [tos 0x10]
 19:16:00.370054 205.149.163.43.1031 > 205.252.116.184.80: . ack 311276380 win 0 (DF) [tos 0x10]
 19:16:01.508746 205.252.116.184.80 > 205.149.163.43.1031: . ack 63543544 win 31744 [tos 0x10]
 19:16:01.508837 205.149.163.43.1031 > 205.252.116.184.80: . ack 311276380 win 0 (DF) [tos 0x10]
 19:16:03.707130 205.252.116.184.80 > 205.149.163.43.1031: . ack 63543544 win 31744 [tos 0x10]
 19:16:03.707211 205.149.163.43.1031 > 205.252.116.184.80: . ack 311276380 win 0 (DF) [tos 0x10]
 19:16:07.965513 205.252.116.184.80 > 205.149.163.43.1031: . ack 63543544 win 31744 [tos 0x10]
 19:16:07.965597 205.149.163.43.1031 > 205.252.116.184.80: . ack 311276380 win 0 (DF) [tos 0x10]
 19:16:09.718441 205.149.163.43.1031 > 205.252.116.184.80: P 63543544:63543549(5) ack 311276380 win 0 (DF) [tos 0x10]
 19:16:09.831310 205.252.116.184.80 > 205.149.163.43.1031: R 311276380:311276380(0) win 0
 
State-Changed-From-To: open->closed 
State-Changed-By: fenner 
State-Changed-When: Tue Oct 7 14:17:13 PDT 1997 
State-Changed-Why:  
Fixed in tcp_output.c rev 1.27 ; if large buffers are available 
but window scaling is not negotiated a value larger than TCP_MAXWIN 
could be inserted into the TCP header, causing truncation. 
>Unformatted:
