Share dissapearing after 30 seconds in iTunes

FireFly Media Server Firefly Media Server Forums Firefly Media Server Setup Issues Share dissapearing after 30 seconds in iTunes

Viewing 10 posts - 1 through 10 (of 19 total)
  • Author
    Posts
  • #1840
    digitalbanana
    Participant

    Hi, just installed mt-daapd. Gotta say, its ace. I have had a NAS for a few years, and only just heard about this…

    Anyways, I have set it up, and it works all apart from the face that the share dissappears after 30 seconds….and is not detected again. I have to restart itunes for the share to appear in the first place.

    I have opened the ports on my NAS (Freecom FSG) as follows:

    iptables -A INPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A OUTPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT
    iptables -A OUTPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT

    This is part of the mt-daapd startup script.

    Why is it only showing for 30 secs and how can I fix it?

    Any help would be appreciated…

    #13020
    rpedde
    Participant

    @digitalbanana wrote:

    iptables -A INPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A OUTPUT -p tcp –dport 3689 -j ACCEPT
    iptables -A INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT
    iptables -A OUTPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT

    I thinks these are not quite right… try:


    iptables -A INPUT -p tcp --dport 3689 - j ACCEPT
    iptables -A INPUT -p udp --dport 5353 -s 224.0.0.215 -j ACCEPT
    iptables -A OUTPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    That will probably work. If you can http to 3689, the first rule is working. If it shows up at all, for any length of time, then the last rule is working. If it disappears at some point after it starts up, then the second rule is broken.

    Your second rule is superfluous, and my third rule is probably superfluous, as from your description of the problem it looks like you aren’t doing egress filtering, or at least not to the hosts on your lan.

    If you can’t get the 3689 by http, because you *are* doing egress filtering, the winning rule would be:


    iptables -A OUTPUT -p tcp --sport 3689 -j ACCEPT

    – Ron

    #13021
    digitalbanana
    Participant

    Thanks for the help, however with your rules it does not show up at all, no matter how many times i restarted iTunes.

    It did resort back to showing for 30 seconds aain when I entered this rule again:

    iptables -A INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    Cheers,

    #13022
    digitalbanana
    Participant

    OK, i have just tried to totally turn off the firewall by doing:

    iptables -P INPUT ACCEPT
    iptables -P OUPUT ACCEPT
    iptables -P FORWARD ACCEPT

    Same happens…it will stream for 30 sec and die. Would this then be an issue with mt-daapd on the server, or a client issue?

    I am using the latest of both: 2.2.4 of mt-daapd and 7.4.2 of itunes.

    Cheers,

    #13023
    rpedde
    Participant

    @digitalbanana wrote:

    Thanks for the help, however with your rules it does not show up at all, no matter how many times i restarted iTunes.

    It did resort back to showing for 30 seconds aain when I entered this rule again:

    iptables -A INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT

    Cheers,

    hrm. Yeah, I guess so. I guess I was thinking that mcast appeared *from* the multicast address, but that’s obviously not right. So yeah, your rule should be the proper rule #2.

    #13024
    rpedde
    Participant

    @digitalbanana wrote:

    OK, i have just tried to totally turn off the firewall by doing:

    iptables -P INPUT ACCEPT
    iptables -P OUPUT ACCEPT
    iptables -P FORWARD ACCEPT

    Same happens…it will stream for 30 sec and die. Would this then be an issue with mt-daapd on the server, or a client issue?

    I am using the latest of both: 2.2.4 of mt-daapd and 7.4.2 of itunes.

    Cheers,

    Then it’s not a firewall issue. It’s probably nic driver on the machine not seeing multicast traffic.

    Try “ifconfig promisc eth0” (or whatever interface), and seeing if that works. If so, it’s a driver issue.

    #13025
    digitalbanana
    Participant

    Entered that command and the same happens, it disappears still.

    Do you think there is incompatibility between the itunes and mt-daapd versions?

    Cheers,

    #13026
    rpedde
    Participant

    @digitalbanana wrote:

    Entered that command and the same happens, it disappears still.

    Do you think there is incompatibility between the itunes and mt-daapd versions?

    Cheers,

    Nope, it’s a multicast issue. That’s how discovery is done. Is it possible you have duplicate names on the network? Like the hostname of your linux box is that same as another machine on the network? Such that the name registration is refused?

    One thing that might be worthwhile would be do make a chain that logs and then drops packets, so you can see dropped packets in syslog. Then make it fail and see if you have any packets canned by the firewall.

    #13027
    digitalbanana
    Participant

    Currentl, and before, the only two boxes in use are this MacBook and the Linux drive, and both are distinctly named. There are no duplicate hostnames on the network according to the router.

    Unfortunately I am not that able with iptables. How would I got about doing the logging and dropping part?

    Cheers,

    #13028
    rpedde
    Participant

    @digitalbanana wrote:

    Currentl, and before, the only two boxes in use are this MacBook and the Linux drive, and both are distinctly named. There are no duplicate hostnames on the network according to the router.

    Unfortunately I am not that able with iptables. How would I got about doing the logging and dropping part?

    Cheers,

    Something like:

    iptables -N logdrop
    iptables -A logdrop -j LOG
    iptables -A logdrop -j DROP

    Then use:

    iptables …blahblahblah.. -j logdrop

    rather than -j DROP

    That way it logs the packet first, then drops it.

    If you have some you don’t want to log (icmp, or windows browser stuff), then just drop that versus logdropping it.

    Or, just before your rules drop off the end (to the default deny), add

    iptables -A INPUT -j LOG

    and they’ll get logged before they drop off the end of the ruleset and get dropped.

    Any of those options would work okay, and let you see what’s getting blocked.

    — Ron

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