Date: Wed, 12 Apr 1995 01:18:39 -0500 (CDT) From: John Lind <john@starfire.mn.org> To: hackers@FreeBSD.org (FreeBSD hackers) Subject: undocumented features of route and netstat in FreeBSD 2.0(-950322-SNAP) Message-ID: <199504120618.BAA02125@starfire.mn.org>
next in thread | raw e-mail | index | archive | help
While I have mentioned the specific version of FreeBSD on which this
behavior was observed, I suspect that it may not be tied to that
specific release and is probably endemic to BSD 4.4Lite systems
of all sorts.
The problem appears when the -netmask optional qualifier is used
in an undocumented position relative to the other parameters of
the route command. I do not mean to open up old wars about
protecting users from every conceivable error in input, or the
"do what I say" argument, but there are some aspects of this that
I think you fill find interesting.
Before I go farther, let me be clear. Using the correct syntax
as documented in the manual gives the correct and expected
behavior as far as I am able to determine. This is by no
means a "bug" report nor is progress on any front halted
because of this. This is an FYI posting, though some of the
behavior documented herein is arguably "wrong."
If the -netmask qualifier is used immediately after the "add"
option keyword (with its appropriate mask value), rather than
in the correct position after the destination, the route
command does not complain. In fact, it reports "add net"
for both cases. The resulting route in the system tables
does not work as desired, however, and behaves as if it
were a host route entry. Now, here is the interesting part:
netstat -nr reports the working entry and the non-working entry
in such a way that it is not possible to distinguish the working
one from the non-working one.
Let me use an example for clarity.
route add -netmask 255.255.255.240 199.199.135.32 199.199.135.69
will report
add net 199.199.135.32: gateway 199.199.135.69
just as will
route add 199.199.135.32 199.199.135.69 -netmask 255.255.255.240
In fact, netstat -nr will show both routes identically. The first,
however, will behave in the same manner as a host route, and the second
will behave as desired.
Look, for example, and the following output of netstat -nr:
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 199.86.32.1 UGc 3 9591 ppp0
127.0.0.1 127.0.0.1 UH 0 2 lo0
199.86.32.1 199.86.32.169 UH 3 0 ppp0
199.86.32.169 127.0.0.1 UH 0 28 lo0
199.199.135.32 199.199.135.69 UGSc 0 0 ed0
199.199.135.64 link#1 UC 0 0 ed0 -84167
199.199.135.65 2:60:8c:43:fa:7c UHLW 0 10 lo0
199.199.135.69 0:20:af:2c:35:a3 UHLW 2 28 ed0 1018
199.199.135.96 199.199.135.69 UGSc 0 8 ed0
224 link#1 UCS 0 0 ed0 -112153
Of the two subnets .32 and .96, one was added with the trailing
-netmask qualifer and works, and one was added with the -netmask
qualifer right after the "add" keyword and does not have the
desired effect. Are you able to determine which is correct and
which is incorrect from the above output? I am not.
To verify that I was not imagining things or attributing behavior
to one thing when another was responsible, I removed the subnet
route entries for .32 and .96 and re-added them, reserving their
"roles" -- that is, the syntax I had used vs. the correct syntax.
Also note that not only is the "confirmation" output of the route
command is identical using either command syntax:
add net ww.xx.yy.zz: gateway aa.bb.cc.dd
but using -net will also force the confirmation to say "net" rather
than "host", though without the trailing -netmask suboption, it will
behave as a host route.
I'd be willing to write a FAQ on this except for the following:
1) the documentation (man page) describes the correct syntax
which gives the desired behavior
2) there has already been plenty written about subnets and
their use (RFC's, etc.)
3) I don't understand well enough what route, netstat,
and the kernel are doing in the cases which appear "wrong"
to know that they are, indeed, wrong and not the action
or side-effect of some other desired behavior.
Still, if someone thought a FAQ was meritted, I'd undertake to
understand things well enough to try it.
I hope that this information is of use, or at least interest, to
someone.
John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG USnail: PO Box 17247, Mpls MN 55417
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504120618.BAA02125>