Subject: Re: Odd routing problem
To: Greg Earle <earle@isolar.Tujunga.CA.US>
From: Dennis Ferguson <dennis@jnx.com>
List: current-users
Date: 08/12/1996 10:26:41
> Internet:
> Destination      Gateway            Flags     Refs     Use    Mtu  Interface
> default          128.149.24.1       UG          0        0      -  le0
> 127.0.0.1        127.0.0.1          UH          2     8937      -  lo0
> 
> I have a default route, yet ...
> 
> netbsd4me:1:35 [/home/earle] % traceroute 128.149.75.2
> traceroute to 128.149.75.2 (128.149.75.2), 30 hops max, 40 byte packets
> sendto: No route to host
>  1 traceroute: wrote 128.149.75.2 40 chars, ret=-1
[...]
> netbsd4me:1:36 [/home/earle] % sudo route delete default 128.149.24.1
> writing to routing socket: No such process
> delete net default: gateway 128.149.24.1: Bad file descriptor
[...]
> Luckily, I just discovered that a "route -n flush" managed to get rid of the
> default route, and manually adding a default back in seems to have cured it.

What this suggests is that the default route wasn't actually a default route,
that is that the mask for the route was other than 0.0.0.0.  `route -n flush'
got it since it deletes whatever the kernel reports is actually installed.
Your `route delete' commands didn't get it since they tried to delete a route
to 0.0.0.0 with a mask 0.0.0.0, which wasn't what was installed in the kernel.

Of course I am only guessing at this since nothing you have included
actually shows the mask associated with the route.  And this is only natural,
I guess, since netbsd has no commands that I know of which show the masks
associated with routes in the kernel, and hence can distinguish between
routes to, say, 0.0.0.0/0.0.0.0 and 0.0.0.0/255.255.255.255, even though
(as you may have demonstrated) the distinction is important.

As for why the route was in there, my guess would be that routed has a
gremlin which sometimes installs broken default routes.  I've seen this
before.

> On the other hand, a bunch of network/host routes that I had in the routing
> tables haven't been picked back up (after the flush):

This is a different issue.  Routed only installs routes into the kernel which
it doesn't think are there already.  If you delete routes routed put into
the kernel, it may not in general know that you have done this (it could
detect this by watching the routing socket, as gated does, but this may be
beyond routed).  If routed doesn't know the routes are gone it won't try
to reinstall them.  Killing and restarting routed was the only way to get
things back in sync again.

Dennis Ferguson