And after that, all the problems listed above magically go away. If you're not scared of a little command line hacking, there's a better solution: you can reinstall the OS X 10.9 mDNSResponder on a 10.10 system. However, even this doesn't always work, and restarting discoveryd gets old fast. If discoveryd isn't doing its job properly, sometimes it helps to restart it. As such, if you enable screen sharing on your Mac and try to connect to it from elsewhere on the Internet, your home router doesn't know where to send the incoming request. mDNSResponder supported all of them, but it looks like discoveryd doesn't use any of them. More recently, the IETF has standardized PCP, a new protocol that also works with IPv6 and firewalls, not just IPv4 and Network Address Translation (NAT) as used by home routers. In the non-Apple world, this is done with the uPnP IGD protocol, and Apple had its own NAT-PMP protocol for this. One of the functions of the mDNSResponder was to talk to a home gateway and ask it to forward incoming network connections for any services running on the Mac in question. discoveryd is also a frequent guest in the CrashReporter logs. For instance, when the system is unable to resolve DNS names, discoveryd log messages indicate that it doesn't recognize the replies from the DNS server to its own requests. As per Joel Spolsky's dire warnings against rewriting software from scratch, discoveryd has its share of bugs. And apparently, the responsible people at Apple haven't been reading their Joel on Software. It's not on Apple's list of open source projects. Curiously, discoveryd is (re)written in C++, not exactly one of Apple's favorite languages. mDNSResponder is written in C and has been released as open source by Apple, and it has found its way to all kinds of non-Apple operating systems and hardware.Īgain, as of OS X 10.10, mDNSResponder has been replaced by discoveryd. This was introduced with Mac OS X 10.2 Jaguar back in 2002. Resolving DNS names, resolving Bonjour machine names, resolving Bonjour service advertisement and discovery, and opening ports in NAT gateways to allow incoming network connections are all jobs that have been performed by the mDNSResponder daemon. Again, pre-10.10 this worked fairly reliably, but under 10.10 it's hit-and-miss, with more "miss" than "hit".Īt first blush, you'd assume that these were all separate, smaller problems. In order to connect to that home machine, we have to register its name and services using Wide Area Bonjour/dynamic DNS updates. Very flakey Wide Area Bonjour registration. Under 10.10, this wouldn't work at all over IPv4, only over IPv6. When on the road, we like to share the screen of a home Mac to monitor the progress of ongoing downloads and the like. Impossible to reach services running on a Mac from the outside. Apart from looking bad, this also makes opening network connections and playing iTunes content harder, as you need to connect to the right version of the name or nothing happens. Changing back the computer name in the Sharing pane of the System Preferences usually doesn't take. Under 10.10, this now happens a lot, sometimes getting all the way to nirrti (7). In the pre-10.10 days, once in a blue moon nirrti would rename herself to "nirrti (2)", presumably because it looked like another machine was already using the name "nirrti". We use an old Mac named "nirrti" as a file- and iTunes server. (Command line tools such as nslookup, host, or dig still work because those use their own DNS lookup code.)ĭuplicate machine names. Turns out that the OS X DNS resolver has stopped working. This is rare, but every once in a while, Safari stops loading any and all websites. Here are some strange networking problems we've observed since installing 10.10: But as of OS X 10.10, the mDNSResponder has been replaced with discoveryd, which does the same thing. Hopefully, the set of network issues with OS X 10.10 described below won't fall into this column, but they do raise an obvious question: why?įor 12 years, the mDNSResponder service managed a surprisingly large part of our Mac's networking, and it managed this task well. Obviously, like everyone else, Apple's software has its share of those.īut there's another category of bug-glaring, perplexing bugs that couldn't possibly have escaped the attention of the software engineers in question, let alone the quality assurance department. Such issues exist, and sometimes they go unfixed for months. Anyone with even a passing familiarity with development knows that bugs are par for the course, and most people aren't bothered by small, day-to-day bugs that are fixed within a reasonable timeframe. Recently, there has been a lot of discussion about the current state of Apple's software quality. Further Reading OS X 10.10 Yosemite: The Ars Technica Review
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |