Reply To: Share dissapearing after 30 seconds in iTunes

#13037
rpedde
Participant

@kenpem wrote:

Firewalling multicast? Dunno! Although I would expect that if it was, I wouldn’t get two hours of music first.

Multicast isn’t what transfers the music, multicast is what is used for discovery. It’s what controls whether the “shared music” icon appears. When the server starts, it blasts out multicast stuff to say it’s on the network, so it shows up on iTunes. After the ttl wears off, iTunes queries for it again. If the server doens’t see requests, it won’t answer, and iTunes drops it from the shared list.

That’s why “plays for a while, then disappears” is usually indicative of the server not seeing multicast. It’s usually one of two things — firewall on server, or wireless routers (which are notorious for dorking up multicast) dropping the multicast.

Multicast is generall the 224.0.0.0/4 network, and you’d see a query from 224.0.0.251, dport 5353 udp.


> iptables -L

Hard to tell from here, too many options missing. an “iptables-save” output would be more helpful.

Another decent thing to try (at least for troubleshooting) might be to add a LOG target for your drops on the input chain. Somehting like:

iptables -A INPUT -i -j LOG

so you can log drops sourced from the inside interface to syslog. Unless you are already passing all traffic received on the inside interface.

In the case of same firewall working for the slug, then my next guess would be something that doesn’t *often* happen, but sometimes does on embedded boxes — a driver without good multicast support, so it misses the multicast traffic sent to it. In that case, a cheap solution is to just kick hte interface into promicuous mode:

ifconfig eth0 promisc

If it’s on a switched port, it’s not really a cpu overhead.

– Ron