Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > News > Mac News > Feature: Apple's 'discoveryd' failure in Yosemite and iOS 8

Feature: Apple's 'discoveryd' failure in Yosemite and iOS 8
Thread Tools
NewsPoster
MacNN Staff
Join Date: Jul 2012
Status: Offline
Reply With Quote
May 6, 2015, 10:23 AM
 
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)
( Last edited by NewsPoster; May 6, 2015 at 07:17 PM. )
     
GaryDeezy
Fresh-Faced Recruit
Join Date: May 2013
Status: Offline
Reply With Quote
May 6, 2015, 10:53 AM
 
Great article! I've been wondering why my Yosemite server can be seen via uPnP, while my old 10.7.5 server works just fine. Thought it was a router bug. Thanks for taking the time to explain all the mumbojumbo.

THIS is why I continue to read and support MacNN!
     
GaryDeezy
Fresh-Faced Recruit
Join Date: May 2013
Status: Offline
Reply With Quote
May 6, 2015, 10:54 AM
 
Yosemite *can't* be seen...
     
noibs
Fresh-Faced Recruit
Join Date: Jul 2007
Status: Offline
Reply With Quote
May 6, 2015, 11:40 AM
 
I realize that what I'm going to say doesn't apply to everyone. However, I had been having serious discoveryd and networkd related problems since the first release of Yosemite. The problem were related to a home media server (Mac Mini) and three different Apple TVs. I had just about given up hope when everything got fixed for me in 10.10.3. It was the last thing I expected.
     
Charles Martin
Mac Elite
Join Date: Aug 2001
Location: Maitland, FL
Status: Offline
Reply With Quote
May 6, 2015, 11:57 AM
 
noibs: glad to hear your issue finally got resolved. My home setup is uncomplex, so I'm not seeing much of this issue, but there are some related networking failures to do with Instant Hotspot between my Mac and my iPhone (but not at all between iPhone and Wi-Fi iPad) that I'm still investigating. Whether I can lay the blame on discoveryd's door or not, I can't tell yet.
Charles Martin
MacNN Editor
     
panjandrum
Dedicated MacNNer
Join Date: Dec 2004
Location: West Michigan
Status: Offline
Reply With Quote
May 6, 2015, 01:09 PM
 
Wow, this is very interesting. I've been managing a school-network which recently added 90+ iPads (now on iOS 8.3). The school has a total of 8 wifi access points, and the network should be able to *easily* handle the additional iPad load. (Each access point, for example, can handle 30+ MacBooks of various vintages - but all running ML in the particular building, without even the slightest hiccup). However, the iPads continually lose connectivity, and I've been through every possible setting I can think of. It's a real problem in the middle of online-testing; because once the connection is lost the test often has to be restarted (we simply moved all testing back to the laptops and iMacs...). Good to know where the blame lies. (Unfortunately, like many recent Apple updates; this simply makes me wish we never installed the updates in the first place. These the the kinds of problems we used to see, and fully expect to see, in Microsoft updates. Seeing these types of repeated major blunders (how many times can Apple release updates that cause major networking issues? Apparently as infinitely as their address suggests...) in Apple's updates is incredibly disheartening...)
     
SiliconJohn
Fresh-Faced Recruit
Join Date: May 2015
Status: Offline
Reply With Quote
May 6, 2015, 01:50 PM
 
I had this problem consistently in one MacBook Pro yet never having it happen my other (nearly identical) MacBook Pro in the same Time Capsule WiFi network at home, that sits five feet away. I did not want to try replacing discoveryD with mDNSresponder because the inconsistent results means to me that the instructions for doing so are incomplete or we are missing some other piece of information, either way its not reliable.

The affected machine experienced the problem several times a day, every day, would randomly not load webpages or retrieve email, and the cooling fans would become very noisy, presumably running at full speed.

Checking Activity Monitor showed every time that discoveryD was using 90 to 100% CPU.

The fix for me was to run a simple AppleScript from Dr Bob Tech Blog:

http://drbobtechblog.com/discoveryd-fix-for-fan-noise-and-excessive-cpu-usage/

I would run this AppleScript which simply halts and restarts discoveryD, it only takes a few seconds to execute and quit itself and then the machine returns to normal operation (and the fans get quiet after third seconds or so).

Strangely, after a few days of using this script, the machine no longer has the problem at all. I wonder if this is clearing out a corrupted buffer (or similar effect) which takes a bit of time to correct itself. Either way, this works quickly.
     
Charles Martin
Mac Elite
Join Date: Aug 2001
Location: Maitland, FL
Status: Offline
Reply With Quote
May 6, 2015, 02:47 PM
 
Silicon John (and the other commenters here): posts like these are exactly the reason we spend the time digging into the technical deep weeds to try and identify issues like this. Thanks so much for these great and helpful comments.
Charles Martin
MacNN Editor
     
applesean
Fresh-Faced Recruit
Join Date: Oct 2013
Status: Offline
Reply With Quote
May 6, 2015, 11:37 PM
 
It is absurd, and on top of it, Safari STILL cannot read RSS pages!!!
     
[email protected]
Fresh-Faced Recruit
Join Date: Jan 2012
Location: Memphis, TN
Status: Offline
Reply With Quote
May 7, 2015, 12:18 PM
 
Thanks for the article. This explains MANY inconsistent yet painfully frustrating issues. Apple TV /iPhone remote, web browser time outs, etc. thanks, Thanks, THANKS!
Chris L.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 01:36 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,