From owner-freebsd-stable@FreeBSD.ORG Fri Feb 9 12:31:38 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FF7016A402 for ; Fri, 9 Feb 2007 12:31:38 +0000 (UTC) (envelope-from aperum=freebsd-stable=freebsd.org=bdvvpieh@serverbitch.de) Received: from serverbitch.de (serverbitch.de [212.227.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 4413513C491 for ; Fri, 9 Feb 2007 12:31:38 +0000 (UTC) (envelope-from aperum=freebsd-stable=freebsd.org=bdvvpieh@serverbitch.de) Received: from aperum by serverbitch.de with local (Exim) (envelope-from ) id 1HFUKp-00033m-U1 for freebsd-stable@freebsd.org; Fri, 09 Feb 2007 12:54:35 +0100 Date: Fri, 9 Feb 2007 12:54:35 +0100 From: Sascha Holzleiter To: freebsd-stable@freebsd.org Message-ID: <20070209115435.GA11692@serverbitch.de> References: <86C10E7655AA8C2D8C433AAC@[10.0.0.90]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: Sascha Holzleiter 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: Fri, 09 Feb 2007 12:31:38 -0000 On Wed, Jul 05, 2006 at 04:56:09PM -0400, Charles Swiger wrote: > 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. Hi, has there been any solution to this problem. I'm seeing this with RELENG_6_2 on an Intel Core2Duo system whilst fetching certain source files for ports, e.g. elinks. Fetch just hangs after the first few kbytes in sbwait state. -- Sascha