Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2001 16:03:23 +0300
From:      Ruslan Ermilov <ru@FreeBSD.ORG>
To:        JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: a comment about a recent change on the route(8) command
Message-ID:  <20010613160323.C30602@sunbay.com>
In-Reply-To: <y7vpuc8sj4c.wl@condor.jinmei.org>; from jinmei@isl.rdc.toshiba.co.jp on Wed, Jun 13, 2001 at 08:40:35PM %2B0900
References:  <y7vpuc8sj4c.wl@condor.jinmei.org>

next in thread | previous in thread | raw e-mail | index | archive | help
My apologies, I didn't realize that the old code was broken.
Yes, ifr_flags is only valid in the SIOCGIFFLAGS context.

On Wed, Jun 13, 2001 at 08:40:35PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> 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

-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010613160323.C30602>