Nf-ID: #N:nemesis:-12366655:004:6498
Nf-From: nemesis.UUCP!uhclem    Dec 22 20:55:00 1992


If you are using NCSA TCP/IP TELNET to connect to SCO XENIX or SCO UNIX
systems, you have probably noticed an annoying problem.  When you
first TELNET to the SCO XENIX/UNIX system, you get the system ID banner,
but before the login prompt is displayed, you sometimes get disconnected.
By repeating the connect attempt, it will eventually stay connected.

Myself and numerous other users at a large local site have struggled
with this problem for some time.  KA9Q TELNET would always connect on the
first try, and if you TELNETed from one of the SCO XENIX/UNIX systems
to SCO box, that would also work fine.  Attempting to connect from the
NCSA TELNET package to a non-SCO system (Interactive, Ultrix, BSD) would
also work on the first try.  Only   NCSA TELNET ---> SCO XENIX/UNIX
would have a problem.

We also noticed that slower SCO systems are harder to connect to.
A 386 33MHz might take two tries, where a 16MHz system might take thirty tries
(conservative value!) before a login prompt would appear.  XENIX seemed
to be slightly worse, but we have more slower systems running XENIX
than we do running SCO UNIX.

I have been corresponding with one of the NCSA programmers on this on and
off for about a year now and despite trying the latest, greatest version
(2.3.05 is the last I have), the problem persisted.

Recently I had a breakthrough.  It seems that SCO XENIX/UNIX TCP/IP (ok,
its really Lachman TCP/IP) doesn't work properly if the remote system
requests certain negotiations.  (Negotiations work out window size,
terminal type, etc.)  By eliminating the request, the connection
doesn't abort.  It turns out that because the NCSA system doesn't negotiate
the point I removed, the SCO system asks the NCSA system about this point,
(NCSA replies), which seems to work.   (In case you are interested,
the negotiation in question is called DOECHO.)

The end result is reliable, first-try-works connections to SCO XENIX/UNIX
systems from NCSA TCP/IP.

Problem:  I am fairly certain that the problem is with the SCO TCP/IP
system, and NCSA is triggering it (KA9Q is stupid and doesn't do much,
if any negotiation).  So SCO should investigate why this happens too.

I have been unable to get a response from the NCSA programmer since
I came across this fix, so I don't have their blessing for the change
either.  But I can assure you that it works and a few dozen people are
already taking advantage of the fix.  We have seen no side-effects,
apart from fewer complaints.  Connections to non-SCO systems also
continue to work correctly.

I have tested the change on NCSA 2.3.01 and 2.3.05, but I am fairly
certain a variant of the fix is applicable to older versions.  Here is
why:

There is a package called WNQVTNET.  It comes from a P. O. Box in NY,
and gives you TCP/IP from within Windows.  It also had the same problem,
but examining the binary shows that it is a front-end for NCSA TELNET 2.2.
I devised a patch for that binary that eliminates the offending
negotiation and it now works flawlessly.

Anyway, here are the patches, and as always, save your originals.
If you have any questions on this, please send me email, but chances
are the question would be answered by the NCSA or the SCO folk.

Enjoy!

Diffs are for NCSA Telnet 2.3.05.  Slight adjustments may be needed for
other versions.

*** negotiat.c00	Sun Mar 8 16:16:00 1992
--- negotiat.c	Sat Dec 19 11:43:09 1992
***************
*** 8,13 ****
--- 8,24 ----
  *	Date		Notes
  *	--------------------------------------------
  *   11/91       Started
+ 
+ ANSI Edit History
+ Edit <1>	Added AVOIDECHO conditional to block our sending a
+ 		DO ECHO to the other end as part of starting the
+ 		protocol.  For some reason this makes connections
+ 		to SCO systems fail.  Slower SCO systems almost always
+ 		fail, faster systems usually fail on the first try to
+ 		connect.  The SCO system eventually asks about ECHO
+ 		anyway, and then we apparently say OK, so everything
+ 		appears to work out.
+ 		18-Nov-92 Frank Durda IV	uhclem@nemesis.lonestar.org
  */
  
  /*
***************
*** 17,23 ****
  #define USETEK
  /* #define USERAS */
  
! #define NEGOTIATEDEBUG  /* define this to print the raw network data to the console */
  
  #ifdef __TURBOC__
  #include "turboc.h"
--- 28,35 ----
  #define USETEK
  /* #define USERAS */
  
! /*<1>#define NEGOTIATEDEBUG  /* define this to print the raw network data to the console */
! #define AVOIDECHO	/*<1>Do not offer to do echo - let other system ask*/
  
  #ifdef __TURBOC__
  #include "turboc.h"
***************
*** 242,248 ****
--- 254,268 ----
  void start_negotiation(struct twin *tw,int cvs)
  {
      /* Send the initial tlnet negotiations */
+ #ifdef AVOIDECHO
+         tprintf(cvs,"Did NOT SEND: %s %s\r\n",telstates[DOTEL-LOW_TEL_OPT],teloptions[ECHO]); /*<1>*/
+ /*<1>Don't ask me why, but it appears SCO bombs the connection off
+      if you do this.  Leaving it out, SCO appears to initiate this
+      handshake itself later.  Whatever.   18-Nov-92 Frank Durda IV
+ */
+ #else	/*AVOIDECHO*/
      netprintf(tw->pnum,"%c%c%c",IAC,DOTEL,ECHO);
+ #endif /*AVOIDECHO*/
      netprintf(tw->pnum,"%c%c%c",IAC,DOTEL,SGA);
      netprintf(tw->pnum,"%c%c%c",IAC,WILLTEL,NAWS);
      if(tw->mapoutput) { /* check whether we are going to be output mapping */
***************
*** 254,260 ****
--- 274,282 ----
  
      /* Print to the console what we just did */
      if(tw->condebug>0) {
+ #ifndef AVOIDECHO
          tprintf(cvs,"SEND: %s %s\r\n",telstates[DOTEL-LOW_TEL_OPT],teloptions[ECHO]);
+ #endif /*AVOIDECHO*/
          tprintf(cvs,"SEND: %s %s\r\n",telstates[DOTEL-LOW_TEL_OPT],teloptions[SGA]);
          tprintf(cvs,"SEND: %s %s\r\n",telstates[WILLTEL-LOW_TEL_OPT],teloptions[NAWS]);
          if(tw->mapoutput) { /* check whether we are going to be output mapping */
  
 -----------------

Here is the patch to WNQVTNET.EXE (not part of NCSA package but based on it)

	Applies to Version 1.32
	01c0f3	01 ff fd 03 ff fc 18 00		Original
	01c0f3  03 ff fc 18 00 fd 00 00		Fix

Again, the goal is to NOT send the SCO system the "01 ff fd" (DoEcho)
sequence, as SCO TCP/IP doesn't seem to like it and will sometimes
terminate the connection just before the login: prompt.


Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi"
...utacfd!nemesis!uhclem (nearest internet) | demand...  A SEGMENT REGISTER!!!"
...letni!rwsys!nemesis!uhclem	            |"A what?"
...decvax!microsoft!trsvax!nemesis!uhclem   |"LETNi! LETNi! LETNi!"  - 1983