Hi!
In fact, i found temporary decision for my problem (workaround :)). I've
decided, the bridge can  work without iptables patch, when i use the power
of ebtables... (iptables patch is also useful, i'll miss it, so i think
i'll queue bridges - one with iptables, next with ebtables:)). But
please, don't forget this bug is still present...

Thank you!

Regards, Oleg.

> On Sat, 12 Jan 2002, Lennert Buytenhek wrote:

> Date: Sat, 12 Jan 2002 16:04:57 -0500
> From: Lennert Buytenhek <[EMAIL PROTECTED]>
> To: Bart De Schuymer <[EMAIL PROTECTED]>
> Cc: Oleg <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [Bridge] 2.4.17 kernel panic...
>
>
> On Sat, Jan 12, 2002 at 09:20:53PM +0100, Bart De Schuymer wrote:
>
> > I am experiencing this oops too. And with a size of around 5000 I get about
> > 50% packet loss.
> > Doing a ping xxx.xxx.xxx.xxx -s 20000 from a host through the bridge to
> > another host also oopses the bridge box.
>
> Hmm.  I see no such troubles with 0.0.6.  Can you reproduce this with 0.0.6?
>
>
> > Lennert:
> > in net/ipv4/netfilter/ip_conntrack_standalone.c the function ip_refrag() is
> > registered onto NF_IP_POST_ROUTING with priority NF_IP_PRI_LAST.
> > So: this function will try to fragment stuff on the bridge POST_ROUTING
> > hook. Is this healthy?
>
> Yes.  In fact, packets passed to NF_HOOK and friends are only unfragmented
> ones (iff connection tracking is loaded).  Makes it easier to filter them
> and such.
>
>
> > Also: is it healthy that connection tracking defragments the ip packets on
> > the bridge PREROUTING hook?  Doesn't this give problems if the bridge/router
> > box has to bridge those frames (instead of route them)?
>
> It only happens on IP packets.  And if it is done on IP packets, it's undone
> again as soon as the packet passes POST_ROUTING.  Right?
>
>
> cheers,
> Lennert
>

_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge

Reply via email to