[OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

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
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel