Date: Sun, 29 May 2016 17:12:01 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: David DeSimone <ddesimone@verio.net>, "net@freebsd.org" <net@freebsd.org> Subject: RE: ifconfig creates a bogus(?) route Message-ID: <20160529163228.I1958@besplex.bde.org> In-Reply-To: <20160529111806.I1012@besplex.bde.org> References: <20160528154122.C1843@besplex.bde.org> <SN1PR08MB1821D18DE13FB882ED3BA327BA430@SN1PR08MB1821.namprd08.prod.outlook.com> <20160529111806.I1012@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160529163228.I1958>