OS X Yosemite Wi-Fi problems – can you help us solve them?

If you’re a Mac user, you’re probably thinking of updating to OS X 10.10, better known as Yosemite.

In fact, many of you will have updated already.

But even if you don’t have a Mac, or are sticking with the five-year-old Snow Leopard release (OS X 10.6) for legacy reasons, you may have seen or heard the growing disquiet about Yosemite and Wi-Fi.

Like me, you may even be affected.

No-one seems to know what’s wrong, and without a scientific explanation it’s hard to know where to lay the blame.

Yosemite itself could have introduced a bug; or your hardware might be affected by a reliability problem that simply didn’t show up before; or some third-party software might be revealing a latent flaw.

Wi-Fi symptoms

The symptoms are varied, but the most commonly reported problem is pretty much what I’ve experienced since first rebooting into OS X 10.10 and going online wirelessly.

Your network works fine for a while, typically between about 30 seconds and five minutes, and then fairly abruptly begins to suffer almost total traffic loss.

The network shows up as active, and low-level packets such as PINGs can be sent and received as normal.

But traffic such as UDP and TCP just doesn’t get through.

So you can’t use DNS (the Domain Name System that tells you sophos.com is actually at 31.222.175.174), and even if you knew Sophos’s IP number already, you wouldn’t be able to connect to it anyway.

User forums and Apple’s own Support Community have plenty of discussion of this issue, and numerous proposed “fixes”.

The problem with these fixes is that it’s hard to be scientific when you don’t have any information about what has changed, and what might be the cause.

So far, many of us seem to be grasping at straws, following a support technician’s worse nightmare of logic: post hoc ergo propter hoc.

That’s Latin for “X happened after Y, therefore Y caused X,” and put in those terms, it’s clearly a misleading and risky form of reasoning.

What we know

All we know is that for those of us who are affected:

1. Wi-Fi network meltdowns happen repeatedly.
2. Meltdowns don’t seem to recover on their own.
3. You rarely get more than about three minutes between meltdowns.
4. No such symptoms were observed before updating to Yosemite.

“Fixes” that I’ve seen include: forgetting all your Wi-Fi networks and entering your password again; using the 2.4GHz range only and avoiding 5GHz; turning off Bluetooth; and even wiping your disk and reinstalling Yosemite afresh from a USB key.

But removing all my networks and starting over was my first reaction (it didn’t help), I never have Bluetooth turned on, I’m not using 5GHz on my access point, and others have done complete reinstalls to no avail.

A few people have reported, “Hey, that fixed it for me” in each case, but almost none of them mentioned how long they waited to see if the trouble would return.

Indeed, many of them seem to have proclaimed success very quickly after making the change, so they may have spoken too soon.

Occasionally my network will stay up for close to 10 minutes, which feels like success if you’re used to getting cut off every three minutes or so.

But even if 10 minutes of uptime feels like a good result, it still counts as failure compared to how things were under Mavericks, with Wi-Fi connections lasting flawlessly all day (and night) long.

Can you help?

We’re not going to blame Yosemite yet, but we are turning to the Naked Security community for fixes, workarounds or even bodges.

But not just any old bodge: you have to come up with a plausible explanation of why you think it works, and why other people should try it.

I’ll open the batting with my effort, which is by no means a fix, and isn’t even a workaround: it really is a bodge, plain and simple.

I’m a hacked-together shell script, run with root privilege using the sudo command.

You can click on the image below for a text version to copy-and-paste to use yourself:

All it does is try a DNS lookup every five seconds, and turn the Wi-Fi Network rapidly off and back on if no reply is received within three seconds.

Simply explained:

• The dig +tries=1 +time=3 command does the lookup, waiting 3 seconds for an answer.
• The grep and cut commands extract some handy feedback (the time taken if the DNS request succeeds).
• ${PIPESTATUS[0]} is the return code of the first command (dig) in the pipeline above, which will be non-zero if there was an error.
• The ifconfig down/up commands force the Wi-Fi network to reconnect.
• The device name en0 is the Wi-Fi network card on my Mac.
• The sleep 5 takes a 5-second break before trying again.

When the Wi-Fi network re-connects, traffic flows again until the next meltdown.

I decided on a 3-second DNS timeout because a quick experiment showed that my successful DNS requests never seem to take more than two seconds, even using a cellular connection, and are typically 5 to 10 times quicker than that.

I chose the 5-second sleep as a reasonable compromise between the amount of “keep alive” traffic I’m generating and the longest outage I can have.

I can’t explain why the network fails only until it is brought up again, nor why it then recovers almost immediately and almost every time.

So this really is a bodge, on a par with that old support favourite, “Have you tried rebooting?”

But the script above has been keeping me online automatically for a sufficiently high proportion of the time to give me a usable internet connection. (I posted this article successfully despite a Bounced en0 message every 3 minutes or so.)

It certainly beats using the mouse to keep turning Wi-fi off and back on, which does the trick for me as well.

What’s your bodge?

Update (2015-01-28T01:07:00Z)

According to Apple the OS X Yosemite 10.10.2 Combo Update includes a resolution for Yosemite’s Wi-Fi disconnection issues.

PS. Criticise me all you like for putting form before function, but I’m not restoring my Mavericks backup. Not yet, anyway. I love the new look, I’m not having any other problems, and my Wi-Fi bodge is holding the fort for the time being.