Why dvbyell requires multicast

dystreamd uses IP multicast to stream the DVB programs. Using this technique, the TV server only needs to transmit the audio/video streams once. Moreover, only subscribed network devices will receive the streams. I.e. only network paths which are absolutetly required to transport the streams are used, and they are only used once. The intelligence for this lies in the network which means that you require a multicast capable network to take full advantage of dvbyell. If you use one of these $50 SOHO routers with builtin switch, it's very probable that your network is not multicast capable. The same is true for most $20 standalone switches.

But don't be desperate, you might still be able to use dystreamd. However, most SOHO switches will treat Ethernet multicast frames as broadcast (as the destination MAC address is unknown to them). So if you use dystreamd to stream a complete transponder into your network you may end up putting a ~40 MBit/s broadcast load onto it. Depending on your network, this might not be a problem.

What you really need to use dystreamd as designed is:

If your network fulfils these conditions you don't need to read on as there is no special multicast configuration required, just the two points above. If you are interested in details or if you only lack the IGMP querier (which can be run on Linux), keep on reading.

IGMP snooping on ethernet switches

Let's see what happens if a program joins an IP multicast.

First start "tcpdump -v -n -i eth0 igmp". Then start "vlc udp://@239.192.1.1:1234". tcpdump will show something like this:

13:33:52.031769 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto
IGMP (2), length 40, options (RA)) xxx.xxx.xxx.xxx > 224.0.0.22: igmp v3
report, 1 group record(s) [gaddr 239.192.1.1 to_ex, 0 source(s)]
13:33:56.391736 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto
IGMP (2), length 40, options (RA)) xxx.xxx.xxx.xxx > 224.0.0.22: igmp v3
report, 1 group record(s) [gaddr 239.192.1.1 to_ex, 0 source(s)]

This means that your machine wants to join the multicast group "239.192.1.1". Such an "IGMP JOIN" packet has an impact on two devices of your network:

You might wonder how the switch can recognize the multicast traffic as it actually is a layer 2 device and the destination IP address is layer 3 information. The answer is that multicast traffic also has a special destination MAC address. Look at this tcpdump output:

13:54:35.686406 00:1b:fc:20:88:b9 > 01:00:5e:40:01:01, ethertype IPv4
(0x0800), length 1358: xxx.xxx.xxx.xxx.33424 > 239.192.1.1.1234: UDP,
length 1316

01:00:5e:xx:xx:xx are multicast MAC addresses. Use Google for more information on these addresses (it isn't a 1:1 mapping from IP multicast addresses!).

So, this is what "IGMP snooping" is about: An ethernet switch implementing this feature will recognize IGMP JOIN packets, compute the MAC addresses belonging to the subscribed multicast IP addresses and put these MAC addresses into its MAC table. A switch which doesn't do IGMP snooping will broadcast ethernet frames with destination address "01:00:5e:xx:xx:xx", thus flooding the network.

Why an IGMP querier is required

However, this isn't the whole story. For several reasons, an IGMP snooping capable switch will remove the multicast MAC addresses from its MAC table after a certain amount of time. Furthermore, if you start tcpdump and vlc as shown above, you can leave them running for several hours and you'll notice that no IGMP reports are sent after the initial two. This has the effect that a machine subscribed to a multicast group and connected to an IGMP snooping capable switch will receive the multicast traffic for some minutes but then the reception suddenly stops (as the switch has expired the MAC address from its table). To prevent this effect, you'll require an IGMP querier on the network. It will periodically send out IGMP QUERY packets and the multicast subscribers will respond with an IGMP JOIN packet. This packet will again be recognized by the snooping switch which will refresh the MAC table entry and the timeout problem is gone.

If your existing router doesn't support multicast querying, you can put such a service onto the machine which is running the dvbyell service. You have two choices for this: