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 ?
I don't think it was ever valid. It's a misstatement. In fact what happens is:
With IGMP snooping enabled, by default multicast doesn't go out any port on the bridge
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
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.
it listens on a "downstream" interface to hear igmp requests (ie. your LAN)
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
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.
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.
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.
work around?