Re: Re: [Ebtables-user] bridge/ebtables interaction...

Op ma, 29-08-2005 te 12:04 -0700, schreef Stephen Hemminger:
> On Mon, 29 Aug 2005 19:11:39 +0000
> Bart De Schuymer <[email protected]> wrote:
> 
> > Op ma, 29-08-2005 te 08:55 -0700, schreef Stephen Hemminger:
> > > On Tue, 23 Aug 2005 22:08:05 +0000
> > > Bart De Schuymer <[email protected]> wrote:
> > > > I was wondering what happened to the plan to postpone fdb updates until
> > > > after the PF_BRIDGE/PRE_ROUTING hook. Looking in the current
> > > > net/bridge/br_input.c I don't see any changes.
> > > > Did you decide not to do this after all?
> > > > 
> > > 
> > > 2.6.12 (and 2.6.13) both don't do fdb_update until handle_frame_finish.
> > 
> > Here's a code snippet from 2.6.12.5 (same code for 2.6.13):
> > int br_handle_frame(struct net_bridge_port *p, struct sk_buff **pskb)
> > {
> > 	struct sk_buff *skb = *pskb;
> > 	const unsigned char *dest = eth_hdr(skb)->h_dest;
> > 
> > 	if (p->state == BR_STATE_DISABLED)
> > 		goto err;
> > 
> > 	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
> > 		goto err;
> > 
> > 	if (p->state == BR_STATE_LEARNING)
> > 		br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
> > ...
> > 
> > Unless I'm not reading this correctly, the fdb update is still done at
> > the same place.
> >
> Only in the learning state which happens only during the initial
> state before frames are forwarded.  There is actually a different
> problem here, it is that the bridge filtering code doesn't really
> process frames in this early state.  It should probably do
> something like feed the packets into the ebtables code then
> drop them.  This would allow the filters to pickup these early
> packets even if they aren't going to be forwarded.

The only way to fix that is by introducing a new ebtables table, like
Jon Anderson did. The problem I had with his code is that it's not
backwards compatible and there was another fix for his problem. It's
actually possible to create a new table without breaking backwards
compatibility. The question now is where to add it. I was thinking of an
ebtables table "fdb" that is traversed inside br_fdb_update, right
before the update. It just seems a waste to make a new table just for
the learning state. Something like this would be added:

--- net/bridge/br_fdb.c.old	2005-08-31 16:05:31.213809448 +0000
+++ net/bridge/br_fdb.c	2005-08-31 16:07:50.850581432 +0000
@@ -341,6 +341,10 @@ void br_fdb_update(struct net_bridge *br
 	if (hold_time(br) == 0)
 		return;
 
+	if (br_fdb_update_hook)
+		if (!br_fdb_update_hook(pskb))
+			return;
+
 	rcu_read_lock();
 	fdb = fdb_find(head, addr);
 	if (likely(fdb)) {

What do you think?

cheers,
Bart




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf