Reply To: Solved: MDNS not working in svn-1696

#16535
skellert
Participant

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???