From owner-freebsd-net  Wed Jun 13  4:43:46 2001
Delivered-To: freebsd-net@freebsd.org
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by hub.freebsd.org (Postfix) with ESMTP id 637BF37B40A
	for <freebsd-net@freebsd.org>; Wed, 13 Jun 2001 04:43:35 -0700 (PDT)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from localhost ([3ffe:501:100f:10c1:cc49:49d8:1293:51aa])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA04600
	for <freebsd-net@freebsd.org>; Wed, 13 Jun 2001 20:43:47 +0900 (JST)
Date: Wed, 13 Jun 2001 20:40:35 +0900
Message-ID: <y7vpuc8sj4c.wl@condor.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: freebsd-net@freebsd.org
Subject: a comment about a recent change on the route(8) command
User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 50
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

I have a tiny comment about the following change to the route(8)
command:
http://www.jp.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/route/route.c.diff?r1=1.49&r2=1.50

In the commit log, the committer said

  Fixed the -iface breakage introduced with the latest KAME merge
  in revision 1.48.  It is pretty valid and often feasible to use
  a non-point-to-point interface as the gateway.

However, I'd say it is not a breakage, but just a fix of a bug.
Actually, the very old versions (before KAME) had a check not to allow
installing such a route to non-p2p-interfaces:

			/* Look for this interface in the list */
			for (ifr = ifconf.ifc_req,
			    ifr_end = (struct ifreq *)
				(ifconf.ifc_buf + ifconf.ifc_len);
			    ifr < ifr_end;
			    ifr = (struct ifreq *) ((char *) &ifr->ifr_addr
				    + MAX(ifr->ifr_addr.sa_len,
					sizeof(ifr->ifr_addr)))) {
				dl = (struct sockaddr_dl *)&ifr->ifr_addr;
				if (ifr->ifr_addr.sa_family == AF_LINK
---->				    && (ifr->ifr_flags & IFF_POINTOPOINT)
				    && !strncmp(s, dl->sdl_data, dl->sdl_nlen)
				    && s[dl->sdl_nlen] == 0) {

However, the check is wrong, because ifr_flags is not a valid value in
this context (recall that the ifreq structure is a union of
sockaddr{}, an integer, etc.).  Surprisingly, the bug introduced a
side-effect that made this type of route installation possible on
*every* type of interface;  In this context, if_flags tend to be
0x123?, where 0x12 is AF_LINK, and 0x3? is a length of the sockaddr
for ordinary link (such as ethernet).  Since IFF_POINTOPOINT is
0x0010, the check tended to misunderstand the interface is a
point-to-point one.

The change introduced with the KAME patch just intended to implement
the check in the original code correctly.

I don't have any particular opinion on the behavior itself, though.
If this is from a consensus in the FreeBSD community, I'm just okay
with the policy.  I just would like to clarify the reason of the
KAME's change.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message