Subject: Re: kern/4827
To: Joel Lindholm <email@example.com>
From: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
Date: 02/05/2001 12:55:05
The problem still exists (not sure if the kernel panics, but we can
have bogus routing table entry easily). The step to repeat
the problem is like this:
- let us assume that, my machine is on 10.0.0.2/24, exit router is
# ifconfig if0 10.0.0.2 netmask 0xffffff00
# route add default 10.0.0.1
- have a host route to 10.0.0.3, with gateway set to 10.0.0.1.
# route add 10.0.0.3 10.0.0.1
# netstat -rn |grep 10.0.0.3
10.0.0.3 10.0.0.1 UGHS 0 0 1500 if0
- if we generate outgoing packet to 10.0.0.3, we will get an ICMPv4
redirect packet. the packet will cause the routing entry to get
updated by rtredirect(). you will get the following routing
entry as a result:
10.0.0.3 10.0.0.3 UGHMS 1 1 1500 if0
the entry will prevent us from adding ARP cache entry, for example.
arpresolve: can't allocate llinfo on if0 for 10.0.0.3
now, what should we do?
1. ignore icmp redirect if we have RTF_HOST|RTF_STATIC entry.
it will not cause the entry to get updated, and can cause
lots of icmp redirects. but since it is the root user who asked
for the entry, maybe the kernel shouldn't modify it.
2. if the rt_key is going to be equal to rt_gateway, remove the routing
entry once and see if cloning behavior (by interface route)
effectively generates the new entry. not sure if it is correct.
also, if we configure the interface with incorrect netmask
(one that does not meet the router's configuration) we will see
3. ignore icmp redirect if rt_key and rt_gateway will become the same
value. similar to (1), but a bit different approach.
I believe no other *BSDs addressed this issue.