You are here: Home » Topic » mt-daapd-share dropout: Linux-Bridges, Xen & Multicast

mt-daapd-share dropout: Linux-Bridges, Xen & Multicast

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues mt-daapd-share dropout: Linux-Bridges, Xen & Multicast

This topic contains 3 replies, has 2 voices, and was last updated by  MikeyP 10 years, 3 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #1477



    actually I signed up to this forum to whine about the usual: music share dropping out of iTunes and Soundbridge, to be fixed only by a restart of mt-daapd. But after my spamfilter ate the registration emails (only to burp them out again this morning…) I continued looking around the forums and finally found the explanation I needed, to get things going.
    As I have a relatively complicated setup, I thought this might interest some other people as well, so here are my experiences:

    I have a Linux-Box running a Xen Hypervisor. For those not familiar with Xen: Xen is a virtualisation technology. Meaning, I have several Operating Systems running in parallel (only Linux 2.6 in my case). In Xen-Termonilogy there is dom0 which is the system that gets bootet at power on and there are several domUs (the virtual machines) which can be startet from the dom0.
    There are several ways to do networking with Xen. Probably the most common one is to have every domU connected to a virtual interface and then create an ethernet-bridge containing all virtual interfaces plus the physical interface. The dom0 (Host-System) then no longer uses the physical interface (most commonly called “eth0”, in my examples it will be renamed to “gbit”) but the brige itself as its network interface.

    So, back to topic. I experienced dropouts about every half hour. Also, when I restartet iTunes it would not find my daap-share until I restartet mt-daapd. My firewall on the Linux-Box allows for far more connections than neccessary, so that couldn’t have been the issue. I used tcpdump (a command-line network packet sniffer. GUI-Fans use Ethereal/Wireshark) to try and track down what was happening on my Linux box.
    tcpdump showed me that whenever I restartet mt-daapd Packets were sent from my linux box to the multicast address. Thus, I assumed that multicast was working and was thinkin about scrapping everything until I stumbled upon a post by rpedde that explained it all. I can’t remember which thread the post was in, so I’ll repeat in short what is happening:

    When mt-daapd starts up it announces itself by sending multicast-packets (destination address:, Port 5353 UDP) to the network. Computers running iTunes or other daap-capable audio players (or the Soundbridge for that matter) recieve these pakets and then show the daap-share. However there is a timeout to these shares. About half an hour the players have to refresh their knowledge about all the daap-shares on the network – which is done by sending a multicast-packet to which is then recieved and acknowledged by mt-daapd. If the players recieve no such acknowledgement they assume that there is no daap-share and one gets a share dropping out.

    So, I saw packets from the server to multicast but no packets from other computers to multicast. A little more digging and asking around brought the solution: A Linux bridge basically acts as a Switch between all the interfaces connected to it. However it is not as intelligent as a real hardware-switch – Multicast-Routing doesn’t neccessarily work. The trick is to set the “ALLMULTI”-Flag on the physical interface (and maybe the bridge as well – I’m enjoying my working setup too much to fiddle around and break it just to test what flags I can safely remove). This tells Linux to forward all Multicast-Packets to the bridge instead of just those that the physical interface subscribed for (which are none, as the system acts on the bridge, not the physical interface).

    So, now I have mt-daapd and my Soundbridge working like a charm. Maybe this will be helpful to others 🙂

    Two additional things I’d like to mention:
    – There is a broken link in the FAQ. It is supposed to link to a thread where the dropout-issue is covered in more detail. Applying the obvious fix (inserting a / between … and index.something) only sends me to the firefly homepage, not a forum thread.
    – Maybe this stuff about how Multicast Packets are send from every host should go into the FAQ?




    what a life-saver… thank you for posting.



    great stuff. thank you. for a day or two of droppage woes i started to despise ssh. no longer! as for this info going in the faq…i vote yes.



    Thanks for posting this, as I was going to report the same thing. I couldn’t for the life of me figure out why I stopped having stable mt-daapd connections after a power outage and system restart.

    For me to have stable connections to mt-daapd running on my linux box with avahi, I must run the following command:

    ifconfig eth1 allmulti

    (where my primary network adapter is eth1, and I have a multicast route enabled).

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.