On Sun, Sep 05, 2004 at 10:29:54PM -0700, Luigi Rizzo wrote:
L> > L> I'd rather not apply the patch unless you can show that
L> > L> the current code leads to incorrect behaviour.
L> >
L> > I suspect that packets dropped by bridge_in() called from if_ed will
L> > not be captured by bpf(4). This is
On Sun, Sep 05, 2004 at 02:37:31PM -0700, Matthew Dillon wrote:
> Well, wait a second... are we talking about a lot of packets being
> discarded by the filter in 'normal' operation, or are we talking about
> an attack? Because if we are takling about an attack the LAST ethernet
...
Su
On Mon, Sep 06, 2004 at 03:01:00AM +0400, Gleb Smirnoff wrote:
...
> L> I'd rather not apply the patch unless you can show that
> L> the current code leads to incorrect behaviour.
>
> I suspect that packets dropped by bridge_in() called from if_ed will
> not be captured by bpf(4). This is incorrec
In a recent experiment w/ Jumbo frames, I found out that sending ip
frames completely ignores the MTU set on host routes. This makes it
difficult (or next to impossible) to support a network that has both
regular and jumbo frames on it as you can't restrict some hosts to the
smaller frames.
I now
Sam Leffler wrote:
> > No. What will move to pfil_hooks is the firewalling within the bridge
> > code and the layer2 ethernet firewalling. The bridging code as such
> > will stay where it is.
>
> Well, that's what _you_ want to do :). What I started on last year was a
> complete purge of specia
On Sunday 05 September 2004 02:53 pm, Andre Oppermann wrote:
> Gleb Smirnoff wrote:
> > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
> > L> > I see that bridge callbacks are still living in if_ed.c
> > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> > L> > not corre
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L> there are performance reasons to do this way -- grabbing
L> the entire packet is expensive because it is done via programmed
L> I/O, so the current code only grabs the header, does the
L> filtering, and grabs the rest of the packet onl
Gleb Smirnoff wrote:
>
> Collegues,
>
> here is netgraph module which implements Netflow traffic
> accounting, which I'm going to add to CURRENT in recent future:
>
> http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz
>
> It is
On Sun, Sep 05, 2004 at 11:53:43PM +0200, Andre Oppermann wrote:
A> > Actually I'm working on the problem decribed here
A> >
A> > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html
A> >
A> > and one of the approaches I'm considering is to push the
A> > block (lines 569-615) f
Gleb Smirnoff wrote:
>
> On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
> L> > I see that bridge callbacks are still living in if_ed.c
> L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> L> > not correct.
> L> >
> L> > Bridge code is called from ether_input(), which is
On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote:
L> > I see that bridge callbacks are still living in if_ed.c
L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is
L> > not correct.
L> >
L> > Bridge code is called from ether_input(), which is
L> > indirectly called from if_ed.
Well, wait a second... are we talking about a lot of packets being
discarded by the filter in 'normal' operation, or are we talking about
an attack? Because if we are takling about an attack the LAST ethernet
device anyone would ever want to use would be ED. i.e. they would be
On Mon, Sep 06, 2004 at 12:52:49AM +0400, Gleb Smirnoff wrote:
> Luigi,
>
> I see that bridge callbacks are still living in if_ed.c
> from FreeBSD 2.x times. See if_ed.c:2816. I think this is
> not correct.
>
> Bridge code is called from ether_input(), which is
> indirectly called from if_ed.c:
Luigi,
I see that bridge callbacks are still living in if_ed.c
from FreeBSD 2.x times. See if_ed.c:2816. I think this is
not correct.
Bridge code is called from ether_input(), which is
indirectly called from if_ed.c:2836.
Any objections about attached patch?
[ccing hackers@ and net@ to get mo
vxp wrote:
On Sat, 4 Sep 2004, Colin Alston wrote:
My point was if it provides no security, then there is no point to it at
all.
oh, but it does. it prevents them from gathering accurate information
about your system. that's an extremely important part of the attack.
From your perspective, certainl
Collegues,
here is netgraph module which implements Netflow traffic
accounting, which I'm going to add to CURRENT in recent future:
http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz
It is quite different to ng_netflow in ports/net, because its
expiry thre
16 matches
Mail list logo
