Date: Sat, 13 Oct 2012 00:24:32 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: George Neville-Neil <gnn@neville-neil.com> Cc: John Baldwin <jhb@FreeBSD.org>, net@FreeBSD.org Subject: Re: Dropping TCP options from retransmitted SYNs considered harmful Message-ID: <20121012202432.GZ89655@FreeBSD.org> In-Reply-To: <3DBAA027-B5D9-44AA-A00D-0496985D4FEA@neville-neil.com> References: <201210121213.11152.jhb@freebsd.org> <3DBAA027-B5D9-44AA-A00D-0496985D4FEA@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 12, 2012 at 02:15:04PM -0400, George Neville-Neil wrote:
G> > Back in 2001 FreeBSD added a hack to strip TCP options from retransmitted SYNs
G> > starting with the 3rd SYN in this block in tcp_timer.c:
G> >
G> > /*
G> > * Disable rfc1323 if we haven't got any response to
G> > * our third SYN to work-around some broken terminal servers
G> > * (most of which have hopefully been retired) that have bad VJ
G> > * header compression code which trashes TCP segments containing
G> > * unknown-to-them TCP options.
G> > */
G> > if ((tp->t_state == TCPS_SYN_SENT) && (tp->t_rxtshift == 3))
G> > tp->t_flags &= ~(TF_REQ_SCALE|TF_REQ_TSTMP);
G> >
G> > There is even a PR for the original bug report: kern/1689
G> >
G> > However, there is an unintended consequence of this change that can be
G> > disastrous. Specifically, suppose you have a FreeBSD client connecting to a
G> > server, and that the SYNs are arriving at the server successfully, but the
G> > first few return SYN/ACKs are dropped. Eventually a SYN/ACK makes it through
G> > and the connection is established.
G> >
G> > The server (based on the first SYN it saw) believes it has negotiated window
G> > scaling with the client. The client, however, has broken what it promised in
G> > that first SYN and believes it is not using any window scaling at all. This
G> > causes two forms of breakage:
G> >
G> > 1) When the server advertises a scaled window (e.g. '8' for a 64k window
G> > scaled at 13), the client thinks it is an unscaled window ('8') and
G> > sends data to the server very slowly.
G> >
G> > 2) When the client advertises an unscaled window (e.g. '65535' for a 64k
G> > window), the server thinks it has a huge window (65535 << 13 == 511MB)
G> > to send into.
G> >
G> > I'm not sure that 2) is a problem per se, but I have definitely seen instances
G> > of 1) (and examined the 'struct tcpcb' in kgdb on both the server and client
G> > end of the connections to verify they disagreed on the scaling).
G> >
G> > The original motivation of this change is to work around broken terminal
G> > servers that were old when this change was added in 2001. Over 10 years later
G> > I think we should at least have an option to turn this work-around off, and
G> > possibly disable it by default.
G> >
G> > Thoughts?
G> >
G>
G> I'm all for taking that code out.
+1
--
Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121012202432.GZ89655>