Solved: MDNS not working in svn-1696

[skellert]

Edited – the problem was that the NIC needs to be put into promiscuous mode to support multicast

---

I’ve been using svn-1696 on a fedora 7 server since it was released last october. Yesterday, I rebuilt a fedora 8 server and recompiled svn-1696.

The server status page now tells me that Bonjour is stopped. My M1001 doesn’t find the music library any more.

Looking around with google, I’ve seen lots of suggestions, but none have worked for me….

I don’t use avahi-daemon and have never used it (neither on F7 nor on F8)

I’ve added the –enable-mdns switch to the configure prompt (I didn’t compile svn-1696 for F7 using this switch and it DID work, but even with this switch it DOESNT work on F8)

For grins, I compiled using –enable-avahi instead of mdns and I turned on avahi-daemon, and the server status page then said Bonjour WAS running.,, but it the M1001 still couldn’t find the library…. and I DONT want to run avahi-daemon permanently anyway.

Here’s the ./configure line I’m using
./configure –prefix=/usr –sysconfdir=/ –enable-sqlite3 –libdir=/usr/lib –enable-mdns

I have ensured that the firewall is open for address 224.0.0.251 udp 5353 – and in fact I’m using the identical shorewall script on the F8 system as I was successfully using on the prior F7 system.

I couldn’t actually find anything telling me about bonjour and what the various valid configurations are on the wiki…. would it be worthwhile for somebody who knows what they’re saying to add something???

Thanks,
Stefan

[skellert]

I prodded around a little longer….

Firstly, I noted that on my old F7 system, the M1001 was connected via eth0. On the rebuilt F8 system, it is now eth1.

When googling last night, I saw that a new ‘interface’ parameter has been added in the [general] options and I set this to ‘interface = eth1’. So this is a difference with the F7 setup that previously worked.

When I compiled and started firefly last night, it built itself a new database and ran all night. My M1001 couldn’t find the library either last night nor this morning. I rebooted the M1001 several times and same result.

Looking through the firewall logs, I can see multicasts to eth0 being tossed (as they should) but nothing being tossed on eth1 (as it shouldn’t) so I went doing some packet traces to see what was getting sent where…

I ran a wireshark capture on a linux box that WASN’T my firefly server. Then I rebooted the M1001 several times over the space of around 10 minutes. Then I looked at the capture file….

What I saw was the M1001 broadcasting on 255.255.255.255 (why not the local broadcast address??) port 3483 (Slimp3 discovery protocol). There were never any responses from my firefly server.

Still the M1001 couldn’t find the library.

I then ran a tcpdump on the F8 server running firefly and repeated the power cycling of the M1001.

Firstly, the M1001 said it found Firefly on my server. But when I clicked OK to select this library, the M1001 said it failed to connect. I tried this a couple of times, but then it connected OK and was able to play music.

Que??

I looked at the tcpdump I’d taken to see wat went on.

I saw the M1001 multicast out on IP address 224.0.0.251 port 5353 (MDNS query). Within milliseconds, the firefly server responded to 224.0.0.251 port 5353 (MDNS response). The M1001 then opened a TCP connection to the firefly server on port 3689 (daap) about 100ms later which firefly accepted.

I’ve checked the firewall scripts again and BOTH ports 5353 (UDP) and 3689 (TCP) are opened.

Now that I’ve stopped the tcpdumps, the M1001 is again claiming it can’t find the library. 🙁 It looks like something’s firewalled, but I can’t see anything getting tossed in the firewall logs. Its almost like mt-daapd is looking to see if I’m doing a tcpdump and if so, it works, but if not, it doesn’t! Grrrrr.

Does this kind of behaviour ring any bells with anybody???

[skellert]

OK… after exhausting my attempts at configuring the shorewall firewall to make mt-daapd work, I ran the mt-daapd daemon using the -d 9 debugging option.

Every time I do this, it crashes almost immediately with the following messages at the tail of the log file

2008-03-16 17:19:45 (b7f1d6c0): Processing rendezvous message
2008-03-16 17:19:45 (b7f1d6c0): Rendezvous socket closed (daap server crashed?) Aborting.
2008-03-16 17:19:45: Aborting

If I start the daemon WITHOUT the -d 9 flag (as originally), the mt-daapd daemon stays up and running but without bonjour and the M1001 fails to find the library..

Also – If the M1001 is connected to the network and powered on when the mt-daapd daemon starts (without -d 9), then the M1001 does find the library and can connect to it and play songs. If however the M1001 is rebooted (and mt-daapd is NOT restarted), then the M1001 cannot find the library.

What’s going on??

[skellert]

Assuming the firewall is set up OK, then firefly works temporarily with the internal MDNS server under fedora 8 when you strictly follow this procedure.

1) Turn on (or restart) M1001 and connect to LAN

2) Start (or stop and re-start) mt-daapd svn-1696

3) Connect to library and play to your hearts content.

This seems to be good for an hour or two, when the M1001 shudders to a halt and displays the dreaded message that no libraries have been found. Also, if you restart the M1001, it also tells you that it can’t find any libraries. When you stop and restart mt-daapd, it works again for a while.

Here’s a complete dump from the mt-daapd.log file (running debug level 0).

2008-03-16 18:15:26 (b7eee6c0): Firefly Version svn-1696: Starting with debuglevel 0
2008-03-16 18:15:26 (b7eee6c0): Warning: Could not load plugins
2008-03-16 18:15:26 (b7eee6c0): Error opening plugin dir /usr/lib/firefly/plugins. Ignoring
2008-03-16 18:15:26 (b7eee6c0): Plugin loaded: daap/svn-1696
2008-03-16 18:15:26 (b7eee6c0): Plugin loaded: rsp/svn-1696
2008-03-16 18:15:26 (b7eee6c0): Plugin loaded: ssc-script/svn-1696
2008-03-16 18:15:26 (b7eee6c0): Starting rendezvous daemon
2008-03-16 18:15:26 (b7eee6c0): Starting signal handler
2008-03-16 18:15:26 (b7eee6c0): Initializing database
2008-03-16 18:15:28 (b7eee6c0): Starting web server from /usr/share/mt-daapd/admin-root on port 3689
2008-03-16 18:15:28 (b7eee6c0): Registering rendezvous names
2008-03-16 18:15:28 (b7eee6c0): Searching for interface eth1
2008-03-16 18:15:28 (b7eee6c0): Searching for interface eth1
2008-03-16 18:15:28 (b7eee6c0): Searching for interface eth1
2008-03-16 18:15:28 (b7eee6c0): Serving 11438 songs. Startup complete in 2 seconds
2008-03-16 18:15:28 (b7eee6c0): Rescanning database
2008-03-16 18:15:44 (b7eee6c0): Starting playlist scan
2008-03-16 18:15:45 (b7eee6c0): Updating playlists
2008-03-16 18:15:47 (b7eee6c0): Scanned 11438 songs (was 11438) in 19 seconds
2008-03-16 19:39:04 (b74ecb90): Write error: Broken pipe

Ron – contact me at my personal email address if you’d like me to send detailed logs or detailed tcpdump traces. Have you any idea what’s causing me this grief?

Stefan

[skellert]

I seem to be musing a lot to myself in this thread….

My old Fedora 7 server was a slow P3-700. The new fedora 8 server is a VIA Esther 1.5G and so quite a bit faster.

The bizarre result that mdns works OK when tcpdump is running on the same machine, but not ok if tcpdump is not running threw me – but perhaps this is CPU related – with tcpdump running, the cpu is busy writing packets to a file when there’s mutlcast traffc going in and out. This is not the case if tcpdump is not running. On the old computer, the CPU was slower anyway etc etc.

I wonder whether there’s a race happening inside the MDNS code?

This might also explain the bizarre behaviour of different outcomes when running -d 0 and -d 9 debugging… which I didn’t provide a lot of detail about in the previous posts, but believe me, its different.

For grins, I tried a few other releases – eg svn-1586 and 0.2.4.1 – they behaved differently – but still mdns didn’t work. Perhaps there’s been some race condition for a while affecting fedora that I’ve not picked up because my server was so slow in the past??

[mas]

No idea I am since a longer time using avahi. If you contineu to have probelms try this out as well. Not a big deal running the avahi daemon unless your on a very small machine.

[skellert]

No idea I am since a longer time using avahi. If you contineu to have probelms try this out as well. Not a big deal running the avahi daemon unless your on a very small machine.

I did (quickly) try to see if running avahi would ‘fix’ my woes. All I did was start the avahi daemon and compile mt-daapd using the –with-avahi option. I noted that the web status page reported that bonjour was running but the M1001 didn’t find the library. I had a bee in my bonet to work out what was ‘wrong’ with my firewall config – and eventually concluded that there was nothing wrong with it.

I’m presuming that I need to do more than launch the avahi daemon to make it work – eg customise its config file…. In rough terms, what’s required?

Thanks[/quote]

[skellert]

I ended up building another system and configuring it as closely as possible to the first that wasn’t working. Of course, mt-daapd worked fine so I started changing hardware between the two systems until the new one broke and the old one worked….

My ethernet card was the culprit. But why does it work with tcpdump running?

After uber-googling, I discovered that tcpdump puts an ethernet card into promiscuous mode. I also discovered that some ethernet cards don’t recognise multicast UNLESS you manually put them into promiscuous mode. Duh.

The mt-daapd internal mdns then works fine when the card is put into promiscuous mode….

ifconfig eth1 promisc

When the ethernet card is in promiscuous mode, you can do an ifconfig eth1 and you’ll see the PROMISC flag listed. Also, if you do a dmesg | grep eth1, you’ll see the log that the card has been placed into promiscuous mode.

Hope this saves somebody else a week of sleepless nights.

[Anonymous]

Thanks skellert, this thread was really helpful.

I just installed mt-daapd on a FreeBSD box. The shares appear on my Ubuntu client w/o fail using an ethernet connection, but results were variable via wireless; sometimes the server showed up, other times not. Putting the host Atheros wireless NIC in promiscuous mode appears to have solved the problem.

[Author]

Posts