ifconfig creates a bogus(?) route

Bruce Evans brde at optusnet.com.au
Sun May 29 07:12:13 UTC 2016


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


More information about the freebsd-net mailing list