From owner-freebsd-net@FreeBSD.ORG Tue Aug 5 11:17:14 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 0041137B401; Tue, 5 Aug 2003 11:17:13 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DACF43FA3; Tue, 5 Aug 2003 11:17:12 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h75IH7Xc012178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 5 Aug 2003 11:17:07 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h75IH7jb006622; Tue, 5 Aug 2003 11:17:07 -0700 (PDT) (envelope-from jdp) Date: Tue, 5 Aug 2003 11:17:07 -0700 (PDT) Message-Id: <200308051817.h75IH7jb006622@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: <20030805133922.GA7713@k7.mavetju> References: <20030805133922.GA7713@k7.mavetju> Organization: Polstra & Co., Seattle, WA X-Bogosity: No, tests=bogofilter, spamicity=0.499856, version=0.11.2 cc: edwin@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: Tue, 05 Aug 2003 18:17:14 -0000 In article <20030805133922.GA7713@k7.mavetju>, Edwin Groothuis wrote: > This afternoon I ran into the ever lasting of "bpf runs before ipfw" > problem again: when you run tcpdump and you get all the rubbish > coming from the public internet into an interface, while all I > wanted to see was how much traffic was actually going past the ipfw > rules. Tcpdump has always shown traffic _at_ the network interface. That's why it has the "-i" option. I would not like to see that behavior changed. > Looking through the code of sys/net/if_ethersubr.c, I thought this > could be solved pretty easy: The second thing ether_input() does > is checking for ifp->ip_bpf and calling bpf_mtap(). If that call > could be repeated in ether_demux() after ether_ipfw_chk() is checked, > and bpf_mtap() did have a way to determine wether it should print > the first or the second one[*], this would solve the problem for > the incoming packets. > > For outgoing packets, the call to bpf_mtap() is done in the driver > of the cards, but the check for ipfw is done in ether_output_frame(), > so it could be done in that routine anyway. This would add additional delays to the code path for both ingress and egress. In a world where gigabit ethernet is becoming the norm, every nanosecond counts. I don't think the benefits of your proposal would justify the performance loss. At the very least, I'd want the extra calls to bpf_mtap to be present in the code only if enabled by an option in the kernel config file. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying