On Saturday, 31 August 2024 21:45:28 CEST Linus Lüssing wrote:
In most setups it is sufficient for us to only send MLD reports to nodes which have a multicast router attached. Which reduces overall overhead, especially in large batman-adv mesh networks, where broadcasts are particularly undesirable.
What is the situation before. How does this change try to modify the behavior. Why is this good?
It also doesn't mention anywhere that the old (multicast filter) behavior was just to handle IPv4/IPv6 messages and it is now expanded to IGMP_HOST_MEMBERSHIP_REPORT + ICMPV6_MGM_REPORT.
However there is one specific, known issue / broken scenario with this setting:
If the IGMP/MLD querier is configured directly on the bridge on top of bat0. But there is no multicast router on or behind this node. Then this bridge will be unable to detect multicast listeners on/behind other nodes which have the MLD-RTR-ONLY setting enabled. (A workaround for this can then in turn be to set multicast_router=2 on the bat0 bridge port on the node with the IGMP/MLD querier.)
Therefore MLD report flooding is kept the default and MLD report to multicast routers only forwarding is considered experimental and warned about.
Most of the text here seems to suggest that (whatever reason you want to enable it), you should most likely not do it because it just creates more problems.
The commit message doesn't show me why I should apply this change in the first place - especially when it just causes more headaches in the end.
Another headache I get is the "Warning: MLD-RTR-ONLY is experimental and has known, broken scenarios" part. Which seems to suggest to me that there might be changes in the future which will cause more problems if I just apply this patch now - and in this process create ABI incompatibilities or "no regression" conflicts later.
Btw. BATADV_ATTR_MULTICAST_MLD_RTR_ONLY_ENABLED seems to suggest that it is about MLD - but it seems to be also about IGMP. At least I didn't expect this.
Kind regards, Sven