Dropping TCP options from retransmitted SYNs considered harmful

[Christian Meutes]

I find the "hack" more than just strange. Because of other OSes bugs FreeBSD breaks it's own stack. Don't want to know how many connections suffered from this.

(Sorry for top-posting)
--
   Christian

On 14.10.2012, at 00:19, Jason Wolfe <nitroboost at gmail.com> wrote:

> On Fri, Oct 12, 2012 at 9:13 AM, John Baldwin <jhb at freebsd.org> wrote:
>> Back in 2001 FreeBSD added a hack to strip TCP options from retransmitted SYNs
>> starting with the 3rd SYN in this block in tcp_timer.c:
>> 
>>        /*
>>         * Disable rfc1323 if we haven't got any response to
>>         * our third SYN to work-around some broken terminal servers
>>         * (most of which have hopefully been retired) that have bad VJ
>>         * header compression code which trashes TCP segments containing
>>         * unknown-to-them TCP options.
>>         */
>>        if ((tp->t_state == TCPS_SYN_SENT) && (tp->t_rxtshift == 3))
>>                tp->t_flags &= ~(TF_REQ_SCALE|TF_REQ_TSTMP);
>> 
>> There is even a PR for the original bug report: kern/1689
>> 
>> [..snip..]
>> 
>> The original motivation of this change is to work around broken terminal
>> servers that were old when this change was added in 2001.  Over 10 years later
>> I think we should at least have an option to turn this work-around off, and
>> possibly disable it by default.
>> 
>> Thoughts?
>> 
>> --
>> John Baldwin
> 
> Not that it alone merits keeping the code in, but there are some cases
> where this comes in handy.  I ran into an issue with heavily
> trafficked Linux <-> FBSD boxes here -
> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031881.html.
> 
> Linux would deny the connection because in FBSD ithe n and outbound
> timestamp randomization isn't sync'd to the same base, so when FBSD
> would hit a 2MSL connection Linux would simply ignore the SYN.  After
> the 3rd SYN FBSD would drop support, and Linux would finally honor the
> request.  I doubt this is too widespread, but it would probably break
> things for a few folks.
> 
> Jason
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"