From owner-freebsd-stable@FreeBSD.ORG Wed Jul 5 20:56:12 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D0CD16A4DA for ; Wed, 5 Jul 2006 20:56:12 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA3843D49 for ; Wed, 5 Jul 2006 20:56:11 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 2ED9C5DB3; Wed, 5 Jul 2006 16:56:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq-IUT7k+Gdr; Wed, 5 Jul 2006 16:56:10 -0400 (EDT) Received: from [199.103.21.238] (pan.codefab.com [199.103.21.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 1D7465C31; Wed, 5 Jul 2006 16:56:10 -0400 (EDT) In-Reply-To: References: <86C10E7655AA8C2D8C433AAC@[10.0.0.90]> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 5 Jul 2006 16:56:09 -0400 To: Justin T. Gibbs X-Mailer: Apple Mail (2.752.2) Cc: stable@FreeBSD.org Subject: Re: fetch hangs on AMD64 RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 20:56:12 -0000 On Jul 5, 2006, at 4:22 PM, Justin T. Gibbs wrote: > Hmm. Seems we close the window unexpectedly and the remote side > doesn't > retransmit when we open it. Yes, interesting that. :-) Normally the stack only sets the window size to 0 in the event of severe congestion, it's used to tell the other side to stop sending traffic for an interval, although the other side should retry with zero-data-length ACK-only packets after a delay, or once your side sends a packet opening the window. > FreeBSD's acks stop once the window is fully > open... aren't the acks supposed to retried longer? If not, shouldn't > fetch eventually see a socket close event instead of hanging forever? RFC-793 says: "The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero. The sending TCP must regularly retransmit to the receiving TCP even when the window is zero. Two minutes is recommended for the retransmission interval when the window is zero. This retransmission is essential to guarantee that when either TCP has a zero window the re-opening of the window will be reliably reported to the other. When the receiving TCP has a zero window and a segment arrives it must still send an acknowledgment showing its next expected sequence number and current window (zero)." The fact that you aren't seeing any ACK's back from this remote server suggests that perhaps a stateful firewall is involved which is getting confused and/or dropping the state entry once it sees the zero-window-size packet from your machine. There may be something wrong on the FreeBSD side as well, of course-- the fact that it grows the window by sending nearly twenty or more ACK packets in the span of about one millisecond without waiting for any ACKs from the other side is pretty wacky in it's own right. -- -Chuck