Johannes Berg
2017-Jan-09 08:08 UTC
[Bridge] [PATCH net-next] bridge: multicast to unicast
On Sat, 2017-01-07 at 15:55 +0100, Linus L?ssing wrote:> On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote: > > Am 06.01.2017 um 14:54 schrieb Johannes Berg: > > > > > > > The bridge layer can use IGMP snooping to ensure that the > > > > multicast > > > > stream is only transmitted to clients that are actually a > > > > member of > > > > the group. Can the mac80211 feature do the same? > > > > > > No, it'll convert the packet for all clients that are behind that > > > netdev. But that's an argument for dropping the mac80211 feature, > > > which > > > hasn't been merged upstream yet, no? > > > > But there is multicast/broadcast traffic like e.g. ARP and some IP > > multicast groups that are not covered by IGMP snooping. The > > mac80211 > > patch converts this to unicast as well, which the bridge cannot do. > > > > That way, these features both complement and overlap each other. > > Right, I'd agree with that.Ok.> I didn't write it explicitly in the commit message, but yes, the > like anything concerning bridge multicast snooping, bridge > multicast-to-unicast can only affect packets as noted in > RFC4541 ("Considerations for Internet Group Management Protocol (IGMP) > and Multicast Listener Discovery (MLD) Snooping Switches"), too. > > So it is only working for IPv4 multicast, excluding link-local > (224.0.0.0/24), and IPv6 multicast, excluding all-host-multicast > (ff02::1). > > And does not concern ARP in any way. > > > The nice complementary effect is, that the bridge can first sieve > out those IP packets thanks to IGMP/MLD snooping knowledge and for > anything else, like ARP, 224.0.0.x or ff02::1, the mac80211 > multicast-to-unicast could do its job. > > > For APs with a small number of STAs (like your private home AP), > you might want to enable both bridge multicast-to-unicast and > mac80211 multicast-to-unicast for this complementary effect. While > on public APs with 30 to 50 STAs with varying distances and bitrates, > you might only one to enable the bridge one, because sending an ARP > packet 50x might actually reduce performance and airtime > significantly.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. It would probably not make sense to combine the two options into one, but it seems relatively simple for bridge to also implement the one mac80211 tentatively has now, with multiple benefits: * single place for configuration, leading to less possible confusion * single implementation for all wireless devices, including ones with Full-MAC firmware that don't use mac80211 * code sharing for the duplication, although admittedly not so much Thoughts? johannes
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.). 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. Michael