I am using a very old Linksys router as a WLAN-AP and a switch for older 100 MBit devices. When I changed my network layout (due to swtiching rooms for my home office), this router was no longer connected directly to my Fritz!Box (Internet router) but via another switch (which is not IGMP V3 ready).
When I now watched TV on my PC (T-Entertain, using vlc) the multicast IP-TV-traffic went all over my switch, all ports, the Linksys router and was finally flooding the WLAN. I can perfectly live with the 10 Mbit or so IP-TV traffic flowing over my cable ethernet - for the WLAN, however I needed to find a solution.
[1] outlines two solutions, one via "unbridging" the WLAN and the other using ebtables to filter the multicast traffic. I did not like the former, because that meant that the Linksys router would need to take over DHCP tasks for the unbridged WLAN segment (DHCP needs broadcasts).
The latter variant turned out not to work, because the ebt_pkttype kernel module is not included in any stable release of dd-wrt for this old router. I have no idea why, and
[2] has a lengthy discussion about possible workarounds, but this was a show-stopper for this variant as well.
But why do they use the pkttype plugin? One can specify source and destination MAC addresses using just the ebtables and ebtable_filter modules (which are available on my router) and there are even broadcast and multicast aliases for this command, see the man page at
[3].
Admittedly, the way these aliases are defined, the multicast alias does also match broadcast packets, which is not what we desire (see above). Nothing prevents us, however, from using a hand-crafted multicast filter which just filters out the IPTV packets. This turns out to be 01:00:5e:00:00:00/01:00:5e:00:00:00. For further information refer to
[4].
The only necessary configuration change is thus to insert the following commands into the startup commands at Administration->Commands:
insmod ebtables
insmod ebtable_filter
ebtables -A FORWARD -o eth1 -p IPv4 -d 01:00:5e:00:00:00/01:00:5e:00:00:00 -j DROP
Note that this does only filter on the eth1 interface (WLAN, see
[5]) and the multicast packets are
not filtered on the cable-based ports 1-4, but this is perfectly fine for me.
Update 04.04.2017: Dammit! My solution also filtered out some IPv6 multicast packets, in particular ICMPv6 neighbour solicitations. The filter needs to be restricted to IPv4 packets only (already applied above).
