On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote: > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the multicast destination MAC to a unicast one accordingly. How does this compare and/or relate to the multicast-to-unicast feature we were going to add to the wifi stack, particularly mac80211? Do we perhaps not need that feature at all, if bridging will have it? I suppose that the feature there could apply also to locally generated traffic when the AP interface isn't in a bridge, but I think I could live with requiring the AP to be put into a bridge to achieve a similar configuration? Additionally, on an unrelated note, this seems to apply generically to all kinds of frames, losing information by replacing the address. Shouldn't it have similar limitations as the wifi stack feature has then, like only applying to ARP, IPv4, IPv6 and not general protocols? Also, it should probably come with the same caveat as we documented for the wifi feature: Note that this may break certain expectations of the receiver, such as the ability to drop unicast IP packets received within multicast L2 frames, or the ability to not send ICMP destination unreachable messages for packets received in L2 multicast (which is required, but the receiver can't tell the difference if this new option is enabled.) I'll hold off sending my tree in until we see that we really need both features, or decide that we want the wifi feature *instead* of the bridge feature. johannes
