Date: Thu, 20 Aug 1998 05:00:01 -0700 (PDT) From: Andrey Alekseyev <fetch@muffin.arcadia.spb.ru> To: freebsd-bugs@FreeBSD.ORG Subject: Re:kern/2991 Message-ID: <199808201200.FAA10319@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/2991; it has been noted by GNATS.
From: Andrey Alekseyev <fetch@muffin.arcadia.spb.ru>
To: freebsd-gnats-submit@freebsd.org, ceharris@vt.edu
Cc: Subject: Re:kern/2991
Date: Thu, 20 Aug 1998 15:55:18 +0400 (MSD)
At attempt to connect to a host via a link layer cloned route
that remains in the routing table until gets expired, is failing
because yes, this route still contains a pointer to the old
interface configuration structure (unallocated by that time yet?
as far as I could understand, exactly like that) and ip_output
puts the old interface address to the packed ready for output.
Now the gory details why this happens:
How ll cloned route is created:
1. interface is being configured. On some step of this configuration
route to corresponding network is added
2. some packet is ready to be out on this interface. In ip_output
rtalloc_ign(ro, RTF_PRCLONING) is called to find route to the
destination
3. rtalloc_ign calls rtalloc1 that finds route to network created
when corresponding interface was created and then tries to allocate
route to destination
4. it calls rtrequest
5. rtrequest allocates a new rtentry and on some internal step
will call ifa->ifa_rtrequest for used interface (arp_rtrequest),
ifa->ifa_rtrequest allocates some ll info
6. finally route is ready and has the flag RTF_WASCLONED (route
to network from which it was cloned has the flag RTF_CLONING on
it)
7. packet is out
Now changing or deleting interface configuraion:
1. interface losts its address. On some step in_ifscrub is called
that will try to remove any route to the interface address that
is being deleted
2. in_ifscrub calls rtinit with RTM_DELETE parameter
3. rtinit on some step call rtrequest with cmd = RTM_DELETE
4. what happens in rtrequest_delete is a little bit strange -
it doesn't do anything that will delete routes cloned from
the route being deleted (not protocol-cloned). I.e. it apparently
doesn't even try to locate routing entries cloned from this
route.
The only pretty simple changes to the route.c that came to
my mind are:
in rtrequest_makeroute when checking if the route is
protocol-cloned check also if it's ll cloned and
create a link to parent route in this case also,
then in rtrequest_delete when checking for cloned routes
look also for any ll cloned routes if there is RTF_CLONING
flag on the route we are deleting.
Apparently this seems pretty functional but I'm not sure
if it's 100% correct. Also netstat behaves itself
somewhat incorrectly with this fix and requires a minor
changes too. It stops showing ll cloned entries with this
fix without an -a flag and that's because it assumes that
having non-zero rt_parent pointer means the route
is _protocol_cloned_.
The FreeBSD version I'm now using and the route.c was
examined on is FreeBSD 2.2.6-RELEASE
--- route.c Tue Aug 18 13:32:27 1998
+++ route.c.orig Tue Aug 18 13:30:29 1998
@@ -450,7 +450,7 @@
* Now search what's left of the subtree for any cloned
* routes which might have been formed from this node.
*/
- if ((rt->rt_flags & (RTF_CLONING | RTF_PRCLONING)) && netmask) {
+ if ((rt->rt_flags & RTF_PRCLONING) && netmask) {
rnh->rnh_walktree_from(rnh, dst, netmask,
rt_fixdelete, rt);
}
@@ -575,8 +575,7 @@
if (req == RTM_RESOLVE) {
rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */
- if ((*ret_nrt)->rt_flags &
- (RTF_CLONING | RTF_PRCLONING)) {
+ if ((*ret_nrt)->rt_flags & RTF_PRCLONING) {
rt->rt_parent = (*ret_nrt);
(*ret_nrt)->rt_refcnt++;
}
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?199808201200.FAA10319>