From owner-freebsd-net@FreeBSD.ORG Wed Mar 12 08:48:38 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 B1FD41065672 for ; Wed, 12 Mar 2008 08:48:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 10FBF8FC33 for ; Wed, 12 Mar 2008 08:48:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 12583 invoked from network); 12 Mar 2008 08:00:56 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Mar 2008 08:00:56 -0000 Message-ID: <47D798E8.3090103@freebsd.org> Date: Wed, 12 Mar 2008 09:48:40 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Kip Macy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 08:48:38 -0000 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. -- 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" > >