On Mon, 2017-01-09 at 12:44 +0100, M. Braun wrote: > Am 09.01.2017 um 09:08 schrieb Johannes Berg: > > Does it make sense to implement the two in separate layers though? > > > > Clearly, this part needs to be implemented in the bridge layer due > > to > > the snooping knowledge, but the code is very similar to what > > mac80211 > > has now. > > Does the bridge always know about all stations connected? > > That is bridge fdb entries (need to) expire so the bridge might > "forget" a still-connected station not sending but only consuming > broadcast traffic. > > E.g. there is a television broadcast station here that receives a > video stream (via wifi, udp packets) and then airs it (dvb-t) but (on > its own) would not send any data packet on wifi (static ip, etc.). Ok, that I don't know. Somehow if you address a unicast packet there the bridge has to make a decision - so it really should know? Would it query the port somehow to see if the device is behind it, if getting a packet for a station it forgot about? > An other reason to implement this in mac80211 initially was that > mac80211 could encapsulate broacast/multicast ethernet packtes in > unicast A-MSDU packets in a way, so that the receiver would still see > process ethernet packets (after conversion) but have unicast wifi > frames. This cannot be done in bridge easily but one might want to > add this later to mac80211. Yes, DMG would have to be done in mac80211, but that's a lot clearer case too since it requires negotiation functionality etc. johannes
