Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 May 2016 17:19:17 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        net@freebsd.org
Subject:   ifconfig creates a bogus(?) route
Message-ID:  <20160528154122.C1843@besplex.bde.org>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160528154122.C1843>