Q: New Macbook Air - wifi connectivity problems

No I haven't done the ping test. For me when I bought the machine originally, It would only say connected to my Linksys for about 5 minutes and then it would say it was connected while not being able to do anything. It would come and go and after repeated attempts I was able to reload the OS over wifi -- kind of took all night.

After replacing the perfectly good wireless router with the Apple time capsule internet was lightning fast and rock solid reliable. Maybe if you analyze the ping times you would find some anomaly in the return times but as long as it all feels quick and reliable I don't really care. I didn't like doing it, but not only is my Air working well, my Roku box, my PS/3s, and my various IOS devices are all working better too. One interesting thing is that the Apple TV now doesn't stall out while playing YouTube videos like it used to. Plus I have backup on my laptop now to the time capsule over wifi and I never notice it.

But again that doesn't mean Apple is not in the wrong here, they are. This is a catastrophically bad mistake on their part and they're making it worse by trying to deny responsibility, just as they did in the infamous iPhone 4 antenna issue.

I now strongly suspect there aren't any 'good' macbook air's out there and they are all suffering the same issue when running the latest software.  The only reason some may appear good is that their usage doesn't show the problem.

As I already said, my MBA works great but my PING results are :

PING 192.168.0.1 (192.168.0.1): 56 data bytes

64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=40.259 ms

64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=63.270 ms

64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=85.969 ms

64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=6.246 ms

64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=29.331 ms

64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=52.062 ms

64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=75.215 ms

64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=98.613 ms

64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=19.022 ms

64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=42.061 ms

64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=64.723 ms

64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=87.646 ms

64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=7.879 ms

64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=30.744 ms

64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=53.406 ms

64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=76.353 ms

64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=98.972 ms

64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=19.564 ms

64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=42.489 ms

64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=65.263 ms

--- 192.168.0.1 ping statistics ---

20 packets transmitted, 20 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 6.246/52.954/98.972/28.157 ms

I also have a Samsung laptop running Windows 8 connected to the same wifi router (2.4 Ghz,N network) and the ping results are around 1 ms.

Exactly.  It has a network issue.  Though depending on your usage it may not be apparent to you.  But the laptop definitely has an issue!

"The only reason some may appear good is that their usage doesn't show the problem."

What do you mean by that? Most people on this thread complain about wifi disconnecting (or showing that it is connected where in reality it is not). I never encountered such problems (finger crossed).

The patch fixed a lot of that.  However, the network can time out (but you don't have to reconnect to wifi necessarily) but its oflline for say a second.  Try using VOIP or remote desktop on your laptop and see how it goes.

If you're happy, then great.  But from your ping results to your local router, that definitely ain't right and somethings broken.

Could anyone confirm me if ping time significanly appears to be more than 30ms, it potentially has a wifi problem? I have also tested my other devices. They all showned <1ms or only 1ms. I am worried that this is the hardware issue...

Your MBA 2013 should be one of the fastest devices on the network (within reason) so should easily match the other devices.  You have the hardware problem.  As I'm now guessing everyone who has a MBA 2013 has....

Should say, not sure whether its hardware/firmware/software.

Message was edited by: andyman2

I said a few posts back that I use Skype and Facetime without an issue (long video calls, 30 min-1 hour/session). I never had any problems but I would like to hear from other owners of working MBAs if they have any problems with Skype or similar programs.

Pleased it works for you, but don't be fooled.  Your ping times, especially since you have other devices quicker on your network, are from reporting a healthy network device.

If you're happy, then great and I'll leave it there.

I am really curious to see if next Haswell macbooks have the same issue with wireless. I am definitely waiting for Apple to release rMBP and Mavericks before buying anything (so I also save the money for the OS update).

Sorry am just adding to thousands of other similar comments but I felt that I should come with my thoughts as well for this after spending quite a bit of money on what should be a top of the range product from one of the most loved brands globally

I am pinging to the the Default Gateway which is just 3 feet away using wireless connection.

this is the result i am getting. I am sure it should not be this unpredictable although this is a wireless connection?

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=53.307 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=75.925 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=98.718 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=19.364 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=42.502 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=65.197 ms

64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=87.677 ms

64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=4.862 ms

64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=31.206 ms

64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=54.061 ms

64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=76.732 ms

64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.797 ms

64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=19.931 ms

64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=43.319 ms

64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=66.596 ms

64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=88.788 ms

64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=10.250 ms

64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=2.024 ms

64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=8.578 ms

64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=2.433 ms

64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=2.459 ms

64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=20.986 ms

64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.999 ms

64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=36.465 ms

64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=2.867 ms

Would be grateful to have your thoughts, and have not gone through all the comments above but have anyone talked to the helpdesk about the erratic pings?

very much indicative of the problem.  Could always be a really noisy wireless env, however, it's exactly like the problem which is seen.  And especially as you're getting a 1ms ping time there as well.  Maybe useful if you have another device you can test to compare with.

MBA 2013 on the left, MBA Pro on the right.  Just to show:

https://dl.dropboxusercontent.com/u/2131484/IMG_20130817_175312.jpg

Yes, I'm holding out hope that the newer latency issue is specifically a driver code issue that can be resolved by Apple's network engineers via a software update.  But its tough to definitively say, until Apple releases a patch for this latency bug.

The only other thought I've considered until that moment, is to boot up my 2013 MacBook Air off a clean 10.8.4 (minus the MBA 1.0 software update) via a USB flash thumb drive, and see what the results are.  I probably will do that later today.

must admit, my concern is that exactly the same thing happens in windows 8 on bootcamp.  Seems unlikely that both drivers have the same bug....