From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 20:40:17 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA61D106566B; Fri, 25 Mar 2011 20:40:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A1B3F8FC0C; Fri, 25 Mar 2011 20:40:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2F9B046B09; Fri, 25 Mar 2011 16:40:17 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B07288A01B; Fri, 25 Mar 2011 16:40:16 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org, Doug Barton Date: Fri, 25 Mar 2011 16:40:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> <201103250825.10674.jhb@freebsd.org> <20110325194109.GB25392@ice.42.org> In-Reply-To: <20110325194109.GB25392@ice.42.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103251640.16147.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 16:40:16 -0400 (EDT) Cc: Subject: Re: The tale of a TCP bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 20:40:17 -0000 On Friday, March 25, 2011 3:41:09 pm Stefan `Sec` Zehl wrote: > Hi, > > On Fri, Mar 25, 2011 at 08:25 -0400, John Baldwin wrote: > > Ah, ok. Can you try this patch first (without the other)? If it doesn't > > work then we can refine the patch above further. > > I tried it completely unpatched and with your new patch. In both cases > that if() statement is not taken. > > Instrumenting this part of the code with printf()s shows that recwin is > 65536 right after your patched if, but reduced to 65535 by the next > statment. > > | if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) > | recwin = (long)TCP_MAXWIN << tp->rcv_scale; > > That's the same effect as in the the affected adv calculation: > > % long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - > % (tp->rcv_adv - tp->rcv_nxt); > > recwin is 65535, but the min limits it to 65535. Reading some more. I'm trying to understand the breakage in your case. You are saying that FreeBSD is the sender, who has data to send, yet is not sending any window probes because it never starts the persist timer when the initial window is zero? Is that correct? And the problem is that the code that uses 'adv' to determine if it sound send a window update to the remote end is falsely succeeding due to the overflow causing tcp_output() to 'goto send' but that it then fails to send any data because it thinks the remote window is full? So one thing I don't quite follow is how you are having rcv_nxt > rcv_adv. I saw this when the other side would send a window probe, and then the receiving side would take the -1 remaining window and explode it into the maximum window size when it ACKd. Are you seeing the other end of the connection send a window probe, but FreeBSD is not setting the persist timer so that it will send its own window probes? -- John Baldwin