Through all of Apple's patches for OS X 10.10.3, and the accompanying iOS 8 versions, one core networking service remains problematic, it has been discovered. At the heart of Apple's networking is the "discoveryd" routine, introduced in the latest versions of the OS, which drives how OS X and iOS 8 locates and resolves network connections to other devices. However, the new iteration (replacing a much older service) is causing problems with Bonjour, fouling DNS resolution, and generating a host of other problems for many users, which can in some cases be exacerbated by the number of modern OS X and iOS devices on a network, making it a major problem for Apple faithful.
Don't be afraid of acronyms
First, a bit of history: Discoveryd is a replacement for legacy code in both OS X and iOS network service location and connection. It replaces the relatively ancient mDNSResponder. The older code was originally written for OS X 10.2 Jaguar, and persisted all the way into OS X 10.9 Mavericks. The older mDNSResponder has been open-source for many years, and is more universally compatible with routers due to cross-compatiblity with with uPNP IGD, PCP for IPv6, and Apple's own NAT-PMP.
So, the new Apple code is faster for Apple's purposes, but is also less compatible with uPNP and other router services. Apple network calls to an Apple router negotiates this fine, but screen sharing requests to or from a DiscoveryD machine across the Internet can fail if a third-party router is on either end of the connection -- and that's the mildest symptom of the problem.
Symptomatically speaking
The problem is pervasive with some users, and aggravated by quantities of Apple devices on a network. It may be at the root of the
Apple TV version 3 network spamming, as well as reports of
Thunderbolt displays saturating a network with requests, both of which we've previously reported. It is certainly related to the
Wi-Fi connectivity issues that were more prevalent with initial releases of Yosemite, and persist for some users to this day.
DNS issues induced by the flaw force users to refresh a site that hasn't loaded properly, or at all on both OS X and iOS 8. Networking users with "Wake on LAN" enabled for devices will often see a series of numerically incremented machine names in a network list in the Finder, such as Mac, Mac (1), Mac (2), and so forth. While Apple routers can be the fix screen sharing issues across the Internet, they aggravate this symptom of the problem, so an all-Apple hardware network isn't a universal fix.
With Bonjour, iTunes network or home shares can fail mid-playback, specifically from a discoveryd machine hosting the content to a machine with iTunes running mDNSresponder -- this is common in households with a modern work machine hosting content for a Mac mini connected to a television, or even an Airport Express -- all of which run mDNSresponder at this time.
Even if the OS patches are fixing the problems for some machines, it doesn't always fix them for all. A single affected machine on a network can poison the queue, inducing the issue across the whole network for machines that work fine otherwise. DiscoveryD can also max out CPU usage with some Bonjour tasks. Killing the runaway task doesn't always fix the problem, necessitating a force quit of the offending application, and in some times, a forced reboot.
Not all networks suffer all the listed flaws, making troubleshooting of the issue problematic.
Workarounds, but no reliable fixes
Ars Technica covered a
terminal-based workaround, which installs mDNSresponder in the place of discoveryd. Some users have reported success, and some had no respite from the issue. Regardless, we don't recommend it -- Apple's software update does a number of checks on an operating system before implementing changes, and there may be unintended consequences of tinkering on the system level in such a manner.
Rebooting may or may not fix the problem, as it may be induced by another machine on the local area network. An entire network reboot, ensuring that all Apple devices are powered off simultaneously, fixes the problem for a while, but it is only a matter of time until the problem re-asserts itself if an afflicted machine is on the network.
Not all users were initially affected by the problem, and some users have seen the problem resolve itself with OS patches. Many users afflicted by the problem only see problematic loading of a website periodically -- a refresh loads the page properly, so for them, its a minor issue.
Developer Craig Hockenberry from The Iconfactory highlighted the issue again in a
blog post earlier this week (caution, foul language), clearly announcing that he's still seeing the problem. He says of the issue that "I've wasted many hours just trying to keep my devices talking to each other. Macs that used to go months between restarts were being rebooted weekly. The situation is so bad that I actually feel good when I can just kill discoveryd and toggle the network interface to get back to work."
The problems have been reported since the beginning of OS X Yosemite testing in one form or another, with users like Hockenberry reporting the issues all along.
The non-universality of the issue points to a hardware incompatibility of some sort related to the new code, but our surveying over the last six months doesn't point to a particular model or chipset. However, reports that
MacNN continues to receive indicate that there is still a problem with the Apple-provided code -- how severe it is depends on the user and use cases. The discoveryd flaw isn't seen universally, and as such, may not be a high priority for Apple to completely fix in a timely manner.
-- Mike Wuerthele (
MacNN_Mike)