I'm running a 2 month old 1.2_ALPHA build on a SPARCstation 2.  After the
Great Power Brownout of 1996, my machine was rebooted by my officemate and
it's up and running, but something Really Weird happened:

netbsd4me:1:34 [/home/earle] % netstat -rn | head -6
Routing tables

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

... I can't get outside my subnet at all.  If I try to delete the default
route and add it back in,

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

netbsd4me:1:43 [/home/earle] % sudo route -v delete -net default 128.149.24.1
u: inet 0.0.0.0; u: inet 128.149.24.1; RTM_DELETE: Delete Route: len 112, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,STATIC>
locks:  inits: 
sockaddrs: <DST,GATEWAY,NETMASK>
 default b168-fddi.jpl.nasa.gov default
writing to routing socket: No such process

This is Most Odd.  I've never seen this behavior with SunOS (or Solaris or ...)
before;  I see a socket() call followed by an immediate shutdown(), and then
the write() returned ESRCH for some unknown reason:

   763 ktrace   NAMI  "/sbin/route"
   763 route    EMUL  "netbsd"
   763 route    RET   execve 0
   763 route    CALL  getpid
   763 route    RET   getpid 763/0x2fb
   763 route    CALL  getuid
   763 route    RET   getuid 0
   763 route    CALL  socket(0x11,0x3,0)
   763 route    RET   socket 4
   763 route    CALL  shutdown(0x4,0)
   763 route    RET   shutdown 0
[...]
   763 route    CALL  write(0x4,0x21510,0x70)
   763 route    RET   write -1 errno 3 No such process

The only thing that really happens in between is a DNS lookup on
1.24.149.128.in-addr.arpa.

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.
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):

(before:)
128.149.90       b168-fddi.jpl.nasa UG          0        0      -  le0
128.149.94       b168-fddi.jpl.nasa UG          0        0      -  le0
128.149.177      b168-fddi.jpl.nasa UG          0        0      -  le0
andes.jpl.nasa.g andes.jpl.nasa.gov UGH         0        0      -  le0
teton.jpl.nasa.g teton.jpl.nasa.gov UGH         0        0      -  le0
alps.jpl.nasa.go alps.jpl.nasa.gov  UGH         0        0      -  le0
wasatch.jpl.nasa wasatch.jpl.nasa.g UGH         0        0      -  le0
temblor.jpl.nasa temblor.jpl.nasa.g UGH         0        0      -  le0
mipl7.jpl.nasa.g mipl7.jpl.nasa.gov UGH         0        0      -  le0
coda3.jpl.nasa.g coda3.jpl.nasa.gov UGH         0        0      -  le0
coda4.jpl.nasa.g coda4.jpl.nasa.gov UGH         0        0      -  le0
fddi-coda7.jpl.n coda7.jpl.nasa.gov UGH         0        0      -  le0

(after:)
netbsd4me:1:74 [/tmp] % netstat -r | egrep G
Destination      Gateway            Flags     Refs     Use    Mtu  Interface
default          b168-fddi.jpl.nasa UGS         0       14      -  le0

I'm seeing the RIP packets go by, so does this mean my "routed -q" went
catatonic?  I killed and restarted it (routed) and it picked up the routes.

	- Greg