This is fresh after a reboot, on a wireless network which is known to be a little flaky. The first line is unlike anything I've seen before:

$ netstat -rn
Routing tables

Destination        Gateway            Flags        Refs      Use   Netif Expire
0&0x68             c8.c8.c8.c8.c8.c8.c8.c8.c8. USc             9        0     en0
default         UGSc           11        0     en0
127                UCS             0        0     lo0          UH              4      155     lo0
172.19.128/20      link#4             UCS             2        0     en0       0:b:86:61:f2:70    UHLWIir        12       14     en0   1177          UHS             0        0     lo0     ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en0

The first entry is very sticky; even taking down the network interface doesn't kill it. It isn't recognized by route delete. I need to restart the OS to get rid of it. It makes the system entirely unusable, since it causes network connections to fail:

$ telnet www.google.com 80
telnet: connect to address Cannot allocate memory
telnet: Unable to connect to remote host

What's going on here, and how can I fix it when it happens without a reboot?

  • User Mike (see his comments on my answer) had a similar problem and could get rid of the bogus route without a reboot by disabling IPv4, applying changes and re-enabling it. Have you experienced the problem again? – jaume Mar 12 '13 at 10:01
  • @jaume Fortunately for me and unfortunately for StackExchange, I have not experienced it recently. – archbishop Mar 13 '13 at 14:35
  • I'm happy for you. Should the problem appear again, I'd appreciate if you gave the steps in my answer a try and reported back. – jaume Mar 13 '13 at 16:19

Although I couldn't reproduce it on my MacBook Pro (OS X 10.8.2), some users have reported a similar behavior, including the creation of a bogus route:

Destination        Gateway            Flags        Refs      Use   Netif Expire
128.0&0x8600  ff.ff.ff.ff. .4f. .6.ff.ff.ff.ff.ff.0.0.7c. . USc             0        4     en0

when putting the computer to sleep while using a VPN connection over WiFi. This doesn't seem to be your case, as you see such a route right after starting your Mac.

I can't tell you what's going wrong here, but there is a post in the link above that mentions that it could be fixed without a reboot like this:

Turning off tcp/ip and turning it back on worked like a charm.

If you want to give it a try, open System Preferences, select the Network pane and, if necessary, click the lock icon to make changes:

enter image description here

Select your open connection from the list on the left hand side (Ethernet or WiFi), press the button Advanced..., select the TCP/IP tab, set Configure IPv4 to Off:

enter image description here

and confirm by pressing OK. Set TCP/IP back to its original setting.

Hope it helps.

  • Thanks! This problem is intermittent, but next time I notice it, I'll try this and see if it helps. – archbishop Feb 5 '13 at 19:14
  • Let's hope it helps. Could you report back after testing? I'm curious too... – jaume Feb 6 '13 at 7:59
  • I'm also curious. I only seem to get this on some occasions, and only when I'm running Juniper's Network Connect VPN client. – Mike Mar 4 '13 at 10:55
  • @Mike: Thanks for your comment. If you can test it I'd appreciate any feedback. – jaume Mar 4 '13 at 12:37
  • @jaume - I encountered this problem again, and it resolved using the steps you suggested - I disabled IPv4 on both of my active interfaces (wifi and eth), applied the changes, then re-enabled them and the bogus route disappeared. Thanks! – Mike Mar 12 '13 at 9:41

To fix the issue from the command line, or remotely:

interfacetofix=`netstat -r -f inet | grep "0&" | awk '{print $NF}'`
interfacenametofix=`networksetup -listnetworkserviceorder | grep "$interfacetofix" -B1 | tail -2 | head -1 | cut -d " " -f 2-10`
networksetup -setv4off "$interfacenametofix"; networksetup -setdhcp "$interfacenametofix"

This disables IPv4 on the interface with the bad route and re-enables DHCP. For manually entered IP addresses:

interfacetofix=`netstat -r -f inet | grep "0&" | awk '{print $NF}'`
interfacenametofix=`networksetup -listnetworkserviceorder | grep "$interfacetofix" -B1 | tail -2 | head -1 | cut -d " " -f 2-10`
interfaceIP=`networksetup -getinfo "$interfacenametofix" | grep "^IP address:" | awk '{print $NF}'`
interfaceSubnet=`networksetup -getinfo "$interfacenametofix" | grep "Subnet mask:" | awk '{print $NF}'`
interfaceRouter=`networksetup -getinfo "$interfacenametofix" | grep "^Router:" | awk '{print $NF}'`
networksetup -setv4off "$interfacenametofix"; networksetup -setmanual "$interfacenametofix" "$interfaceIP" "$interfaceSubnet" "$interfaceRouter"

For full details on what does what and why I use this specific code: http://briancanfixit.blogspot.com/2014/05/fix-juniper-network-connect-on-mac-bad.html


Be aware of the field: Netif,

disabling the proper interface according to Netif to clean up the invalid routes. (e.g., on my MacBookPro Retina, en0 is wi-fi)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .