From owner-freebsd-hackers Sun Sep 21 17:34:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27757 for hackers-outgoing; Sun, 21 Sep 1997 17:34:26 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA27712; Sun, 21 Sep 1997 17:34:13 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA24672; Mon, 22 Sep 1997 02:34:10 +0200 (MET DST) Date: Mon, 22 Sep 1997 02:34:10 +0200 (MET DST) Message-Id: <199709220034.CAA24672@bitbox.follo.net> From: Eivind Eklund To: Brian Somers CC: hackers@FreeBSD.ORG In-reply-to: Brian Somers's message of Sun, 21 Sep 1997 16:02:39 -0700 (PDT) Subject: Re: cvs commit: src/usr.sbin/ppp lcp.c References: <199709212302.QAA14109@freefall.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > brian 1997/09/21 16:02:38 PDT > > Modified files: (Branch: RELENG_2_2) > usr.sbin/ppp lcp.c > Log: > MFC: Sleep for a second before sending the first LCP > config request. This stops us from squirting stuff > down a line that still has ECHO turned on because the > peer hasn't had a chance to start yet. > Lead to the cause by: Greg Lehey Isn't detecting this what the magic number more-or-less was introduced for? You can catch looping LCP-negotiation by looking for the same magic number, and it really seems a pity to waste a second on connection, as this could be running on really fast links (like TCP or ISDN links). Besides, if the other end is slow, 1 second might not be enough. Eivind.