Date: Wed, 09 Oct 1996 22:18:15 -0700 From: Julian Elischer <julian@whistle.com> To: hackers@freebsd.org Subject: Annoying artifact of the routing code Message-ID: <325C8717.167EB0E7@whistle.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?325C8717.167EB0E7>