Q: New Macbook Air - wifi connectivity problems

It didn't start from the first day but I dont' remember when it started.

For some people it started immediately.

For me it now went away. It is a mystery.

The issue with drops has been discussed extensively and I can say I have not read of a final total solution.

In my case it is really strange. My MBA got 'infected' some four months after purchase with a lot of drops.

I had these bad drops up to a month ago, went through Applecare with reboots etc etc and the problem was still there on my office router, fixed elsewhere. Then it gradually got better, almost stopping completely. No drops, just erratic pings (which I monitor but is not a serious problem). 

Then I updated to Mavericks and back it came again. Unpredictable drop frequency, none at all in one hour, then 2-3 in 10 minutes.

Now it is completely gone. It's like a flu and somehow it can get better...makes no sense.

I still notice that the problem happen more when the MBA is connected to the ac charger and/or when the battery is nearly full.

When the battery is under 60/50% and without charger plugged, after a fresh boot, there are NO drops usually..It's really strange...

I can confirm this is happening on Haswell MBP 15' Retinas as well, I've gone through two replacements and it's the same thing exact problem. Judging by the fact the Macbook Air and MacBook Pro use the same chipset / firmware for Wi-fi (Broadcom BCM43xx) it's likely power-management functions causing a problem.

The following (running in terminal) did fix my issue for the time being though:

ping -i 0.2 8.8.8.8 > /dev/null

I created a plist file called "com.servaxnet.wifi-fix.plist" that can be used to automate this at boot:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.servaxnet.wifi-fix</string>
    <key>ProgramArguments</key>
    <array>
        <string>/sbin/ping</string>
        <string>-i</string>
        <string>0.2</string>
        <string>8.8.8.8</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>Nice</key>
    <integer>10</integer>
    <key>KeepAlive</key>
    <false/>
    <key>AbandonProcessGroup</key>
    <true/>
</dict>
</plist>

You can place this file in /Library/LaunchDaemons and then start Terminal and run the following to make it work and launch at boot:

sudo chown root:wheel /Library/LaunchDaemons/com.servaxnet.wifi-fix.plist

Reboot and things should be good to go, you can confirm by starting Terminal and running:

ps aux | grep ping

You SHOULD see something along the lines of:

root               90   0.0  0.0  2437968    600   ??  SNs  11:43PM   0:00.26 /sbin/ping -i 0.2 8.8.8.8

This is more of a workaround for the time being until Apple issues a firmware update to fix this.

Thanks for all the detail.

Seems a real shame that the same happens on the rMBP.  Though did have a look at the threads and it seems there's quite a few unhappy with this gen as well.

Have you tried bootcamp on the rMBP?

andyman2 wrote:

 

Thanks for all the detail.

 

Seems a real shame that the same happens on the rMBP.  Though did have a look at the threads and it seems there's quite a few unhappy with this gen as well.

 

Have you tried bootcamp on the rMBP?

I tried to get Bootcamp working so I could test it inside Windows, but both Windows 7 and Windows 8 ISO's don't boot for some reason.. Windows 8 gets stuck on the Windows 8 Logo and on Windows 7, no mouse or keyboard input. Guessing everything is just too new.

Some clarified instructions.. Since I couldn't edit my old post anymore.

I created a plist file called "com.servaxnet.wifi-fix.plist" that can be used to automate this at boot; after you start Terminal:

sudo nano -w /Library/LaunchDaemons/com.servaxnet.wifi-fix.plist

Enter the following (Copy and Paste):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.servaxnet.wifi-fix</string>
    <key>ProgramArguments</key>
    <array>
        <string>/sbin/ping</string>
        <string>-i</string>
        <string>0.2</string>
        <string>8.8.8.8</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>Nice</key>
    <integer>10</integer>
    <key>KeepAlive</key>
    <false/>
    <key>AbandonProcessGroup</key>
    <true/>
</dict>
</plist>

Press Ctrl+X, Y, and Enter.

Correct permissions on the plist in order for it to work:

sudo chown root:wheel /Library/LaunchDaemons/com.servaxnet.wifi-fix.plist

Reboot and things should be good to go, you can confirm by starting Terminal and running:

ps aux | grep ping

You SHOULD see something along the lines of:

root               90   0.0  0.0  2437968    600   ??  SNs  11:43PM   0:00.26 /sbin/ping -i 0.2 8.8.8.8 

Hello!

With your workaround, no more disconnections?

Surfing and downloading is OK?

I'm still waiting before buying a MBA, and it's been almost 6 months now ;-)

Using this fix for 2 days now, no disconnections.

Thanks for your answer Can you (try to) explain to me what exactly this does?

I know nothing about coding and terminal stuff ^^

That'll help me decide whether to buy my MBA, or wait for the next version now I've already been wainting 6 months

Thanks the the detailed response. I too think its the power management functions. I've managed to avoid any dropped connections using a different method.

In "Energy Saver" under "System Preferences", I set to "Never" the setting to switch off the display - for both battery and power adapter. It seems that the display going off also deactivates the wifi. I haven't had any problems with dropped connections since making this change, and I read that shortening of display life is negligable, so I'm not worried about that, either. Now, when I re-open the lid the connection also re-establishes in a few seconds without issue - that didn't used to happen before.

However, a different problem remains, which is latency/packet drops. That hasn't been resolved, and I have to use an Airlink101 USB wifi adapter when connecting to my home router. Outside of home I've tested in a couple of locations, with basically no latency/packet drops at all.

Thanks

This method didn't work for me.  I turned off all energy saver options as suggested.  Then I ran wireless diagnostics while running a speedtest.  The connection dropped within the first 15 seconds of starting the test.  I'll continue to use my IOGEAR GWU625.

I think there may be more than one problem going on here.  For example, I use a wifi extender in my house which broadcasts on the same channel as the main router - I can't change the channel of the extender, it broadcasts on whichever channel the main router broadcasts on.  I notice that there is significant difference in spped when the extender is on versus when it is off.  It seems there is some sort of interference that the MBA wifi can't tolerate, even though the IOGEAR GWU625 isn't bothered by it at all.  However, the interference is not the full answer, because even with the extender shut off, I experience occasional wifi drops.

Lolokidd wrote:

 

Thanks for your answer Can you (try to) explain to me what exactly this does?

 

I know nothing about coding and terminal stuff ^^

 

That'll help me decide whether to buy my MBA, or wait for the next version now I've already been wainting 6 months

This starts a constant ping (traffic which uses very little bandwidth) in order to keep your Wi-Fi awake and not in power-saving mode, my assumption is that when the broadcom chip tries to save power - that's where your irratic ping and connection drops come from.

khanamok wrote:

 

Thanks the the detailed response. I too think its the power management functions. I've managed to avoid any dropped connections using a different method.

 

In "Energy Saver" under "System Preferences", I set to "Never" the setting to switch off the display - for both battery and power adapter. It seems that the display going off also deactivates the wifi. I haven't had any problems with dropped connections since making this change, and I read that shortening of display life is negligable, so I'm not worried about that, either. Now, when I re-open the lid the connection also re-establishes in a few seconds without issue - that didn't used to happen before.

 

However, a different problem remains, which is latency/packet drops. That hasn't been resolved, and I have to use an Airlink101 USB wifi adapter when connecting to my home router. Outside of home I've tested in a couple of locations, with basically no latency/packet drops at all.

 

Thanks

Try my method, this keeps your Broadcom chip awake and not in power-saving mode. It should completely fix your dropped packets and latency, here is before my fix:

BEFORE:

64 bytes from 4.2.2.1: icmp_seq=1137 ttl=50 time=337.630 ms

64 bytes from 4.2.2.1: icmp_seq=1138 ttl=50 time=76.461 ms

64 bytes from 4.2.2.1: icmp_seq=1139 ttl=50 time=216.259 ms

64 bytes from 4.2.2.1: icmp_seq=1140 ttl=50 time=123.979 ms

64 bytes from 4.2.2.1: icmp_seq=1141 ttl=50 time=378.658 ms

64 bytes from 4.2.2.1: icmp_seq=1142 ttl=50 time=72.328 ms

64 bytes from 4.2.2.1: icmp_seq=1143 ttl=50 time=161.531 ms

64 bytes from 4.2.2.1: icmp_seq=1144 ttl=50 time=76.611 ms

64 bytes from 4.2.2.1: icmp_seq=1145 ttl=50 time=359.237 ms

64 bytes from 4.2.2.1: icmp_seq=1146 ttl=50 time=159.300 ms

64 bytes from 4.2.2.1: icmp_seq=1147 ttl=50 time=171.521 ms

64 bytes from 4.2.2.1: icmp_seq=1148 ttl=50 time=105.632 ms

64 bytes from 4.2.2.1: icmp_seq=1149 ttl=50 time=80.951 ms

64 bytes from 4.2.2.1: icmp_seq=1150 ttl=50 time=169.618 ms

64 bytes from 4.2.2.1: icmp_seq=1151 ttl=50 time=172.226 ms

64 bytes from 4.2.2.1: icmp_seq=1152 ttl=50 time=195.803 ms

64 bytes from 4.2.2.1: icmp_seq=1153 ttl=50 time=92.673 ms

64 bytes from 4.2.2.1: icmp_seq=1154 ttl=50 time=64.236 ms

64 bytes from 4.2.2.1: icmp_seq=1155 ttl=50 time=234.075 ms

64 bytes from 4.2.2.1: icmp_seq=1156 ttl=50 time=196.057 ms

64 bytes from 4.2.2.1: icmp_seq=1157 ttl=50 time=246.046 ms

64 bytes from 4.2.2.1: icmp_seq=1158 ttl=50 time=220.863 ms

64 bytes from 4.2.2.1: icmp_seq=1159 ttl=50 time=69.799 ms

AFTER:

64 bytes from 4.2.2.1: icmp_seq=132 ttl=52 time=62.757 ms

64 bytes from 4.2.2.1: icmp_seq=133 ttl=52 time=58.443 ms

64 bytes from 4.2.2.1: icmp_seq=134 ttl=52 time=57.473 ms

64 bytes from 4.2.2.1: icmp_seq=135 ttl=52 time=58.468 ms

64 bytes from 4.2.2.1: icmp_seq=136 ttl=52 time=57.661 ms

64 bytes from 4.2.2.1: icmp_seq=137 ttl=52 time=60.503 ms

64 bytes from 4.2.2.1: icmp_seq=138 ttl=52 time=62.090 ms

64 bytes from 4.2.2.1: icmp_seq=139 ttl=52 time=66.189 ms

64 bytes from 4.2.2.1: icmp_seq=140 ttl=52 time=60.658 ms

64 bytes from 4.2.2.1: icmp_seq=141 ttl=52 time=61.391 ms

64 bytes from 4.2.2.1: icmp_seq=142 ttl=52 time=60.189 ms

64 bytes from 4.2.2.1: icmp_seq=144 ttl=52 time=61.474 ms

64 bytes from 4.2.2.1: icmp_seq=145 ttl=52 time=57.787 ms

64 bytes from 4.2.2.1: icmp_seq=146 ttl=52 time=61.616 ms

64 bytes from 4.2.2.1: icmp_seq=147 ttl=52 time=59.441 ms

You can test it easily without doing all the fancy plist stuff simply by running this in Terminal:

ping -i 0.2 8.8.8.8 > /dev/null

Open up another terminal tab and run the same test, you will notice your pings are no longer irratic.

This fix has been posted many times before, and we tested it and concluded that it is not a 100% reliable fix while it also means a little battery drain as we checked on the new mavericks task admin.

This fix was supposed to be used when low ping is needed such as in games or voip.

Moreover, at least when I tried it, it only reduced ping but disconnections where still there, i can test this again though.