Q: New Macbook Air - wifi connectivity problems

It seems that the orginal for this thread is becoming confused.

The initial problem is that many 2013 Macbook Airs regularly drop their wifi connection using the original .22 wifi driver. Many Macbook Airs worked flawlessly and didn't have a wifi problem.

Mac put out an update supposedly to fix the problem. The fix was a "fudge" with the computer recognising the wifi had dropped out and the update told the computer to reconnect. The fix did not address the orginal problem of the wifi dropping out.

In introducing this "fix" Apple created a futher problem of latency, identified and very well explained by headcase who has made a major contribution to this thread. Latency is identified by looking at the ping times.

The update has been included in the latest Mac OS update. Does this mean that now all new Macbook Airs have latency problems instead of the previous situation in which only some Macbook Airs had disconnection problems?

Newcomers to this thread may think that the latency issue is the fundamental problem, we need to make sure that the orginal problem is not forgotten.

We can assume that rolling back to the orginal .22 driver will fix the new latency problem but will return us to some Macbook Airs having disconnection problems.

It is highly probable that Apple are struggling to find a solution.

It is not plug n play as I downloaded the driver off their website. But the install was relatively painless.

Anorax1 wrote:

 

It is not plug n play as I downloaded the driver off their website. But the install was relatively painless.

Which one do you mainly use?  The stock or the IOGear?

IOGear. Stable pings, solid connection, and doesn't do the disconnect/reconnect dance every 20 minutes like the built-in Broadcom chip in the MBA.

I just read your post about your recent success using IOGear's USB WIFI device -- good pings, connectivity, etc. (I can't find your original message, although it came to my email). Please could you tell us which version of the OS (10.8.4? or 10.8.5? with the 'supplement' or not?) and the MBA WIFI driver you are currently using with the IOGear? These details might help some people who are trying to figure out what to do until the Apple fix for the chip or software appears. Thank you very much. (PS I note that the supplement put out to tweak 10.8.5 several days ago includes something designed for Bluetooth issues, if I recall correctly.)

This is a link to my original post:

https://discussions.apple.com/message/23148902#23148902

I am using the latest IOGear driver v2.0.1 from here:

http://www.iogear.com/support/dm/driver/GWU625#display

I am using the latest OS X 10.8.5 with the supplement that was released a couple of days ago.

Please note the IOGear solution works for my environment (at my work and home using Draytek routers and an Airport Express). I cannot guarantee the IOGear will work perfectly with every router. Having said that it has performed flawlessly.

Purchased the IOGear wireless N USB device and can confirm that the results (at least from a Ping test perspective) is much better and more stable than the built in wifi

Results, which is in line with the results Anorax1 posted previously

IOGear

PING 192.168.1.254 (192.168.1.254): 56 data bytes

64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.338 ms

64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.282 ms

64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=1.553 ms

64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.205 ms

64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=1.801 ms

64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=1.182 ms

64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=1.532 ms

64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=1.195 ms

64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=2.860 ms

64 bytes from 192.168.1.254: icmp_seq=9 ttl=64 time=1.333 ms

64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=1.194 ms

64 bytes from 192.168.1.254: icmp_seq=11 ttl=64 time=2.393 ms

64 bytes from 192.168.1.254: icmp_seq=12 ttl=64 time=1.383 ms

64 bytes from 192.168.1.254: icmp_seq=13 ttl=64 time=1.660 ms

64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=1.683 ms

64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=5.154 ms

64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=1.475 ms

64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=1.711 ms

64 bytes from 192.168.1.254: icmp_seq=18 ttl=64 time=1.481 ms

64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=2.723 ms

Built in

PING 192.168.1.254 (192.168.1.254): 56 data bytes

64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.227 ms

64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=1.364 ms

64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=27.872 ms

64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=1.229 ms

64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=4.781 ms

64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=1.390 ms

64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=17.070 ms

64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=39.778 ms

64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=67.669 ms

64 bytes from 192.168.1.254: icmp_seq=9 ttl=64 time=70.245 ms

64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=5.908 ms

64 bytes from 192.168.1.254: icmp_seq=11 ttl=64 time=6.577 ms

64 bytes from 192.168.1.254: icmp_seq=12 ttl=64 time=51.708 ms

64 bytes from 192.168.1.254: icmp_seq=13 ttl=64 time=74.441 ms

64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=102.199 ms

Request timeout for icmp_seq 15

Request timeout for icmp_seq 16

Request timeout for icmp_seq 17

64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=3075.222 ms

64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=2077.145 ms

64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=1076.035 ms

64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=15.653 ms

For the meantime until Apple fixes this issue, I'll have this device handy as a workaround.  Purchased for around AUD 35, its acceptable

AllThingsD is reporting that Apple is holding an iPad event on Tuesday, October 22. Apparently, the focus of the event will be not only iPads, but also new Mac Pros and OS X Mavericks.

AllThingsD has a pretty good track record with these things—it correctly predicted the date of the iPhone event last month, so new iPads on the 22nd are probably a safe bet.

Fingers crossed...

Has anyone successfully returned their MacBook Air outside of the 14 day window?

Hi all!

I received my first replacement Air last friday, and the first thing I did was erased it and reinstalled it and updated it to the most current version. I specifically did not tweak any WiFi drivers. Now I get the irregular and long ping times to my router, but it has never dropped a connection (that I've noticed, at least: I haven't yet been pinging for hours at a time. Note to self: do that). Also my TimeMachine backups happen regularly and without any problems. Screen sharing to my Mac Mini never hangs. Network drives stay mounted and available.

Today I tested it at the office and at the mall, and it could connect to WiFi networks my previous Air could not connect to (no security at the mall and WEP at the office). I still can't connect to the WPA Enterprise network at the office, but even some other devices have problems with that one, so I can't conclusively say anything about that.

However, at these locations, I didn't test the old MBA with exactly the same OS version/driver setup as with the curent MBA, so I can't really say for sure if they would behave differently having all the same updates installed. I guess I could temporarily do the .22 -tweak on my new MBA and see what happens, but currently I'm quite happy with how things are, although there is a slight feeling of it not being quite complete yet.

I've been wondering, though: does the long ping time as such really matter? I've noticed it goes down to around 1 ms when there's a lot of network traffic (as noted elsewhere in the thread), so does it really have any noticeable effect on my network experience? Is there any chance it could be a power-saving feature? I assume not, but would it make sense?

But in any case, it looks like I won't be returning this one.

Cheers,

Kim

Yes, for eg.it can effect RDP and VOIP.  Presuming it drops into powersave mode a bit too quickly when traffic is low, and then can't pick up again quickly enough to keep up the with the traffic.  Eg. voip can be great, but then can start stuttering after a random amount of time.  This is using the same network as a macbook pro which doesn't exhibit the same problem at all.

Of interest, has anyone tried Windows 8.1 or Mavericks to see if the problem is resolved with the updated drivers in these systems?

If indeed the Broadcom chip is being forced into power saving mode constantly I'd rather not have this "feature" at the expense of wifi stability. At the very least Apple should offer an option to turn off aggressive power saving. As some others have pointed out installing Windows bootcamp results in ultra-low pings and a stable wifi connection with the built-in chip. This should be the norm.

If this was Apple's way of achieving the much lauded 12 hour battery time well I think they need to go back to the drawing board. I shouldn't have to be forced to use an external wifi USB to achieve a stable connection as a workaround simply to allow Apple to achieve their operating specifications.

No problem under windows in bootcamp.

This is an OS X only issue.

You don't get the problem on yours?

I've seen it on 3 MBA's.  Two of my own, and as I primarily use windows this is the reason I returned. Which drivers are you using in windows?

6.30.223.75

Rock solid performance in Windows.  Most pings under 1ms.

Maybe I just got lucky...