As a coda to my Macbook Pro wifi network dropping tribulations, I should note that the MBP probably wasn’t to blame for the wifi drops.
I provide this explanation as a bookmark for myself, as I’m sure to need it later, and also as an offering to the robot overlords, since I’m sure someone with a similar problem will eventually land here looking for help.
I’ll start off by saying this: being your own IT shop is very challenging. If you run a home network with multiple devices using it, there could be any number of issues that cause what seems to be a simple, wifi keeps dropping problem.
In my case, I started with the MBP, since all the other devices in my household were fine, and I’d just made a change, i.e. cleaning up old cruft with CleanMyMac.
After the initial failure documented in my previous post, I did a full wipe, a reinstall of Snow Leopard (10.6.8), and another data migration with Migration Assistant. Shortly after that eight-hour process completed, I quickly realized the problem persistented, which debunked my hypothesis that CleanMyMac had inadvertently nuked an old file that was somehow keeping my wifi alive.
I decided to brave the Genius Bar, one of my least favorite things, in a quest to get answers.
Of course, like a car at a mechanic, my MBP stayed connected to the Apple Store wifi just fine as I discussed further options with the Genius, who was a really nice guy, incidentally. Options were few. Basically, nuke the network configuration and add the network again. If that didn’t work, take it in to Best Buy for a network card (or new machine) swap.
Not good.
After some searching, I did find the proper way to get OS X to reset its network configuration. Rename or delete the preferences.plist file, and restart. One thing to note, you can’t modify this file from the Finder. You’ll need to enable the root user, then head to the Terminal and dust off your CLI skills.
This seemed to work, which I verified by pinging Google all night long.
But there was a rub. My wife’s iMac started dropping, as did my Ubuntu laptop, and my TiVo wouldn’t hold an IP address at all, tell-tale signs of a router issue.
Sigh.
Back in July, I had another home IT adventure with a new wifi camera, which prompted the purchase of a new, dual-band router, the Netgear N600 WNDR3400. That router had been functioning just fine for months, so why, all of a sudden, would it go nutty?
After sleeping on this mess, I attacked it today with renewed vigor and solved it. Knock on wood. I’m piecing this together, so this is my best hypothesis of what happened. Could be wrong, so your mileage may vary.
The WNDR3400 is a dual-band router, meaning it has two wireless radios, one using the older 2.4 GHz band and one using the 5.0 GHz band.
Having both is nice. 5.0 Ghz is quite a bit faster (up to 300 mbps), but its range is lower. Plus, older wireless adapters don’t support this band. 2.4 GHz is the old standard and has better range, but this band is polluted with interference from other wireless networks (e.g. your neighbors), microwave ovens, baby monitors, cordless phones, etc.
When I configured the router, I used the same SSID and security on both networks, assuming that newer cards would connect to the faster network. Turns out this is true, which is what caused my problem.
My office is just within the range of the router at 2.4 GHz, which is what my MBP was using until I took it on a trip into my living room, which is in the range of the 5.0 GHz network. The MBP did exactly as expected and connected to the 5.0 GHz network, and that’s when the fun began.
The 5.0 GHz network’s range is smaller, and the MBP’s constant attempts to join the faster network were causing the drops, as it switched between networks. This was transparent to me because they had the same SSID, so I couldn’t tell that it was switching.
Further, I think the constant switching somehow alerted the other devices to the 5.0 GHz network, causing my wife’s iMac to show the same behavior, switching due to signal weakness and causing my TiVo to fail, since it only understands 802.11 b and g, not a or n which the faster network uses.
Another sigh.
After diagnosing this, I renamed the 5.0 GHz network so I can use it on capable devices, but eventually shut it off entirely since none of them are in its range very often.
I’m happily staying connected now, albeit at the slower 54 mbps, but it’s a small price to pay for constant wifi, which is a necessary utility in my house.
Moral of the story, maybe it does just work, it’s tough being your own IT, technology overcomplicates life, look before you leap, etc.
Pick your favorite and go with it.
Yeah, duplicate SSIDs is really asking for trouble. Basically the two radios act as essentially different wireless APs. I keep mine named differently ad join capable devices to /both/, with a preference for the faster one. That way they will try to do the right thing and it will be completely visible to me when it happens.
Sorry you had to experience such frustration but this is often how we learn. 🙂
Makes sense now. When I installed the router, I had a completely different problem to solve, so I flew through the router setup without putting enough thought into it, as is frequently the case w home-IT. This stuff needs to be easier, or maybe I’m just in the wrong business 🙂
So would the problem still occur if the SSIDs were different but the device was still configured to use the fastest available ? The changing SSID would make it more obvious what was happening, but you really want the router to be smart enough to hand the connection over seamlessly.
The devices are configured to do that, i.e. if capable, the network card will join the faster network. That’s what caused my issues. The router doesn’t do any work really; it just broadcasts on both bands and manages the connections. The network card does the switchover work.
The problem was the range difference. Once the network card became aware of a faster network, it tried to connect to it first, but my laptop’s primary position in my office puts it right at the edge of the 5.0 GHz range apparently.
So, it would connect, then drop, iteratively, never defaulting back to the 2.4 GHz bc the 5.0 was ever-so-close.