Date: Mon, 28 Apr 1997 21:57:07 -0400 From: Rohit Dube <rohit@cs.umd.edu> To: Archie Cobbs <archie@whistle.com> Cc: rohit@cs.umd.edu (Rohit Dube), hackers@freebsd.org Subject: Re: Bizzare Ping (and other) bugs. Message-ID: <199704290157.VAA27764@darling.cs.umd.edu> In-Reply-To: Your message of "Mon, 28 Apr 1997 18:25:20 PDT." <199704290125.SAA17527@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Apr 1997 18:25:20 -0700 (PDT) archie@whistle.com writes: =>Easier noted than fixed, unfortunately... but maybe someday... Julian E. =>has looked at this a good deal. => Thanks for your note. =>The problem is that the networking code isn't real good at keeping =>track of what's pointing at what other structures, and it can't =>completely free old interface addresses since a route in the routing =>table may still point to it, etc. That's my level of detail of =>understanding anyway. We traced it down. The problem boils down to the following - rip_output()/other_outputs() calls ip_output(). ip_output() finds the route based on the destination address. Since this route (rtentry) contains a pointer to the old in_ifaddr structure corresponding the previous address, ip_output() uses the wrong address to source the packet and things go bad. The solution is to delete all routes going out the changed interface. When a packet needs to go out the interface for a now missing route, it is cloned appropriately. The problem is that some PCBs cache routes. I haven't checked this out but, these cached routes should still cause a problem as they would point to the old in_ifaddr. These would have to be caught separately, unless one wants to sweep thru all the PCBs and fix them when the interface address changes. (I would go for the second option as address change is a rare event). Yes, easier said than done; but we'll probably be implementing this locally. --rohit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704290157.VAA27764>