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." _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"