I've been most unfortunate to see my mid-2012 Macbook Air 11" running Mac OS X 10.8.2 stop properly receiving DHCP leases AND resolving DNS names to IPs.

I know, there is 10.8.5, and Mavericks that is free.. I like 10.8.2, yes, I know what I'm doing. Security argument will be futile. Anyway... :)

What was supposed to be a real day off with no time spent on looking at a monitor, turned into about 9 hours already of trying to pin down the problem, and ultimately solve it.

I think I have enough information to describe the problem unambiguously, but I have no idea whatsoever how to solve it. And the real problem here perhaps is that I use this machine for work, so I'm going to need it by Monday morning EEST lol

That being said, let's dive right in and define the problem, which is that Mac OS X cannot obtain IP address, default gateway and DNS records via DHCP. If AirPort interface is configured manually, DNS resolving does not work. I can still ping WAN, though. If I boot into Recovery mode, EVERYTHING WORKS JUST FINE lol This is a problem only in standard mode of operation of Mac OS X.

Some important points to keep in mind:

  • this Macbook, my dad's Macbook, my Android cellphone and another Linux laptop are all connected to the same router device which ASUS RT-N66U
  • all those devices, including another Macbook Air work just fine, except my Macbook Air
  • disabling AirPort (Wi-Fi) NIC and configuring USB ethernet has the same effect: DHCP and DNS resolution do not work
  • I can see in the logs of the router that the Macbook in question does is being setn DHCPOFFER, and I think I can also see that in tpcdump running on Mac OS X. There is never DHCPACK.
  • I've restarted and shutdown machine a dozen times
  • disabled and re-anbled interfaces both via GUI and cli
  • renamed, deleted and recreated network Locations
  • disabled and enabled DHCP service on the rotuer
  • rebooted and powercycled the router several times
  • changed wireless AP name
  • tried to connect to open access AP in my neighborhood (no luck)
  • made Mac OS X forget the networks in question
  • deleted associated passphrase/password keys from KeyChain utility
  • firewall was never a problem, beyond any shadow of a doubt. This is the machine I intentionally change configuration on as little as possible.. all I want is a reliable computer that works predictably any day of the year, but I still turned it off completely
  • created new administrator user account
  • attempted to troubleshoot from Guest account (same as new admin account, which was the same result, i.e. no luck)
  • booted in Recovery mode, WI-FI WORKS JUST FINE (and it makes me laugh at absurdity of the situation lol)

So, this is what I see in ASUS RT-N66U system log:

...
Nov 16 22:15:34 dnsmasq-dhcp[793]: DHCPDISCOVER(br0) 00:13:77:49:00:be 
Nov 16 22:15:34 dnsmasq-dhcp[793]: DHCPOFFER(br0) 192.168.0.252 00:13:77:49:00:be 
Nov 16 22:15:34 dnsmasq-dhcp[793]: DHCPREQUEST(br0) 192.168.0.252 00:13:77:49:00:be 
Nov 16 22:15:34 dnsmasq-dhcp[793]: DHCPACK(br0) 192.168.0.252 00:13:77:49:00:be sega
Nov 16 22:15:36 WAN Connection: WAN was restored.
Nov 16 22:15:36 notify_rc : start_nat_rules
Nov 16 22:15:37 dnsmasq-dhcp[793]: DHCPDISCOVER(br0) 98:fe:94:45:31:be 
Nov 16 22:15:37 dnsmasq-dhcp[793]: DHCPOFFER(br0) 192.168.0.253 98:fe:94:45:31:be 
Nov 16 22:15:40 dnsmasq-dhcp[793]: DHCPDISCOVER(br0) 98:fe:94:45:31:be 
Nov 16 22:15:40 dnsmasq-dhcp[793]: DHCPOFFER(br0) 192.168.0.253 98:fe:94:45:31:be 
Nov 16 22:15:44 dnsmasq-dhcp[793]: DHCPDISCOVER(br0) 98:fe:94:45:31:be 
Nov 16 22:15:44 dnsmasq-dhcp[793]: DHCPOFFER(br0) 192.168.0.253 98:fe:94:45:31:be 

98:fe:94:45:31:be is MAC address of my AirPort (Wi-Fi) NIC.

This is what I see in Mac OS X

22:15:37.603894 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:15:39.138672 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:15:39.145250 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:15:41.951468 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:15:41.955493 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:15:46.339588 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:15:46.345376 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:15:55.289666 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:15:55.296430 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300

192.168.0.1 is IP address of the ASUS router.

And no, there are no stale DHCP lease files:

shiny:~ root# ls -lah /var/db/dhcpclient/leases/
total 0
drwx------  2 root  wheel    68B Nov 16 13:57 .
drwx------  3 root  wheel   102B Nov 23  2012 ..

This is what happens when I disable AirPort interface and use USB ethernet NIC (00:22:75:d7:09:b3)

22:20:19.707735 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:20:19.713510 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:20:25.212703 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:75:d7:09:b3, length 300
22:20:27.057501 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:75:d7:09:b3, length 300
22:20:28.532392 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:20:28.549107 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:20:29.464039 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:75:d7:09:b3, length 300
22:20:34.121707 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:75:d7:09:b3, length 300
22:20:36.947258 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:20:36.953005 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300
22:20:42.110222 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:22:75:d7:09:b3, length 300
22:20:45.913686 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 98:fe:94:45:31:be, length 300
22:20:46.019007 IP 192.168.0.1.67 > 192.168.0.253.68: BOOTP/DHCP, Reply, length 300

Some troubleshooting in the terminal

shiny:~ root# ifconfig -a
lo0: flags=8049 mtu 16384
    options=3
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
gif0: flags=8010 mtu 1280
stf0: flags=0 mtu 1280
en0: flags=8923 mtu 1500
    ether 98:fe:94:45:31:be 
    media: autoselect ()
    status: inactive
p2p0: flags=8802 mtu 2304
    ether 0a:fe:94:45:31:be 
    media: autoselect
    status: inactive
en2: flags=8863 mtu 1500
    options=4
    ether 00:22:75:d7:09:b3 
    inet6 fe80::222:75ff:fed7:9b3%en2 prefixlen 64 scopeid 0x6 
    inet 192.168.0.199 netmask 0xffffff00 broadcast 192.168.0.255
    media: autoselect (1000baseT )
    status: active
shiny:~ root# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.486 ms
^C
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.486/0.486/0.486/0.000 ms
shiny:~ root# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=59.500 ms
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 59.500/59.500/59.500/0.000 ms
shiny:~ root# scutil --dns
DNS configuration

resolver #1
  nameserver[0] : 192.168.0.1
  reach    : Reachable,Directly Reachable Address

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  nameserver[0] : 192.168.0.1
  if_index : 6 (en2)
  flags    : Scoped
  reach    : Reachable,Directly Reachable Address
shiny:~ root# ping i.ua
ping: cannot resolve i.ua: Unknown host

Okay, let's try Google public DNS service:

shiny:~ root# scutil --dns |grep nameser
  nameserver[0] : 8.8.8.8
  nameserver[0] : 8.8.8.8
shiny:~ root# ping i.ua
ping: cannot resolve i.ua: Unknown host

By the way dig just times out. I can see in tcpdump that it sends a request to 192.168.0.1 (when it is configured as DNS resolver) but nothing else happens.

Other things I've tried

ipconfig set en0|en2 BOOTP
ipconfig set en0|en2 DHCP

dscacheutil -flushcach

echo "add State:/Network/Interface/en0/RefreshConfiguration temporary" | sudo scutil

I've been googling for hours, and maybe it is just my bubble, but I think I've exhausted every sensible option to troubleshoot this problem.

I would rather not reinstall and fix this instead by finding the problem and applying a fix. Unfortunately, people who had gone down this road before me never came back with a success story:

Oh, and as you can see this problem has been around apparently for a very long time. Yet, this is the first and hopefully only time I've encountered it in a year of running this exact setup and version of Mac OS X. I have not applied any combo updates since it was purchased etc. As I said, I intentionally try not to change configuration to ensure that the OS keeps working as it does, because I like everything about it the way it is at this particular version (well, except this really nasty problem).

So, I was hoping somebody might have and idea, or perhaps a solution for this problem? I so not excited about the possibility of applying a combo update or, shivers, reinstalling everything from scratch.

Update

I would like to know why someone downvoted this question. Please, explain.

  • In fact, Mac OS X won't let you use both. It's either Wi-Fi or Ethernet. I tried both when the other was completely disabled/disconnected. The paste just shows the one for Ethernet. It does not matter what interface I use, the problem manifests regardless. – ILIV Nov 17 '13 at 6:26
  • In my tests I set it up manually more than several times only to see exactly the same behavior. – ILIV Nov 17 '13 at 11:28
  • dig @$IP hostname bypasses whatever is written in configuration files. That never worked. – ILIV Nov 17 '13 at 14:02
  • Maybe it was a coincidence, but it happened two times in a row. I pinged a machine on the LAN by using Zeroconf DNS name -- sega.local Immediately connection would drop, then it was reistablished. I tried ping again, and it again reset, and that or something occurring in parallel took me down the rabbit hole. – ILIV Nov 17 '13 at 21:29
  • I'm sorry, I think you're not reading what was written in original question: "this Macbook, my dad's Macbook, my Android cellphone and another Linux laptop are all connected to the same router device which ASUS RT-N66U all those devices, including another Macbook Air work just fine, except my Macbook Air" Just to be clear, another Macbook and Android phone are connected to the same wireless AP. Linux laptop uses ethernet. They all worked WHILE my Macbook couldn't. – ILIV Nov 18 '13 at 8:03

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.