Date: Wed, 5 Jul 2006 16:56:09 -0400 From: Charles Swiger <cswiger@mac.com> To: Justin T. Gibbs <gibbs@scsiguy.com> Cc: stable@FreeBSD.org Subject: Re: fetch hangs on AMD64 RELENG_6 Message-ID: <F1942343-65E6-489C-A7DC-B3D92900E628@mac.com> In-Reply-To: <C11BD5CD359465AF9DFCE52C@[10.0.0.90]> References: <86C10E7655AA8C2D8C433AAC@[10.0.0.90]> <B2E79C72-F189-4678-AF04-39F3FE3ED12D@mac.com> <C11BD5CD359465AF9DFCE52C@[10.0.0.90]>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F1942343-65E6-489C-A7DC-B3D92900E628>