Path: utzoo!utgpu!watserv1!watmath!att!news.cs.indiana.edu!sdd.hp.com!cs.utexas.edu!sun-barr!lll-winken!gauss.llnl.gov
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Want 8-bit/256 character clean TELNET session -- is it possible?
Message-ID: <90263@lll-winken.LLNL.GOV>
Date: 28 Jan 91 03:35:44 GMT
Sender: usenet@lll-winken.LLNL.GOV
Organization: Lawrence Livermore National Laboratory
Lines: 42
Nntp-Posting-Host: gauss.llnl.gov


| From: quest!ssb@cs.umn.edu (Scott Sheldon Bertilson)
| Date: 26 Jan 91 04:30:47 CST (Sat)
| 
|   I haven't been following this discussion very well, but I sometimes
| fiddle with inter-machine UUCP connections where the client makes a raw
| TCP connection (typically directly from "uucico") to the "rlogin" port on
| the remote system.  If you begin your login sequence with 3 (or is it 4)
| null characters, "rlogind" can sometimes be fooled into assuming that you
| didn't send local username, remote username, or terminal/speed and hand
| you off to "login".  This is all I've had to do to get a clean enough
| connection that will allow "uucico" to run the "g" protocol
| successfully.  I have the impression that you might have to use TELNET,
| but thought I'd mention this for what it's worth.
| 
|   I just experimented a little more with this and am disappointed to have
| to say that a SunOS-4.1 and a SCO ODT system didn't like cooperate.  I
| get "rlogind: permission denied" when I send a null byte...can't figure
| out why it would say that.
| 
|   I also sometimes do "rlogin host -e -8" if I want to fiddle with
| something like SLIP when I'm dialed into a non-SLIP-capable host.

  Actually I should have included more information.  I want two things:

    1.	A fully transparent connection.

    2.	No other daemon other than my program on the other end of the
	connection.

The first condition is because my application requires an 8-bit clear
path.  The second condition is because if I either rlogin or telnet into
the remote machine and then start up my server, the remote server and the
rlogin or telnet daemons thrash when data is being transmitted or
received by the application server.  Every time the application server
transmits data, the CPU has to immediately context switch to the rlogin
or telnet daemon.  The same process happens for received data.  In
addition to the totally synchronized context switch thrashing which goes
on, the data is copied multiple times back and forth to the kernel.  This
has a significant impact on performance.

Casey