Firefly disappears when multiple iTunes/macs are used

[cydbjr]

Hi,
I have mt-daapd-svn-1586 running on a FC 4 box. iTunes (on mac) connects to it from machine A across the network (mix of hubs and PlugLink boxes), and all is fine.
When I start iTunes on machine B, C, D or E, all being macs located on different PlugLink nodes, the mt-daapd is “most of the time” not discovered. Further more, iTunes on machine A stops rendering music and looses also the server from its shared music.
If I stop/restart mt-daapd, then it appears on all iTunes currently running. I can play music on all machines, there doesn’t seem to be problem anymore.
But if I start yet another instance of iTunes on another machine, the problem occurs again, on all machines that are currently reaching mt-daapd.
I’m running iTunes 7 on all the macs (4 with 10.4, one with 10.3).
I do have an airport extreme, an airport express, and a Linksys BEFVP41 V2 also on the LAN, but none of the macs go “through” these nodes to reach the mt-daapd. I have disabled the “filter multicast” feature on the BEFVP41, but I think it is related to the firewall from wan to lan.
I have had the same problem with mt-daapd 0.2.4.
There is no firewall rule on the FC4 box.
I have run mt-daapd with -d 9, and see lots of “processing rendezvous message” in the log; yet nothing that looks like an error message or complaint.
When I enable the “share my music” on iTunes, all macs see all other iTunes instance.
Just for the kick, I’ve also started mt-daapd with -m, and then configured mDNSResponder to publish the service; the same problem shows up.
Finally, the problem doesn’t occur every time I start a new instance of iTunes, but pretty much every time. I haven’t figured out a pattern (the macs are all around the house, it’s not easy to do many experiments!).
And unfortunately I didn’t forget to stop mDNSResponder (I just read a post that mentions that and thought it was also my problem, but alas…) 8-(

So in one word: help!

[rpedde]

@cydbjr wrote:

Hi,
I have mt-daapd-svn-1586 running on a FC 4 box. iTunes (on mac) connects to it from machine A across the network (mix of hubs and PlugLink boxes), and all is fine.
When I start iTunes on machine B, C, D or E, all being macs located on different PlugLink nodes, the mt-daapd is “most of the time” not discovered. Further more, iTunes on machine A stops rendering music and looses also the server from its shared music.
If I stop/restart mt-daapd, then it appears on all iTunes currently running. I can play music on all machines, there doesn’t seem to be problem anymore.
But if I start yet another instance of iTunes on another machine, the problem occurs again, on all machines that are currently reaching mt-daapd.
I’m running iTunes 7 on all the macs (4 with 10.4, one with 10.3).
I do have an airport extreme, an airport express, and a Linksys BEFVP41 V2 also on the LAN, but none of the macs go “through” these nodes to reach the mt-daapd. I have disabled the “filter multicast” feature on the BEFVP41, but I think it is related to the firewall from wan to lan.
I have had the same problem with mt-daapd 0.2.4.
There is no firewall rule on the FC4 box.
I have run mt-daapd with -d 9, and see lots of “processing rendezvous message” in the log; yet nothing that looks like an error message or complaint.
When I enable the “share my music” on iTunes, all macs see all other iTunes instance.
Just for the kick, I’ve also started mt-daapd with -m, and then configured mDNSResponder to publish the service; the same problem shows up.
Finally, the problem doesn’t occur every time I start a new instance of iTunes, but pretty much every time. I haven’t figured out a pattern (the macs are all around the house, it’s not easy to do many experiments!).
And unfortunately I didn’t forget to stop mDNSResponder (I just read a post that mentions that and thought it was also my problem, but alas…) 8-(

So in one word: help!

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.

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

[cydbjr]

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.

[rpedde]

@cydbjr wrote:

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.

I use Bonjour Browser on the mac to see what’s registered at any time, or to see what the resolver sees.

Beyond that, I just use ethereal/wireshark to watch traffic to see what’s going on.

[cydbjr]

@rpedde wrote:

I use Bonjour Browser on the mac to see what’s registered at any time, or to see what the resolver sees.

Ok, so I got BB running now. First, mt-daapd is running for a few days now, and I noticed that it has disappeared and reappeared from time to time on 2 machines (but this it not a throurough checking, it is a random check with usual use of iTunes on machines in the house).
On BB, I see 1 “iTunes Music Sharing” from an actual iTunes instance. And indeed I only have one iTunes exporting music right now. The interesting piece of information is that I just ssh’ed to the mt-daapd server, and suddenly in BB the mt-daapd feed appeared in the ‘iTunes Music Sharing”. I started checking out the parameters it exports, and then it disappeared. It was visible in BB for at most a minute.
I was able to reproduce this behavior a few times: I logoff and log back in the mt-daapd server; about 10 sec after ssh’ing into the mt-daapd server, BB will display its feed info for about 40 sec, and then it will disappear again.
I hope that gives you additional clues on what is going on.

[rpedde]

@cydbjr wrote:

@rpedde wrote:

I use Bonjour Browser on the mac to see what’s registered at any time, or to see what the resolver sees.

Ok, so I got BB running now. First, mt-daapd is running for a few days now, and I noticed that it has disappeared and reappeared from time to time on 2 machines (but this it not a throurough checking, it is a random check with usual use of iTunes on machines in the house).
On BB, I see 1 “iTunes Music Sharing” from an actual iTunes instance. And indeed I only have one iTunes exporting music right now. The interesting piece of information is that I just ssh’ed to the mt-daapd server, and suddenly in BB the mt-daapd feed appeared in the ‘iTunes Music Sharing”. I started checking out the parameters it exports, and then it disappeared. It was visible in BB for at most a minute.
I was able to reproduce this behavior a few times: I logoff and log back in the mt-daapd server; about 10 sec after ssh’ing into the mt-daapd server, BB will display its feed info for about 40 sec, and then it will disappear again.
I hope that gives you additional clues on what is going on.

is it possible for the sake of debugging to move the firefly server to a fully wired connection to the rest of the machines?

I’m suspecting an intervening network issue.

[Author]

Posts