fetch hangs on AMD64 RELENG_6
cswiger at mac.com
Wed Jul 5 20:56:12 UTC 2006
On Jul 5, 2006, at 4:22 PM, Justin T. Gibbs wrote:
> Hmm. Seems we close the window unexpectedly and the remote side
> 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?
"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
interval when the window is zero. This retransmission is
guarantee that when either TCP has a zero window the re-opening of
window will be reliably reported to the other.
When the receiving TCP has a zero window and a segment arrives it
still send an acknowledgment showing its next expected sequence
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.
More information about the freebsd-stable