Brijesh-Thakkar commented on issue #18762: URL: https://github.com/apache/nuttx/issues/18762#issuecomment-6650379563
Checked latest master. Nothing in flight for this; #18738 only added the scope filter. Findings: - ipv4_in() forwards a multicast packet only if the ingress device has locally joined the group. ipv4_forward_broadcast() then floods it to all other netdevs, with no egress membership check. - IPv6 floods everything above link scope. - The per-netdev IGMP/MLD lists only track local joins. IGMP drops remote reports for unjoined groups, and the MLD_ROUTER counts are never read on the forward path. So I don't think those lists are the right place to store downstream membership. Proposal: a small, separate multicast forwarding table in net/ipforward/, shared by IPv4 and IPv6, behind CONFIG_NET_IPFORWARD_MCAST (default n). - Option off: behavior and size unchanged, fully compiled out. This should cover the low-end MCU concern. - Option on: forward only to interfaces with an entry for the group. Rough estimate ~32 B RAM per entry and 1.5-3 KB flash. I'll post measured numbers with the first PR. Staging: 1. Table, lookup and data-path filtering, plus a minimal control ioctl so it's testable. 2. IGMP snooping. 3. MLD snooping. 4. Docs and a sim defconfig. Open questions before I start: (a) Separate table OK, vs extending the group lists? (b) With the option on and no entry, drop (Linux behavior) or flood? (c) ioctl for the control interface, or Linux-style MRT_* socket options? @acassis @xiaoxiang781216 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
