Lots of ISPs provide their users with an IPTV service, usually done via IPv4 UDP multicasting. This document aims to explain how to make it work for most common scenarios.

When a host wants to start receiving UDP multicast traffic, it needs to subscribe itself to a "UDP multicast group". Control of multicast groups is archived with IGMP protocol. Once a host is subscribed, all the traffic for this group is sent to it using broadcast L2 frames. This detail is important because common bridges just pass all the broadcast traffic to all the ports. So if you use Linux to bridge wireless and wired networks (usual scenario for home LANs) and you subscribe to a multicast group from one of the wired clients, the wireless will be hogged too. Luckily, starting from 2.6.34, the kernel has IGMP snooping feature for the software bridges (disabled by default in OpenWrt) which should prevent unnecessary traffic on ports that were not actually subscribing.

Another important consideration is that multicasting over wireless doesn't usually work as one might expect since it uses the lowest possible bitrate (to enable all clients to "hear" it) and also employs special tricks for power-saving. Basically, this makes multicasting useless for IPTV.

Thanks to IGMP snooping, igmpproxy should no longer cause wifi hogging and so you can have both igmpproxy and udpxy configured and running, accessing IPTV over wifi with udpxy when needed.

If your client is behind NAT, it can't subscribe to multicast directly, so it needs some kind of proxy to do it for him. OpenWrt comes with igmpproxy utility to do that automatically. You need to edit /etc/igmpproxy.conf according to your setup:

quickleave
# eth1 is the WAN interface
# 10.254.0.0/16 is the ip range your ISP sends multicast from
phyint eth1 upstream  ratelimit 0  threshold 1
        altnet 10.254.0.0/16
# br-lan is LAN bridge
phyint br-lan downstream  ratelimit 0  threshold 1

If you're not sure what to specify for altnet, comment it out and look for the igmpproxy output in the log (or on stdout if you start it in debug mode), it'll say something like Warn: The source address 10.254.16.66 for group 233.32.240.222, is not in any valid net for upstream VIF. and so you'll learn the multicast source address for your ISP.

You also need to allow IGMP from wan interface and to forward multicast traffic by something like this:

config rule
        option src      wan
        option proto    igmp
        option target   ACCEPT
config rule
        option src      wan
        option proto    udp
        option dest     lan
        option dest_ip  224.0.0.0/4
        option target   ACCEPT

This is an alternative way which allows you to access udp multicast streams over TCP connection. As such, it works nicely both over wired and wireless links.

You can start it with something like:

#!/bin/sh /etc/rc.common
# Copyright (C) 2010 OpenWrt.org

START=99
STOP=10

IGMP_OPTS="-p 8080 -a 192.168.2.1"
IGMP_BIN="/usr/bin/udpxy"
PID_F="/var/run/udpxy.pid"

start() {
        echo "Starting udpxy"
        start-stop-daemon -S -x $IGMP_BIN -p $PID_F -b -m -- $IGMP_OPTS
}

stop() {
        echo "Stopping udpxy"
        start-stop-daemon -K -x $IGMP_BIN -p $PID_F -q
}

This tells udpxy to use port 8080 to accept http connections and to bind to interface which has 192.168.2.1 address (br-lan in my case).

Now when you want to access e.g. rtp://@239.64.64.58:1234 , you can tell your player to connect to http://192.168.2.1:8080/udp/239.64.64.58:1234 and it'll just work.

As with igmpproxy you need to accept IGMP traffic and also you need to allow it for INPUT:

config rule
        option src      wan
        option proto    igmp
        option target   ACCEPT
config rule
        option src      wan
        option proto    udp
        option dest_ip  224.0.0.0/4
        option target   ACCEPT