Bridge MAC addr learning from WiFi port

wayne liu waynix
Mon Mar 28 15:12:10 PST 2005


Thanks for pointing out that earlier thread. I've found it.
Your scenario examplifies what I intended to cover by inserting L2 XID
frame on behalf of the STA. I need to look at the code to see what's
in now after two years
from that discussion. 
I was wrong earlier in saying flooding is the only impact, actually
before local
fdb entry ages out, there is loss of traffic. 

Wayne

On Mon, 28 Mar 2005 11:33:04 +0200 (CEST), Jon-Olov Vatn
<vatn at imit.kth.se> 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 http://www.it.kth.se/~vatn/research/handover-perf.pdf
> 
> 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 shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
> >
> 
>




More information about the Hostap mailing list