My new provider Telekom offers TV via multicast (IPTV). They call it Entertain or EntertainTV (which is the newer version). Here is how I got it to work with my Turris Omnia which is attached to a DrayTek Vigor130 VDSL2-Modem. So no provider-supplied hardware involved here. Also, I was not willing to pay a monthly fee for a suitable receiver but I want to watch TV via VLC on my computer. By the way, this guide should work on mostly every OpenWRT-based router. Interface names might be different though.

Here are some prerequisites/a summary:

• Watching TV via multicast within my LAN (e.g. by using VLC), not just from a dedicated Ethernet port on the Turris Omnia (as in some other guides)
• PPPoE via VLAN7
• Entertain / EntertainTV via VLAN8
• eth1 is the WAN-Port

In the advanced administration webinterface (or as we normally call it: LuCI) we add a new network interface (go to Network --> Interfaces --> Add new interface...) to our router.

As shown in the screenshot above, I called it entertain, configured it for DHCP client and, most importantly, configured it to cover VLAN8 on the WAN port (eth1.8).

Next on our list is the firewall. Go to Network --> Firewall and add a new zone.

Basically, the settings are the same as for the WAN zone. Obvious difference here is the name (entertain) and the covered network, which is our entertain network interface we just created. For all other zone-related settings, especially within the category Inter-Zone Forwarding, keep the defaults.

As a last step within LuCI, we need to configure some Traffic Rules for our new firewall zone (go to Network --> Firewall --> Traffic Rules).

As you can see, I allowed DHCP, ICMP echo-requests, IGMP and multicast traffic. You should be able to add these rules with the data visible in the screenshot above. Always be sure to select entertain as source zone and Device (input) as destination zone (at least for the first three rules). The fourth rule has lan as destination zone and the network 224.0.0.0/4 as destination address. As Entertain seems to be IPv4-only at the moment (is it really?) I left out the IPv6 counterparts of the rules shown.

Next, install igmpproxy via System --> Software. Don't forget to enable it in System --> Startup.

Of course, all things done until now could also be done via SSH. To not mess up the configuration, I try to use LuCI as long as it gives me all options necessary to accomplish what I want to do. For the next steps, connect via SSH to your router.

igmpproxy is configured via the files /etc/config/igmpproxy:

config igmpproxy
        option quickleave 1

config phyint entertain
        option network entertain
        option direction upstream
        list altnet 239.0.0.0/8
        list altnet 217.0.119.194/16
        list altnet 193.158.35.0/24
        list altnet 87.141.128.0/17
        list altnet <your LAN network>

config phyint lan
        option network lan
        option direction downstream
        list altnet <your LAN network>

Here, we defined an upstream (our entertain interface) and a downstream (our lan interface) network. Several networks are valid sources for IGMP or multicast packets, including our own LAN network (replace with your IPv4 network you use within your LAN, e.g. 192.168.0.0/24).

In a guide from the guys at IPFire I read that it is recommended to explicitly exclude other interfaces in the igmpproxy configuration. As this seems not to be possible via /etc/config/igmpproxy, I added the following lines at the end of the igmp_header() function in /etc/init.d/igmpproxy:

echo "phyint lo disabled" >> /var/etc/igmpproxy.conf
echo "phyint pppoe-wan disabled" >> /var/etc/igmpproxy.conf
echo "phyint eth1.7 disabled" >> /var/etc/igmpproxy.conf
echo "phyint eth1 disabled" >> /var/etc/igmpproxy.conf
echo "phyint ifb4pppoe-wan disabled" >> /var/etc/igmpproxy.conf

Here you have to see which interfaces are present in your system. Please note that this will probably be overwritten by an update. Do not forget to start igmpproxy afterwards...

Last but not least I enabled igmp_snooping for the lan interface via /etc/config/network. This makes the bridge (br-lan) mutlicast-aware so that packets are not send as broadcasts to your network.

config interface 'lan'
    ...
    option igmp_snooping '1'
    ...

With this configuration I could watch (multicast) TV via VLC with the playlists provided here from my LAN.

My guide is loosely based on this and this and probably some others.

[update]
For multicast to work via WiFi I had to remove the low rates from supported_rates and basic_rate in /etc/config/wireless. I simply removed the lines with the rates 6000, 9000 and 12000 (bit/s it is) for both radios. This should only be a problem if your WiFi links are very bad.

Otherwise, streams were stuttering.

We have a specific use-case where requests to our DNS resolver should be answered dependent on the address of the requesting client. Somehow, unbound was giving me hard time when trying to implement that. After asking for help on the unbound-users mailing list, the necessary configuration got much clearer.

So here is a config snippet (which works) for our use case. There are two networks (sued and west) which unbound is serving. Each of them has a specific tag within the configuration file.

server:
define-tag: "sued west"

Two zones (node.ffhh and knoten.ffhh) are defined which should be handled differently depending on the network from which the request originated. Both tags are assigned to both zones.

local-zone: "node.ffhh." redirect
local-zone-tag: "node.ffhh." "sued west"
local-zone: "knoten.ffhh." redirect
local-zone-tag: "knoten.ffhh." "sued west"

For each tag the corresponding networks are defined (IPv4 and IPv6).

access-control-tag: 10.112.64.0/19 "sued"
access-control-tag: 10.112.96.0/19 "west"
access-control-tag: 2a03:2267:1::/48 "sued"
access-control-tag: 2a03:2267:2::/48 "west"

Afterwards, the ressource records served to the clients in the two networks are defined. This now happens for both zones at the same time, which was a little bit confusing for me at the beginning. So one could say that ressource records are assigned to tags, not to zones.

access-control-tag-data: 10.112.64.0/19 "sued" "AAAA 2a03:2267:1::1"
access-control-tag-data: 10.112.64.0/19 "sued" "A 10.112.64.1"
access-control-tag-data: 10.112.96.0/19 "west" "AAAA 2a03:2267:2::1"
access-control-tag-data: 10.112.96.0/19 "west" "A 10.112.96.1"
access-control-tag-data: 2a03:2267:1::/48 "sued" "AAAA 2a03:2267:1::1"
access-control-tag-data: 2a03:2267:1::/48 "sued" "A 10.112.64.1"
access-control-tag-data: 2a03:2267:2::/48 "west" "AAAA 2a03:2267:2::1"
access-control-tag-data: 2a03:2267:2::/48 "west" "A 10.112.96.1"

Depending on your use case the redirect type at the beginning is not the best choice. Consult the unbound documentation for further types.

AS-Stats is a handy tool to visualize traffic on a per-AS basis. We are making heavy use of it to spot optimization potential regarding traffic from or to our Freifunk Hamburg AS 49009.

In addition to the per-AS graphs showing ingress and egress traffic (separated for IPv4 and IPv6), a graph for each link showing the traffic caused by the top 10 AS (on that link) is generated.

Structure

We use pmacct as IPFIX probe (NetFlow might be a name you already heard) on the routers (which run bird as routing daemon) handling the traffic we want to visualize. For each network interface, a pmacctd instance is run.

Some other host within our AS runs AS-Stats, to which all pmacctd instances are reporting information regarding the traffic sampled by them.

Noteworthy, we let pmacctd do the aggreation per-AS, so that only a counter for egress respective ingress traffic per-AS is sent towards the AS-Stats instance, but no information regarding single flows.

For that pmacct needs to have information regarding the mapping from IP networks to ASs.

pmacct

Probably, it is a good idea to compile pmacct from source (not covered here...).

For each interface you want to monitor in AS-Stats, put a config file with the following content in /etc/pmacct/ (named e.g. pmacct.1.conf).

interface:<ifname>
nfprobe_source_ip:<ipOfPmacctHost>
daemonize:false
promisc:true
snaplen:200
pre_tag_map:/etc/pmacct/pre_tag.map
plugin_buffer_size:10240
plugin_pipe_size:10240000
sampling_rate:128
aggregate:etype,src_as,dst_as,vlan
nfacctd_as_new:file
networks_file:/var/cache/pmacct/netmap.txt
plugins: nfprobe[a]
nfprobe_version[a]:10
nfprobe_receiver[a]:<asstatsIp>:<asstatsPort>
nfprobe_direction[a]:tag
nfprobe_ifindex[a]:tag2

Replace <ifname> with the name of the interface to monitor and choose a source IP (<ipOfPmacctHost>) from which to send the IPFIX packets to AS-Stats, reachable at <asstatsIp>:<asstatsPort>.

The aggregate parameter defines that we want to distinguish traffic by EtherType (0x0800 for IPv4 and 0x86DD for IPv6), by source and destination AS, and by VLAN (if any). For an explanation of the other config parameters see the quite extensive pmacct wiki.

Note: We only sample each 128th packet here to reduce CPU load. Depending on the amount of traffic you are seeing you might want to adapt that value (but this has to be equal to the value configured in AS-Stats).

To map traffic to a certain interface for AS-Stats, pmacct has to add a tag (see parameter pre_tag_map above). We do this depending on the source respective destination mac address of the interfaces we are monitoring.

id=1 filter='ether dst <macInterface1>' jeq=nif1
id=2 filter='ether src <macInterface1>' jeq=nif1
id=1 filter='ether dst <macInterface2>' jeq=nif2
id=2 filter='ether src <macInterface2>' jeq=nif2
!
id2=70  label=nif1
id2=80  label=nif2

Replace the parameters <macInterfaceX> with the mac addresses of the interfaces you are monitoring. Each interfaces has a label (nif1 and nif2 in this case) which lead to a tag with a certain value (70 and 80 in this case).

Note: Due to laziness, we only have one pre_tag_map for all interfaces holding all the mac addresses.

AS-Stats

The corresponding configuration for AS-Stats could look like the following:

<ipOfPmacctHost> 70 link_1 Link 1 ABCDEF  128
<ipOfPmacctHost> 80 link_1 Link 2 FEDCBA  128

Mapping from IP networks to AS

pmacct needs information regarding the mapping of IP networks to AS. For that, the parameter networks_file gives the path to a file holding tuples of AS and network line by line.

We generate that file by the following, very ugly bash script.

#!/bin/bash

/usr/sbin/birdc sh route primary | gawk 'match($0, /AS([0-9]+)/, ary) \
{ print ary[1] "," $1 }' | sort -n > /tmp/.birdout
/usr/sbin/birdc6 sh route primary | gawk 'match($0, /AS([0-9]+)/, ary) \
{ print ary[1] "," $1 }' | sort -n > /tmp/.bird6out

cat /tmp/.birdout > /var/cache/pmacct/netmap.txt
cat /tmp/.bird6out >> /var/cache/pmacct/netmap.txt