ng_ether vs bridge Was: bridge callbacks in if_ed.c?

[Gleb Smirnoff]

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) from if_ethersubr.c into bridge.c. This
A> > probably requires small changes to bridge_in()/bdg_forward()
A> > logic, so it's caller must take care. We have only two callers
A> > now - ether_input(), which is OK and if_ed, which looks like
A> > a hack.
A> 
A> I'm not sure if I can follow the graph correctly.  Shouldn't the
A> straight line between where ng_ether_input and ng_ether_rcvdata
A> branch be disconnected?  The way it is drawn there looks like the
A> packet is arrving double in the upper half?

Yep, this is an error in originators email. Vertical line
should be removed.
What we need to achieve is to return from netgraph into the same place
we were sent to netgraph. You should have received a patch from me,
which splits ether_input() in 2 parts. It is a hacky PoC, but it is working.

What I'd like to do is "push block (lines 569-615) from if_ethersubr.c
into bridge.c". That will not be a hack and will also remove another
intermixing.

A> > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks.
A> > If this happens, the code in if_ed.c will be on the way again.
A> 
A> No.  What will move to pfil_hooks is the firewalling within the bridge
A> code and the layer2 ethernet firewalling.  The bridging code as such
A> will stay where it is.

Thanks for this information.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE