casey@gauss.llnl.gov (Casey Leedom) (01/18/91)
I want to dial in to a Xylogics Annex IIe terminal server and then connect to a application server on a machine on our network listening on port FOO. I want that connection to be 8-bit/256 character clean. I.e. completely transparent. The Annex knows how to RLOGIN and TELNET. RLOGIN is out because there's no way to connect up to anything except an RLOGIN daemon on TCP port 513. With TELNET I can connect up to any TCP port I want to, but so far I can't see how to negotiate an 8-bit/256 character clean channel. Is it possible to do this? Do I need to write an RFC suggesting this? Casey
casey@gauss.llnl.gov (Casey Leedom) (01/19/91)
Well, from cruising through the various TELNET RFCs, it look like it's impossible to establish an 8-bit/256 character clean *and* efficient channel. Moreover, it appears to be impossible to do this automatically from the server. Even if you enable TELNET BINARY mode and set tesc to UNDEFINED (which I only presume will work, not having had a chance to test it), the client (in the Annex) is forced to constantly scan for IAC (the TELNET command escape) in both the inbound and outbout data streams. I suppose that this isn't much load on the Annex, but it sure would be nice just to be able to say ``open host port'' from the Annex CLI (Command Line Interface) and have the Annex open a TCP connection to the indicated host and port and then step out of the way. More seriously, it doesn't appear to be possible for the server to negotiate away the client ESCAPE processing; primarily because ESCAPE processing isn't part of the TELNET protocol. ESCAPE processing is a client function. It sounds to me as if an intelligent client should automatically turn off ESCAPE processing if a server requests BINARY mode, but, unfortunately, that's not even recommended by the standards as far as I can see. (sigh) I think I'm screwed. Casey
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/21/91)
I have actually written a spec for the "telnet `don't telnet anymore'" option, which allows a system to volunteer that it will never send any more telnet command or negotiations. The idea behind this was to allow hosts/terminal servers that don't care about negotiations after the initial setup phase to be able to stop looking for them, and gain the efficiency that you are talking about. This RFC has been up before the IETF telnet working group, on and off again. We can't seem to decide whether the potential usefullness of the option outweighs the fact that it's such a disgusting kludge. Bill Westfield cisco Systems. -------
prc@erbe.se (Robert Claeson) (01/21/91)
In article <89746@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > Even if you enable TELNET BINARY mode and set tesc to UNDEFINED (which >I only presume will work, not having had a chance to test it), the client >(in the Annex) is forced to constantly scan for IAC (the TELNET command >escape) in both the inbound and outbout data streams. I suppose that >this isn't much load on the Annex, but it sure would be nice just to be >able to say ``open host port'' from the Annex CLI (Command Line >Interface) and have the Annex open a TCP connection to the indicated host >and port and then step out of the way. The "-r" flag to the Annex telnet command will open a raw TCP connection without the telnet protocol. Usage: telnet -r host port -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
casey@gauss.llnl.gov (Casey Leedom) (01/22/91)
| From: prc@erbe.se (Robert Claeson) | | The "-r" flag to the Annex telnet command will open a raw TCP connection | without the telnet protocol. Someone else pointed that out to me in a private response. I had seen the switch and had initially thought ``yes!'' But was discouraged almost immediately when I saw all the stuff about local line editing, etc. and realized that the connection was anything but raw. Fortunately the person who pointed out the Annex raw ``telnet'' mode told me that I needed to do: stty -break -lbreak # allow BREAKs to be passed through stty iflow none oflow none # disable XON/XOFF processing stty attn undef # disable "attention" character telnet -r host port # ``TELNET'' ``raw'' to port@host ^]toggle crmod # turn off CRLF mapping ^]mode remote_echo # turn off local echoing ^]set escape undef # turn off escape processing Whew! As I mentioned in a response to him (and Xylogics), I felt that "-r" should be renamed "-l" for local line editing, etc., and that a new "-r" should be developed (or better yet just add a command called "tcp" since this really has absolutely nothing to do with the TELNET protocol) that did much of the above seven lines. (Although I don't think I would have my proposed "tcp" command automatically disable BREAK processing since there's really nothing I can think of to map BREAKs to in a raw TCP connection and it would be nice to have *some* method of breaking the connection and returning to the Annex CLI (Command Line Interpreter.) I'm also hesitant to have it do anything about flow control, but I can see strong arguments for disabling in-band flow control.) I guess I just don't see the problem with having terminal servers offer a command like my proposed "tcp" command above. It's certainly within the domain of a terminal server's function in life (offering EIA-232 / network interconnectivity.) As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I think I have to agree that it's too much of a kludge. TELNET was and is designed for *terminal* interactions with translations going on to convert different systems' CRLF models, etc. I think it makes much more sense to simply offer a TCP interconnect command in terminal servers and other systems needing it. *BUT*, if such an option is proposed, I hope that it recommends that any TELNET client implementing such an option should strive to the best of it's ability to be fully 8-bit / 256 character transparent. I.e. local client escape processing, in-band flow control and other in-band signals should all be disabled, etc. Otherwise we'll have a bunch of different TELNET clients which offer varying implementations of DONT_TELNET ``cleanliness'' and no one will ever have confidence that such a connection can truly be trusted. Casey Casey
casey@gauss.llnl.gov (Casey Leedom) (01/22/91)
| From: casey@gauss.llnl.gov (Casey Leedom) | | [To use Annex ``raw telnet'' mode]: | | stty -break -lbreak # allow BREAKs to be passed through | stty iflow none oflow none # disable XON/XOFF processing | stty attn undef # disable "attention" character | telnet -r host port # ``TELNET'' ``raw'' to port@host | ^]toggle crmod # turn off CRLF mapping | ^]mode remote_echo # turn off local echoing | ^]set escape undef # turn off escape processing Opps! I shouldn't have done that from memory. It's really closer to: stty -break -lbreak # allow BREAKs to be passed through stty iflow none oflow none # disable XON/XOFF processing stty attn undef # disable "attention" character telnet -r host port # ``TELNET'' ``raw'' to port@host ^]toggle crlf # turn off CRLF mapping ^]mode character remote_echo # turn off local echoing ^]set escape U # turn off escape processing Further, I should note that this assumes that the current escape character, inherited from the tesc stty setting, is set to the default ``^].'' Oh, one other note, doing ``stty iflow none oflow none'' is also wrong because flow control may be set to eia which you don't want to turn off. Casey
jbvb@FTP.COM (James B. Van Bokkelen) (01/22/91)
If what you want is the ability to connect to an arbitrary remote host/port and send binary data fast, why is Telnet in the picture at all? Just use the standard system API for TCP and blast away. Telnet is intended for virtual terminal support, and isn't designed for bulk data transfer. If the widget you're hacking doesn't have a TCP API, where are you getting the data you want to send from in the first place? James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
lars@spectrum.CMC.COM (Lars Poulsen) (01/23/91)
In article <89861@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: > I guess I just don't see the problem with having terminal servers offer >a command like my proposed "tcp" command above. It's certainly within >the domain of a terminal server's function in life (offering EIA-232 / >network interconnectivity.) The CMC TranServer offers this feature. On the TranServer, there are 3 different commands to open sessions: TELNET host [session-name] [port] RLOGIN host [session-name] [port] ["as" user] OPEN host port The OPEN command is what you are asking for. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/23/91)
[Annex raw ``telnet'' mode requires:]
stty -break -lbreak # allow BREAKs to be passed through
stty iflow none oflow none # disable XON/XOFF processing
stty attn undef # disable "attention" character
telnet -r host port # ``TELNET'' ``raw'' to port@host
^]toggle crmod # turn off CRLF mapping
^]mode remote_echo # turn off local echoing
^]set escape undef # turn off escape processing
Whew! A shining example of the superiority of a unix-compatible user
interface! :-)
As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I
think I have to agree that it's too much of a kludge. TELNET was and is
designed for *terminal* interactions with translations going on to
convert different systems' CRLF models, etc.
Yes. The point was that many hosts set all that up, perhaps completely
transparently, and then never do any further negotiation anyway. These
systems would gain some efficiency in both the host and the terminal server.
In particular, I claimed that it would be much more likely to have kernal
based implementations if all they had tyo do was copy data back and forth.
If such an option is proposed, I hope that it recommends that any
TELNET client implementing such an option should strive to the best of
it's ability to be fully 8-bit / 256 character transparent. I.e.
local client escape processing, in-band flow control and other in-band
signals should all be disabled, etc.
Unfortunately, this brings up an interesting point - the user interface
connected to a protocol and the protocol itself should be divorced from one
another. The ARPANet TACs used to turn off the escape characters when binary
mode was negotiated. This prevented users from issuing all sorts of commands,
and they were not happy. Doing this with "dont telnet" would be even more
dangerous - while a system can negotiate to turn binary mode off, once you
negotiate "don't telnet", it can never be turned on again...
Bill Westfield
cisco Systems.
-------casey@gauss.llnl.gov (Casey Leedom) (01/23/91)
| From: jbvb@FTP.COM (James B. Van Bokkelen) | | If what you want is the ability to connect to an arbitrary remote | host/port and send binary data fast, why is Telnet in the picture at | all? Just use the standard system API for TCP and blast away. Telnet is | intended for virtual terminal support, and isn't designed for bulk data | transfer. If the widget you're hacking doesn't have a TCP API, where are | you getting the data you want to send from in the first place? Because I'm dealing with a terminal server whose only connection mechanisms are RLOGIN and TELNET (actually it also supports some proprietary protocol but that's of no import.) I'm only trying to do it with telnet because that's what I've got. My feeling is that I fundamentally agree with you. TELNET is for terminal interaction. | From: billw@mathom.cisco.com (William "Chops" Westfield) | | As far as Bill Westfield's proposal for a DONT_TELNET TELNET option, I | think I have to agree that it's too much of a kludge. TELNET was and | is designed for *terminal* interactions with translations going on to | convert different systems' CRLF models, etc. | | Yes. The point was that many hosts set all that up, perhaps completely | transparently, and then never do any further negotiation anyway. These | systems would gain some efficiency in both the host and the terminal | server. In particular, I claimed that it would be much more likely to | have kernal based implementations if all they had to do was copy data | back and forth. I don't think there's enough logic in the TELNET server side to really provide much of an impediment to kernel implementation. All it's got to be able to do is acknowledge option processing and change it's behavior in minor ways. | If such an option is proposed, I hope that it recommends | that any TELNET client implementing such an option should strive to | the best of it's ability to be fully 8-bit / 256 character | transparent. I.e. local client escape processing, in-band flow | control and other in-band signals should all be disabled, etc. | | Unfortunately, this brings up an interesting point - the user interface | connected to a protocol and the protocol itself should be divorced from | one another. The ARPANet TACs used to turn off the escape characters when | binary mode was negotiated. This prevented users from issuing all sorts | of commands, and they were not happy. Doing this with "dont telnet" | would be even more dangerous - while a system can negotiate to turn | binary mode off, once you negotiate "don't telnet", it can never be | turned on again... But without such a recommendation the DONT_TELNET proposed option is going to be useless for my purposes. Yes, I know that I could have users explicitly unset all the client interface garbage, but I'd spend the rest my life explaining it over, and over, and over, ... At the very least, let's have a *REAL* BINARY mode that specifies that the channel should be as clear as possible, including in-band client command escapes. In any case, I'm now convinced that TELNET is the wrong way to do what I'm trying to do which is simply establish a clear TCP connection between the Annex and a remote, non-TELNET server. It appears that I may be able to kludge the Annex's TELNET into letting me do it, but it's not going to be pleasant. I will lobby Xylogics to support a new command to implement this. Maybe if Xylogics implements this and the CMC TranServer already has it (see Lars Poulsen's note), other terminal server manufacturers will implement the same functionality and it'll become common. Casey
casey@gauss.llnl.gov (Casey Leedom) (01/28/91)
| 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