I'm not sure if this is a kernel bug, or what. A coworker installed a system for use on a local net (that has no inter-network connetivity) but for some reason entered an address for a default gateway. He used the address that would be correct if that net had a route out, but since it doesn't, there's no machine at that address. So upon boot, 'route -n' shows a default route to an ip address that, while valid, isn't in use. For the sake of argument we'll say that the ip address of the system is 10.9.8.5 and that the default gateway (which doesn't exist) is set to 10.9.8.1 'route -n' shows this: 10.9.8.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.9.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.9.8.1 0.0.0.0 UG 1 0 0 eth0 But if a user tries to use the network, all hosts are unreachable. Indeed, if the user attempts to ping the local address of "10.9.8.5" there is no response. If the administrator manually removes the route, the network is still unusable. If the administrator uses linuxconf to remove the configuration for the route and then restarts the network, the network is then usable. I admit it sounds strange but i have been able to reproduce the error without deviation.
I'm not sure what the problem is here. There appear to be two issues: 1) Configuring a default route to a non-existent host breaks connectivity. 2) Deleting the default route by itself is not sufficient to reestablish connectivity. and you appear to have acceptable solutions for both issues. Meanwhile, what appears to be happening is that there is an attempt to send packets to the non-existent host through the default route even when trying to ping the local host. This can be verified using tcpdump, but there is little reason to devise a solution for having a default route to a non-existent host (although such a solution probably exists). Displaying the route table and interface configuration before/after the administrator corrections should give you a hint about what linuxconf is doing that the administrator is not.
Actually you're correct that with further examination this appears to be a kernel bug. It's pretty nasty from my perspective - if the gateway becomes unavailable (power cycle, momentary wiring change) all local networks are also unavailable, which is pretty irrational and could serve as an effective DoS (take out the gateway, shut down the network behind the gateway as well) I'll report it to linux-net.