On Wed, Sep 10, 2014 at 03:49:18PM +0200, Felix Fietkau wrote: > On 2014-09-10 05:41, Linus Lüssing wrote: > > Hi Felix, > > > > Matthias just told me about the work you have done on the bridge > > code which can be found as 645-bridge_multicast_to_unicast.patch > > in the OpenWRT repositord. > > > > I really like the idea of unicasting multicast packets to STAs. > > Especially as that would fit nicely with the work done on > > batman-adv and multicast :P.
> > > Currently, I think I'm seeing a conceptual issue with this > > specific implementation though, leading to multicast packet > > loss: It seems to me that IGMPv2/MLDv1 report suppression (as well > > as IGMPv3/MLDv2 report suppresion in the presence of IGMPv2/MLDv1 > > listeners/reports) was not considered. > Could you please give me some details on that? I don't understand how > this relates to my multicast->unicast translation implementation or how > it can cause multicast packet loss. Sure. With IGMPv2/MLDv1, only one of possibly many will answer with a report to an IGMP/MLD query. If your AP has two IGMPv2/MLDv1 listeners A and B listening to the same multicast address, you will get a report of one of these two only (let's say A). As far as I understand your implementation will save the MAC address of A and will forward multicast packtes to A directly by modifying the packets destination address. B won't get the multicast packets it wants because the bridge does not know that B wants them. Although IGMPv3/MLDv2 does not have this suppression - all such listeners should answer with an individual report - there's one exception: If an IGMPv3/MLDv2 listener heard a IGMPv2/MLDv1 report of the same group it MAY suppress its IGMPv3/MLDv2 report, too. Potential solutions I could think of are two ones: The easy one would be to disable multicast->unicast if an IGMPv2/MLDv1 report was seen (which can happen quite often). Another approach would be to add a feature to mac80211 to disable the forwarding of IGMPv2/MLDv1 reports to other STAs, only forwarding it on the own AP interface so that the bridge would see all reports. > Great, now that it has received some test coverage, I'm considering > sending it upstream soon (after your comments below have been addressed > of course). Nice, looking forward to having it upstream :). To be honest, I didn't test it yet though ;). I only looked at what your patch changes. One more thing/optimization I was thinking of is, instead of modifying the destination address of the frame whether the 802.11 receiver address could be modified. For instance by letting the bridge forward the destinations to mac80211 as a list in the skb. Would seem a little cleaner to me and I think then this feature could even be enabled by default in upstream kernels for any mac80211 based wifi interface. What do you think? > > - Felix Cheers, Linus _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
