Messages in this thread | | | Subject | Re: [PATCH net-next] bridge: multicast to unicast | From | Johannes Berg <> | Date | Mon, 09 Jan 2017 13:15:59 +0100 |
| |
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
| |