Date: Wed, 13 Jun 2001 20:40:35 +0900 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 Message-ID: <y7vpuc8sj4c.wl@condor.jinmei.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vpuc8sj4c.wl>