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>