I dropped into a Starbucks this afternoon, all prepared to get some emails written and to get some work done between my Sunday afternoon and evening commitments. Everything was fresh in my mind and ready to go via the keyboard and onto the screen. I fetched my grande two-pump sugar-free vanilla skinny latte and sat down in the chair, opened the laptop and watched it wake up and connect to the AT&T wireless access point.
But much to my dismay nothing would load over the network. The AirPort icon in the status bar showed the name of the network and indicated that I was connected to the access point, but I had no connection to the Internet.
After a brief bit of trying over and over to load a web page, I checked the network preferences in the apple system preferences panel and found that I was not getting an IP address. The Mac was self-assigning a 169.* address, which is a non-routable local-only address. I tried restarting the AirPort card in the Mac, but that didn’t help. I then found I was able to connect normally with my iPhone to the AT&T WiFi network and get a “real” IP address (192.x), so I quickly deduced that something was wrong with my Mac.
I had to give up on troubleshooting and head back out into the world, but I spent the rest of the day wondering if maybe there was something about the MAC address for my wireless card that AT&T had chosen to hate. After finishing my day of activities, I drove home this evening and fired my laptop back up. It connected to my home wireless network. But again, no IP address assigned. Hmm, definitely the laptop.
I started thinking now. What could be happening? Powering the AirPort on and off, shutting down the Mac and powering it back up, manually telling the network stack to renew it’s DHCP lease – all these things did no good.
I finally decided to take a look at the Mac firewall logs. You’d think that would be the first place I’d look, being a security guy. They’re kind of hidden in plain sight, a few layers deep in the Mac’s preferences dialogs. You go to the System Preferences panel, in the Security section, then the Firewall tab, then click the Advanced button, and finally click the Open Log button. If logging isn’t already turned on, you can enable it there, as well.
Sure enough, I looked in the log and found several examples of this (emphasis mine):
Feb 8 23:02:04 greg-hughess-macbook-air Firewall: Deny configd data in from 192.168.0.1:67 uid = 0 proto=17
Feb 8 23:02:26: — last message repeated 2 times —
Ah hah… apparently the firewall was refusing inbound connections initiated by the router as it tried to set up the DHCP address being requested by the laptop. The configd daemon is a service that handles configuration changes for various pieces of the system, mostly all network-related. Great, I had something to fix!
I first confirmed configd was in fact running, then deleted the firewall configuration file (located at /Library/Preferences/com.apple.alf.plist) and configured the firewall to temporarily allow all connections, and then back to allowing essential services. Sure enough, as soon as I made the changes the Mac was able to get a DHCP address from the router, and the network was back up and working.
I have no real idea how the firewall got messed up. At one point I had it set to configure access for specific services and apps, so that might have had something to do with it. But it’s strange that this problem only started today. It’s possible the configd process was denied by a rule, I suppose. Perhaps I hit a key on a pop-up dialog to deny firewall access to the daemon without even realizing it while typing?
At any rate, it seems to be working now (as evidenced by the fact that I am able to post this blog entry, of course) and hopefully it will continue to work as expected. Maybe this will help someone else troubleshoot a similar issue.