Strange Routing Entry

Question

Hello,I am running the latest lion, and just installed the latest updates. This is the second time I have encountered this issue. It is typically resolved by rebooting. But it is very annoying. It seems to occur when changing networks while having a VPN clinet up. This looks like some sort of route corruption that is happening when swapping networks or when putting the device to sleep and waking it up to a different network. The symptom is routes to specific locations cannot be reached. My questions are :Has anyone seen this behavior before ?Can someone tell me what this is ? How it gets into the routing table ? and how to get rid of it without having to reboot ?ThanksMBA-Loyaldhcp-172-25-42-229:~$ netstat -rnRouting tablesInternet:Destination        Gateway            Flags        Refs      Use   Netif Expiredefault            192.168.123.1      UGSc            2        0     en0127                127.0.0.1          UCS             0        0     lo0127.0.0.1          127.0.0.1          UH              3    49709     lo0128.0&amp;0x9605       &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Badnesss ff.ff.ff.ff.0.0.0.0.0.0.0.0.6.ff.ff.ff.96.5.0.0.88.0.5.14.5.0.68.c.1.8.1.0.7.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.7f.ff.ff.ff.0.0.0.0.dc.5.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .10.2.0.0.80.0.0.0.0.0.0.0.0.0.0.0.14.12.5.0.0.0.ff.0.ff.ff.ff.ff.0.0.0.0.0.0.0. 0.5.ff.ff.ff.86.0.0.0.88.0.5.14.5.0.68.c.1.9.0.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.7f.ff.ff.ff.0.0.0.0.dc.5.0.0.0.0.0.0.8d.c.5a.4f.0.0.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.0.0.a9.fe.0 USc             2        0     en0128.0&amp;0x8600      &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Badnesss ff.ff.ff.ff.0.0.0.0.0.0.0.0.5.ff.ff.ff.86.0.0.0.88.0.5.14.5.0.68.c.1.9.0.0.7.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7f.ff.ff.ff.0.0.0.0.dc.5.0.0.0.0.0.0.8d.c.5a .4f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 0.0.10.2.0.0.a9.fe.0.0.0.0.0.0.0.0.0.0.14.12.5.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .6.ff.ff.ff.ff.ff.0.0.7c.0.5.14.1.0.68.c.7.8.0.0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 .0.0.0.0.7f.ff.ff.ff.0.0.0.0.0.40.0.0.0.0.0.0.0.0.0.0.0.c0.0.0.0.c0.0.0.0.0.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.10.2.0.0.ac.1c.84 USc             0        4     en0169.254            link#5             UCS             0        0     en0172.28.132.224     127.0.0.1          UGHS            0        0     lo0192.168.5.1        0:90:fb:1c:4c:b4   UHLS            0     1274     en0192.168.123        link#5             UCS             4        0     en0192.168.123.1      0:1b:2f:64:66:6c   UHLWIi          8      103     en0   1172192.168.123.200    127.0.0.1          UHS             0        0     lo0192.168.123.205    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1168192.168.123.206    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1094192.168.123.207    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1175Internet6:Destination                             Gateway                         Flags         Netif Expire::1                                     link#1                          UHL             lo0fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0fe80::1%lo0                             link#1                          UHLI            lo0fe80::%en0/64                           link#5                          UCI             en0fe80::5a55:caff:fef5:bfad%en0           58:55:ca:f5:bf:ad               UHLI            lo0ff01::%lo0/32                           fe80::1%lo0                     UmCI            lo0ff01::%en0/32                           link#5                          UmCI            en0ff02::%lo0/32                           fe80::1%lo0                     UmCI            lo0ff02::%en0/32                           link#5                          UmCI            en0Segmentation fault: 11   &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; Badnesssdhcp-172-25-42-229:~$ dhcp-172-25-42-229:~ $ ping somewebsite.comPING somewebsite.com (some.ip.address.here): 56 data bytesping: sendto: Cannot allocate memoryping: sendto: Cannot allocate memoryRequest timeout for icmp_seq 0ping: sendto: Cannot allocate memoryRequest timeout for icmp_seq 1^C--- somewebsite.com ping statistics ---3 packets transmitted, 0 packets received, 100.0% packet lossdhcp-172-25-42-229:~ $

Zaid Albanna · Answer

Hello, I did not expect to answer my own question but I just happened to stumble upon this work around so I thought I would share it.One way the situation above could be encountered is be the following a combination of these general steps:1- user logged onto a VPN and using wireless network A (via interface en0)2- user puts computer to sleep3- user wakes the computer up using wireless network B (via interface en0).4- turns off en0 and put the computer to sleep5- wake up the computer. The shortes way to solve this is by restarting the computer. Another way to deal with this issue is to:0- ensure you have admin access1- go to system preferences2- click on network3- select Wi-Fi4- select advanced button (at the bootom right of the screen, before the "?" sign)5- select tcp/ip tab6- disable and enable tcp/ipThis procedure removed the 128.0.... strange routing entries that appeared in the netstat -r output. I enabled en0 after that and was alble to re-establish connectivity.

DeesBek · Answer

Hi Thanks for this.  I had the same problem when I was using Juniper Network Connect.  When the machine went to sleep after it was on the VPN I was getting ping: sendto: Cannot allocate memory when I was trying to ping anything.I had not checked the routing table, but there you go.Turning off wifi and turning it back on did not work.Turning off tcp/ip and turning it back on worked like a charm.

user-sl · Answer

There is an easier way to remove the bogus 128.0&amp; route.  &#x60;sudo route delete -host 128.0.0.0&#x60;.

BabarOnWheels · Answer

Thanks, user-sl. That was not obvious. In general, the Juniper VPN seems to be horrible about cleaning up its routing entries. It regularly leaves routes around that then make it impossible to reconnect when moving between home and office. This is the first time I&#x27;ve seen the 128.0&amp;0x8500-type entry though. (In my case, rebooting did not even clear the entry! ***?)

AvadhutAtre · Answer

BabarOnWheels thanks. That worked like charm.

AvadhutAtre · Answer

I faced exact same problem when using Juniper Network Connect. I closed the laptop lid and happened to open it in a different WiFi. Network conect after that used to hang at "Establising Secure Connection". I noticed that &#x27;netstat -rn&#x27; it was issuing was hanging on the command prompt too. Solution user-sl provided worked like a charm.

SeanKelly · Answer

Thanks for these solutions, folks.I also have to use Juniper&#x27;s "Network Connect" (version 7.1.7 (20581)) and encounter this problem frequently, even when using Mac OS X "Mavericks" (10.9.2).I never would&#x27;ve guessed that a simple routing table cleanup was all it took.

sathish.vc · Answer

Am also on OS X Mavericks. Resorted to restarting the MBP a few times. Then found this thread. Works. Thanks Zaid Albanna and user-sl