From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 7 23:00:40 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 BD18D16A400 for ; Wed, 7 Mar 2007 23:00:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id A378B13C48E for ; Wed, 7 Mar 2007 23:00:40 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l27N0eic021808; Wed, 7 Mar 2007 15:00:40 -0800 (PST) Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 83F9930076; Wed, 7 Mar 2007 15:00:40 -0800 (PST) X-AuditID: 11807125-a1479bb0000007df-e7-45ef4418e7e1 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay7.apple.com (Apple SCV relay) with ESMTP id 719C430012; Wed, 7 Mar 2007 15:00:40 -0800 (PST) In-Reply-To: <45EF3E33.2040507@sk1llz.net> References: <000301c760fa$df57eb40$9e07c1c0$@net> <45EF32E2.8000807@sk1llz.net> <4C17F7D1-6763-41EC-970E-E88FF3782D22@mac.com> <45EF3B1E.1080706@sk1llz.net> <45EF3E33.2040507@sk1llz.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35795E3A-98DC-4354-A77E-BFB95E33913A@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 7 Mar 2007 15:00:39 -0800 To: Justin Robertson X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-ipfw@freebsd.org 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:00:40 -0000 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