[ cc'd to tech-net, since this touches on some routing stuff that
  somebody there should understand.  8-]

> The "defaultroute" argument for PPP does it not as in NetBSD 1.1.
> I get this error:
> 
> Nov 11 16:36:06 alice routed[147]: Send sendto(ppp0, 194.77.82.26.520):  
> Network is down

Heh.  I noticed this last night (the first time i'd dialed in with my
laptop since I updated my user-land to 1.3_ALPHA from 1.2G, and
probably the first time since i've been running routed all the time).


That message is not obviously related to pppd trying to set (and seemingly
not succeeding at setting) the default route.  I didn't get any error
messages from pppd, but neither did I get the default route added.


The following isn't really meant to be a "solution" just some more
data about the problem reported by routed:

I ran routed with tracing/debugging turned on, and it noted:

-- 22:40:34 --
note RTM_NEWADDR with flags 0 for interface index #3
RTM_ADD from pid 0: 16.5.224.1/32 --> 16.5.224.65
-- 22:40:36 --
Add interface ppp0 16.5.224.65    -->16.5.224.1/32   <PT-TO-PT> <NO_SOLICIT|NO_RDISC_ADV> 
Add    16.5.224.1/32   -->16.5.224.65      metric=0  ppp0 <IF> 
Add    16.5.224.65/32  -->127.0.0.1        metric=0  ppp0 <IF|LOCAL> 
note RTM_IFINFO with flags 0xffff8051 for ppp0
-- 22:40:36 --
Send RIPv1 REQUEST to 16.5.224.1.520 via ppp0
        QUERY 
Send sendto(ppp0, 16.5.224.1.520): Network is down
Chg interface ppp0 16.5.224.65    -->16.5.224.1/32   <PT-TO-PT> <SICK|NO_SOLICIT|NO_RDISC_ADV> 

In other words, routed sees the interface go up, tries to send a RIPv1
request over the interface, and gets an ENETDOWN.

pppd brings up the interface with the sifup() call around line 1234 of
pppd/ipcp.c.  However, only later (the sifnpmode() call a few lines
below) is it allowing IP packets to be passed over the interface.  (It
looks like the standard condition at that time is to have them be
bounced with ENETDOWN, as the message would seem to indicate.)  I'm
not really sure what the 'correct' behaviour is, but it seems that the
interface should be able to pass IP traffic as soon as it's configured
'up' with an IP address...


I continued to play around with it some more, apparently managing to
get routed to send its packets over the net, but never got a reply
from the remote side.  I guess I didn't even look directly into the
fact that 'defaultroute' didn't work, even though that's what I
started wondering about.  I ended up just setting the default route by
hand.  8-)




cgd