Subject: arpresolve: can't allocate llinfo
To: None <tech-net@netbsd.org>
From: Jun Xie <jun@qnx.com>
List: tech-net
Date: 02/17/1999 19:53:44
I've noticed that netbsd could create a looped route on routing table and
that trying to delete the route causes the kernel to crash.
The version I'm using is "NetBSD 1.3 (GENERIC) #0: Tue Dec 30 18:26:29 EST 1997".
I don't know if the latest version fixes it.

Host A (10.4.0.252), host B (10.1.0.29), and router C (10.1.0.31) are
connected directly on ethernet (netmask is 0xff000000).

For the testing purpose, I added a route on 10.4.0.252 (netbsd):
# route add 10.1.0.29 10.1.0.31
add host 10.1.0.29: gateway 10.1.0.31
# netstat -nr
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
10                 link#1             UC          0        0      -  le0
10.1.0.29          10.1.0.31          UGHS        0        0      -  le0
10.1.0.31          link#1             UHL         1        0      -  le0

Ping'ing 10.1.0.29 from 10.4.0.252 elicits an ICMP redirect from 10.1.0.31,
and the routing table changes to
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
10                 link#1             UC          0        0      -  le0
10.1.0.29          10.1.0.29          UGHMS       1        1      -  le0
10.1.0.31          00:c0:93:01:a3:e2  UHL         0        0      -  le0

Now 10.1.0.29 is unreachable from 10.4.0.252. If I try to ping 10.1.0.29, the
message "arpresolve: can't allocate llinfo" is logged. Running
"route delete 10.1.0.29" crashes the kernel (stopped at _rt_msg2).

The reason is that when the ICMP redirect is received rtredirect() calls
rt_setgate() to change the rt_gateway field of the routing table entry to
the new gateway address, which happens to be the same as its rt_key and
the rt_gwroute field is set to point to the entry itself.

Should the redirect message be ignored, the current entry be modified
to be a clone of the entry "10 link#1", or somehting else?

By the way, the above operations work perfect with 4.3BSD stack.

--
Jun Xie