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

[Rodney W. Grimes]

> 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?

.0.0/16 is not a valid host specification,
it is a network specification.

But I know what might work though still invalid....
ifconfig_lo1="inet 10.241.0.0/32"


> 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.

A p2p link does not even require the same subnet on both ends, you
can p2p 10.241.1.1/32 to 192.168.1.1/32.  If you look at the addresses
on the ends of a p2p they should actually be set /32.

> > >          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