Reply To: Firefly disappears when multiple iTunes/macs are used

#11121
cydbjr
Participant

Thanks for the quick follow-up.

@rpedde wrote:

That’s one of two things:

1. a firewall issue. I think you’ll also find that if you stop the server, then start it, it instantly appears in all the iTunes on the network.

Then if you let it sit for a half hour or so, or wait 15 minutes and start a new iTunes, then it dissappears.

That’s a symptom of having a firewall on the server box that allows outbound traffic, but is blocking inbound traffic from 224.0.0.251 on port 5353 udp.

I’ve see only half of that pattern showing up. I’ve used a single iTune instance yesterday for the whole day, never lost contact with the mt-daapd (actions: played music for ~3 hours, then let iTunes sit idle for another 3 hours, then play music for ~5 hours, then let iTunes sit idle for the rest of the day, then play music the following morning for ~2 hours).
On the other side, I do see the mt-daapd on all iTunes instances if they are already running and I then start mt-daapd. And the server disappears after a short while, maybe 10 or 15 min (but only when multiple instances are running).
There is no firewall on the server running mt-daapd (iptables -t {filter,nat, mangle, raw} -L shows ACCEPT policy for all chains).

@rpedde wrote:

2. Another cause could be something else binding to port 5353. avahi-daemon, or mDNSResponder are likely culprits, but you mentioned stopping mDNSResponder. Check for avahi-daemon.

— Ron

If you watch the log files, I think you’ll see that it never receives any queries

avahi-daemon isn’t running. I see only one process which I don’t know the behavior of: dbus-daemon.
What does a ‘query’ looks like in the log file? When running in -d 9, I see “Status inquiry” and “Processing rendezvous message” lines showing up every ~5 sec.

Do you have any kind of test client I could run on a mac to show rendezvous messages floating on the network. The fact that problems arise only when multiple instances are activated make me feel that it isn’t a firewall issue, but some kind of collision/confusion in the rendezvous protocol.