cvs commit: src/sys/netinet tcp_var.h

Bjoern A. Zeeb bz at
Mon Feb 25 22:11:51 UTC 2008

On Sun, 24 Feb 2008, Mike Silbersack wrote:

> silby       2008-02-24 05:13:20 UTC
>  FreeBSD src repository
>  Modified files:
>    sys/netinet          tcp_var.h
>  Log:
>  Change FreeBSD 7 so that it returns TCP options in
>  the same order that FreeBSD 6 and before did.  Doug
>  White and the other bloodhounds at ISC discovered that
>  while FreeBSD 7's ordering of options was more efficient,
>  it caused some cable modem routers to ignore the
>  SYN-ACKs ordered in this fashion.
>  The placement of sackOK after the timestamp option seems
>  to be the critical difference:

After reading and thinking of this I was about to say that apart from
TCP option kind 0 and 1 do we preserv order by kind ascending.
I couldn't easily remember an RFC talking about this permitting either
one or the other but we had TSOPT (kind 8) before SACK permitted
(kind 4) so that seems to be nonsense.

Still, are you really sure that this is about ordering?
Basically there is another crucial change coming with this commit
as we discovered while rwatson was showing me the commit message
sitting next to him at FOSDEM: no EOL for "7.orig"

>  FreeBSD 6:
>  <mss 1460,nop,wscale 1,nop,nop,timestamp 3512155768 0,sackOK,eol>

option length: 23 (should be + 1 padding after EOL)

>  FreeBSD 7.0:
>  <mss 1460,nop,wscale 3,sackOK,timestamp 1370692577 0>

option length: 20 (thus no padding and no EOL)

>  FreeBSD 7.0 + this change:
>  <mss 1460,nop,wscale 3,nop,nop,timestamp 7371813 0,sackOK,eol>

option length: 23 (should be + 1 padding after EOL)

The questions would be: have you tried simply adding another NOP to
"7.orig" thus forcing an EOL or removing the NOP and putting an EOL
at the end (I know 793 was before the MUST/MUST NOT times so this
might not be strictly correct as it says "This might not coincide
with the end of the TCP header according to the Data Offset field.
[This option] need only be used if the end of the options would not
otherwise coincide with the end of the TCP header".

I would really assume (on principle;) that instead of ordering,
those consumer grade devices, mostly built cheaply, ... are expecting
an End of Option list instead of being picky on the order of the

Is there any chance we could get that tested so we would be more sure
what the actualy cause is and have a reference for the furture?


Bjoern A. Zeeb                                 bzeeb at Zabbadoz dot NeT
Software is harder than hardware  so better get it right the first time.

More information about the cvs-src mailing list