During the last months T-Online switches more and more T-Home
customers to a new setup that routes the IPTV Traffic via VLAN8.
Since the information on how to do the new setup is scattered
around, many things seem to be wrong, and there are a lots of
questions about the "why", I decided to collect the
information that helped me to setup my network.
While this primarily describes the setup under Linux there is no
reason to believe that implementing the same functionality under
another OS will not succeed.
You need:
From here on I assume that you have all the cabelling done and that you did not do any setup on the needed interfaces yet other than to get them up and running.
To be able to properly seperate and scale traffic, T-Home uses VLANs to manage their traffic. You will have to setup interfaces that use VLAN with the ID 7 and ID 8. How to do this with your specific linux distribution may vary. These are the interface setup files for SuSE 11.1:
ghost:/etc/sysconfig/network # cat ifcfg-vlan7 STARTMODE=onboot ETHERDEVICE=eth1 IPADDR=192.168.3.1/24 ghost:/etc/sysconfig/network # cat ifcfg-vlan8 STARTMODE=onboot ETHERDEVICE=eth1 BOOTPROTO=dhcp
SuSE will setup interfaces as vlan interfaces ontop of others if
they are named vlan* and if they contain an ETHERDEVICE line in
their config. This only works however if you have a
vconfig binary installed, which resides in the package
vlan installable via yast. Other distros will have a
similar named package with the same binary available.
When the need arises, you can also setup a vlan interface by hand:
vconfig set_name_type vlan_plus_vid_no_pad vconfig add eth0 8 ifconfig vlan8 up
This starts a vlan interface named vlan8 on top of the
eht0 interface. Of course you have to substitute this with the
interface you have your VDSL modem connected to!.
If you would like to have another naming scheme like
eth0.8 please refer to the vconfig manpage.
Of course you have to setup the vlan 7 interface the same way too.
The internet will go over the vlan7 interface, so all you have to do is to tell your normal pppoe setup to use the vlan7 device. Since this is written in much details everywhere, I am pretty sure that you will be able to handle this yourself. SuSE 11.1 even offers you a T-Home setup assistent where you just have to enter vlan7.
Note that it is not needed to provide an IP for this interface, just bringing it up is sufficient. However some setup systems do not bring up interfaces without an ip, so chose a static one for this that will not collide with any of your normal LAN.
This is probably the important stuff you have been searching for, and it is also the somewhat most complex part.
The vlan8 interface needs an IP address to properly function, and that IP Address you get by dhcp. So simply running a dhcp client should suffice, shouldn't it?
Unfortunately you also some routes over that interface, since the IP TV Receiver does not only get the multicast TV stream over this interface, but also quite some additional stuff, like its software updates (Windows CE 5.0 if you are curious...), EPG data or some generic settings webpages. All those can only be accessed through the vlan8 interface, since it forms a subnet that is independent from the whole internet. Why they nevertheless use official routable IPs is beyond me, but be it so if they have enough of them.
To be able to also get those routes, your dhcp client must
support rfc 3442 classless static routes options (Option 121).
Since CIDR is implemented for a while now (since 1993) one might
think that this is supported widely, but it isn't. As the time of
writing this, the dhcpcd that is preferred by SuSE
11.1 does not know about this and also cannot be made to understand
it. The dhclient that is also available can be made to
understand it, however SuSE 11.1 does not include the needed
support for it. The support is a combination of a crude hack and
some scripts. Debian and Debian based distros do support it out of
the box, so you can just implement the said configurations (maybe
they are even there in modern versions) and just start dhcp right
away.
To have the dhclient use the option 121, we have to tell it that it
should expose the data in that option, we do that with adding the
following to the /etc/dhclient.conf
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
Then we add this newly created option to the request
block of the config, so that it might look like (depending on your
other settings):
request subnet-mask, broadcast-address, routers,
interface-mtu, host-name, domain-name,
domain-name-servers, nis-domain, nis-servers,
nds-context, nds-servers, nds-tree-name,
netbios-name-servers, netbios-dd-server,
netbios-node-type, netbios-scope, ntp-servers,
rfc3442-classless-static-routes;
Of course the dhclient doesn't know what to do with the data yet, so we have to give some support via scripts. I replaced the SuSE script by the debian one, and patched that a little bit to make it work (debian has some exclusive shell tools that they like to use in their scripts to make them incompatible with LFS based distros). So the following two files will be needed:
/sbin/dhclient-script /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes
Those are the scripts that will transform the route data as
provided from the dhclient (in an array of integers) into an actual
route. If you are intrested, the leases files in /var/lib/dhclient
contain the raw data, so in case you have to debug something you
will find them there.
If everything went ok, the following should show up:
ghost:/tmp # route -n | grep vlan8 217.6.164.42 79.254.251.251 255.255.255.255 UGH 0 0 0 vlan8 194.25.134.197 79.254.251.251 255.255.255.255 UGH 0 0 0 vlan8 217.6.164.45 79.254.251.251 255.255.255.255 UGH 0 0 0 vlan8 194.25.237.4 79.254.251.251 255.255.255.255 UGH 0 0 0 vlan8 217.6.164.40 79.254.251.251 255.255.255.254 UG 0 0 0 vlan8 217.6.164.46 79.254.251.251 255.255.255.254 UG 0 0 0 vlan8 217.6.164.48 79.254.251.251 255.255.255.248 UG 0 0 0 vlan8 217.6.167.128 79.254.251.251 255.255.255.192 UG 0 0 0 vlan8 87.140.255.0 79.254.251.251 255.255.255.128 UG 0 0 0 vlan8 193.158.34.0 79.254.251.251 255.255.254.0 UG 0 0 0 vlan8 79.254.96.0 0.0.0.0 255.255.224.0 U 0 0 0 vlan8 87.141.128.0 79.254.251.251 255.255.128.0 UG 0 0 0 vlan8
79.254.251.251 is my address so in your case you will see a different one. Also in the case you cannot possibly get the dhclient to work properly with the option 121, you can use this list, however it will likely change one day.
I am using igmpproxy 0.1 beta4, however I think that the format of the configuration will be quite stable for a while.
ghost:/usr/local/sbin # cat /etc/igmpproxy.conf quickleave phyint vlan8 upstream ratelimit 0 threshold 1 altnet 217.0.119.0/24 altnet 193.158.35.0/24 altnet 10.0.0.0/8 altnet 239.35.0.0/16 phyint eth0 downstream ratelimit 0 threshold 1 phyint eth1 disabled
First of all you likely want to have the quickleave option enabled, since that means to leave a multicast group as quickly as possible. During zapping this would otherwise quite quickly saturate your line with useless streams.
We setup the vlan8 as the upstream interface, meaning that the multicast streams come from there. For the proxy to be able to properly route the IGMP packets we tell it the subnets that it should consider as valid for routing. Beside the subnet for your internal network (10.0.0.0/8 in my case, your mileage may vary) you want at least to have all the multicast groups there that contain the channels you want to watch. Adding more subnets (even those that you will never see a packet for) doesnt do any harm.
The eth0 is in my case the interface into my LAN, that
is where the IPTV box is. We tell the proxy that this is the
downstream interface. Other than for the upstream, the proxy can
handle multiple downstream interfaces.
All other interfaces that might be present on your system should be disabled so the igmp proxy doesnt try to handle traffic here.
The igmp proxy doesnt only route IGMP packets from one interface to another, it will also establish multicast routes for the kernel so that the multicast packets travel properly from your vlan8 to your internal interface. You should be able to check if it does all this properly by doing:
ghost:~ # ip mroute (193.158.35.14, 239.35.133.11) Iif: vlan8 Oifs: eth0 (193.158.35.222, 239.35.158.200) Iif: vlan8 Oifs: eth0 (193.158.35.158, 239.35.158.200) Iif: vlan8 Oifs: eth0 (10.0.0.30, 239.255.255.250) Iif: vlan8 Oifs: eth0 (10.0.2.243, 239.255.255.250) Iif: vlan8 Oifs: eth0 (10.0.0.22, 239.255.255.250) Iif: vlan8 Oifs: eth0
Of course your mileage again can vary. Unfortunately for linux I wasn't able to find a tool that can change those routes manually.
In case the igmp proxy isn't working (you will most likely notice
this by having the TV freeze after 10 seconds, because the first 10
seconds are sent via TCP not via multicast), starting it with
-d -c -c can reveal useful information.
In case you see something like:
#0: Src: 0.0.0.0, Dst: 239.35.68.11, Age:2, St: I, OutVifs: 0x00000001 #1: Src: 0.0.0.0, Dst: 239.35.203.11, Age:2, St: I, OutVifs: 0x00000001 #2: Src: 10.0.0.22, Dst: 239.255.255.250, Age:2, St: A, OutVifs: 0x00000001
That is, many St: I (inactive) routes then there went
something wrong with the interface the igmp proxy thinks the stream
should come through, so make sure you tell it that its vlan8.
Most likely your firewall isn't configure correctly to play well with the IPTV Multicast setup needed. The best thing, regardless what you enable the is most likely that you do not blindly let it drop packets, but have it log each dropped packet. That way you can see easily what you still need to let through.
There are two things that you need to tell your firewall: Packets it should let through, that is that should be routed. That happens via the FORWARD chain in the filters table. Secondly, you need to masquerade your IP TVs IP, since its not an officially routable one. That is most easily done by letting all the vlan8 packets being masqueraded. So the commands I issue for my setup is:
iptables -t nat -A POSTROUTING -o vlan8 -j MASQUERADE iptables -A FORWARD -s 217.0.119.0/24 -i vlan8 -j ACCEPT iptables -A FORWARD -s 193.158.35.0/23 -i vlan8 -j ACCEPT iptables -A FORWARD -s 87.141.147.0/24 -i vlan8 -j ACCEPT iptables -A FORWARD -s 217.6.167.0/24 -i vlan8 -j ACCEPT
As a watchful reader, you surely already observed that those are both, the multicast IPs and those from the routes that you get via dhcp. I only let through those that I see are needed (because my firwall logs dropped packets) to get some insight on what IPs are for what, however you might want to add all those nets that come in via your route settings (remember that those might be different for you than for me)