From owner-freebsd-bugs Wed Aug 14 12:30:17 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 566B737B400 for ; Wed, 14 Aug 2002 12:30:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07CE143E3B for ; Wed, 14 Aug 2002 12:30:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.4/8.12.4) with ESMTP id g7EJU3JU026468 for ; Wed, 14 Aug 2002 12:30:03 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.4/8.12.4/Submit) id g7EJU318026467; Wed, 14 Aug 2002 12:30:03 -0700 (PDT) Date: Wed, 14 Aug 2002 12:30:03 -0700 (PDT) Message-Id: <200208141930.g7EJU318026467@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Qing Li" Subject: RE: kern/41494: static routes set with interface address as gateway are non-functional Reply-To: "Qing Li" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/41494; it has been noted by GNATS. From: "Qing Li" To: "QING LI" , "Ruslan Ermilov" Cc: Subject: RE: kern/41494: static routes set with interface address as gateway are non-functional Date: Wed, 14 Aug 2002 12:28:29 -0700 > > > This route addition should be allowed as a place holder > > to be filled in later, similar to of an entry with RTF_LLINFO flag. > > > I disagree. In your ``route add'', you specified a gateway and you > get what you requested. What would be a purpose of adding such a > route? > This issue came up while I was trying to narrow down an EHOSTUNREACH problem when running PPP over IPv6. > > > It's possible to create such an entry (though a bit tricky) even without > patching sys/net/route.c: > > route -vn add -host 147.11.38.15 -link : -ifp rl0 -iface > This would be one reason. > > ARP can already do this for you by cloning from the network > route, > Right, and I am aware of that. My point is, however, that the code tries to validate gateway reach-ability for indirect routes. So why can't that code be extended to make an attempt in determining whether a route should be converted from RTF_GATEWAY to RTF_LLINFO during the insertion process. > > adding route with the gateway of some of the local addresses > has its own purpose; > No disagreement here. > > e.g. one can put a divert(4) daemon listetning > on lo0 that would get these packets. Or: > I don't really see how that is of what you said above looking at ip_output and divert_packet. But I think I understand what you are getting at. I am also trying to find a case, if any, that would indicate the code change would break the existing operation. > > # ifconfig rl0 inet > rl0: flags=8843 mtu 1500 > inet 192.168.4.115 netmask 0xffffff00 broadcast 192.168.4.255 > # ifconfig rl0 192.168.4.201/32 alias > # route delete 192.168.4.201/32 > delete net 192.168.4.201 > # route add 192.168.4.201 192.168.4.115 > add host 192.168.4.201: gateway 192.168.4.115 > # ping -c1 192.168.4.201 > PING 192.168.4.201 (192.168.4.201): 56 data bytes > 64 bytes from 192.168.4.201: icmp_seq=0 ttl=64 time=0.088 ms > --- 192.168.4.201 ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.088/0.088/0.088/0.000 ms > # > Hmmm.... That is not what I get after doing the exact same thing as the above (without any modification of course). Using your example, my route table looks like the following: Internet: Destination Gateway Flags Refs Use Netif Expire 192.168.4.201 192.168.4.115 UGHS 0 3 rl0 > > > } > > + if (rt->rt_gwroute->rt_ifp && > > + (rt->rt_gwroute->rt_ifp->if_flags & IFF_LOOPBACK)) > > + { > > + rt->rt_gwroute = 0; > > This leaks. You need to RTFREE() it first. > Nice catch. Thank you. > > I think this might make the ``route add'' I quoted above to do > what you want, > It does just that though I haven't tested the code exhaustively to see if it broke something. -- Qing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message