-
All replies
-
Helpful answers
-
May 15, 2016 5:22 AM in response to Rocky Rakoonby futzle,I've seen this on the wireless LAN at my work. It's obvious when it happens because one of the wired servers that stops responding to pings from the MacBook is the DNS server, so any new hostname lookups start timing out. I've gone so far as to install Wireshark on both the MacBook and the DNS server, comparing the packet traces.
What I've found:
- After a bit of inactivity, the wired LAN PC wants to check that the MacBook is still there and sends an ARP request. This packet appears in the PC's Wireshark output but not in the MacBook's Wireshark output. It's as if the packet has been lost somewhere along the way.
- If I ping the LAN PC from the MacBook then the ping request appears on the LAN PC, and the response is sent, but the response doesn't appear in the MacBook's Wireshark output. The LAN PC lists the MacBook's ARP table entry as "invalid".
- If I run sudo arp -d -a on the MacBook to delete the ARP table, the MacBook naturally has to send a new ARP request to the LAN PC. This clears the blockage and everything is good, for a bit.
- Disabling unicast ARP through setting net.link.ether.inet.arp_unicast_lim=0 made no difference. That's not surprising; I'm not seeing unicast ARP in the Wireshark dumps anyway.
In short: ARP solicitation broadcast packets sent by the LAN PC sometimes, but sometimes don't, make it to the MacBook.
I conclude from this that one of these things is happening:
- One of the devices between the LAN PC and the Wi-Fi access point is dropping just those packets. In between is a Netgear branded smart switch but I've observed the same behaviour with a D-Link branded dumb switch too. The Netgear smart switch never fails to respond to pings from the MacBook. I can see both the MacBook and the LAN PC in the smart switch's learned address list.
- There's a bug in the LAN PC's ARP aging algorithm that only happens sometimes and only with Mac OS X clients. The LAN PC is Windows SBS 2011. Messing with the ARP lifetime parameters on the PC hasn't helped.
- The Wi-Fi access point connected to the smart switch is intermittently not forwarding some broadcast packets from the wired segment to the wireless segment. It is Netgear branded and is configured to bridge the wireless and wired segments.
- The MacBook is filtering the ARP solicitation at either the firmware or OS level, preventing it from updating its own neighbour table.
I've got more tests to run—one obvious one is to sniff the Wi-Fi traffic from another device and see if the packets are travelling over Wi-Fi at all.
I bet I could make the problem go away by adding a static ARP table entry on the LAN PC, but that feels like admitting defeat.
-
May 15, 2016 12:48 PM in response to futzleby borderless,Add me to the list.
I had (early 2015) Macbook 12 retina suffered from the same issue. Awake from sleep and its connected to WiFi and when holding Option and clicking the WiFi icon in the menu bar OS X thinks its connected to the Internet. I can fix it every time by simply turning WiFi off and then back on.
Was excited when I got my new (early 2016) MacBook Retina 12 last week..didn't do a restore, didn't migrate anything. Simply set it up new and installed all the OS X updates..SAME PROBLEM.
I have no issues with any other iPhones, iPads or Macs on the same network.
Has anyone heard from Apple on this?
-
May 15, 2016 11:41 PM in response to futzleby futzle,Curiously, I don't experience the dropouts when the wireless interface is in monitor mode. If I leave this running in the background:
sudo tcpdump -Ini en0 > /dev/null
then my connection seems to act as I expect. Running the above command while in the dropped-out state makes it come good too.
I don't know why monitor mode should have this effect; it should not affect the data stream being sent or received by the Wi-Fi interface. But it supports the experiences of borderless and others: interacting with the Wi-Fi icon in the menu bar (which does an SSID discovery to display nearby access points) can make it come good.
I'm curious to see if the above command helps others. My gut feeling is that it will only help some, and that this thread has a few related but different bugs.
-
-
May 17, 2016 7:26 PM in response to Rocky Rakoonby Loni Berreth,From a post on another thread - this work for me! Thank this guy if it works for you too.
"I had a lot of wifi drops and went to system preference---network---advanced----TCP/IP----configure ipv6 and changed it to link-local only."
On my iMac - it doesn't seem to matter, automatic or link-local only - works good.
But on the new MacBook it has to be on "link-local only" or i get dropouts!
-
Jun 5, 2016 2:51 AM in response to Rocky Rakoonby Brucelin,I have the same issue on my 2015 Macbook. I find that if I wait about 30 seconds or so, or if I stop and restart WIFI everything seems to be fine, although if I do something that does not involve WIFI for a while, I have to do the same thing to get a connection again. I have seen this issue on the network at my home, and at my employer. Oddly enough, we stayed in a friends apartment for a few days to pet sit, and the issue went away while there. It returned when we got back on our home network. What I do not know is if this is a router issue, or a provider issue. And yes, I am hoping Apple will find a fix to this issue with a soon to be released update.