Bridge MAC addr learning from WiFi port

wayne liu waynix
Mon Mar 28 11:04:41 PST 2005

Haven't found your thread yet. 
Thanks for the paper. I only got a chance to take a very brief look of
those two
sections, it seems I would agree on what should be done as you described. 
I believe the effect of not having updated fdb is only a performance
issue not a
functionality one. If nobody knows where a STA has roamed to, then flood.
It may or may not be serious depending on actual appl. and/or traffic scenario.
In your VoIP case, it probably is.

On Mon, 28 Mar 2005 11:33:04 +0200 (CEST), Jon-Olov Vatn
<vatn at> wrote:
> Hi,
> I'm not sure if it applies to your case, but I initiated an email
> discussion on hostap and bridging code interaction some time ago.
> (In case you want to search the mail archives, the subject line was
> "Question on HostAP, IAPP link layer update and bridge station cache").
> I have not followed what has happened since then, so I cannot say
> how relevant it is today. You may be interested in sections 4.1-4.2
> of
> BW J-O
> On Mon, March 28, 2005 9:40 am, wayne liu said:
> > I was wondering what the consideration was when in bridge mode frames from
> > one associated STA to another assocaietd STA are only sent back to
> > wireless
> > media, but not to the kernel network code. I know in terms of frames
> > reaching its
> > destination, this is the all that's needed, but wouldn't this hide the
> > traffic from
> > the bridge so that the forwarding database entry for the STA won't be
> > refreshed ?  This would lead to only minor performance impact for bridging
> > when e.g. a machine which talked to the WiFi STA earlier has a record of
> > the STA (e.g. ARP entry) that ages slower that bridge's fdb, leading to
> > flooding of future frames from that machine to the STA.
> >
> > I'm doing my own driver and planning to send such frames to both its dst
> > and
> > the bridge, or inform bridge of the active status of the STA by
> > sending Layer 2 XID
> > frames to the bridge to freshen up the fdb. Of course this incurs its
> > own overhead.
> >
> > A brief explanation from Jouni would be appreciated.
> > _______________________________________________
> > HostAP mailing list
> > HostAP at
> >
> >

More information about the Hostap mailing list