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>