Losing connection

[eschoeller]

It dropped off the face of the planet again.

started server: 16:10
mt-daaped dissapears from itunes: 17:21

I was hoping that the times would be identical, this time it was an hour and 11 minutes.

Short of adding static entries to the avahi dnsconfd service files, what else can I do?

I was not running -d 9 at the time, so I have limited log info.

[rpedde]

@eschoeller wrote:

I was hoping that the times would be identical, this time it was an hour and 11 minutes.

It won’t be. It will depend on how the ttl of the pre-caching announcement that avahi makes, combined with how often the client (or any other client) does a dns-sd query for that machine.

Short of adding static entries to the avahi dnsconfd service files, what else can I do?

Forget short of… that’s the best test. If it sticks when added to statically, then we know the problem is either an avahi-compat problem, or a problem in the eventloop on the rendezvous code on the mt-daapd side.

Either way, it’s a good test.

[eschoeller]

creating a static entry did not resolve the issue.
To be more specific, the service appears in iTunes after mt-daapd is restarted, but if iTunes is closed and re-opened, it does not appear.
Using either the static entry or the one provided by mt-daapd exhibit the same behavior.

I’ve been here before with my last install, it always seems that it is a miracle when mDNS is working reliably.

I believe this means that I still have a networking problem of some sort. I am running mt-daaped within a security context provided by linux-vserver. I realize this inevitably complicates things, but no other services seem to have issues with it, the security context has an interface alias assigned to it but no loopback. Some services need to explicity be told to bind to the alias IP, so they don’t try to bind to 0.0.0.0 or 127.0.0.1.

Any thoughts?

[rpedde]

@eschoeller wrote:

creating a static entry did not resolve the issue.
To be more specific, the service appears in iTunes after mt-daapd is restarted, but if iTunes is closed and re-opened, it does not appear.

That’s unquestionably a firewall issue. What happens is when the server registers, the mdns daemon pre-caches listening mdns clients by announcing startup. The mdns clients resolvers are supposed to cache that announcement. So when iTunes is open and you start mt-daapd, you see the pre-cache announcement.

If you close iTunes and start iTunes, iTunes does an mdns-sd query. If it gets no response from the server, then it shows up nothing.

Since it’s clear the server can send packets (since it shows up when it starts up), it must be that is doesn’t see the mdns-sd query. Usually that’s a firewall issue, since many firewalls forget that 224.0.0.0/4 are local addresses (certainly 224.0.0.0/24 are, anyway).

I’ve been here before with my last install, it always seems that it is a miracle when mDNS is working reliably.

Probably because everyone else uses broadcast resolutions since multicast seems so universally overlooked/broken.

Some services need to explicity be told to bind to the alias IP, so they don’t try to bind to 0.0.0.0 or 127.0.0.1.

I don’t think that’s the case here — it’s sending packets, so the networking can’t be totally broken.

How does the networking work on that? Is the vserver interface a bridged interface, or something like that?

[eschoeller]

It’s basically an interface alias in linux. ie. eth0:1 etc. the virtual server context gets assigned as many aliases as it needs.

I have no firewall rules at all. The default policies for all chains are ACCEPT. There isn’t much else I can do to remove the firewall, unless I recompile the kernel w/o iptables support at all.

In the past I have just run an mdns server on the host O/S, not on the individual virtual server actually running mt-daapd, that worked but was not ideal. I thought maybe this time around i’d finally nail this.

I’m removing netfilter from the kernel completely to see what happens.

[eschoeller]

No Difference after removing the entire netfilter stack from the kernel.

[rpedde]

@eschoeller wrote:

No Difference after removing the entire netfilter stack from the kernel.

I looked around on the vserver mailing lists, and I saw some people talking about problems with multicast, but I didnt’ get a feel for whether it was an old problem, or existing problem, or a fixed problem or if there were workarounds or what.

I saw one post that made it look like it might be possible to get one vserver working with multicast to a particular address, but I wasn’t sure. :/

Might be that the proxy mdns thing is the best answer.

[eschoeller]

Yes, proxy mdns may be a good idea. At some point, when I get around to it, i may speak with bertl on irc.oftc.net (#vserver) about multicast connections for vserver contexts. I am pretty sure at this point that it is a multicast/vserver problem that’s causing the problem here.

For now, I have resulted back to my old method. I’m running howl (mDNSResponder) on the host binded specifically to the IP of the vserver context running mt-daapd, and it’s publishing _daap._tcp.

This works reliably, but when the daap server goes down, howl is still publishing the service. It’s not ideal, but it’s working – now at least I can listen to music while I work on it!

As always, thanks for your help Ron. If I come up with anything I’ll post more comments here.

[Author]

Posts