From owner-freebsd-current  Tue Apr 11 13:22:27 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id NAA04270
          for current-outgoing; Tue, 11 Apr 1995 13:22:27 -0700
Received: from irbs.com ([199.182.75.129])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA04254
          for <freebsd-current@freefall.cdrom.com>; Tue, 11 Apr 1995 13:22:22 -0700
Received: (from jc@localhost) by irbs.com (8.6.11/8.6.6) id QAA00482; Tue, 11 Apr 1995 16:22:11 -0400
From: John Capo <jc@irbs.com>
Message-Id: <199504112022.QAA00482@irbs.com>
Subject: Re: Missing telent login prompt
To: terry@cs.weber.edu (Terry Lambert)
Date: Tue, 11 Apr 1995 16:22:10 -0400 (EDT)
Cc: freebsd-current@freefall.cdrom.com (freebsd-current)
In-Reply-To: <9504111818.AA00822@cs.weber.edu> from "Terry Lambert" at Apr 11, 95 12:18:32 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1494      
Sender: current-owner@FreeBSD.org
Precedence: bulk

Terry Lambert writes:
> 
> > > > The missing telnet login prompt is timing related.  A usleep(250000)
> > > > anywhere in the child fixes it, at least for 50 login tests.
> > > 
> > >     When I telnet to any of the FreeBSD boxes here, the time it takes
> > > for the login prompt to show up appears to be more or less random.
> > > Sometimes it pops up right away, other times it can take up to 6 or 7
> > > seconds.  Is this the same problem?
> > 
> > No, the prompt fell on the floor.  login is running and waiting
> > for a user name.  Terry says its a option negotiation problem.
> 
> The reason the prompt is missing is because it was flushed by the
> client who though it was still option negotiation time.  Clearly,
> a login prompt does not contain IsACommand characters.
> 
> There are hacks in telnet to deal with BSD 4.2 and BSD 4.3 TCP/IP;
> basically, the difference between the two is whether or not the
> out of band data handling works.  The telnet and telnetd decide
> what type they are talking to based on option negotiation order.
> 
> If the order is of one when it should be of the other, or if a
> 4.2 implementation is talked to with someone who doesn't use the
> order of operation hacks and starts using OOB for control messages,
> then you get "dropped prompt" and other wierd behaviour.
> 
> This is well known, and is in fact documented in the telnet code
> that came with Net/2.
> 

It worked with 1.1.5.1 so I guess we have lost the hacks to fix it.

John Capo