Late 2013 Macbook Pro Retina 13'' Wifi Issues

I just tried this and it has been ok for the past 36 hours. fingers crossed....

http://osxdaily.com/2012/11/30/resolving-stubborn-wi-fi-connection-problems-in-m ac-os-x/

Deleting the plists has been mentioned here before. As the article itself says, that it may not address the problem of waking up from wifi seemingly connected without any packets moving.

Since you said that's you're problem (and it's mine) I'm pretty surprised to hear this. My own attempts to delete the plists and regenerate them only worked until I put my macbook to sleep over night.

If you're leaving it on and pinging for 36 hours and haven't tried at least a 15 minute sleep, you might not have tested it.

If you have slept and woken the macbook after an hour or so, and your problem is gone, please let me know, and I'll try this again. Also did you only do the plist deletion or also go to the dhcp renewal and mtu shortening.

I also tested pinging for 12 hours straight right after wake up to see if at any point it will at least slowly start sending a fraction of the packets. It did not. So far only turning off the wifi and on again (and you can conversely reset your wifi router, but you're doing the same thing, and no other device needs you to do that) has worked for me after waking up.

The early 2013 model has a different airport card (broadcom) hardware, and a different driver to match it. That one doesn't seem to have this issue. I'm suspecting that the one person who says their problem went away with a new card got one of these older cards. And I'm not sure that's fair since the late 2013 model is supposed add 802.11ac and bluetooth 4 which the early 2013 model doesn't have.

While I think this is a failure in the Apple QA process, I don't know if these drivers are by Apple or just packaged by Apple (by Broadcom, who probably would get a long time consulting group to do it). You could swap either end of your connection, but it my experience I can't quite predict which routers have the issue (a list would be nice, I have the [cisco] Linksys EA3500) AND no other device using the router has a similar issue. If I were taking it to a genius bar (and I won't) I'd bring the router and some other device to also connect to the router.

Also if earlier posts are to be believed the drivers packaged with Win8.1 work via boot camp... which either means there's some fixes in that packaged driver yet to be ported to the mavricks packaged driver, OR there's some architectural differences in the way the OS calls into those drivers that reveal bugs in the driver under one OS but not the other. Either scenario would be a QA failure.

ifixit says the card is: AirPort Card with WLAN 802.11ac, Broadcom BCM4360 for 5-GHz-Band (bis 1,3 Gbps), Broadcom BCM20702 Bluetooth 4.0, Skyworks SE5516 Dual-Band 802.11a/b/g/n/ac WLAN Frontend-Module so, you know, it could be a bad power sleep/wake of the front end module too.

I just want to say that anyone who writes as though Apple is knowing selling crap to them and refusing to address the problem... well. Don't act surprised, nor expect stating the way you feel to change anything. Apple's a little more secretive about what problems they know exist and which they can or can't do anything about. It's very frustrating, and it might never get fixed, but you can't know. They're a little better than say Samsung or Sony who might release a new batch of hardware, that changes everything and fixes a long standing issue, but refuse to go back and patch an issue with the just discontinued hardware. Basically every piece of Apple hardware I've had has some corner case for users who aren't getting what they expect (most commonly heatsink/cooling related; in the 90s there were a lot of doesn't wake from sleep issues). But I see that with a lot of companies' products. I agree that some other companies can be good about saying, "okay, you will be happier if I replace this with something that works," and they do. Apple has shown me repeatedly to be highly reluctant of anything along those lines. The only time it's been really unnacceptable (to me) is when they do start replacing some people's products with the exact same problem I have, but only if you happen to call within the right 2 month period. Not before (even a year before), nor after, and don't expect them to deliver the good news of a limited free replacement roll out by following up on that problem report you made that left you with an "it's just you, did you try not using it that way." That stung me enough to bring it up again now.

4rk wrote:

Also if earlier posts are to be believed the drivers packaged with Win8.1 work via boot camp... which either means there's some fixes in that packaged driver yet to be ported to the mavricks packaged driver, OR there's some architectural differences in the way the OS calls into those drivers that reveal bugs in the driver under one OS but not the other. Either scenario would be a QA failure.

i definitely have no problems under Win 8.1, it works perfectly on 802.11g, n and ac. On Mavericks there are various issues with the wifi since the day i bought it. And if thats not enough of a proof for a faulty driver, i had the whole notebook replaced and the new one was the same.

But what really amazes me is that so FEW people are complaining here. I mean, the disconnects and especially the slow speed on 802.11n networks are a huge problem for me, i wonder how so many MBP owners can live with that.

But what really amazes me is that so FEW people are complaining here.

Perhaps others are not having much of a problem.

I don't know how to say this without sounding like a complete and utter jerk. But one possibility is that you have a problem caused by something that you do differently than most other users, and not a fundamental flaw in Mac OS X (or at least not one that EVERY user encounters).

hm, now this might sound a bit odd as well, but i was curious and i asked two colleagues that own MBPr's as well if they are having issues with their WiFi. Guess what, they do. One of them just lives with it and the other one is using the Thunderbolt-to Ethernet Adapter now. But they may have bought these computers mainly for the style-factor, so i guess its not a big deal.

This thread is full of people reporting problems and i have had two machines with excellent wifi under windows and terrible wifi on Mavericks (on the same network) tested on 802.11g, n and ac. And you still believe its a user-related problem? Wow.

I've been having this issue here and there. What I finally decided to do is install SleepWatcher and have it turn Wifi off and on immediately after the system wakes up. So everytime it wakes up I see it turn off and back on, takes about 2 seconds, and it connects right away to my network.

This will get me by until there is a fix supplied by Apple.

Grant Bennet-Alder wrote:

But what really amazes me is that so FEW people are complaining here.

Perhaps others are not having much of a problem.

...

It's a flaw in software (since there's a couple of confirmations that the same hardware with windows 8.1 doesn't have the issue).

It doesn't happen to everyone because it happens only on certain types of wireless networks. Even the one spec type (802.11n) has many variations, from whether it's 2.4Ghz or 5Ghz or both, or b/g/n just n, the number of TX and RX antennas (1x1 1x2 2x2 2x3 3x3), channel hopping or not, and which mode of encryption (at least 5 options there) all to combine to 2^3*5*5 not to mention differences in implementation to the spec by vendors that don't present any options. People do expect thier network adapters to work with all networks that support the spec, but this laptop's adapter does not. The specs have variations and it could be that there's a common variation that shouldn't be allowed by the spec if you read it Apple's way, but is practially in use, and it triggers the problem.

So I know that I only see this issue at home and at a couple of random cafes. My workplace is doing just fineon a 5Ghz 802.11n connection that seems almost like the one I use at home except my home one is using a PSK and not a certificate for encryption.

Good explanation. I can confirm that on 5GHz i am not having any disconnects and extreme slow-down at home. This is why i kept the machine in the end.

However I have to add that even there the performance is still not as it should be and could be. See my earlier posts where on Mavericks I have measured less than 50% of the SMB2 transfer rates that i get with Windows 8.1. (same test setup)

I think i spoke too soon 😟, within 48 hours it happened again. (actually it started when I put in charging with the external display, bluetooth mouse and keyboard).

BTW, my network is a dualband and i am connecting to the 5GHz. I do not have any issues while connected. but the wake from sleep issue is a shame for this beautiful machine.

Also, i have trouble to login to my NAS made by LG from time to time.

Here is something funny ..

I did not turn the wifi off and on right away after the problem started... i happened to be busy with somethign else. and i found it eventually connects...after a long while though.

equest timeout for icmp_seq 820

Request timeout for icmp_seq 821

Request timeout for icmp_seq 822

Request timeout for icmp_seq 823

Request timeout for icmp_seq 824

64 bytes from 192.168.1.1: icmp_seq=673 ttl=64 time=152873.262 ms

64 bytes from 192.168.1.1: icmp_seq=674 ttl=64 time=151872.520 ms

64 bytes from 192.168.1.1: icmp_seq=675 ttl=64 time=150872.426 ms

64 bytes from 192.168.1.1: icmp_seq=676 ttl=64 time=149871.617 ms

64 bytes from 192.168.1.1: icmp_seq=677 ttl=64 time=148871.923 ms

64 bytes from 192.168.1.1: icmp_seq=678 ttl=64 time=147871.209 ms

64 bytes from 192.168.1.1: icmp_seq=679 ttl=64 time=146889.132 ms

64 bytes from 192.168.1.1: icmp_seq=680 ttl=64 time=145888.390 ms

64 bytes from 192.168.1.1: icmp_seq=681 ttl=64 time=144888.734 ms

....

64 bytes from 192.168.1.1: icmp_seq=810 ttl=64 time=16232.699 ms

64 bytes from 192.168.1.1: icmp_seq=811 ttl=64 time=15231.947 ms

64 bytes from 192.168.1.1: icmp_seq=812 ttl=64 time=14231.200 ms

64 bytes from 192.168.1.1: icmp_seq=813 ttl=64 time=13230.446 ms

64 bytes from 192.168.1.1: icmp_seq=814 ttl=64 time=12229.680 ms

64 bytes from 192.168.1.1: icmp_seq=815 ttl=64 time=11228.982 ms

64 bytes from 192.168.1.1: icmp_seq=816 ttl=64 time=10228.268 ms

64 bytes from 192.168.1.1: icmp_seq=817 ttl=64 time=9227.536 ms

64 bytes from 192.168.1.1: icmp_seq=818 ttl=64 time=8226.785 ms

64 bytes from 192.168.1.1: icmp_seq=819 ttl=64 time=7226.083 ms

64 bytes from 192.168.1.1: icmp_seq=820 ttl=64 time=6225.337 ms

64 bytes from 192.168.1.1: icmp_seq=821 ttl=64 time=5224.599 ms

64 bytes from 192.168.1.1: icmp_seq=822 ttl=64 time=4223.849 ms

64 bytes from 192.168.1.1: icmp_seq=823 ttl=64 time=3223.136 ms

64 bytes from 192.168.1.1: icmp_seq=824 ttl=64 time=2222.391 ms

64 bytes from 192.168.1.1: icmp_seq=825 ttl=64 time=1221.655 ms

64 bytes from 192.168.1.1: icmp_seq=826 ttl=64 time=220.542 ms

64 bytes from 192.168.1.1: icmp_seq=827 ttl=64 time=43.029 ms

64 bytes from 192.168.1.1: icmp_seq=828 ttl=64 time=50.387 ms

64 bytes from 192.168.1.1: icmp_seq=829 ttl=64 time=2.164 ms

64 bytes from 192.168.1.1: icmp_seq=830 ttl=64 time=6.426 ms

64 bytes from 192.168.1.1: icmp_seq=831 ttl=64 time=1.511 ms

64 bytes from 192.168.1.1: icmp_seq=832 ttl=64 time=3.451 ms

64 bytes from 192.168.1.1: icmp_seq=833 ttl=64 time=2.044 ms

I've been having this issue here and there. What I finally decided to do is install SleepWatcher and have it turn Wifi off and on immediately after the system wakes up. So everytime it wakes up I see it turn off and back on, takes about 2 seconds, and it connects right away to my network.

This will get me by until there is a fix supplied by Apple.

Edit: I made a couple more tweeks and I now barely notice that I'm sometimes missing a connection and sometimes not. If anyone is interested in doing this I can send you a tutorial. You need to write some shell script and stuff. For now it's working great. No guarantees though. ;-)

This may be of help to someone...

Having the same connection issue with a brand new 15'" late 2013 macbook pro and tried all of the router setting and other fixes in this thread on my Billion 7700n and was not able to connect to wifi at all - the router is only 3 feet from the macbook and an older unibody macbook 17" is working fine over wifi right next to it.

I isolated the problem to a cheap generic usb cable extender and USB3 HD plugged into the right USB port that was interfering with the wifi signal, I plugged the HD directly into the USB port and Wifi connected straight away.

On the left side of the macbook is a Thunderbolt to firewire adaptor and a Dell U2711 via display port and also acting as a 4 port hub.

It might be worth unplugging and checking your USB peripherals for problems.

Cheers

Dave

USB-3 signals are in about the same range as the 2.4GHz band of WiFi.

Cables that came free in the box with a peripheral are often "lowest bidder" cables, and are not manufactured to high standards, especially regarding proper shielding of the cable.

Hey so just to clarify my issues, they're only from waking, it doesn't resume sending packets even after 13h of trying (as mentioned before) unlike phoneuser's experience. I have tried a new location, deleting the plists, and zapping pram (that seemed to work once and once only), I'm using the late 2013 15" macbook pro retina model with the 802.11ac broadcom and 10.9.2. When it wakes the wifi is on, connected to the same (right) ssid, with the same IP the same netmask, but it can't even ping the first hop (the router itself).

And my reason for updating is that I had previously written that getting a thunderbold gigabit ethernet adapter would be my way to work around this... well one amazon prime delivery later and behold: the late 2013 15" macbook pro retina model has a problem using the adapter when it's woken from sleep.

https://discussions.apple.com/thread/5484290?answerId=23532814022#23532814022

True story. So it's probably not worth your extra $30+tax to Apple for removing the port from your slim slim machine.

The fix regarding the dhcp lease after switching ipv6 to link-local only works (so far). Not sure if it will work for the wifi.

Interfaces:

en0:

Card Type: AirPort Extreme (0x14E4, 0x134)

Firmware Version: Broadcom BCM43xx 1.0 (6.30.223.154.63)

MAC Address: 60:03:08:a6:8c:3e

...

Apple 57762-A0:

Name: ethernet

Type: Ethernet Controller

Bus: PCI

Slot: Thunderbolt Slot 1@195,0,0

...

BSD name: en3

Kext name: AppleBCM5701Ethernet.kext

Firmware version: 57762-a1.10, 0x5397cc35

...

Version: 3.8.1b2

In my new location I changed the order of devices and removed/disabled some unlikely ones. Again this didn't fix it.

Home:

Active Location: Yes

Services:

Wi-Fi:

Type: IEEE80211

BSD Device Name: en0

Hardware (MAC) Address: 60:03:08:a6:8c:3e

IPv4:

Configuration Method: DHCP

IPv6:

Configuration Method: Link Local

Proxies:

Exceptions List: *.local, 169.254/16

FTP Passive Mode: Yes

IEEE80211:

Join Mode: Automatic

PowerEnabled: 0

RememberJoinedNetworks: 1

RequireAdminIBSS: 0

RequireAdminNetworkChange: 0

RequireAdminPowerToggle: 0

Thunderbolt Bridge:

Type: Bridge

BSD Device Name: bridge0

IPv4:

Configuration Method: DHCP

IPv6:

Configuration Method: Automatic

Proxies:

Exceptions List: *.local, 169.254/16

FTP Passive Mode: Yes

Bluetooth DUN:

Type: PPP

IPv4:

Configuration Method: PPP

IPv6:

Configuration Method: Automatic

Proxies:

FTP Passive Mode: Yes

PPP:

ACSP Enabled: No

Display Terminal Window: No

Redial Count: 1

Redial Enabled: Yes

Redial Interval: 5

Use Terminal Script: No

Dial on Demand: No

Disconnect on Fast User Switch: Yes

Disconnect on Idle: Yes

Disconnect on Idle Timer: 600

Disconnect on Logout: Yes

Disconnect on Sleep: Yes

Idle Reminder: No

Idle Reminder Time: 1800

IPCP Compression VJ: Yes

LCP Echo Enabled: No

LCP Echo Failure: 4

LCP Echo Interval: 10

Log File: /var/log/ppp.log

Verbose Logging: No

Thunderbolt Ethernet:

Type: Ethernet

BSD Device Name: en3

Hardware (MAC) Address: 68:5b:35:c8:ec:6e

IPv4:

Configuration Method: DHCP

IPv6:

Configuration Method: Automatic

Proxies:

Exceptions List: *.local, 169.254/16

FTP Passive Mode: Yes

Nice to see this issue being picked up by MacWorld:

http://www.macworld.com.au/help/bugs-fixes-slow-wi-fi-reconnect-after-macbook-wa kes-up-123742/?utm_medium=email&utm_campaign=304&utm_content=304+CID_bba52b5bb1e 65b0eb9872edee02c41a1&utm_source=Email%20marketing%20software&utm_term=So%20what %20do%20you%20do%20Click%20here#.U2Dvr15wzLR

We need as much pressure for a fix as we can get!