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>