Share dissapearing after 30 seconds in iTunes

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
    Posts
  • #13034
    rpedde
    Participant

    @kenpem wrote:

    an almost exactly two hours later… <>

    The log looks fine, and the symptoms sound just like what happens when the server doesn’t see mdns requests. Like above, this looks like a firewall or router issue.

    Is the server and client split by a wireless link? Is it possible that the linux box is firewalling multicast (or routing it upstream)?

    #13035
    Anonymous
    Inactive

    In the current test scenario, there is no wireless. The “server” is the FSG-3, and the “client” is my laptop, on a direct cable connection to one of the FSG’s LAN ports.

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


    > iptables -L
    Chain INPUT (policy DROP)
    target prot opt source destination
    DROP all -- 192.168.2.0/24 anywhere
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:smtp
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:pop3s
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:pop3
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:imaps
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:imap2
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:www
    ACCEPT all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    ACCEPT udp -- anywhere 255.255.255.255 udp dpt:5004
    ACCEPT icmp -- anywhere 192.168.1.2
    ACCEPT all -- anywhere 192.168.1.2 state RELATED,ESTABLISHED
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:ssh
    ACCEPT udp -- anywhere anywhere state NEW,RELATED,ESTABLISHED udp dpt:loc-srv
    ACCEPT udp -- anywhere anywhere state NEW,RELATED,ESTABLISHED udp dpts:netbios-ns:netbios-dgm
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:netbios-ssn
    ACCEPT tcp -- anywhere anywhere state NEW,RELATED,ESTABLISHED tcp dpt:microsoft-ds
    DROP all -- anywhere anywhere

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT all -- 192.168.2.0/24 anywhere
    DROP all -- anywhere anywhere

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    >

    the 192.168.2.x subnet is no longer in use, I should probably get it out of there.

    #13036
    Anonymous
    Inactive

    More info…

    Just for a laugh this morning I killed mt-daapd on the FSG, dusted off my old NSLU2 Slug (running uNSLUng), connected it to one of the FSG’s LAN ports, and fired up mt-daapd on the Slug. Music has been playing ever since. Almost eight hours now.

    Music being played on the same laptop, which is still connected to one of the FSG’s LAN ports.

    So now: same version of mt-daapd. Same client software (iTunes 7). Same firewall. If anything, I’ve made the setup worse by doing this. But this music plays on.

    Thoroughly confused! 😯 😕 😥 ❓ ❓ ❓

    #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

Viewing 4 posts - 16 through 19 (of 19 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.