I have found a similar thing with users logging in to my NetNSD system, =
worked fine under NetBSD 1.5.x but since installing NetBSD 1.6 is =
failing.
=20
I have added ip-up & ip-down scripts to work around.
=20
In messages have found the following message:-
=20
Jun 30 09:52:39 lamborghini pppd[290]: Couldn't add default route: File =
exists
=20
From a bit of hunting around this message is produced by the =
dodefaultrout() procedure in pppd/sys-bsd.c. Code fragment below.=20
=20
static int
dodefaultroute(g, cmd)
    u_int32_t g;
    int cmd;
{
    int routes;
    struct {
            struct rt_msghdr            hdr;
            struct sockaddr_in        dst;
            struct sockaddr_in        gway;
            struct sockaddr_in        mask;
    } rtmsg;
    if ((routes =3D socket(PF_ROUTE, SOCK_RAW, AF_INET)) < 0) {
            error("Couldn't %s default route: socket: %m",
                   cmd=3D=3D's'? "add": "delete");
            return 0;
    }
   =20
    memset(&rtmsg, 0, sizeof(rtmsg));
    rtmsg.hdr.rtm_type =3D cmd =3D=3D 's'? RTM_ADD: RTM_DELETE;
    rtmsg.hdr.rtm_flags =3D RTF_UP | RTF_GATEWAY | RTF_STATIC;
    rtmsg.hdr.rtm_version =3D RTM_VERSION;
    rtmsg.hdr.rtm_seq =3D ++rtm_seq;
    rtmsg.hdr.rtm_addrs =3D RTA_DST | RTA_GATEWAY | RTA_NETMASK;
    rtmsg.dst.sin_len =3D sizeof(rtmsg.dst);
    rtmsg.dst.sin_family =3D AF_INET;
    rtmsg.gway.sin_len =3D sizeof(rtmsg.gway);
    rtmsg.gway.sin_family =3D AF_INET;
    rtmsg.gway.sin_addr.s_addr =3D g;
    rtmsg.mask.sin_len =3D sizeof(rtmsg.dst);
    rtmsg.mask.sin_family =3D AF_INET;
=20
    rtmsg.hdr.rtm_msglen =3D sizeof(rtmsg);
=20
    if (write(routes, &rtmsg, sizeof(rtmsg)) < 0) {
            error("Couldn't %s default route: %m",                =
=E2=86=90--------------------------
                   cmd=3D=3D's'? "add": "delete");
            close(routes);
            return 0;
    }
    close(routes);
    default_route_gateway =3D (cmd =3D=3D 's')? g: 0;
    return 1;
}
=20
This procedure does not appear to have changed since NetBSD 1.5.x. Have =
tried to debug this further, but not really that up on C and the inner =
works of ppp, tcp etc.
=20
=20
> Subject: curious PPP routing behavior
> To: None <current-users@netbsd.org>
> From: John F. Woods <jfw@jfwhome.funhouse.com>
> List: current-users
> Date: 06/30/2002 08:50:32=20
> I have been running 1.6B built yesterday from a Friday-evening cvs =
update.
> It seems to be mostly working, but I have noticed some curious =
behavior
> with PPP routing:  yesterday, I couldn't ping my own PPP address from =
the
> NetBSD system; I can ping the Ethernet address, however, and other =
hosts
> can ping the PPP address, including hosts on my Ethernet.  Today, =
pinging
> the PPP address works, but gives evidence that it is sending the ping
> packets out on the PPP interface:
> =20
> $ ping jfwhome.funhouse.com
> PING jfwhome.funhouse.com (146.115.236.216): 56 data bytes
> 36 bytes from apx2.sbo.ma.rcn.net (208.59.89.102): Redirect Host New =
router addr: >jfwhome.funhouse.com (146.115.236.216) for icmp_seq=3D0
> 64 bytes from 146.115.236.216: icmp_seq=3D0 ttl=3D254 time=3D343.400 =
ms
> ...
> =20
> $ traceroute jfwhome.funhouse.com
> traceroute to jfwhome.funhouse.com (146.115.236.216), 64 hops max, 40 =
byte packets
>  1  apx2.sbo.ma.rcn.net (208.59.89.102)  154.413 ms  169.224 ms  =
158.851 ms
>  2  jfwhome (146.115.236.216)  288.681 ms  294.612 ms  294.475 ms
> =20
> However, when hosts on my Ethernet ping (or traceroute) the PPP =
address, it
> responds directly, without sending the packets out through the PPP =
interface:
> =20
> localhost:~] jfw% traceroute jfwhome.funhouse.com
> traceroute to jfwhome.funhouse.com (146.115.236.216), 30 hops max, 40 =
byte packets
>  1  jfwhome.funhouse.com (146.115.236.216)  4.998 ms  2.11 ms  1.75 ms
> =20
> What is going on here?
=20