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

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.


-------------------------------------------------------
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