From owner-freebsd-hackers Tue Aug 8 20:34:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA08326 for hackers-outgoing; Tue, 8 Aug 1995 20:34:14 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id UAA08293 for ; Tue, 8 Aug 1995 20:34:10 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.6.11/8.6.11) with ESMTP id UAA10135 for ; Tue, 8 Aug 1995 20:12:40 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA02181; Wed, 9 Aug 1995 13:11:30 +1000 Date: Wed, 9 Aug 1995 13:11:30 +1000 From: Bruce Evans Message-Id: <199508090311.NAA02181@godzilla.zeta.org.au> To: hackers@freefall.cdrom.com, tony@thing.sunquest.com Subject: Re: client & server ppp Cc: jc@irbs.com Sender: hackers-owner@FreeBSD.org Precedence: bulk >> It sounds like you have the getty on the wrong port or you are >> dialing out on the wrong port. Getty should not wake up when you >> dial out on a /dev/cuxxx port. >Getty doesn't wake up when kermit dials out - maybe I wasn't clear on this. >However, kermit eventually terminates, and then pppd starts up. >At this point, pppd and getty (or login, as getty seems to spawn a login) >seem to clash heads. Perhaps kermit is being misused. If you terminate it without hanging up and before starting pppd, and then try to start pppd, then there will be a race between pppd and getty to grab the port. getty will probably win. If you terminate kermit normally then it will hang up. Then there should be no races, but kermit will be of no use for starting pppd sessions. These problems may be avoided in many different ways: 1. suspend kermit instead of exiting from it. 2. some kludge to hold the device open after exiting from kermit. 3. run kermit from inside pppd. 4. run something simpler than kermit from inside pppd. Bruce