Am 12.09.2014 um 03:48 schrieb Linus Lüssing:
Another idea would maybe be to translate MLDv1 / IGMPv2 reports into
appropriate MLDv2/IGMPv3 equivalents before sharing them on the
bridge to prevent the suppression.
Hm, IGMPv2/MLDv1 to IGMPv3/MLDv2 should be relatively easy. But
I'm currently not sure whether a router/querier will make and take
some wrong assumptions and actions by thinking there is no
IGMPv2/MLDv1 listener. What if there is one MLDv2 listener which
included source specific state messages in its state change report?
The querier would respond with a "Multicast Address and Source
Specific Query" to learn whether there are listeners left for
this multicast and source addresses. Would the MLDv1 listener
interpret this query and process this message as a "Multicast Address
Specific Query" or would it ignore it?
It doesn't really matter since sending / receiving
address-and-source-specific queries doesn't reduce the filter timer of
the group but only the source timers of the sources included in the query.
What about the many MLDv1 queriers we have right now through the
bridge code? What if someone sneaks in an MLDv1 listener somewhere
in your bridged network over an ethernet cable? (You'd need
report translation both on the AP and on bridges and maybe query
translation, too)
Ah so the bridge code is actually a dumb v1-querier. Hmm that is
problematic then I suppose. But doesn't that effectively downgrade the
whole link to MLDv1 even if you potentially have a v2 querier at hand?
Sounds very fishy to me.
Cheers,
Steven
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
