fetch hangs on AMD64 RELENG_6
Sascha Holzleiter
sascha at root-login.org
Fri Feb 9 12:31:38 UTC 2007
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
More information about the freebsd-stable
mailing list