BURATI@ulowell.CSNET.UUCP (07/25/86)
We are running both versions of telnet on our apollo net,
talking to VAX 11/750's running Ultrix, an 11/780 running VMS
and a MV10000 running DG/UX.
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.
Trying to escape from /com/telnet then becomes an adventure,
Control-q won't work and any other key sequence just repeats
the error "Remote machine reset connection"... If I try to
sigp the process from another shell, it ignores it. A sigp -B
from another shell causes any input to the locked window to
be completely ignored, and the process disappears from the
process list. But then the window can't be deleted (even
control-n is ignored). Finally in desparation, I turned it
into an icon to keep it out of the way and it turned into
a graphics icon. When I tried to log off it was unable to stop
all processes and I had to tell it to BLAST them.
What's the major difference between the two telnet utilities
(that question directed mostly towards any Apollo R&D's
listening). I realize that the VMS telnet may be the one
messing up /com/telnet, but there should still be a way to
kill it without all this trouble.
Michael Burati
University of Lowell
CS Dept
UUCP: {apollo | wanginst | masscomp | datacube}!ulowell!burati
CSNET: burati@ulowell.csnet
ps: I'm not unhappy with the software, in fact except for
this one problem, the net software has been perfect since we
got the sr9.2.3 version (sr9.0 tcp software gave me nightmares).Hans-Werner_Braun@UMich-MTS.MAILNET.UUCP (07/26/86)
If the Apollo implementation does not close a connection if it gets a reset from the other peer than it is broken. Note that Unix 4.3 will send you resets in some cases, too. I mentioned to Excelan that they set the RES bit instead of the FIN bit some while ago, and I think it is fixed in a newer version (at least for VMS, but I assume for their other implementations, too) except where it makes sense to RESet to avoid hanging connections. Even though I found some problems with the Excelan implementation I got the impression that Excelan is eager to listen (if one tells them) and to fix the problems.
rees@apollo.UUCP.UUCP (07/31/86)
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.