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