WiFi Woes with Dan Benjamin
December 9, 2011 at 9:46 AM by Dr. Drang
If you’ve been listening to The Talk Show for the past couple of weeks, you know that Dan Benjamin has been having WiFi connectivity problems with his MacBook Air, which he attributes—justifiably—to a recent Lion update. I’ve had the same problems with my (late 2010 model) MBA, but Lion had nothing to do with it. I’ve written about this problem twice before, but I thought it worthwhile to put everything I know about it together in one post. I was inspired to do so by this morning’s lament from Eddie Smith on Twitter:1
@drdrang And my Wi-Fi woes are back despite leaving BT off. Some things…
@eddie_smith Eddie Smith
The WiFi connectivity problem appears when you open the lid of your MBA and wake it from sleep: it doesn’t connect to your local WiFi network. Dan’s solution, and my current solution, is to turn Bluetooth off. This apparently resolves some conflict between the Bluetooth and WiFi networking software (although obviously not in Eddie’s case).
As I said, Dan attributes this problem to the most recent Lion update. It’s hard to argue with his reasoning: before the update he never had this problem; after the update he always has it. But in my case, Lion isn’t the culprit. I noticed the problem—intermittently, but often enough to be annoyed by it—about a year ago, shortly after I got the Air and long before I had any version of Lion installed on it.
You might be wondering whether my Air had a hardware problem. I didn’t think so, and still don’t, because I could always get connected by turning AirPort off from its menu and then turning it back on again.
Because the failure to connect didn’t happen every time I woke up the Air, and because it always connected when I toggled the AirPort off and on, I concluded that the hardware was fine and that there was some timing conflict in the software.
I lived with this problem for months until I found this discussion on MacRumors, which suggested the WiFi/Bluetooth conflict. I turned Bluetooth off and, like Dan, have never had the problem since.
In my case, turning Bluetooth off was no sacrifice because I almost never have a Bluetooth device linked to my Air. That I had Bluetooth on in the first place was just an old habit from back when I often linked my (pre-iPhone) cell phones to my computers.
In Dan’s case, it’s a huge sacrifice because he’s had to switch to a wired keyboard and mouse. I suspect a lot of people are in the same boat but are less willing to make the switch. Or they may be in Eddie’s position, where turning Bluetooth off wasn’t a permanent fix. For those people, I suggest the following workaround I used in the months before I found the Bluetooth solution.
It’s a short shell script called “Reset AirPort,” and it uses the networksetup command, a Mac-specific utility that seems to mimic the functionality of the Network preference pane in System Preferences.
bash:
1: #!/bin/bash
2:
3: # Toggle AirPort off and on.
4: networksetup -setairportpower en0 off
5: sleep 2
6: networksetup -setairportpower en0 on
The workings of the script are pretty obvious: Line 4 turns AirPort off, Line 5 waits two seconds, and Line 6 turns AirPort back on again. It’s exactly what I used to do through the AirPort menu, but by scripting it I was able to collapse the mousing around and menu selections into a single keyboard combination.
Because I use FastScripts, I saved the script file in ~/Library/Scripts/, where FastScripts can find it, and assigned it a keyboard shortcut of ⌃⌥⌘F12. If you use some other script-launching utility, I’m sure you can adapt it to your needs. If, for example, your utility can’t launch shell scripts directly but can launch AppleScripts, you can get around that limitation by using this AppleScript:
do shell script "networksetup -setairportpower en0 off; sleep 2; networksetup -setairportpower en0 on"
Between these two scripts, you should be able to get Reset AirPort assigned to a keyboard combo some way or another—Keyboard Maestro, LaunchBar, Alfred, Quicksilver, System Services, whatever.
Update 12/9/11
David’s comment below reminded me that I forgot to mention another way to run Reset AirPort. It’s mentioned at the end of my post from last year. There’s a free utility called SleepWatcher from Bernhard Baehr which, if installed as a daemon, will run any script you specify when the computer goes to sleep or wakes up. I have no experience with it (I wanted to know when my Air was failing to connect), but SleepWatcher sounds like a good way to automate the process.
Our old friend Lri points out another matter I left behind in last year’s post: determining the “device name” to provide to networksetup. In the general case, there could be many “Ethernet” devices on your computer—they’ll be assigned the names en0, en1, en2, etc. Strictly speaking, you should run
networksetup -listallhardwareports
to see which one is assigned to AirPort.
As a practical matter, though, I think it highly unlikely that your Air is going to have some other device in the en0 slot. I suspect Lri just wanted to show off his superior grepping skills (which I bow down to).
Finally, a confession of sorts. Since learning about the WiFi/Bluetooth conflict back in July, I hadn’t had Bluetooth on for even a second. So I had absolutely no experience with this problem under Lion. Until this morning, that is, when I figured I ought to check out the problem before publishing this post. I’ve had my Air asleep and awake several times so far, sometimes for just a few seconds, sometimes for half an hour or more. The WiFi has come back on flawlessly every time I woke the machine. Figures.
-
You’ll note that I’m still using my blackbird.py script to embed tweets rather than Twitter’s new supercool embedding code. That’s because Twitter’s code is thoroughly arsed up, a topic I’ll no doubt return to in a later post. ↩
