From owner-freebsd-questions  Thu Jan 19 09:05:53 1995
Return-Path: questions-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id JAA26166 for questions-outgoing; Thu, 19 Jan 1995 09:05:53 -0800
Received: from sci.brooklyn.cuny.edu (eastham.sci.brooklyn.cuny.edu [146.245.1.21]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id JAA26160 for <questions@freebsd.org>; Thu, 19 Jan 1995 09:05:51 -0800
Received: from robeson.brooklyn.cuny.edu (robeson.sci.brooklyn.cuny.edu) by sci.brooklyn.cuny.edu (4.1/SMI-4.1a)
	id AA08733; Thu, 19 Jan 95 12:05:29 EST
Date: Thu, 19 Jan 95 12:05:29 EST
From: dayton@sci.brooklyn.cuny.edu (Dayton Clark)
Message-Id: <9501191705.AA08733@sci.brooklyn.cuny.edu>
Received: by robeson.brooklyn.cuny.edu (4.1/SMI-4.1)
	id AA08344; Thu, 19 Jan 95 12:05:27 EST
To: questions@FreeBSD.org
Subject: PPP problem with 2.0R
Sender: questions-owner@FreeBSD.org
Precedence: bulk

I have two machines running 2.0R, dogs and holiday.  I've applied the
patch to if_ppp.c, otherwise it is "out of the box".

Here's the problem:  I connect them using ppp, the connection is
initiated from dogs.  Everything looks fine.  I ping holiday from
dogs.  This will run from 5 - 20 minutes then holiday becomes
unresponsive.  It doesn't drop the connection, it just hangs.  Logging
into holiday (via a different route) I find that the pppd is running,
it has logged many FCS errors and a few queue full errors.  If I run
top, pppd is consuming somewhere between 85% - 112% (!!) of the cpu,
apparently in a pretty tight loop.  Only -KILL will stop it.

This behaviour occurs each time I connect.  I haven't tried
connecting/pinging the other direction.  I've recompiled pppd with
debugging enabled so maybe I can find out what it's doing.

Any ideas as to what's happening?  Any thoughts will be apprecitated.

Some specifics:

	Dogs is a vanilla system, 486/33Mhz, 16M, IDE drives,
		standalone.

	Holiday is 486/66MZ, 32M, EISA bus, with Ultrastore 24f
		controller, 32bit EtherLink III ethernet adapter.

	The ppp connection is via a pair of Intel 14.4 modems running
		at 9600bps with compression and error detection.

Thanks,

Dayton Clark
CIS Dept.
Brooklyn College/CUNY
Brooklyn, New York 11210

dayton@sci.brooklyn.cuny.edu