ifconfig creates a bogus(?) route

[Kimmo Paasiala]

On Sat, May 28, 2016 at 10:19 AM, Bruce Evans <brde at optusnet.com.au> wrote:
> Sometime between r191220 and r201220, ifconfig started creating a bogus(?)
> static route.  The following is under r248255 with
> "ifconfig em0 inet 192.168.2.8" (where 192.168.2.8 is for the local host
> and I don't bother typing the netmsk) done before bringing up lo0:
>
> Routing tables
>
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> 192.168.2.0/24     link#1             U           0        0    em0
> 192.168.2.8        link#1             UHS         0        0    lo0
>
> The bogus(?) route points to itself (route get shows this more clearly),
> and doesn't work.  I know little about routiing, but can fix things like
> this manually.  Simply "route delete" on the bogus(?) route works in this
> case.  An alias for lo0 also works.
>
> Netif is lo0 although lo0 is not up yet.  Normally lo0 is brought up before
> em0.  This makes no obvious difference, but then bringing up lo0 again
> removes the bogus(?) route.  The order em0, lo0, lo0 doesn't remove the
> bogus(?) route.
>
> After the bogus(?) route is removed, netstat -r[n] stops showing any route
> except in old versions of FreeBSD it does show it as something like
> "192.168.2.8 <mac address> UHLW 0 <many> em0 <many>" after using it.
> (I use many different kernel versions and only a 1 userland version
> except for utilities like netstat whose ABI keeps breaking, and
> haven't found newer version of netstat and/or flags on it to show
> all the details.)  Similary for other local machines.
>
> After the bogus(?) route is removed, route get 192.168.2.8 shows a working
> route even before it is used.  The main differences are that the
> destination changes from 192.168.2.8 (self) to 192.168.2.0 (link) and
> the interface changes from em0 to if0.  That actually seems more bogus --
> it will have to be translated back to the "bogus(?) route to work.
>
> How is this supposed to work?  freefall seems to have the bogus(?) route,
> but it works.  Routing utilities seem to be broken on ref11-i386
> (route can't even find localhost).
>
> Bruce


As far as I know there's nothing wrong with those two routes. They are
both needed to allow local connections to the address bound on the
interface to be sourced from the localhost 127.0.0.1 address and
traffic leaving the system via the interface to be sourced from the
address bound on the interface. Someone correct me if I'm off with the
details.

-Kimmo