Date: Wed, 6 Aug 2003 10:14:59 +1000 From: Edwin Groothuis <edwin@freebsd.org> To: freebsd-net@freebsd.org Subject: Re: bpf, ipfw and before-and-after Message-ID: <20030806001459.GB558@k7.mavetju> In-Reply-To: <200308051817.h75IH7jb006622@strings.polstra.com> References: <20030805133922.GA7713@k7.mavetju> <200308051817.h75IH7jb006622@strings.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
> 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.
I totally agree with the idea that it is _at_ the network interface,
but if you think about what people are actually using it for you
realise that most of the output you're interested in is at the IP
or the TCP layer.
Another thing which argues for the case is that the ipfw checks
(for ethernet at least) are done on the network layer too, just
after the packet would have been pushed through bpf.
> > 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.
If you want it to be enabled via a kernel option, fine with me.
I'm not sure what the performance loss would be, since if you are
running without having a bpf opened, it would be one single additional
if statement ("if (ifp->if_bpf != NULL)"). If the bpf device is
opened, it would be one additional call to bpf_mtap() and a check
there if this is the right place for the packet to be processed,
there will be no double processing of the bpf-filters.
Edwin
--
Edwin Groothuis
edwin@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030806001459.GB558>