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

[Rodney W. Grimes]

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

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