From owner-freebsd-hackers Tue Apr 11 23:19:40 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA29054 for hackers-outgoing; Tue, 11 Apr 1995 23:19:40 -0700 Received: from kksys.skypoint.net (kksys.skypoint.net [199.86.32.5]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id XAA29048 for ; Tue, 11 Apr 1995 23:19:38 -0700 Received: from starfire.mn.org by kksys.skypoint.net with smtp (Smail3.1.29.1 #2) id m0ryuqP-0003UDC; Wed, 12 Apr 95 00:20 CDT Received: (from john@localhost) by starfire.mn.org (8.6.8/1.2.1) id BAA02125 for hackers@FreeBSD.org; Wed, 12 Apr 1995 01:18:40 -0500 From: John Lind Message-Id: <199504120618.BAA02125@starfire.mn.org> Subject: undocumented features of route and netstat in FreeBSD 2.0(-950322-SNAP) To: hackers@FreeBSD.org (FreeBSD hackers) Date: Wed, 12 Apr 1995 01:18:39 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4431 Sender: hackers-owner@FreeBSD.org Precedence: bulk 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