mroek:

The Netgear R7800 has a QCA8337N switch chip, and the CPU has two interfaces (eth0/port 0 and eth1/port 6) connected to the switch. The default in LEDE is that WAN is on port0/eth0, and LAN is on port6/eth1.

When using multicast, it is often desirable to enable IGMP snooping on the switch to avoid flooding the multicast stream to all ports. A multicast server will normally send IGMP general queries to the all hosts address 224.0.0.1 at a regular interval (every few minutes) to check if there are still clients that wants to receive the multicast.

However, when IGMP snooping is enabled on this device, these queries are all //redirected// to port 0 on the switch, which is a problem if the multicast server is within the LAN. In this scenario, the server sends queries, but these queries are not being broadcast to the clients within the LAN, instead they end up at port 0 (eth0) where they are not needed. The server will then receive no responses to the queries, and subsequently times out and stops the stream multicast.

I think I found a viable fix for this, which is to set bit 3 (IGMP_COPY_EN) of the GLOBAL_FW_CTRL0 register in the switch chip to 1. This causes the IGMP queries to be broadcast on all switch ports (provided they are members of the same VLAN), instead of being redirected only to port 0. In my testing, I have found no adverse effects from this change.

I have attached a patch for this change, to make testing easy:

Assuming that the LAN interface is br-lan, run tcpdump on the router and inject IGMP general queries from a computer in the LAN, for example using Ostinato. With IGMP snooping off, the query is seen on br-lan:

root@R7800:/# tcpdump -i br-lan igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
11:47:06.832511 IP 192.168.20.1 > all-systems.mcast.net: igmp query v2


If IGMP snooping is turned on (globally or for the port where the query is received), then the query no longer appears at br-lan,
but instead only on eth0. Applying the attached patch fixes this.