Subject: kern/3508 bug: cached ip route and interface up/down.
To: None <email@example.com, firstname.lastname@example.org, email@example.com>
From: Tad Hunt <firstname.lastname@example.org>
Date: 11/12/2002 13:27:23
In the future, should I direct problems having to do with the
networking portion of the kernel to tech-net or tech-kern? Or is
it appropriate to send such things to both?
I'm using a NetBSD box as a router. It happens to be running
NetBSD 1.5, but after looking through the networking code, I
believe that this is still a problem in NetBSD-current.
The ip stack, when forwarding a packet, in ip_forward(), makes use
of a cached route from a global variable called "ipforward_rt".
When the interface that route directs outbound packets toward goes
down the cached route is not cleared, so the packets don't get
re-routed. When the interface comes back up, the packets still
don't get delivered to it.
Hmm. I just looked in the PR database. This appears to be
a longstanding problem. der Mouse reported PR3508, which is
the same problem, way back in 1997. As he said then, I believe
this is still a problem in NetBSD-current.
I put in a call in if_down() and if_up() to free the cached route.
The next time a packet is received, the route will be reallocated
and everything will be happy. This is just a hack to see if I'm
on the right track. However, PR3508 points out more ways that
the cached route can be wrong. I'm inclined to follow der Mouse's
lead and get rid of the cached route entirely.
Client1 <----> NetBSD Router <----> Client2
1) Setup a NetBSD router with at least two interfaces (ifc0, ifc1)
2) Configure a default route on ifc0, and a route to Client2
3) In the absence of any other traffic to be forwarded, ping
Client2 from Client1. (The cached route is cleared whenever a
packet for a different destination arrives)
4) ifconfig ifc1 down
5) notice the ping stops receiving the echo reply.
6) ifconfig ifc1 up
7) notice the ping still doesn't receive the echo reply.
8) without stopping the first ping, ping another address which
the router will also forward (doesn't have to respond)
9) notice the first ping starts working again