From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 23:11:12 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AC7E16A401 for ; Wed, 7 Mar 2007 23:11:12 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id 40D8813C491 for ; Wed, 7 Mar 2007 23:11:12 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id 04AC410BBE57; Wed, 7 Mar 2007 15:11:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=-99.4 required=5.0 tests=AWL,BAYES_50, USER_IN_WHITELIST autolearn=disabled version=3.1.3 Received: from [192.168.1.102] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id 66A0010BBD3F; Wed, 7 Mar 2007 15:11:09 -0800 (PST) Message-ID: <45EF4683.7060508@sk1llz.net> Date: Wed, 07 Mar 2007 15:10:59 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chuck Swiger , freebsd-ipfw@freebsd.org References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net> <45EF3E33.2040507@sk1llz.net> <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> In-Reply-To: <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: IPFW SACK options X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2007 23:11:12 -0000 Chuck Swiger wrote: > On Mar 7, 2007, at 2:35 PM, Justin Robertson wrote: >>> The issue here is that no windows PC is compliant, and continues to >>> try and send SYN SACK packets until giving up entirely on the >>> connection - I've already tried this. I can't tell you why the bsd >>> stack doesn't have an issue with bare SYNs, but does on SYNs with >>> SACK set in the tcpoptions, but it apparently does. >>> >> Example - windows PC trying to connect to POP mailserver, sacks >> blocked (being viewed from firewall) >> >> 14:31:54.632444 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 > 8,nop,nop,sackOK> (DF) (ttl 115, id 12030, len 52) >> 14:31:57.629151 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 > 8,nop,nop,sackOK> (DF) (ttl 115, id 12034, len 52) >> 14:32:03.635511 client.52985 > server.110: S [tcp sum ok] >> 3734795545:3734795545(0) win 8192 (DF) (ttl >> 115, id 12046, len 48) >> >> You get three sack attempted retransmissions, then failure. It's not >> sending selective acks, it's trying to establish that selective acks >> are allowed for the rest of the communication between client/server. > > Which flavor of Windows was the sender? > > I seem to recall that Win2000/XP/2003 was willing to resend the SYN > without enabling the SACK option after a few retries, but it's been a > while since I've done that sort of testing... > >> I just want to strip the sack options from the packet and pass it on. >> The "issue" is that BSD can't cope with a flood of syn/sack permitted >> packets. All IP lags, and on 6.x stops all-together. > > Is the machine you're testing against the destination of this traffic, > or are you wanting to change this on a firewall box which lies between > the sender and destination? > > If the latter, I would agree that you'd need to hack the firewall > code. But if the former, take a look into > /usr/src/sys/netinet/tcp_input.c for the tcp_dooptions() function, and > try to #ifdef out the cases for TCPOPT_SACK_PERMITTED & TCPOPT_SACK? > > ---Chuck > > All latest windows updated XP machines, as well as all new Vista machines have this issue. And this is being done on a firewall box between sender/destination. The firewall machine itself (even in a transparent bridge) lags when passing SYN w/ SACK - hence the need to hack up ipfw to strip TCP options. -- Justin