ifconfig creates a bogus(?) route

[Kevin Oberman]

On Sun, May 29, 2016 at 12:12 AM, Bruce Evans <brde at optusnet.com.au> wrote:

> On Sun, 29 May 2016, Bruce Evans wrote:
>
> ...
>> I still haven't figured out how to set up the bogus(?) route using route
>> add/change, but can now complete the initialization using a "route change"
>> that appears to be null:
>>
>> Test script:
>> ...
>> X # Fix up the initialization with a null change:
>> X route change -iface 192.168.2.8 192.168.2.8
>> X netstat -rn
>>
>
> Before:
>
>> ...
>> Y Destination        Gateway            Flags    Refs      Use  Netif
>> Expire
>> Y 127.0.0.1          link#2             UH          0        0    lo0
>> Y 192.168.2.0/24     link#1             U           0        0    em0
>> Y 192.168.2.8        link#1             UHS         0        0    lo0
>> Y    route to: 192.168.2.8
>> Y destination: 192.168.2.8
>> Y   interface: lo0
>> Y       flags: <UP,HOST,DONE,STATIC>
>> ...
>>
>
> After:
>
>> ...
>> Y Destination        Gateway            Flags    Refs      Use  Netif
>> Expire
>> Y 127.0.0.1          link#2             UH          0        0    lo0
>> Y 192.168.2.0/24     link#1             U           0        0    em0
>> Y 192.168.2.8        192.168.2.8        UHS         0        0    lo0
>> Y    route to: 192.168.2.8
>> Y destination: 192.168.2.8
>> Y   interface: lo0
>> Y       flags: <UP,HOST,DONE,STATIC>
>> ...
>> Note that the "null" route change just echos the current setting and it
>> doesn't change anything according to netstat -rn and route -n, but it
>> fixes up some internal state so that the ping works.  When ping works,
>> tcpdump shows it going from 127.0.0.1 to 192.168.2.8 and coming back as
>> expected.  When ping hangs, tcpdump shows it going from 0.0.0.0 to
>> 192.168.2.8 and never coming back.  The default route doesn't exist in
>> either case.
>>
>
> Bah, it did change (from link#1 to 192.168.2.8 for Gateway in netstat -rn
> output only).  -iface makes no difference (I thought it prevented this
> change).
>
> The initialization bug has something to do with the magic default route
> of 0.0.0.0).  When lo0 is used uninitialized, it is still initialized
> to 0 and the 0 gets copied to somewhere not shown properly in the
> initial route from (or is it to?) 192.168.2.8.  netstat -rn translates
> this 0 together with another address to #link1, but route -n get
> doesn't show it.  I think this configuration is supposed to not occur.
> I couldn't find a way to get back it using route(8) after fixing it.
>
> When lo0 is brought up first, different magic obscures what is
> happening.  E.g., when lo0 is misconfigured with "inet 127.0.0.127",
> the em0 route is auto-configured with this strange lo0 address instead
> of completely misconfigured to 0.  Neither netstat -rn nor route -n
> get displays this clearly (they give the same display as in the
> uninitialized case except for the .127 route).  Then if lo0 is
> ifconfig'ed again to fix this misconfiguration, the all routes related
> to the old lo0 (bogus or working) are deleted and not restored.  But
> if lo0 is brought up for the first time after em0, the the 0.0.0.0
> route related to the old lo0 is not deleted; it keeps breaking things.
>
>
> Bruce
>

Bruce,

When it is in the "broken" condition,  what is the output of "route -n get
0"?

So you have a default route? None appears in any of your messages. Normally
0 should route to default. In fact 0/0 is a definition of default. (Well, I
suppose anything/0 is default, but 0/0 is the normal representation.) Since
most systems have a default gateway defined, this may relate to the issue
you are seeing. I'm very unclear what happens with 0/0 if default is not
defined.

FWIW, here is what I see on this system (10.3-STABLE r299096):
Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.1.1        UGS         re0
127.0.0.1          link#2             UH          lo0
192.168.1.0/24     link#1             U           re0
192.168.1.16       link#1             UHS         lo0
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683