From owner-freebsd-current Mon Jul 3 07:16:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA07050 for current-outgoing; Mon, 3 Jul 1995 07:16:57 -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 HAA07025 for ; Mon, 3 Jul 1995 07:16:09 -0700 Received: from localhost (uucp@localhost) by specgw.spec.co.jp (8.6.5/3.3Wb-SPEC) with UUCP id WAA17127; Mon, 3 Jul 1995 22:58:05 +0900 Received: by tama.spec.co.jp (8.6.11/6.4J.5) id CAA00773; Mon, 3 Jul 1995 02:35:11 +0900 From: Atsushi Murai Message-Id: <199507021735.CAA00773@tama.spec.co.jp> Subject: Re: ppp To: jleppek@harris.com (Jim Leppek) Date: Mon, 3 Jul 1995 02:35:11 +0900 (JST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freefall.cdrom.com, tony-o@iij.ad.jp (Toshiharu Ohno) In-Reply-To: <199507021426.KAA00305@cyclops> from "Jim Leppek" at Jul 2, 95 10:26:59 am Reply-To: amurai@spec.co.jp X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1430 Sender: current-owner@FreeBSD.org Precedence: bulk > > Yes, my provider wants to see 0.0.0.0 during the initial negotiation > phase however thats the problem. A 0.0.0.0 address gets converted to > 192.0.0.1 within the ppp even if you set ifaddr 0 0. > This occurs in ipcp.c around line 164 per my earlier mail message. > It is this forced ( and hidden ) conversion that I question. > When I set my initial address to 0.0.0.0 I expect ppp to use it. > > I definitely like the new ppp and have stopped using my old pppd > scripts by this conversion of 0.0.0.0 is a definite gotcha IMHO. User process ppp has a dial on demand function, too. And it's should assume a valid ip address for trapping a outgoing packet. After dailing and connecting your ISP, it may negotiate and get a new ip address. In this situation, trigger packet will be lost due to old ip address without any bad effect to peer - using "192.0.0.1". But other mode, they don't do need a such a tric. > I removed the questionable src lines and rebuilt ppp so all > is well for me but for anyone not comfortable with tweeking sources > or tracking ip negotiation bugs I suspect it would have taken > a bit of time. So I will recomended we should confirm and make sure what's a right things ;-) > Jim Leppek Atsushi. P.S. I will CC: this to auther. -- Atsushi Murai Internet: amurai@spec.co.jp System Planning and Engineering Co,.Ltd. Voice : +81-33833-5341