Article Index:

After being a Shaw TV and Internet customer for several years, I recently made the switch to Telus Optik TV ^[2] and Telus Optik High Speed Turbo Internet ^[3]. While I’m very happy with both the Optik TV and Internet so far, there have been a few bumps along the way. For example, the other day I hooked up a DD-WRT ^[4] powered wireless router to the network and experienced an IGMP ^[5] multicast packet flood when I turned on the TV. In this article I show you how to use ebtables ^[6] to block an IGMP multicast packet flood on a DD-WRT WLAN when watching IPTV ^[7].

What is Telus Optik TV and Internet?

Telus Optik TV is the fancy marketing name for Telus’ IPTV ^[8] service. Telus Optik High Speed Turbo Internet is the fancy marketing name for Telus’ VDSL ^[9] internet service. The two services are closely related in that they are delivered into your home over the same physical line. Once that line enters your home, it is connected to a VDSL modem-router combination device, which is responsible for delivering both services to your computers, television set-top boxes (STB) and personal video recorders (PVR).

Currently, Telus uses the Actiontec V1000H ^[10] VDSL Modem Router as the VDSL endpoint device. Because both the IPTV and internet are delivered over the same physical medium, they share bandwidth. One of the V1000H’s main jobs is to manage this sharing so that you can watch high definition TV programs while simultaneously downloading files and surfing the internet. For the most part, the Actiontec does a great job of this sharing as I have not noticed any glitches with the TV while downloading big files.

In addition to being a modem and a router, the V1000H is also a wireless-N WiFi access point. By default, the V1000H’s WLAN is bridged to its (wired) LAN so that they share the same subnet addressing scheme (192.168.1.0/24) and broadcast domain ^[11]. As far as I know, you can’t put the WLAN on a different subnet than the LAN and you can’t change the subnet addressing scheme either (unless, perhaps, you hack the V1000H or put an unsupported firmware on it).

Anyway, as I said at the start of this article, I like Optik TV and Internet but there have been some problems here and there, one of which is IGMP multicast floods.

Why Does IPTV Use IGMP Multicasting?

Like other IPTV services, Telus Optik TV uses IGMP ^[5] multicasting ^[12] to efficiently deliver TV program data, or streams, to your TV. I won’t get into all the technical details here (and I’m over-simplifying things a bit too) but one of the main reasons for using IGMP multicasting is to save bandwidth. For example, if two TVs at the same home are watching the same stream, Telus only has to send the stream once. When the stream arrives at your router, the router then makes a “copy” of the stream and sends it to both TVs using IGMP multicasting.

In practice, I have observed that some (or maybe all?) of these IGMP multicast packets seem to be sent not only to each TV but also every networked device on your home network. This is okay if each device is on your wired LAN because there is lots of bandwidth available there, especially if those devices have gigabit network interfaces. However, it can cause problems on a WLAN, especially for wireless-G devices. Let me explain how I discovered this.

Adding a Second Wireless Access Point to the Telus Optik Network

As I said above, the Actiontec V1000H modem router has a built-in wireless-N wifi access point. For the most part, it does a great job of serving up wireless connections to most parts of my home, especially for wireless-N clients. However, the other day I was using my old wireless-G netbook in a far away corner of my home. Here’s a signal strength graph taken with Wifi Analyzer ^[13] on my Android ^[14] phone:

^[15]

Wifi Signal - One Access Point

The V1000H is located on the west side of my home and the above measurement was taken on the east side, in a corner. That signal strength is good enough for my wife’s wireless-N notebook but it isn’t always good enough for my wireless-G netbook, which is experiencing some slowness and occasional dropouts on wireless connections to that access point. Thankfully, I had an extra wireless router lying around, which I hooked up the other day on the east side of my home to provide stronger signals to wireless clients on that side of my home. Specifically, that router is the Netgear WNR3500L ^[16], running the excellent third party firmware DD-WRT ^[4], version v24-sp2 (08/07/10) mega – build 14896. Here’s the signal strength graph with two access points:

^[17]

Wifi Signal - Two Access Points

The red line represents the signal strength of the new router in the east part of my home. As you can see, the signal is much stronger, which provides a fast connection to my wireless-G netbook when it is in the east side of my home.

As an aside, you may be wondering why I didn’t use WDS ^[18] mode and put both routers on the same SSID ^[19]. First of all, WDS is not always compatible between different models of routers and since the V1000H is essentially a black box ^[20], I don’t think there is any way to get it to work in WDS mode with another model of router. Furthermore, WDS mode can cut your WLAN performance in half ^[21]. Therefore, I decided to go with two separate access points using two different SSIDs.

Notice, however, that I put each access point on a separate non-overlapping ^[22] channel to prevent interference between them. In North America, there are only 3 non-overlapping channels: 1, 6 and 11. If you are going to use multiple access points in your home, make sure you use only these channels and don’t use the same channel twice. In the two access point graph above, I used channels 6 and 11 and you can see that the trailing “tails” of each line do not overlap.

WLAN Performance Problems Due to IGMP Multicast Flooding

At first, my wireless-G netbook experienced great performance on the new WLAN. Here are some ping times between the netbook and the second access point:

Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time<1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.7 ^[23]:
Packets: Sent = 73, Received = 73, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 46ms, Average = 1ms

Wow! 1 ms average ping time and no lost packets! Great! Then I turned on the TV and got terrible wireless performance on my netbook. Here are the ping times on the netbook while watching IPTV:

Reply from 192.168.1.7 ^[23]: bytes=32 time=964ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1833ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=59ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1735ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.1.7 ^[23]: bytes=32 time=1560ms TTL=64
Request timed out.
Reply from 192.168.1.7 ^[23]: bytes=32 time=1950ms TTL=64
Request timed out.
Reply from 192.168.1.7 ^[23]: bytes=32 time=1583ms TTL=64
Request timed out.
Reply from 192.168.1.7 ^[23]: bytes=32 time=1670ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1774ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=58ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=1634ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=2066ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=58ms TTL=64
Reply from 192.168.1.7 ^[23]: bytes=32 time=910ms TTL=64

As you can see, the ping times are very high and there is substantial packet loss! What can account for this? The answer is IGMP multicast flooding ^[24]. The V1000H was sending a whole bunch of IGMP multicast packets to the WNR3500L, which in turn was sending those packets out its wireless interface to all connected wireless clients. The result was complete saturation of the capacity of the wireless interface, despite the strong wifi signal. No wonder the ping results sucked!

Now you may be wondering whether wireless clients connected to the V1000H also suffer from IGMP multicast flooding. I haven’t investigated this yet but I suspect the answer is “no” because my ping times seem fine when connected wirelessly to the V1000H while watching IPTV. I’m not sure how the V1000H prevents this flooding (or if it does at all) but it does warrant further investigation and a future story on NerdBoys.com.

Anyway, the task at hand was to prevent IGMP multicast flooding on the new WLAN I created with the WNR3500L. Flip to the next page to find out how I did it.

There are two approaches ^[25] to blocking IGMP multicast flooding on a WLAN while watching IPTV:

1. Put your WLAN on a separate subnet ^[26] from the wired LAN and block the multicast packets on network layer 3 ^[27], or
2. Put your WLAN on the same subnet as the wired LAN and block the multicast packets on network layer 2 ^[28].

In the first approach, your wired LAN would be on the subnet 192.168.1.0/24 and your WLAN would be on a separate subnet such as 192.186.2.0/24. I won’t go into the details of how to configure your router to do this other than to say you can do it with DD-WRT ^[4] (and probably also with similar third party firmware such as OpenWrt ^[29] and TomatoUSB ^[30]). After configuring these separate subnets, you would block the packets with a layer 2 packet filter (i.e. layer 2 firewall) such as netfilter/iptables ^[31].

In my case, I didn’t want to use separate subnets because I wanted all of my clients, both wired and wireless, to be on the same broadcast domain ^[11]. Having all clients on the same broadcast domain facilitates easier discover of network services such as DLNA ^[32] media server streaming. In my case, I wanted all of my clients on the subnet 192.168.1.0/24, the default subnet used by the Telus’ V1000H firmware. Incidentally, as far as I know, this particular subnet cannot be changed in Telus’ firmware (at least not without some unsupported hacking).

Putting my second WLAN on the same subnet as the V1000H was the easy part. The hard part was figuring out how to block the IGMP multicast traffic on layer 2. Thankfully, after some googling, I discovered ebtables ^[6], which is essentially a layer 2 packet filter (i.e. layer 2 firewall). Some builds of DD-WRT include the ebtables kernel modules and as luck would have it, the build I was using on my Netgear WNR3500L has those modules!

The question is, how do you configure ebtables in DD-WRT so that it blocks IGMP multicast packets? I found most of what I needed on the DD-WRT website. In particular, I will point you to these helpful pages:

• IPTV – blocking multicast on WIFI ^[25]
• Network Share not working via Wireless while blocking IPTV ^[33]
• WNR3500L – Wireless Physical Interface wl0 Not Accessible ^[34]

The first two pages had most of the ebtables-related commands I needed but I had to combine and adapt those solutions because I was getting error messages such as “The kernel doesn’t support a certain ebtables extension, consider recompiling your kernel or insmod the extension.” The third page helped me get the name of the physical wireless interface on my WNR3500L, namely eth1.

Without further ado, here is my script for blocking IGMP multicast packets with ebtables while watching IPTV on the Telus Optik TV network:

insmod ebtables
insmod ebtable_filter
insmod ebt_pkttype
ebtables -A FORWARD -o "eth1" --pkttype-type multicast -j DROP
ebtables -A OUTPUT -o "eth1" --pkttype-type multicast -j DROP

After applying that script to my WNR3500L WLAN, ping times while watching IPTV returned to 1 ms with no packet loss and wireless performance was excellent. To make the script run automatically every time I reboot my WNR3500L, I did the following:

1. Log into the DD-WRT web interface.
2. Click the Administration tab.
3. Click the Commands tab inside the Administration tab.
4. Paste my code into the Commands text box.
5. Click the Save Startup button.

If this how-to article helped you, please leave a comment! Cheers!

Epilog (Bonus Points for the Astute Reader)

I’m sure that the more astute readers out there are wondering whether Telus’s V1000H firmware uses ebtables. The answer is indeed, “yes”, as I discovered by using a back door “trick” to get command line shell access to the Actiontec V1000H (I won’t describe that trick here…). After getting a command line prompt on the V1000H, I ran ebtables -L, which returned this output:

# ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 3, policy: ACCEPT
-p IPv4 –ip-dst 192.168.1.254 –ip-proto 6 –ip-dport 21 -j DROP
-p IPv4 –ip-dst 192.168.1.254 –ip-proto 6 –ip-dport 22 -j DROP
-p IPv4 –ip-dst 192.168.1.254 –ip-proto 6 –ip-dport 53 -j DROP

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

To my utter surprise, the above output apparently contains no rules to block IGMP multicast packets on the V1000H’s WLAN. In fact, the above rules only block layer-2 LAN-side access to FTP (port 21), SSH (port 22) and DNS (port 53) services running on the V1000H. So, if the V1000H does indeed prevent IGMP multicast packets from reaching its WLAN, it doesn’t use ebtables to do it. Rather, I suspect perhaps it uses IGMP snooping ^[35] to figure out which links need multicast streams. If someone out there knows for sure, please enlighten me be leaving a comment!

Astute readers may also be wondering whether it is possible to put your Telus Optik TV PVRs and STBs behind your own router. The answer is a qualified “yes”. Although I don’t currently have my network set up like that, I did try it for a day a few weeks ago and had some success after much trial and error. I may even write a how-to story about it in the near future. For now, all I will say is that I used pfSense ^[36] with IGMP Proxy ^[37]. The details, unfortunately, are a proverbial “exercise for the reader”.

Article Index: