Mavericks and Failed ARP causing network drops!

Here is the code:

https://raw.github.com/MacMiniVault/Mac-Scripts/master/unicastarp/unicastarp.sh

The first if statement makes surre that the OS is OS X 10.9.x .... not linux or some older version of OS X

If that is true, then the script looks to see if the /etc/sysctl.conf file exists (second if statement).

If that is true, we just look for the word 'unicast' in the file. If we have a positive hit (third if statement) then we stop the script and assume the parameter has already been set and exists.

With that out of the way, the script sets the parameter in the live envrionment. It also uses the 'tee -a' command to take the echo'd line and put it in the config file, appending it if the file exists. We also set the ownership and permissions properly to the config file.

So the script will always be active in the background? If it does not find the file, then will it keep searching for it later? In other words, will it affect system performance in any way? Thanks!

I'm sorry for not explaining that part. It runs once and that's it. The script stops executing once it says "PATCH ENABLED" or "PATCH WAS PREVIOUSLY ENABLED".

Is there no way to stop the script from ever running again..in essence, disabling it? Thanks for responding so fast and being helpful!

The script runs once and that is it. It sets a variable in /etc/sysctl.conf to keep the 'fix' enabled on boot. Removing the variable from the /etc/sysctl.conf file, or removing the file itself, and rebooting reverts the system back to the default behavior.

Once again, not a bug:

Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls.

This is a bug, but it doesn't appear to be a bug with Mavericks. I believe this is a Cisco bug.

We're having the same problem here with GLBP and Mavericks. The fix provided in this thread solved the problem for us, but I dug a little deeper to determine if this was only limited to Mavericks. From my testing, it does not appear to be.

Linux provides a neat utility called arping that essentially pings a remote host by using unicast arp requests. If you use that tool and ping the lova GLBP address on the router (Not the shared address you use as a default gateway) you'll get consistent ping replies, as you would expect. If you ping the shared address, you get a few (1-3 in my testing) requests answered, and then the remote stops responding. What's interesting is that if you do this a few times, you'll see that the pings stop as soon as the MAC address the router replies with changes. Here's an example :

PROD> $ arping -I em1 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.123 em1
Unicast reply from 192.168.0.1 [00:07:B4:00:01:01] 3.581ms
Unicast reply from 192.168.0.1 [00:07:B4:00:01:02] 3.014ms

The ping stopped as soon as the MAC address changed.

I have an open case with Cisco where I'm referencing this problem as well as this thread. Hopefully more information will follow. If I receive any viable information, I'll pass it on.

So I spoke with Cisco and they're pointing a finger at Apple. Per Cisco, Apple has implemented this improperly. They claim that the MAC Address is being removed from the ARP table prior to the Unicast ARP requests. Can anyone confirm this is the case?

They also pointed out this page which also explains the issue and has a note that 10.9.2 is rumored to resolve this. http://www.macstadium.com/blog/osx-10-9-mavericks-bugs/

I have the same issue with a non-Cisco product after upgrading to Mavericks.

I have a friend who has a new MacBook Pro. When it was running 10.9.0, everything was fine. But when we updated it to 10.9.1, the wireless would not hold a connection for more than a minute or so even though he was sitting right next to his time capsule. He spent almost two hours with a very responsive guy at the local Genius Bar. The Genius finally decided to roll the machine back to 10.9.0 and wait for the next release of 10 to see if the problem will be fixed. Once the machine was installed again with 10.9.1, everything is fine. I don't know if this has anything to do with your issue or not. BTW, I run 10.9.1 on my older MBP with no issues. Phil

I recently changed my router and now it connects and stays connected but I have no internet access intermittently or until I turn wifi off and back on. This new router is a Samsung SMT-G7400/XEN and I think it's dualband.

How would I be able to fix this issue? I'm not even sure it's what other people here are having because most of what everyone is talking about goes over my head. I'm on a late 2013 13" MBPr on 10.9.2.

This problem still exists with 10.9.2. None of the other suggested solutions in this thread fix the problem for me personally.

I just spent about 20mins on the phone with apple support and they couldn't figure it out either.

I'm connected directly to the cable modem ( no wifi or router ).

Running into the same problem only if i switch from Ethernet to USB Ethernet the problem is gone (MacMini)

added a bug to bugreport.apple

I found on a forum some solution to duplicate the Ethernet port and use the duplicated port as main ethernet port

but dont delete the old port (and dont forget to set the service error) i have no time to check now but friday i change it on my mac mini server i will post the result here.

Duplicate the Ethernet port dont solved the problem back to the drawning board.