Date: Mon, 25 Feb 2008 22:11:41 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Mike Silbersack <silby@FreeBSD.org> Cc: dwhite@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_var.h Message-ID: <20080225213119.P94494@maildrop.int.zabbadoz.net> In-Reply-To: <200802240513.m1O5DKBG093031@repoman.freebsd.org> References: <200802240513.m1O5DKBG093031@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 options. 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? /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080225213119.P94494>