From owner-cvs-src@FreeBSD.ORG Mon Feb 25 22:11:51 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C01F16A400; Mon, 25 Feb 2008 22:11:51 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3571613C455; Mon, 25 Feb 2008 22:11:51 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D2DEA41C747; Mon, 25 Feb 2008 23:11:49 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id rpByDJ6LIPUj; Mon, 25 Feb 2008 23:11:48 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E662341C759; Mon, 25 Feb 2008 23:11:48 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5399D444885; Mon, 25 Feb 2008 22:11:41 +0000 (UTC) Date: Mon, 25 Feb 2008 22:11:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Silbersack In-Reply-To: <200802240513.m1O5DKBG093031@repoman.freebsd.org> Message-ID: <20080225213119.P94494@maildrop.int.zabbadoz.net> References: <200802240513.m1O5DKBG093031@repoman.freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dwhite@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Robert Watson , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 22:11:51 -0000 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: > option length: 23 (should be + 1 padding after EOL) > FreeBSD 7.0: > option length: 20 (thus no padding and no EOL) > FreeBSD 7.0 + this change: > 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.