'no route to host" for cloned lo1 iface 12.0-CURRENT r334376+56a973815425(master) amd64

Andreas Nilsson andrnils at gmail.com
Thu May 31 06:41:47 UTC 2018


On Thu, May 31, 2018, 00:13 Rodney W. Grimes <
freebsd-rwg at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Wed, 30 May 2018, at 17:46, Rodney W. Grimes wrote:
> > > > > > > > ifconfig_lo1_aliases="inet 10.241.0.0-15/16"
> >
> > > > > > > > lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu
> 16384
> > > > > > > >         inet 10.241.0.0 netmask 0xffff0000
> > > > > > > >         inet 10.241.0.1 netmask 0xffffffff
> > > > > > > >         inet 10.241.0.2 netmask 0xffffffff
> >
> > Thanks Rod, Andreas, Herbert for your help! Back at a proper computer
> now.
> >
> >  I think there are 2 things; invalid IP (see end for some interesting
> notes), and also expansion of ifconfig_<if>_aliases.
> >
> > # ifconfig_$(if)_aliases
> >
> > This is my config:
> >
> > > cloned_interfaces="lo1"
> > > ifconfig_lo1_aliases="inet 10.24 1.0.0-15/16"
> I am not even sure that parses????
>
> >
> > But,  I *don't* have a line like this:
> >
> > > ifconfig_lo1="inet 10.241.0.0/16"
>
> This should be an error, or as per rfc treated as
> "10.241.255.255/16" which should also be an error.
>
> >
> > and if I add it and bump the range to 10.241.0.1/16,  then all is well
> again and ping $DODGY_IP works again, but I get 2 entries with /16 mask:
> >
> > inet 10.241.0.0 netmask 0xffff0000
> This should not be allowed.
>
> > inet 10.241.0.1 netmask 0xffff0000
> This is correct.
>
> > inet 10.241.0.2 netmask 0xffffffff
> >
> > So the solution seems to be this, to keep the 0xfff0000 to just 1 IP:
> >
> > > cloned_interfaces="lo1"
> > > ifconfig_lo1="inet 10.241.0.0/16"
> > > ifconfig_lo1_aliases="inet 10.24 1.0.0-15/16"
>

How about
cloned_interfaces="lo1"
ifconfig_lo1="inet 10.241.0.0/16”
ifconfig_lo1_aliases="10.241.0.1-15/32”

There is one other way, but I need to get to a computer to verify it.

>
> > Presumably I've copy-pasted this a long time ago and never questioned
> it. I checked several random websites, and there are quite a few skipping
> `ifconfig_lo1`, using just the aliases, and mainly with jail configs, so I
> guess this change will catch other people too.
> >
> > I'm not sure what's changed, as nothing recent in /etc/rc.d or
> /etc/network.subr commits seems related. What's the best option here?
> >
> > Just a doc patch saying you can't use aliases without a prior
> ifconfig_<if> ?
>
> I do not believe that needs to be a requirement.
>
> >
> > # invalid IP
> >
> > TLDR 10.241.0.0/16  is technically not a valid host IP but it has
> obviously worked in the past.
> Yes, and that working in the past is bad,
> probably need to see how far back this bug goes.
> Eeekks.. it goes back to at least 5.4 which means
> it is bad behavior we are probably going to have to fix.  :-(
>
> > I've been binding 10.241.0.1-15 to jail IPs, and abusing 10.241.0.0 as
> the "magic ip" that is bound to net/haproxy or spiped in the host system to
> broker exernal connections into the jail IP ranges from external internet.
> I will rectify my configuration  but I will miss the symmetry :-)
> >
> > https://tools.ietf.org/html/rfc1122#section-3.3.6 is the closest
> description I could find for this. Interestingly, they blame 4.2BSD for
> this and say it's addressed since 4.3:
> >
> > ## 3.3.6  Broadcasts
>             ^^^^^^^^^^
> This is not the all 0's host value, but the all 1's host value,
> these rules are VERY well known and enforced.  I am actually
> amazed that this use of 0 has not been RFC'ed out of existance,
> as far as I know all the other stuff says that the 0th host
> on a network is reserved for indicating the Network.
>
> If you look at all the tables on cidr and such they say
> the valid host ranges are 1 to (END - 1)  Leaving out
> the host part value of 0.
>

Well, setting up point-to-point links for bgp and stuff it happens
frequently that /31s are used to conserve ip space, which is sort of
equivalent to having host ip of .0.

>
> >          Section 3.2.1.3 defined the four standard IP broadcast address
> >          forms:
> >            Limited Broadcast:  {-1, -1}
> >            Directed Broadcast:  {<Network-number>,-1}
> >            Subnet Directed Broadcast:
> >                               {<Network-number>,<Subnet-number>,-1}
> >            All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
> >          A host MUST recognize any of these forms in the destination
> >          address of an incoming datagram.
> >          There is a class of hosts* that use non-standard broadcast
> >          address forms, substituting 0 for -1.  All hosts SHOULD
>                                                             ^^^^^^
> >          recognize and accept any of these non-standard broadcast
>                                              ^^^^^^^^^^^
> >          addresses as the destination address of an incoming datagram.
>
> Ok, so we *SHOULD* be mapping the 10.241.0.0 to 10.241.255.255 which
> should of caused ALL the hosts on that subnet to respond to the ping.
>
> Someone want to investiage linux on this one?
>
> > _________________________
> > *4.2BSD Unix and its derivatives, but not 4.3BSD.
>
> --
> Rod Grimes
> rgrimes at freebsd.org
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>


More information about the freebsd-net mailing list