Date: Fri, 9 Feb 2007 12:54:35 +0100 From: Sascha Holzleiter <sascha@root-login.org> To: freebsd-stable@freebsd.org Subject: Re: fetch hangs on AMD64 RELENG_6 Message-ID: <20070209115435.GA11692@serverbitch.de> In-Reply-To: <F1942343-65E6-489C-A7DC-B3D92900E628@mac.com> References: <86C10E7655AA8C2D8C433AAC@[10.0.0.90]> <B2E79C72-F189-4678-AF04-39F3FE3ED12D@mac.com> <C11BD5CD359465AF9DFCE52C@[10.0.0.90]> <F1942343-65E6-489C-A7DC-B3D92900E628@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070209115435.GA11692>