From owner-freebsd-current@FreeBSD.ORG Thu Oct 9 07:04:00 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD55D16A4B3 for ; Thu, 9 Oct 2003 07:04:00 -0700 (PDT) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1293143FDD for ; Thu, 9 Oct 2003 07:04:00 -0700 (PDT) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id 1DE856A; Thu, 9 Oct 2003 10:07:04 -0400 (EDT) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Thu, 9 Oct 2003 10:07:03 -0400 Message-ID: <1065708423.752rpf5i638c@www.sweetdreamsracing.biz> Date: Thu, 9 Oct 2003 10:07:03 -0400 From: Kenneth Culver To: Vector References: <008401c38e21$0eb936b0$6afea8c0@VECTOR> <002101c38e2a$fda426f0$8d00a8c0@marcos1> <003001c38e32$87214780$f501a8c0@VECTOR> In-Reply-To: <003001c38e32$87214780$f501a8c0@VECTOR> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: current@freebsd.org Subject: Re: ipnat memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 14:04:01 -0000 Quoting Vector : > Several reasons: > > Having it in the kernel improves performance It also avoids at least 2 context switches per packet... one when the packet goes into natd and one when it goes back to the kernel. > > natd chokes on the latest windoze worms and I have implemented some DoS > prevention/worm protection in ipnat but I'm seeing this memory leak without > my improvements there at all. > > If it's in the kernel, ipnat is kept under control when natd would normally > be sucking the CPU dry and preventing things like remote logins, very > slugish updates, etc... > > and others I don't particularly want to go into at the moment. > > vec > Not to mention the syntax for doing things like stateful firewalling is much more sane, and the fact that you can view the firewall state-table in near real-time using ipfstat -t (top style viewing). Ken