Date: Tue, 5 Aug 2003 11:17:07 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: net@freebsd.org Cc: edwin@freebsd.org Subject: Re: bpf, ipfw and before-and-after Message-ID: <200308051817.h75IH7jb006622@strings.polstra.com> In-Reply-To: <20030805133922.GA7713@k7.mavetju> References: <20030805133922.GA7713@k7.mavetju>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030805133922.GA7713@k7.mavetju>, Edwin Groothuis <edwin@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308051817.h75IH7jb006622>