Also, and more critically, the current behavior of offloaded switches do forwarding like this already. So there is a discrepancy currently between how the bridge forwards unknown multicast and how any underlying switchcore does it. Sure, we'll break bridge behavior slightly by forwarding to more ports than previous (until the group becomes known/registered), but we'd be standards compliant, and the behavior can still be controlled per-port. [1]: https://www.rfc-editor.org/rfc/rfc4541.html#section-2.1.2 [2]: Section 3 goes on to explain how this is similar also for MLD >> diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c >> index 02bb620d3b8d..ab5b97a8c12e 100644 >> --- a/net/bridge/br_forward.c >> +++ b/net/bridge/br_forward.c >> @@ -199,9 +199,15 @@ static struct net_bridge_port *maybe_deliver( >> void br_flood(struct net_bridge *br, struct sk_buff *skb, >> enum br_pkt_type pkt_type, bool local_rcv, bool local_orig) >> { >> + struct net_bridge_mcast *brmctx = &br->multicast_ctx; > Note this breaks per-vlan mcast. You have to use the inferred mctx. Thank you, this was one of the things I was really unsure about since the introduction of per-VLAN support. I'll extend the prototype and include the brmctx from br_handle_frame_finish(). Thanks! Best regards /Joachim
