From owner-freebsd-hackers Mon Apr 24 07:51:00 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA06584 for hackers-outgoing; Mon, 24 Apr 1995 07:51:00 -0700 Received: from specgw.spec.co.jp (specgw.spec.co.jp [202.32.13.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA06575 for ; Mon, 24 Apr 1995 07:50:56 -0700 Received: from localhost (root@localhost) by specgw.spec.co.jp (8.6.5/3.3Wb-SPEC) with UUCP id XAA01784; Mon, 24 Apr 1995 23:41:04 +0901 Received: by tama.spec.co.jp (8.6.11/6.4J.5) id XAA00777; Mon, 24 Apr 1995 23:21:29 +0900 From: Atsushi Murai Message-Id: <199504241421.XAA00777@tama.spec.co.jp> Subject: Re: Re(2): IP problem with 950412-SNAP (and earlier -SNAPs) To: Andrew.Gordon@net-tel.co.uk Date: Mon, 24 Apr 1995 23:21:29 +0900 (JST) Cc: amurai@spec.co.jp, hackers@FreeBSD.org, tony-o@iij.ad.jp (Toshiharu Ohno) 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 Reply-To: amurai@spec.co.jp X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2731 Sender: hackers-owner@FreeBSD.org Precedence: bulk > 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