From owner-freebsd-net@FreeBSD.ORG Wed Mar 12 19:01:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 878511065678 for ; Wed, 12 Mar 2008 19:01:00 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41E2C8FC21 for ; Wed, 12 Mar 2008 19:00:59 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so1692498ele.12 for ; Wed, 12 Mar 2008 12:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Tx+Hm3noJymkLtTBTa3ozYGZ6WjZ84WtpT47trVEFSk=; b=W5C5FPw5XsfgirUjq9KbwpQZBXSr1bmgBPuhjhB2JKhmt+QtStaxS4gB55JQRESYyd91C7o6bOvhIOqH/9JakJjlZ27PbHcr/QsktDAMCkfdX7S4awq0KZ+eNnlt1GDsxw8ZFjefBqv/L4masgQj6U3J7n97n3KlGjsWD5pdTwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gDqE55PDr4vPp/2nlfy444DrQZ/bkUMq1wVzLknNFRuY5Ca87y4JEYuigdhfwfOjzymNK+VXNCcEXN6OR5badCDTU3mBhYVR8TGXGsG8vvJNffXzEt0C6ZBQs8vrcU82wRh61r45TZg5oozDuORwGnig8xuSf6EFhu6/MrJLB2g= Received: by 10.114.120.1 with SMTP id s1mr4839541wac.82.1205348457524; Wed, 12 Mar 2008 12:00:57 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Wed, 12 Mar 2008 12:00:57 -0700 (PDT) Message-ID: Date: Wed, 12 Mar 2008 12:00:57 -0700 From: "Kip Macy" To: "Andre Oppermann" In-Reply-To: <47D798E8.3090103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47D798E8.3090103@freebsd.org> Cc: freebsd-net@freebsd.org, "d.s. al coda" Subject: Re: TCP options order changed in FreeBSD 7, incompatible with some routers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 19:01:00 -0000 On Wed, Mar 12, 2008 at 1:48 AM, Andre Oppermann wrote: > Kip Macy wrote: > > Are you running 7.0-RELEASE? What I believe was this issue was a > > showstopper for it, so I'm surprised to hear of it now. > > No, this is a different issue and not really the fault of TCP but > of certain cable modem vendors with broken code in their devices. > FreeBSD is fully compliant to the spec. Sibly committed a workaround > for this issue to -current and I expect the MFC to RELENG_7 and > RELENG_7_0 soon. We know your opinion Andre. Most people don't care whose fault it is, they just want it to work. I didn't realized that Silby's change hadn't made it in to the release. -Kip > > -- > Andre > > > > > -Kip > > > > On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda wrote: > >> Hi, > >> We recently upgraded one of our webservers to FreeBSD 7, and we started > >> receiving complaints from some users not able to connect to that server > >> anymore. On top of that, users were saying that the problem only occurred on > >> Windows (at least, the ones who had more than on OS to try it out). > >> > >> After managing to get a user who had the problem running windump, running > >> tcpdump on the new server, and comparing that to the windump & tcpdump > >> output for a "control" user (me) that could connect, we managed to figure > >> out the following: > >> - For the user with this problem, ping works fine, but all TCP connections > >> to the server fail. > >> - The user, trying to connect, sends out a SYN packet, receives no response, > >> and retries a few times until timing out. > >> - The server sees a bunch of SYN packets and responds with SYN-ACK each > >> time. > >> - The issue only seems to arise if the sender has RFC1323 disabled. > >> > >> So, the SYN-ACK is getting lost somewhere. > >> > >> - For the control user (who can connect via TCP just fine), we set the TCP > >> window size and RFC1323 options the same as the user with the problem. > >> - The control user sees the SYN-ACK packet. > >> - We send a connection attempt to one of our other servers, running FreeBSD > >> 5.5, and one to the server running FreeBSD 7. > >> - There is only one notable difference between the responses: the order of > >> the options. > >> - FreeBSD 5.5 has > >> - FreeBSD 7 has (there is of course an aligning nop > >> after the eol, which tcpdump skips) > >> - These options don't appear in this exact configuration when using RFC1323 > >> options. > >> > >> I get a hunch that the users with the problem have a router that erroneously > >> thinks that these options are invalid, or thinks that the some part of byte > >> sequence (e.g. 0204 05b4 0101 0402) is an attack. > >> > >> Just to try it out, I patched tcp_output.c so that the SACK permitted option > >> was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from > >> ever occuring. Looking through previous versions, I found where the tcp > >> option code had changed, and there used to be a comment about putting SACK > >> permitted last, but I can't tell if it's relevant. > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 > >> > >> The one-line patch to tcp_output.c is attached. > >> > >> Sure enough, it fixed the problem. Afterwards, we collected some information > >> about the routers the users who had the problem were using, and while they > >> didn't all have the same manufacturer, several mentioned that their router > >> had a built-in firewall, which, when they disabled it, allowed them to > >> access the server. > >> > >> Does all of this sound reasonable? And if so, would it be worth submitting > >> this patch? I don't know if this particular change in options order was > >> intentional, or just a side-effect of the new code, but it certainly works > >> around an extremely hard-to-diagnose problem. > >> > >> -coda > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > >