Date: Mon, 28 Jun 1999 17:35:02 +0100 From: Kevin Bracey <kbracey@e-14.com> To: freebsd-net@freebsd.org Subject: Re: Old IP addresses hanging around in routes Message-ID: <708f551949%kbracey@kbracey.acorn.co.uk> In-Reply-To: <199906281612.MAA17098@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199906281612.MAA17098@khavrinen.lcs.mit.edu>
Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
>
> There is supposed to be code in there to delete all of the
> (non-static) routes which refer to a specific interface when that
> interface goes down. At least, I feel fairly certain that I wrote
> code to do that; I can't seem to find it right now. I think
> in_ifscrub ought to be doing it, but I don't see the code that would,
> either there or in rtinit. The cloned-route cleanup in
> rtrequest(RTM_DELETE,...) ought to take care of it too.
The only code that appears to attempt a clean-up is the bit that
cleans up protocol-cloned routes. That correctly catches this case:
route add default my-router
telnet machine.outside.router (TCP clones route)
route delete default (cloned route deleted)
However, the cases that don't seem to be caught are:
A) ifconfig eh0 192.168.0.1 (interface route created)
ping 192.168.0.5 (cloned route with ARP info created)
ifconfig eh0 192.168.0.2 (old interface route deleted,
new one created, cloned route
left untouched)
ping 192.168.0.5 (doesn't work - outgoing packets
have wrong source IP)
ping 192.168.0.6 (works ok)
B) ifconfig eh0 192.168.0.1 (interface route created)
route add default 192.168.1.0
telnet 3.3.3.3 (TCP clones route)
ifconfig eh0 192.168.0.2 (default route and cloned route
untouched)
telnet 3.3.3.3 (doesn't work - local address of
connection is 192.168.0.1)
ping 4.4.4.4 (doesn't work - outgoing packets
have source IP 192.168.0.1)
Case (A) is dealt with by Andreyev's code in the kern/2991 bug report.
Case (B) is harder. In both cases, the untouched routes contain the old IP
address, so in_pcbladdr() and ip_output() both come up with that address
for the address of the outgoing interface.
I've just had a response from Kevin Rowett <krowett@rowett.org>, who said
(edited):
"I ran into exactly the same problem, for the same reason. Added DHCP
client to a stack derived from the BSD networking stack.
It's a real nightmare to sort out. It required almost as much code as
the DHCP client.
To be completely safe, I parse the existing route table, delete all the
routes, and then re-add them, using the route add mechanism."
Which is a solution of sorts, but the kernel really should be able to figure
this out for itself. Maybe whenever an interface route is removed,
the routing table can be searched for entries referencing that ifaddr, and
those ifaddr pointers could be set to NULL. Future routing lookups could then
spot NULL pointers and figure out the interface anew. I'm not sure if
that's practical.
--
Kevin Bracey, Senior Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 725228
645 Newmarket Road Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?708f551949%kbracey>