Date: Wed, 14 Aug 2002 12:30:03 -0700 (PDT) From: "Qing Li" <Qing.Li@windriver.com> To: freebsd-bugs@FreeBSD.org Subject: RE: kern/41494: static routes set with interface address as gateway are non-functional Message-ID: <200208141930.g7EJU318026467@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/41494; it has been noted by GNATS. From: "Qing Li" <Qing.Li@windriver.com> To: "QING LI" <qing.li@windriver.com>, "Ruslan Ermilov" <ru@freebsd.org> Cc: <bug-followup@freebsd.org> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208141930.g7EJU318026467>