On Sun, May 29, 2016 at 12:12 AM, Bruce Evans <b...@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: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
