Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Apr 1995 23:21:29 +0900 (JST)
From:      Atsushi Murai <amurai@spec.co.jp>
To:        Andrew.Gordon@net-tel.co.uk
Cc:        amurai@spec.co.jp, hackers@FreeBSD.org, tony-o@iij.ad.jp (Toshiharu Ohno)
Subject:   Re: Re(2): IP problem with 950412-SNAP (and earlier -SNAPs)
Message-ID:  <199504241421.XAA00777@tama.spec.co.jp>
In-Reply-To: <"PC-950423232723-3424*/G=Andrew/S=Gordon/O=NET-TEL Computer from "Andrew.Gordon@net-tel.co.uk" 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 1.2.3.4 5.6.7.8      # normally done for you by ppp
> route add default 1.2.3.4          # *WRONG* should be 4.5.6.7
> ping 9.8.7.6                       # any address with no specific route
> BOOM!

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.
> 
> andrew.gordon@net-tel.co.uk
> 

Atsushi.
-- 
Atsushi Murai                                       Internet: amurai@spec.co.jp
System Planning and Engineering Co,.Ltd.            Voice   : +81-33833-5341



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504241421.XAA00777>