Re: interesting routing bug...

Alexander V. Chernikov wrote this message on Thu, Jan 09, 2014 at 15:04 +0400:
> On 09.01.2014 05:18, John-Mark Gurney wrote:
> >Well, I was trying to manually add a route for a host on the local
> >network (I can explain why, but it doesn't matter) and I got this:
> Hello!
> There are several different kernel & userland bugs :)
> 
> ># netstat -rnfinet
> >Routing tables
> >
> >Internet:
> >Destination        Gateway            Flags    Netif Expire
> >default            192.168.0.14       UGS       re0
> >127.0.0.1          link#3             UH        lo0
> >192.168.0.0/24     link#1             U         re0
> >192.168.0.21       link#1             UHS       lo0
> ># route add -host 192.168.0.254 -interface re0 -link 04:4a:31:d3:95:dc
> >add net 192.168.0.254: gateway re0
> "-link" specifier assumes no parameter, so the next argument is treated 
> as netmask (since dst/gw are already supplied).

Ahh, now I understand the following:
     The optional modifiers -xns, -osi, -atalk, and -link specify that all
     subsequent addresses are in the XNS, OSI, or AppleTalk address families,
     or are specified as link-level addresses, and the names must be numeric
     specifications rather than symbolic names.

>From what you state above, it appears you're saying that -interface re0
becomes the gateway, but the man page isn't clear about that...  In the
above command, I assume that the -interface is being interpeted as the
gateway.

     If the destination is directly reachable via an interface requiring no
     intermediary system to act as a gateway, the -interface modifier should
     be specified; the gateway given is the address of this host on the common
     network, indicating the interface to be used for transmission.  Alter-
     nately, if the interface is point to point the name of the interface
     itself may be given, in which case the route remains valid even if the
     local or remote addresses change.

Because I didn't give it a common address (I assume IP) and I didn't give
it a PTP interface.  Maybe something like:
... the -interface modifier should be specified.  If the specified gateway
is an address on this host, use the interface that the address is on.
If the gateway is the name of the interface then the route remains valid
even if the local address changes.

This way it will be more clear that -interface is a modifier for the
gateway argument instead of still requiring you to specify a gateway
in addition to the -interface.

Part of my confusion was that the gateway returned was a mac address...
I assumed it was bogus junk, but it turns out that it's the mac address
of my local interface instead of link#1 or the mac address of the
destination system like it was on 9.x and before.

> It is successfully parsed by getaddr() as AF_LINK sockaddr.
> 
> I've added additional check which requires dst/mask address families to 
> be equal (r260472).

Thanks.

> Historically, our kernel is a bit relaxed on checking validness for 
> network masks:
> it does not check family& does not perform usual (addr&mask == addr) check.
> masked copy is performed instead. This is a bit tricky to fix since most 
> in-kernel consumers are supplying non-masked address.
> I'm going to fix this soon.
> 
> 
> ># netstat -rnfinet
> >Routing tables
> >
> >Internet:
> >Destination        Gateway            Flags    Netif Expire
> >0.0.0.0&0x20500    90:2b:34:ab:bb:85  US        re0
> Basically kernel treats sockaddr_dl as non-contiguos mask.
> >default            192.168.0.14       UGS       re0
> >10.0.0.0/8         link#2             U        msk0
> >10.42.42.21        link#2             UHS       lo0
> >127.0.0.1          link#3             UH        lo0
> >192.168.0.0/24     link#1             U         re0
> >192.168.0.21       link#1             UHS       lo0
> ># route delete 0.0.0.0
> >delete net 0.0.0.0
> ># route flush
> Our rtsock protocol does not provide rtable flush, so internally 
> route(8) does route dump for given table and issues RTF_DELETE messages 
> for every route.
> It seems that non-contiguous masks are handled incorrectly here..

Ok, thanks for pointers on where to look.  The above did solve my
problem in that I just needed to leave off the -link xxx arg, and I
was able to do what I wanted to...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."