bpf, ipfw and before-and-after

[John Polstra]

In article <20030805133922.GA7713 at k7.mavetju>,
Edwin Groothuis  <edwin at 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