8 Replies Latest reply: Sep 14, 2014 9:28 PM by sathish.vc
MBA-Loyal Level 1 (0 points)



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 ?





dhcp-172-25-42-229:~$ netstat -rn

Routing tables



Destination        Gateway            Flags        Refs      Use   Netif Expire

default        UGSc            2        0     en0

127                UCS             0        0     lo0          UH              3    49709     lo0

128.0&0x9605       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Badnesss

ff.ff.ff.ff. . . 0.5.ff.ff.ff. . . USc             2        0     en0

128.0&0x8600      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Badnesss ff.ff.ff.ff. .4f. .6.ff.ff.ff.ff.ff.0.0.7c. . USc             0        4     en0

169.254            link#5             UCS             0        0     en0          UGHS            0        0     lo0        0:90:fb:1c:4c:b4   UHLS            0     1274     en0

192.168.123        link#5             UCS             4        0     en0      0:1b:2f:64:66:6c   UHLWIi          8      103     en0   1172          UHS             0        0     lo0    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1168    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1094    c:77:1a:8d:ac:49   UHLWIi          0        0     en0   1175




Destination                             Gateway                         Flags         Netif Expire

::1                                     link#1                          UHL             lo0

fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0

fe80::1%lo0                             link#1                          UHLI            lo0

fe80::%en0/64                           link#5                          UCI             en0

fe80::5a55:caff:fef5:bfad%en0           58:55:ca:f5:bf:ad               UHLI            lo0

ff01::%lo0/32                           fe80::1%lo0                     UmCI            lo0

ff01::%en0/32                           link#5                          UmCI            en0

ff02::%lo0/32                           fe80::1%lo0                     UmCI            lo0

ff02::%en0/32                           link#5                          UmCI            en0

Segmentation fault: 11   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Badnesss




dhcp-172-25-42-229:~ $ ping somewebsite.com

PING somewebsite.com (some.ip.address.here): 56 data bytes

ping: sendto: Cannot allocate memory

ping: sendto: Cannot allocate memory

Request timeout for icmp_seq 0

ping: sendto: Cannot allocate memory

Request timeout for icmp_seq 1


--- somewebsite.com ping statistics ---

3 packets transmitted, 0 packets received, 100.0% packet loss

dhcp-172-25-42-229:~ $

MacBook Air, Mac OS X (10.7.3)
  • Zaid Albanna Level 1 (5 points)



    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 sleep

    3- user wakes the computer up using wireless network B (via interface en0).

    4- turns off en0 and put the computer to sleep

    5- 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 access

    1- go to system preferences

    2- click on network

    3- select Wi-Fi

    4- select advanced button (at the bootom right of the screen, before the "?" sign)

    5- select tcp/ip tab

    6- disable and enable tcp/ip


    This 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 Level 1 (35 points)

    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 Level 1 (10 points)

    There is an easier way to remove the bogus 128.0& route.  `sudo route delete -host`.

  • BabarOnWheels Level 1 (0 points)

    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've seen the 128.0&0x8500-type entry though.


    (In my case, rebooting did not even clear the entry! ***?)

  • AvadhutAtre Level 1 (0 points)

    BabarOnWheels thanks. That worked like charm.

  • AvadhutAtre Level 1 (0 points)

    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 'netstat -rn' it was issuing was hanging on the command prompt too. Solution user-sl provided worked like a charm.

  • SeanKelly Level 1 (70 points)

    Thanks for these solutions, folks.


    I also have to use Juniper'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've guessed that a simple routing table cleanup was all it took.

  • sathish.vc Level 1 (0 points)

    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