Multicast snooping

The (old) wiki page on UDP multicast ( says at the end:

With IGMP snooping, multicast forwarding is disabled for bridges. One pure bridge solution is to disable multicast_snooping.
Add the following in /etc/rc.local
echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

Is this still valid? What means the first sentence exactly?

Is this the only way to achieve UDP multicasting without the need for additional packages such as igmpproxy and/or udpproxy?

Finally, is there a way to prevent flooding wifi ?

New URL:

The old page is for archival purposes only and does not receive updates any more.

I'm not clear on what you don't understand.

No, some people have simply used sysctrl to enable mc_forwarding, created made multicast routes; and changed the TTL of the UDP packets to 2.

  • Can't you enable snooping on the VLAN; and/or
  • Don't place WiFi on a bridge

I don't think it was ever valid. It's a misstatement. In fact what happens is:

  1. With IGMP snooping enabled, by default multicast doesn't go out any port on the bridge
  2. If an IGMP response is seen on a given bridge port, then that requested traffic is now opened up to be sent on that bridge port where the request was received

Without IGMP snooping, then for that bridge multicast is just broadcast, so any multicast received on any port is mirrored to all ports.

One issue is that the IGMP snooping code has been somewhat buggy in the past, so people were disabling it and making the bridge broadcast.

Yes, this is exactly what IGMP snooping is supposed to do. WiFi will only get the multicast if someone on wifi requests it. (see part 2 of my list above)


Thanks. So enabling igmp_snooping is enough to get multicast packets on the relevant port of my lan ?

Why is the documentation not saying this clearly upfront then, instead of going through igmpproxy and udpproxy configurations ?

BTW, it seems that the last version of igmpproxy is having a bug with pppoe, which prevents me from using it as I have a modem+pppoe/vlan 7+router config. So I am trying to find alternative solutions...

Depends on where they come from. If you're trying to multicast from a LAN device to a LAN device, then yes this should be enough.

If, on the other hand, you are trying to route multicast from the WAN to the LAN, then that's what igmpproxy and udpproxy etc are for, subscribing on the WAN and moving multicast packets from WAN to LAN

My apologies for not being clear.

I am indeed trying to route multicast from WAN to LAN, without igmpproxy/udpproxy.

Well, udpproxy isn't needed, but can make things more bandwidth efficient on wifi... but igmpproxy is needed unless you are ok with just a few static routes, in which case you can use smcroute.

What types of traffic are you trying to multicast? If 'all' you want is multicast discovery of service, then avahi will do that fine.

IPTV from my Internet Provider (Deutsche Telekom).

Then you want igmpproxy. I recently edited that page to bring it up todate as a result of helping others on this forum. It's here:

Here's what igmpproxy does as I understand it:

  1. it listens on a "downstream" interface to hear igmp requests (ie. your LAN)
  2. It mirrors those requests onto the "upstream" (WAN) interface which causes your ISP to open up the floodgates and start sending the requested Multicast traffic
  3. It sets up a route for the requested traffic from WAN to LAN so that the traffic crosses your router from WAN to LAN.

Without igmpproxy your LAN devices can not "talk to" your ISP to request the IPTV traffic.

1 Like

Thank you for the wiki page, which I read before and is very informative.

Unfortunately, I am using pppoe and igmpproxy has a bug which prevents it to start if pppoe is the upstream interface:

Conclusion: I cannot use a adsl<->modem<->pppoe<->openwrt configuration to "listen" to the IPTV multicast from my network provider, which is a bit... frustrating (I already abandoned any hope to make DECT work a long time ago).

So after having lost my phone and my tv, and consequently my wife and my children, I now fear to loose my internet connection altogether. I remain hopeful for the future of openwrt though.

I wonder if it would work if it were a bridged interface with just the pppoe as the only bridge port? :slight_smile: work around?

Well, I can disable pppoe passthrough in the modem and just use a static ip client on the router wan, but my psychiatrist recommended me not to go that route.

Well, I'm not sure what your best option is but maybe at least understanding what is needed and why will help you find things to try. The big issue is that your ISP doesn't just send you all the packets for all the IPTV channels simultaneously, and so there needs to be some communication between your TV device and the ISP to request the packets needed for the channel of interest. This communication occurs via IGMP packets which are not IP packets and do NOT route. So some software has to get them onto the ISPs wire so the ISP multicast routers will hear them and will do their thing and start sending you TV packets.

smcroute can route specific fixed multicast streams, and might not have the pppoe bug, but it probably won't work for you because most likely you have many channels and each one is a different multicast destination.

The next thing you might be able to do is run some sort of multicast routing PIM type daemon, but I doubt that the ISP will listen to your PIM, they are probably only listening for IGMP. To do so you'd have to know the IP address of your own ISP's PIM routers, and you'd have to have them be willing to listen to your PIM packets which arrive via regular unicast IP. I doubt that is likely to happen.

I talked to the garbage collector this morning and mentioned my DECT and multicast issues. He said that he uses the telecom provider modem/router and has no issue. His wife and kids are still at home and he has no additional psychological support expenses.

is your TV device wired to your network, or wireless?


This is why multicast_snooping + ebtables to disable wifi flooding would have been nice.

Does your ISP provide the TV stuff on a separate tagged VLAN? many do

All traffic goes through VLAN 7.