From owner-freebsd-hackers  Wed Oct  9 22:21:32 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA18891
          for hackers-outgoing; Wed, 9 Oct 1996 22:21:32 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA18881
          for <hackers@freebsd.org>; Wed, 9 Oct 1996 22:21:29 -0700 (PDT)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id WAA23532 for <hackers@freebsd.org>; Wed, 9 Oct 1996 22:20:13 -0700 (PDT)
Message-ID: <325C8717.167EB0E7@whistle.com>
Date: Wed, 09 Oct 1996 22:18:15 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: hackers@freebsd.org
Subject: Annoying artifact of the routing code
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

The following bug has been annoying us here for ages
I recently decided to track it down..


set up device (ethernet) to use address A.B.C.D

do some work

change device to new address A.B.C.E

look on network.
notice packets coming from A.B.C.D

the mechanism:

the IP code, when figuring out it's local address finds the route
to the destination, and uses that. The route has a pointer to the 
ifaddr at the time it was created. It's actually a llinfo
entry and has been set up by arp.
That ifaddr is no longer valid, but is used by IP to set it's
"from" address. This means that some clients cannot RESPOND
to the client untill such a time as the arp entry times out.
(in theory, however I've never waited that long to find out).

Things I've thought of to fix it..
ARP entries are CLONED.. however when removing a route, onlty
PRCLONING routes have all their derived routes removed, while CLONING
routes do not.

I made the following patch:
Index: route.c
===================================================================
RCS file: /cvs/freebsd/src/sys/net/route.c,v
retrieving revision 1.37
diff -r1.37 route.c
453c453
<               if ((rt->rt_flags & RTF_PRCLONING) && netmask) {
---
>               if ((rt->rt_flags & (RTF_PRCLONING|RTF_CLONING)) && netmask) {
578c578
<                       if ((*ret_nrt)->rt_flags & RTF_PRCLONING) {
---
>                       if ((*ret_nrt)->rt_flags & (RTF_PRCLONING|RTF_CLONING)) {


just to see what would happen.
Well, the routes certainly dissappeared, but arp routes disappeared
IMMEDIATLY, even without changing the net address.
So something else would need to be fixed as well.

It seems to me that the whole section needs to be cleaned up a bit,
with correct referenc counting being extended a bit further,
and correct invalidation of derived (WAS_CLONED) routes
when the master(as referenced by rt_parent)
is invalidated.

Does anyone have any reasons why the cleaning extended to
PRCLONING routes should not extend also to CLONING
routes?

Garret?

julian