- This topic has 6 replies, 2 voices, and was last updated 18 years, 5 months ago by
.
-
Posts
-
I used the .dev of 0.2.4 on a debian linux machine with 2.6.18-k8 kernel.. and on a k7 machine as well. mt-daap starts fine, indexes music and shows up in iTunes. It all works quite well. However, if you let iTunes sit without connecting to the displayed server to get a song listing or play any music from the server.. the listing goes away and will not come back until the server is restarted. If however, you leave the server highlited and the song list from the server active.. the connection stays. Restarting the server and all is well again for a few minutes.
The time seems to vary.. so far I’ve seen about 5 minutes.. and once I saw about 20 mins. An NMAP of the server verifies the port is open and the web admin interface is working. It seems like the server is not announcing itself.. or iTunes is choosing to ignore it. I have iTunes 6.0.4 (3). I have avahi and avahi-howl compatibility packages installed. Anybody know what I’m missing?
@pegmonkey wrote:
The time seems to vary.. so far I’ve seen about 5 minutes.. and once I saw about 20 mins. An NMAP of the server verifies the port is open and the web admin interface is working. It seems like the server is not announcing itself.. or iTunes is choosing to ignore it. I have iTunes 6.0.4 (3). I have avahi and avahi-howl compatibility packages installed. Anybody know what I’m missing?
That’s almost always udp port 5353 to or from 224.0.0.251 being blocked by a firewall. That usually happens because the mdns responder doesn’t see the requests, so it doesn’t respond to queries. So it drops out of the mdns browse lists.
If you stop and restart, it “pre-caches” queries by performing an unsolicited advertisement, which makes it show up in peoples browse lists.
See if your firewall has an option for allowing multicast. That should do it.
— Ron
Thanks for your reply, I greatly apprecriate it. Actually, there are no firewalls, software or otherwise between any of the machines involved. And I have two completely different setups on two completely different networks that behave identically. And after some more observation, it seems to be completely random. For example, today.. both servers are showing up on clients in their respective networks. Sometimes they are there.. sometimes they are not. I’ll keep tabs on it and capture some network traffic and see if I can make some sense out of it. My home network is pretty quiet most of the time.. so I can’t see lost packets being a problem. Sometimes at work on the big network I could see that being problem.. and maybe it could be an apple problem with the client.. (gasp).. 😀
thanks again.
Well, after some actual testing and packet capture.. it does appear to be a problem with the iTunes client. It’s very sparodic about even attempting to look for shared music. When it does, the server dutifully responds.
After some more checking.. and confusing results. I realized my packet capturing would throw the nic on the linux box into promiscuous mode. Thus, all my traffic monitoring was making the nic listen to the port 5353 stuff to 224.0.0.251. So, when I was monitoring, it always worked. Manually sticking the card into promiscuous mode works. So, in my case, it wasn’t a firewall, it was the nic just not accepting traffic that wasn’t addressed to its ip or broadcast range. In this case, iptables rules didn’t help since iptables wasn’t blocking anything to start with. Most linux distros have promiscuous mode disabled by default… I’d prefer not to use promiscuous mode.. I may come up with a workaround.. if I do I’ll post it here.
@pegmonkey wrote:
After some more checking.. and confusing results. I realized my packet capturing would throw the nic on the linux box into promiscuous mode. Thus, all my traffic monitoring was making the nic listen to the port 5353 stuff to 224.0.0.251. So, when I was monitoring, it always worked. Manually sticking the card into promiscuous mode works. So, in my case, it wasn’t a firewall, it was the nic just not accepting traffic that wasn’t addressed to its ip or broadcast range. In this case, iptables rules didn’t help since iptables wasn’t blocking anything to start with. Most linux distros have promiscuous mode disabled by default… I’d prefer not to use promiscuous mode.. I may come up with a workaround.. if I do I’ll post it here.
Aaah.. yeah, I think that’s a card driver thing. Some drivers don’t do multicast. I’ve only ever seen that on the linkstations, though. Do you have a different card you can use?
p.s. — what kind of network card is it? Something borderline supported? Like a sis900 or nforce?
Ethernet controller: National Semiconductor Corporation DP83820 10/100/1000 Ethernet Controller is the one that didn’t work without promiscuous mode. I think that’s the same card I have in the machine on my home network too. I’m trying a Broadcom Corporation BCM4401 100Base-T (rev 01) in it now.. I got digging around and it looks like the only way to hack it to work without promiscuous mode is to hack the drivers.. I don’t know enough about drivers to be able to pull that off. I’ll test out the broadcom and see if it works.
- The forum ‘Setup Issues’ is closed to new topics and replies.