Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!hplabs!ucbvax!apollo.UUCP!rees
From: rees@apollo.UUCP.UUCP
Newsgroups: mod.computers.apollo
Subject: Re: /com/telnet vs /usr/ucb/telnet
Message-ID: <8608010724.AA00316@uw-beaver.arpa>
Date: Thu, 31-Jul-86 11:02:14 EDT
Article-I.D.: uw-beave.8608010724.AA00316
Posted: Thu Jul 31 11:02:14 1986
Date-Received: Fri, 1-Aug-86 23:20:04 EDT
References: <8607260143.AA03949@yale-vlsi-vax.YALE.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24
Approved: apollo@yale-comix.arpa


    Here's the problem, /usr/ucb/telnet talks to everybody fine,
    hangs up after a session fine... But, /com/telnet is a different
    story.  It will call any of the other machines fine, work fine
    during the session and even close fine after a session to a unix
    machine.  But to VMS, which is running EXCELAN telnet and ftp,
    when I log out, the /com/telnet starts spitting out errors
    "Remote machine reset connection" or something to that effect.

The Excelan telnet server does indeed reset the connection instead of
closing it.  This is a bug on their side.  They are aware of the
problem and have promised to fix it.

You could argue about what the right thing to do is when the connection
is reset.  I assert that we do a reasonable thing -- tell the loser that
the connection was reset, then await further instructions.  Probably we
should put the user into telnet command mode instead of staying in
conversation mode, since the connection is unusable at that point.  The
telnet protocol spec is no help on this matter.  Most users seem to
want us to just exit telnet, the same as bsd4.2 telnet does.

The manual says how to close a telnet connection.  I won't spoil your
fun by telling you here, but I will say that if you blast telnet (or any
process, for that matter), you get what you deserve -- utter chaos.