From ceharris@anthill.cns.vt.edu  Sat Mar 15 06:38:09 1997
Received: from anthill.cns.vt.edu (anthill.cns.vt.edu [198.82.250.228])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA25008
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Mar 1997 06:38:07 -0800 (PST)
Received: (from ceharris@localhost) by anthill.cns.vt.edu (8.8.5/8.7.3) id JAA26129; Sat, 15 Mar 1997 09:37:59 -0500 (EST)
Message-Id: <199703151437.JAA26129@anthill.cns.vt.edu>
Date: Sat, 15 Mar 1997 09:37:59 -0500 (EST)
From: ceharris@vt.edu
Reply-To: ceharris@vt.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: RTF_LLINFO route problem
X-Send-Pr-Version: 3.2

>Number:         2991
>Category:       kern
>Synopsis:       RTF_LLINFO routes remain when interface is downed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 15 06:40:01 PST 1997
>Closed-Date:    Tue Sep 26 10:37:29 PDT 2000
>Last-Modified:  Tue Sep 26 10:39:01 PDT 2000
>Originator:     Carl Harris
>Release:        FreeBSD 2.1.7-RELEASE i386
>Organization:
Communication Systems Lead Engineer
                 CNS Research and Planning, Virginia Tech
>Environment:

Pertains to 2.1.x-RELEASE (x <= 7).  I have not verified this behavior 
for later releases.

>Description:
	
When the IP address associated with an ethernet interface is deleted (via 
ifconfig delete) and the interface is downed (via ifconfig down), routes
of type RTF_LLINFO which use the downed interface remain in the route 
table.

This will cause problems on a multi-homed host.  An attempt to connect to
a host with an extant RTF_LLINFO route will be routed to the downed  
interface, even though the host may be reachable via an alternative interface.

>How-To-Repeat:

Assign an IP address to an ethernet interface on a live network.  Ping
several hosts on the local subnet.  Delete and down the interface via
ifconfig.  Run netstat -rn and observe that RTF_LLINFO routes for the
pinged hosts via the down interface still exist in the route table.

>Fix:

Flush all RTF_LLINFO routes for an interface when that interface is
downed.
>Release-Note:
>Audit-Trail:

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++;
  			}
 

From: "Kevin Bracey" <kevin@bracey-griffith.freeserve.co.uk>
To: <freebsd-gnats-submit@freebsd.org>, <ceharris@vt.edu>
Cc:  
Subject: Re: kern/2991: RTF_LLINFO routes remain when interface is downed
Date: Fri, 25 Jun 1999 21:05:41 +0100

 I've just independently discovered this problem in my FreeBSD-derived
 network stack. In my case it is causing problems when the address of an
 interface is changed - outgoing packets will have the old source IP address!
 
 This is potentially serious for me, as the systems will otherwise be fully
 capable of full run-time IP
 address reassignment via DHCP.
 
 Has there been any further progress on this problem? How confident are we
 with Andrey Alekseyev's patch?
 
 Many thanks,
 
 Kevin Bracey
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Tue Sep 26 10:37:29 PDT 2000 
State-Changed-Why:  
Fixed in src/sys/net/if.c,v 1.81. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2991 
>Unformatted:
