The content of this topic has been archived on 5 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
My router is running OpenWrt trunk, with hardware similar to TPLink 4300, which has an AR8327 switch that is supposed to do hardware IGMP snooping.
However, today I tested multicast in my LAN, by using one PC with VLC player delivering media stream. Without any client joined in the multicast group I created, I could still capture multicast data on OpenWrt.
Is IGMP snooping enabled for this switch? or do I miss something?
I have exactly the same problem.
Using,
Buffalo WZR-HP-G300NH
OpenWrt Barrier Breaker r35828 / LuCI Trunk (trunk+svn9672)
1. Building
I checked IGMP snooping option in kernel_menuconfig before compiling.
2. Flashed, booted and,
/sys/devices/virtual/net/br-lan/bridge/ has all the multicast_* files with 1's
3.
I did all the igmpproxy.conf setting and firewall configurations. There IGMP packets are flowing and IPTV works.
4.
However, Openwrt is not doing any IGMP Snoofing. LAN is flooded with UDP packets.
IGMP snooping is broken in Openwrt. I have tried backfire, latest gargoyle, Backfire 10.03.1-rc6. No IGMP snooping in any of these releases.
(Last edited by test011 on 28 Feb 2013, 18:59)
I have tried a cheap local brand home router with 'Multicast' feature.
It claims to do multicast forwarding and IGMP snoofing to restrict LAN flood. Just like Openwrt with igmpproxy does. (or rather supposes to do)
Unlike my Buffalo WZR-HP-G300NH with OpenWrt Barrier Breaker r35828, it really prevents flooding while IPTV work absolutely fine. I have checked that with Winshark sniffing software.
BTW, Buffalo WZR-HP-G300NH has RTL8366S for the switch.
"For the increasing IP multicast application, the RTL8366S/SR supports IPv4
IGMPv1/v2/v3 and IPv6 MLDv1/v2 snooping." - from http://realtek.info/pdf/rtl8366s_8366sr … 071022.pdf
Multicast forwarding and IGMP snoofing are two different things although the apparent result seems identical. While your IPTV works fine, it may just mean that your router has only multicast packet forwarding function and still flooding your entire LAN with UDP packets. (You need to perform packet sniffing to confirm that)
igmpproxy just forwards multicast packets - like a dummy HUB - which default Openwrt does not do. By installing igmpproxy, you just enable the multicast forwarding achieved by flooding LAN, igmpproxy itself does not prevent LAN flooding. IGMP packet snoofing and preventing the LAN flood is handled by kernel. Since IGMP snoofing in Openwrt is a kernel feature, I guess everybody is just assuming it works. Information on this is really scarce.
Can anybody confirm whether IGMP snoofing works or not?
(Last edited by test011 on 4 Mar 2013, 18:43)
It is not compiled into the kernel as the feature seems to be broken, it randomly shuts down bridge ports when activated.
It is not compiled into the kernel as the feature seems to be broken, it randomly shuts down bridge ports when activated.
You mean it does not work at all, even if you set the kernel options for that before compiling? IGPM snoofing never worked.
(Last edited by test011 on 4 Mar 2013, 18:38)
In this case it might make more sense to report the problem to kernel.org.
In this case it might make more sense to report the problem to kernel.org.
It's hard to believe it's broken since IGMP snoofing has been (supposed to be) supported since 2.6.xx. No possibility with drivers malfunctioning or architecture specific problem?
(Last edited by test011 on 4 Mar 2013, 18:46)
There are 2 problems here: 1, does the hardware switch support IGMP snooping and if so is there a way to turn it on (which is what OP was asking)? 2. the kernel bridge snooping, which can be activated by setting /sys/devices/virtual/net/br-lan/bridge/multicast_snooping to 1. The kernel bridge snooping only works between the bridge ports, igmpproxy will still flood all LAN ports since all ports are a single bridge port as far as the kernel is concerned...but it won't flood wifi bridge port if enabled.
There are 2 problems here: 1, does the hardware switch support IGMP snooping and if so is there a way to turn it on (which is what OP was asking)? 2. the kernel bridge snooping, which can be activated by setting /sys/devices/virtual/net/br-lan/bridge/multicast_snooping to 1. The kernel bridge snooping only works between the bridge ports, igmpproxy will still flood all LAN ports since all ports are a single bridge port as far as the kernel is concerned...but it won't flood wifi bridge port if enabled.
You mean OpenWrt and linux kernel based routers have no other way but to flood all LAN switch ports, even if kernel IGMP snoofing is on?
Then, is it safe to say that OpenWrt is NOT recommened in IPTV environment for now?
Should we put some kind of warning about this? These days many over $20 routers have IGMP snooping features, not just bridging it but intelligently forwarding it to specific port. No flooding. If OpenWrt can't do it and stock firmware can, we should let people know so they can choose.
WZR-HP-G300NH, for example, does not do any multicast forwarding in the stock firmware at all! Can you give me an example of a router that does this in the switch?
In my experience the routers bundled with IPTV services in Finland are configured to put the IPTV box in a separate VLAN, and iptables is then used to forward the multicast traffic only to this VLAN, thus preventing multicast flood to the rest of the LAN and wireless. Moreover, igmpproxy is used to subscribe to the multicast group from behind NAT. This is how I have configured my OpenWrt router as well (WZR-HP-G300NH, incidentally).
An easier approach not involving iptables is to just bridge the VLAN of the IPTV to the rest of the LAN and use the IGMP snooping functionality in the kernel. I personally have never experienced the problems jow described with this approach, but I still prefer to isolate the IPTV box to a separate VLAN - who knows what security holes they might have.
Finally, one could use the IGMP snooping functionality in the switches. The problem here is the lack of support in the Linux switch drivers. This is also the reason I doubt that stock firmwares use this approach either - OEMs tend to be lazy (like Buffalo) and not do any extra work by writing a new driver with this functionality.
WZR-HP-G300NH, for example, does not do any multicast forwarding in the stock firmware at all! Can you give me an example of a router that does this in the switch?
In my experience the routers bundled with IPTV services in Finland are configured to put the IPTV box in a separate VLAN, and iptables is then used to forward the multicast traffic only to this VLAN, thus preventing multicast flood to the rest of the LAN and wireless. Moreover, igmpproxy is used to subscribe to the multicast group from behind NAT. This is how I have configured my OpenWrt router as well (WZR-HP-G300NH, incidentally).
An easier approach not involving iptables is to just bridge the VLAN of the IPTV to the rest of the LAN and use the IGMP snooping functionality in the kernel. I personally have never experienced the problems jow described with this approach, but I still prefer to isolate the IPTV box to a separate VLAN - who knows what security holes they might have.
Finally, one could use the IGMP snooping functionality in the switches. The problem here is the lack of support in the Linux switch drivers. This is also the reason I doubt that stock firmwares use this approach either - OEMs tend to be lazy (like Buffalo) and not do any extra work by writing a new driver with this functionality.
I do agree. VLAN method is proven way to do it, but if you need to connect to local network for example NAS from your IPTV box or from a smartphone to IPTV box, it won't do much good. We have here a Google TV + IPTV in one device, and some IPTV related service involving Smartphone and NFC tag, not sure how common it is, but VLAN is not very good path to go in this case. Maybe some complex routing table setting might do.
My ISP tells me that Buffalo is one brand that does not really do IGMP multicast support. Since they are inclined to use DD-WRT as their power tool for advanced user, IGMP is not really supported as other XX-wrt variant.
I am in a country where broadband connection is very common with over five million of IPTV users. I don't know how,whether it is done in switch or in CPU, but many cheap home routers sold here support IPTV, IGMP snoofing and multicast without flooding. I am using a $25 router, made in China with local brand name ipTime. I had rang the company and they told me that all of their routers less than 2 years old have IGMP multicast support without flooding and those 3-4 years old routers only have IGMP multicast with flooding. I could kind of confirm that since I own 5 routers of theirs. It is rather common feature here by demand.
I do agree that it is a matter of open source swtich driver lacking such feature and those home router companis may have something better to work on. As long as the versatility of OpenWrt is concerned, this may be critical in the future. There are about 50 million IPTV users world-wide who have better alternative than OpenWRT.
(Last edited by test011 on 10 Mar 2013, 17:21)
You mean OpenWrt and linux kernel based routers have no other way but to flood all LAN switch ports, even if kernel IGMP snoofing is on?
The kernel usually only sees one port on the LAN side, so there's no way for it to do the snooping. One could theoretically put each LAN port into separate VLAN, bridge them all in Linux and snooping would work, but switching performance would be significantly lower.
Then, is it safe to say that OpenWrt is NOT recommened in IPTV environment for now?
I use IPTV as well...I really don't see a big problem if the stream is all over the LAN. I have Gb connections everywhere, those 8-10Mb of extra traffic just causes some extra blinking, no other real downside. Why is it a big problem if IPTV is flooded over the LAN?
The kernel usually only sees one port on the LAN side, so there's no way for it to do the snooping. One could theoretically put each LAN port into separate VLAN, bridge them all in Linux and snooping would work, but switching performance would be significantly lower.
Many switches in commercial home routers have that feature embedded into the hardware and usually they run on Linux, which means there is some way to do this. There really is such thing as IGMP snoofing. Openwrt lacking feature? Openwrt has been always superior to stock firmwares, it's hard to believe current situation.
I use IPTV as well...I really don't see a big problem if the stream is all over the LAN. I have Gb connections everywhere, those 8-10Mb of extra traffic just causes some extra blinking, no other real downside. Why is it a big problem if IPTV is flooded over the LAN?
Because every single device connected to the same LAN receives (= packets are legitimately delivered to every device, they are broadcast packets) those constant stream of UDP packets, and must process them all. Even if bandwidth is not a problem, all those devices wastes CPU process time ignoring the packets. When you change channels on IPTV, UDP connections/streams may temporarily multiply and again delivered to every device, creating a similar situation as DDOS attack. If they can handle it, then it's good for them, but they don't have to.
(Last edited by test011 on 21 Mar 2013, 22:22)
Regarding rtl8366s, anybody find out how to activate igmp snooping ? (I'm talking about the hardware LAN switch, not the kernel bridde.)
I'm still looking for a way to activate IGMP Snooping on the hardware switch (as the feature is available => RTL8366S datasheet).
Regarding the swconfig utility, it's compile with a driver for each hardware switches. But, none of these drivers have registries and attributes for IGMP Snooping. A solution could be to update these drivers (IGMP snooping registries are given in datasheets) and recompile the swconfig utility. But I have no experiences in this… And swconfig seems to be depreciate for few years.
According to swconfig wiki, Linux Ethernet switches are now configurable with API. I also noticed that there is a kernel module to support each switches (ex: kmod-switch-rtl8366s). But I have no idea how to use the API (or functions to manipulate switchs) and what features are present in each kernel module. Can someone can help me with this ?
Those kernel modules are the backends for swconfig.
Ok, so how to find information on the "new" switch configuration API ?
Which package or which module are involve ?
The discussion might have continued from here.