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.


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.


More information about the freebsd-stable mailing list