From owner-freebsd-hackers Tue Mar 4 00:21:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA05927 for hackers-outgoing; Tue, 4 Mar 1997 00:21:46 -0800 (PST) Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05916 for ; Tue, 4 Mar 1997 00:21:43 -0800 (PST) Received: from chai.plexuscom.com (localhost.torrentnet.com [127.0.0.1]) by chai.plexuscom.com (8.8.5/8.8.5) with ESMTP id DAA00463; Tue, 4 Mar 1997 03:21:55 -0500 (EST) Message-Id: <199703040821.DAA00463@chai.plexuscom.com> To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: [FUN/WORK] BSD Networking virtual meeting. In-reply-to: Your message of "Mon, 03 Mar 1997 21:32:13 PST." <331BB3DD.41C67EA6@whistle.com> Date: Tue, 04 Mar 1997 03:21:55 -0500 From: Bakul Shah Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If you invalidate and ifaddr, the routes that were set up > do not notice, because they have both a pointer to the ifaddr, > and a pointer to the ifnet. This is bogus.. Code implementing ifaddr deletion: `ioctl(fd, SIODIFADDR, ..)' calls `in_ifscrub(ifp, ia)' which calls rtinit(.., RTM_DELETE, ..) which calls rtrequest(.., RTM_DELETE, ..). This _should_ clear out the route, no? As you are well aware, this code is hard to follow -- single stepping through it under gdb and with an appropriate test case may help elucidate its logic. Then again.... > The other part of the equation is to be proactive about it > and whenever an ifaddr is removed, clean out any affected routes > in the routing table. I think this is already supposed to happen. > This is where I'm hitting problems. > at the moment, ARP entries are being removed from the table, > but not from the ARP list, (llinfo is not being taken out of the) > llinfo list when they are removed due to a change in ifaddr. > eventually the llinfo times out (18 minutes arp timeout) > and the code suddenly discovers that the rest of that route > was freed ages ago, and falls off a random pointer. llinfos are on a linked list only so that the arptimer() routine can `garbage collect' old route entries. It calls arptfree for expired entries, which in turn calls rtrequest(.., RTM_DELETE, ..) if rt->rt_refcnt is 0. AFAIK this is supposed to happen. If you are falling off a random pointer, may be rtfree is being called on an already freed rtentry? Anyway, non-zero rt_llinfo by itself should not matter as the route has already been declared down when you deleted the address. If you have a simple enough test I can run it here to check out what is going on. -- bakul PS: another bug that people have seen may have some bearing on whatever you are seeing: 1: ifconfig de0 # note inet address. call it addr-A. 2: ping foo # make sure this works fine for some host foo 3: ifconfig de0 inet addr-B netmask ... # change to some other address 4: ping -n foo # this won't work! You may need to use a numeric address for foo so as to cut DNS out of the loop. Now if you watch ping packets with tcpdump, you will notice they still have the *old* IP address, addr-A! foo will actually reply but your machine will keep waiting as it is looking for packets to addr-B.