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:
A multicast capable switch (look for "IGMP snooping" in the datasheet)
An IGMP querier (if your existing router does not act as IGMP querier, you can put a querier service onto your dvbyell machine)
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.
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:
A (multicast capable) IP router checks if it receives multicast traffic for this group on any of its (IP) interfaces and forwards this traffic. Depending on the multicast routing configuration, this might also involve other routers as IP multicast can span several subnets. It might also involve a multicast routing protocol such as PIM. All this is layer 3 (IP) stuff and of no interest in small networks with only one IP subnet.
A (IGMP snooping capable) ethernet switch will also examine this IP packet (yes, it examines layer 3 information although it's actually a layer 2 device, but this is usually only done for IGMP JOIN packets). As soon as it receives such a packet on a specific port, it will forward traffic for the specified multicast group to this port.
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.
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:
xorp (eXtensible Open Router Platform): At first sight this might seem to be an overkill, as xorp supports BGP, OSPF, RIP, PIM etc. However, it will only do the protocols which are explicitely configured, and IGMP querying can be used without enabling all the other cruft, so it's just fine for our purpose. Get it from http://www.xorp.org. Compiling it takes some time but worked without problems for me. For your convinience the dvbyell tarball includes a configuration file which only enables IGMP querying (xorp/config.boot)
mrouted (DVMRP multicast router): This is a rather ancient piece of software (last version released in 1999). You can get it at ftp://ftp.research.att.com/pub/fenner/mrouted/ but you'll need to apply the patch coming with the dvbyell tarball (patches/mrouted-3.9beta3+IOS12+linux.diff) to compile it on a Linux system. One of the problems with mrouted is that it expects more than one network interface or it will refuse to start. You can disable the if block for this check in vif.c (line 114) and recompile it to work around this. If you start it then, it seems to work at first. However, it somehow killed the network connectivity on my machine several times, so I can't really recommend using it. Also note that it apparently is not possible to turn of the DVMRP routing machinery and that mrouted is not open source software.