avahi-daemon and incrementing Apple device names

For a long time on my network I noticed my various Apple devices incrementing their hostname (specifically the name advertised with mDNS/mdns-sd – as appears in the ‘Sharing’ section of ‘System Preferences’). I lazily put this down to a poorly configured (by me) WLC and/or avahi-daemon running on my FreeBSD NAS and moved on to bigger problems.

My recent purchase of an AppleTV and it’s placement on a different subnet to my wireless clients (iPhones, etc.) meant getting cross-subnet mDNS working, and so I started playing with the WLC, the Avahi daemon, as well the mDNS service routing on my Cisco 1941.

Hoping the Cisco IOS router would solve everything I removed all of the interesting mDNS configuration from the WLC, stopped the avahi-daemon, and concentrated on getting the router mDNS service working. After much Googling and perusal of configuration guides and CiscoLive! PDFs I applied what I thought was an appropriate configuration. Unfortunately the implementation proved to be quite buggy (although it appeared to have potential). I may revisit it with a newer IOS and some spare time.

Something common to Cisco’s IOS implementation of an mDNS cache and avahi-daemon (and possibly mDNS on the WLC) is that they can act as mDNS advertisement caches, responding on behalf of hosts on subnets other than that on which the request arrived (I assume they ignore requests seen on the same interface as the searched-for service/hosts). Cisco also mention that cache interaction with Apple’s sleep proxies can behave badly and helpfully describe how to block the sleep proxy mDNS service advertisements into the cache.

Another common feature is mDNS relaying across subnets, whereby advertisements and requests are simply forwarded across participating interface. In a CiscoLive! presentation Cisco warns against implementing this – I guess to avoid good-old broadcast loops should a second relay be present. Who knows whether IP TTL would even help here).

Back to the incrementing hostnames. While watching avahi-browse -a, tcpdump, and repeated restarts of the AppleTV I noticed a reliable +1 to the AppleTV Airpay name (per restart). Interestingly was that avahi-browse was not showing any withdrawal of the AppleTV’s services as it shutdown. So when it came back up it checked whether any other device was using the proposed name, to which request avahi-daemon helpfully replied. Of course, the AppleTV had to choose a different name, and incremented it by one.

The answer was to disable the cache, effectively limited the cache’s size to zero. The line “cache-entries-max=0” in the configuration file and a restart was all that was needed. Turning on the relaying with “enable-reflector=yes” and I was off the races.

A couple of notes:
the avahi-browse command only talks to the avahi-daemon, and only via DBUS, so if the daemon has yet to start, or it’s configured with “enable-dbus=no” avahi-browse will be useless
all of my devices talk happily to each other, although I had a couple of quirks. 1) I could not get my Mac and the AppleTV to pair using Apple Configurator 2 – I would be prompted with a password to enter into the Mac and once entered the AppleTV would say it was paired, but the Mac would time out with a “pairing failed (49)” error. Though it irked me so, I gave up and associated my Mac with the SSID on the same vLAN as the AppleTV and instantly they paired. Upon moving my Mac back to original vLAN the pairing remained. 2) sometimes the remote function on my iPhoneXS would allow gestures to control the AppleTV, but none of the buttons worked – sometimes that behaviour was reversed. I have no idea what caused/fixed it.

This entry was posted in Uncategorized and tagged . Bookmark the permalink.