From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 17:29:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30A0637B401; Tue, 5 Aug 2003 17:29:50 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 446C543F75; Tue, 5 Aug 2003 17:29:49 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h760Tj2A058056; Tue, 5 Aug 2003 20:29:45 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h760TjUc058055; Tue, 5 Aug 2003 20:29:45 -0400 (EDT) (envelope-from barney) Date: Tue, 5 Aug 2003 20:29:45 -0400 From: Barney Wolff To: Edwin Groothuis Message-ID: <20030806002945.GA57865@pit.databus.com> References: <20030805133922.GA7713@k7.mavetju> <20030805143100.GA52099@pit.databus.com> <20030805235411.GA558@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030805235411.GA558@k7.mavetju> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.35 cc: freebsd-net@freebsd.org Subject: Re: bpf, ipfw and before-and-after X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Aug 2003 00:29:50 -0000 On Wed, Aug 06, 2003 at 09:54:11AM +1000, Edwin Groothuis wrote: > On Tue, Aug 05, 2003 at 10:31:01AM -0400, Barney Wolff wrote: > > Seems to me that with ipfw logging and tcpdump packet selection this > > is largely a non-issue. We should be wary of adding complexity to > > what's already at the limits of human comprehension. > > Could you explain that first line a little bit more verbose? ipfw can log packets, giving source ip/port, dest ip/port, proto and interface which is at least some of the info that tcpdump would supply. tcpdump can take quite complex selection criteria to determine whether to log a packet. So your complaint that tcpdump logs stuff that ipfw is going to drop can be substantially mitigated. > About the second one, given the fact that I could find out how it > works (more or less) and where to add the statements, makes me think > that despite the complexity of the thing being achieved, the > implementation in the code is pretty neat and structured. The issue is not that the addition would be complex, but that every addition to a system already very complex must be carefully weighed against the claimed benefits. Does the expression "creeping featurism" sound familiar? Every feature of the Win32 API, OS/360 and the US Federal Tax Code was added because somebody thought it was a good idea. "Perfection in design is achieved not when there is nothing left to add, but when there is nothing left to take away." -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.