In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> My point is that the extra calls to bpf_mtap would harm performance
> even when bpf wasn't being used.
In -current I believe all the calls are prefixed with a check for
ifp->if_bpf or similar. So any slow down should only ha
On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Edwin Groothuis <[EMAIL PROTECTED]> 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 fr
In article <[EMAIL PROTECTED]>,
Petri Helenius <[EMAIL PROTECTED]> wrote:
> >
> > 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
> >
one thing one could do is to add special 'interface names'
to the list recognised by /dev/bpf (e.g. "ipfw", "ipf", etc)
in bpf_setif(), and insert calls to bpf_mtap() at the end
of ipfw_check() and friends. Now the question is, of course,
do you want only 'accept'ed packets, or all of them ?
In th
In article <[EMAIL PROTECTED]>,
Petri Helenius <[EMAIL PROTECTED]> wrote:
>
> 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 jus
>
> 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
On Tue, Aug 05, 2003 at 10:31:01AM -0400, Barney Wolff wrote:
> On Tue, Aug 05, 2003 at 11:39:23PM +1000, Edwin Groothuis wrote:
> >
> > Now my question to you guys is, does what I want or what I describe
> > here make a little bit sense? Or am I totally going the wrong way?
> > Or has this topic
On Tue, Aug 05, 2003 at 11:39:23PM +1000, Edwin Groothuis wrote:
>
> Now my question to you guys is, does what I want or what I describe
> here make a little bit sense? Or am I totally going the wrong way?
> Or has this topic already been discussed multiple times and decided
> not to do it? Maybe
In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > Sam Leffler <[EMAIL PROTECTED]> wrote:
> >> > My point is that the extra calls to bpf_mtap would harm performance
> >> > even when bpf wasn't being used.
> >>
> >> In -current I believe
In article <[EMAIL PROTECTED]>,
Edwin Groothuis <[EMAIL PROTECTED]> 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
In article <[EMAIL PROTECTED]>,
Sam Leffler <[EMAIL PROTECTED]> wrote:
> > My point is that the extra calls to bpf_mtap would harm performance
> > even when bpf wasn't being used.
>
> In -current I believe all the calls are prefixed with a check for
> ifp->if_bpf or similar. So any slow down sh
In article <[EMAIL PROTECTED]>,
Edwin Groothuis <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 05, 2003 at 11:17:07AM -0700, John Polstra wrote:
> > 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.
>
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
Greetings,
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.
Looking through
14 matches
Mail list logo
