Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Apr 1995 23:21:29 +0900 (JST)
From:      Atsushi Murai <>
Cc:,, (Toshiharu Ohno)
Subject:   Re: Re(2): IP problem with 950412-SNAP (and earlier -SNAPs)
Message-ID:  <>
In-Reply-To: <"PC-950423232723-3424*/G=Andrew/S=Gordon/O=NET-TEL Computer from "" at Apr 23, 95 11:28:28 pm

Next in thread | Raw E-Mail | Index | Archive | Help

> Well, I have now discovered the problem that was giving me my reboots (at
> least the ones concerned with IIJ PPP).  Having found out what made it go
> bang, it then became obvious that my configuration was in fact wrong -
> though this does point up some issues in kernel packet routing and in the
> IIJPPP that probably want fixing.
> How to make it go bang
> ======================
> This problem applies to any point-to-point interface - I have reproduced it
> with tun0 and ppp0.
> ifconfig tun0      # normally done for you by ppp
> route add default          # *WRONG* should be
> ping                       # any address with no specific route

I've never done before. Let me check.

> Problem 3
> =========
> IIJ PPP really needs a better means of adding default routes.  The reason
> my configuration was wrong in the first place was that my ISP assigns me a
> fixed IP address, but the address at their end varies according to which of
> their machines I dial into - so I set up the default route to my interface
> address (fixed) and let the address of the other end get negotiated by PPP.
> Manual dialling is no problem, since the script can contain "add 0 0
> HISADDR", but the problem with dial-on-demand is that the default route
> must exist before the link is up (in order to get the packets to trigger
> the auto-dial), yet may need to change afterwards when the address at the
> far end has been negotiated.  Either ppp needs to know all the routes that
> point at its interface (which might be network route(s) rather than a
> global default route), and delete/re-insert them once the address of the
> far end is known, or else the kernel restriction on routing to the local
> interface address needs to be relaxed (but what if you have multiple
> point-to-point links sharing the same address).

  As you describe, A Dial on demand mode, IIJ PPP need to know the
destination address for trigger of dialing. Normal usage, it can
change a destination by negotiation without BOMB! But trigger packet
will be lost casuing by *old* destination. (Chickin and Egg ?) So it's
a specification and Limitation. Let me check Not only FreeBSD but also
other platform(BSDI,HP,SUN,NetBSD) that it can be reproduce or not.

> Any thoughts on the above greatly appreciated.  I can probably make some
> suitable changes to ppp to solve problem 3, but I'm not sure I understand
> the existing kernel routing code well enough to fix 1 and 2.
> Andrew.

Atsushi Murai                                       Internet:
System Planning and Engineering Co,.Ltd.            Voice   : +81-33833-5341

Want to link to this message? Use this URL: <>