Bridge MAC addr learning from WiFi port

[Jon-Olov Vatn]

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
>