This chapter describes the TELNET-OpenVMS Server from the system manager's point of view. Topics include:
• TELNET logicals
• TELNET control functions
• Setting up Virtual Terminals
• TELNET options
RFCs 854 through 858, RFC 885, and RFC 1091 describe the TELNET protocol. The User's Guide, Chapter 11, TELNET: Connecting to Remote Terminals, the Command Reference section describes the commands you can use with TELNET.
The logicals in Table 18-1 appear in the TCPWARE:TELNET_CONTROL.COM file.
CAUTION! Editing the TELNET_CONTROL.COM file is not recommended, since each TCPware installation replaces this file. If you want to define a special purpose logical, do so in another place, such as in your system startup file.
Logical |
Description |
TCPWARE_TELNETD_INTRO_MSG |
Define this logical as a special message that appears whenever a user reaches the host through TELNET. If the system logical name table contains a value for this logical, the Server sends the equivalence string to the peer before the standard login sequence starts. Use this logical to issue warnings such as Authorized Use Only for remote logins. |
TCPWARE_TELNETD_DEFCHAR |
Define this logical to set up the default terminal characteristics for TELNET sessions. You can thereby avoid having to change the SYSGEN TTY_DEFCHAR and TTY_DEFCHAR2 fields system-wide. (See Virtual Terminals .) This logical forces the hangup bit set. To prevent the forcing of the hangup bit set, use the TCPWARE_TELNETD_NO_FORCED_HANGUP logical. |
TCPWARE_TELNET_WINDOW |
If defined, specifies the window size that the TELNET Server offers to the peer. By default, this value is 4096. If the TCPWARE_TELNET_WINDOW logical's value is less than 512, TELNET uses 4096. |
TCPWARE_TELNETD_FLAGS |
This logical has several purposes. The default value is 1. TCPWARE_TELNETD_FLAGS Logical Bit Description describes the bit options. Setting either bit 0 or 1 can improve Server performance and reduce system processing overhead. Note, however, that doing so means that you are not adhering to the TELNET protocol. |
Bit... |
(Mask) |
Set to... |
Description |
0 |
1 |
0 |
Inserts a <NULL> character following a <CR> character that is not followed by an <LF> character. (Ignored if bit 1 is set to 1.) |
1 (default) |
Inserts nothing after a <CR> character that is not followed by an <LF> character. |
||
1 |
2 |
0(default) |
Server does not run in raw mode. It doubles <IAC> data characters as required by the TELNET protocol. |
1 |
Ignores bit 0: Sends all characters without special processing, doubling of characters, or inserting <NULL> after <CR>. |
||
7 |
128 |
0(default) |
Incoming TELNET sessions are REMOTE. |
1 |
Incoming TELNET sessions are LOCAL (compatible with earlier TCPware versions). |
||
8 |
256 |
0(default) |
Tries to return the peer's hostname in the NTA terminal's TT_ACCPORNAM field.* Otherwise uses the IP address. |
1 |
Ignores bit 9: Adds the port number to the IP address, such as192.168.95,1094(compatible with an earlier TCPware). |
||
9 |
512 |
0 (default) |
Tries to return the peer's hostname in the NTA terminal's TT_ACCPORNAM field.* Otherwise uses the IP address. |
1 |
Adds the port number to either the hostname or IP address, such asbart.nene.com,1094 or 192.168.95,1094. (Ignored if bit 8 is set to 1.) |
||
The combination of bit 8 and 9 settings has the following effect on TT_ACCPORNAM:* |
|||
Bit 8 |
Bit 9 |
ReturnedRemote Port Info(TT_ACCPORNAM Field) |
|
0 |
0 |
host or address (default):bart.nene.com or 192.168.95 |
|
0 |
1 |
host,port or address,port:bart.nene.com,1094 or 192.168.95,1094 |
|
1 |
0 |
address,port:192.168.95,1094 |
|
1 |
1 |
address,port:192.168.95,1094 |
|
* The TT_ACCPORNAM field is limited to 63 bytes; if the value is too long, the port number may be truncated or even dropped. |
Virtual terminals (VTAs) allow users to disconnect from a physical terminal without terminating a process—the process remains active on a virtual terminal. Virtual terminals are used to reconnect to a process when the connection is lost, and to maintain sessions on more than one disconnected terminal.
To set up the TELNET Server to support VTAs:
1 Set up VTA devices as follows:
VAX:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>CONNECT VTA0: /NOADAPTER /DRIVER=TTDRIVER
SYSGEN>EXIT
ALPHA:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN>IO CONNECT VTA0 /NOADAPTER-
_SYSMAN>/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE
SYSMAN>EXIT
2 Edit the TELNET_CONTROL.COM file to define the TCPWARE_TELNETD_DEFCHAR logical (see TELNET logicals):
$ DEFINE/SYSTEM TCPWARE_TELNETD_DEFCHAR 402657952,135174
TCPWARE_TELNETD_DEFCHAR permits TELNET server devices to override the values in the SYSGEN TTY_DEFCHAR and TTY_DEFCHAR2 parameters, if they are not set up correctly for TELNET sessions. These SYSGEN parameters apply to all terminals and only take effect after a reboot.
In the above logical definition:
• 402657952 (%X180012A0) is the VMS default value for TTY_DEFCHAR.
• An optional value 135174 (%X0021006) for TTY_DEFCHAR2 is appended.
• The default value for TTY_DEFCHAR2 is normally %X0001002, which is TT2$M_SECURE combined with TT2$M_AUTOBAUD.
• The value 135174 (%X00021006) reflects the addition of TT2$M_DISCONNECT (131072, or %X00020000) and TT2$M_HANGUP (4).
(See the SYS$LIBRARY:TTDEF.H file and SYS$LIBRARY:TT2DEF.H file for bit definitions for TTY_DEFCHAR and TTY_DEFCHAR2, respectively.)
• TT2$M_DISCONNECT is needed to allow disconnected virtual terminals.
Note! TT2$M_HANGUP is forced on even if it is not specified in the TCPWARE_TELNETD_DEFCHAR logical. If you are using this logical to prevent the TT2$M_HANGUP bit from being set, you need to define the TCPWARE_TELNETD_NO_FORCED_HANGUP logical.
3 Restart TELNET for the changes to take effect:
$ @TCPWARE:RESTART TELNET
When a client opens a session to the server set up with VTAs and the virtual terminal disconnects, the opening sequence might be as follows:
Username:
Password:
You have the following disconnected process:
Terminal Process name Image name
VTA2:_ VTA2: (none)
Connect to above listed process [YES]: Return
Connecting to terminal _VTA2:
The Client-TELNET utility and TELNET Server support the following options:
ECHO |
END-OF-RECORD |
REMOTE-FLOW-CONTROL |
TERMINAL-SPEED |
TERMINAL-TYPE |
TRANSMIT-BINARY |
SUPPRESS-GO-AHEAD |
WINDOW-SIZE |
|
The Client and Server negotiate options using the TELNET protocol WILL, WONT, DO, and DONT commands.
The ECHO option enables or disables echoing data received over the network. You can configure each side of a connection independently. The initial default is no echoing.
The Client supports enabling and disabling of echoing for characters it sends over the network. It does not support echoing for characters it receives over the network. The Server supports enabling and disabling of echoing for characters it receives over the network. It refuses any attempts to have the Client echo characters that the Client receives over the network.
The user's or interactive process terminal sets the OpenVMS terminal device driver TT$M_NOECHO characteristics depending on the echo requirements. Both the Client and Server attempt to negotiate for the Server to echo the characters it receives over the network from the Client.
Use the END-OF-RECORD option during IBM 3270-class terminal emulation. This option affirms that the client and server both use the TELNET end-of-record character. Use this character to delimit TELNET screens.
The Remote Flow Control Option (RFC 1372) is supported on both the Client and Server to enable or disable local flow control on the client, or the handling of Ctrl/Sand Ctrl/Q keystrokes to stop and resume TELNET transmission, respectively. These controls are usually processed locally by the terminal driver and are not sent to the remote server.
The SET LOCAL_FLOW_CONTROL and SET NOLOCAL_FLOW_CONTROL commands are provided on the Client if the remote server does not support the Flow Control Option. By specifying SET NOLOCAL_FLOW_CONTROL, the flow control characters are passed to the remote server and are not processed locally.
The default flow control setting depends on the TT$V_TTSYNC value for the terminal. You can set "TTSync" mode (local flow control) outside of TELNET by using the DCL SET TERMINAL /TTSYNC command, or set "No TTSync" mode (server flow control) by using the DCL SET TERMINAL /NOTTSYNC command; some full-screen editors also set these modes. However, if you are inside TELNET, SET NOLOCAL_FLOW_CONTROL can force the terminal into "No TTSync" mode for a particular connection.
The SUPPRESS-GO-AHEAD option enables or disables sending the TELNET "go-ahead" (GA) control function. You can configure each side of a connection independently. The initial default is not to suppress go-aheads.
Both the Client and Server support negotiating this option. Regardless of the option's state, both ignore the GA control function if they receive it and never transmit it. The user can send this option by entering the SET GA or SEND commands in the Client. Both the Client and Server attempt to negotiate for GA suppression.
The Terminal Speed Option (RFC 1079) is useful for applications that may want to adjust some actions based on the baud rate at which a user connects. The Server does an equivalent of a DCL SET TERMINAL/SPEED command. This is supported on the Client and Server.
TELNET uses the TERMINAL-TYPE option to negotiate the type of terminal used. TELNET uses this option if both the client and server support the option and are willing to use it. This option tells the TELNET server what type of terminal the client has.
The TRANSMIT-BINARY option enables or disables the full eight-bit ASCII character set. You can configure each side of a connection independently.
The initial TELNET protocol default is to use the seven-bit ASCII character set. However, the peer TELNET implementation can strip the eighth bit unless you use the TRANSMIT-BINARY option. For the Client, use the SET BINARY command to enable full eight-bit mode.
The Client and Server always transmit the full eight-bit ASCII character set over the network, regardless of the option's status.
When you request the Client to enable the TRANSMIT-BINARY option, it sets the OpenVMS terminal device driver TT$M_EIGHTBIT characteristics. When you request the Server to enable this option, it does not change the TT$M_EIGHTBIT characteristic.
Depending on the state of the EIGHTBIT terminal option, OpenVMS may strip the eighth bit. OpenVMS strips the eighth bit on input if the terminal attribute is NOEIGHTBIT. However, OpenVMS does not strip this bit on output.
The Window Size Option (RFC 1073) is also known as the Negotiate About Window Size (NAWS) option. The client and server negotiate sending the window size information using the standard TELNET WILL/DO/DONT/WONT mechanism. If the client and server agree, the client may send a subnegotiation to convey the window size. If the client's window size later changes, the client may send a subsequent subnegotiation. This is supported on the Client and Server.
The TELNET protocol defines several control functions. Some of these functions include interrupting a process, aborting output, and erasing a character or line.
The Client sends these functions with the SEND command, or if the user types characters defined with the SET commands. The Client ignores these functions if it receives them.
The Server never sends these functions. The Server replaces the received functions with an OpenVMS character sequence as shown in Supported T. The exception is the "are you there" (AYT) function that returns the BELL character (ASCII 7).
The Server recognizes the control functions listed in Supported T; it ignores all other control function.
Table 18-3 Supported TELNET Control Functions |
|
TELNET control function... |
Recognizes OpenVMS character sequence... |
Interrupt Process (IP) |
Ctrl/Y |
Abort Output (AO) |
Ctrl/O |
Erase Character (EC) |
DELETE |
Erase Line (EL) |
Ctrl/U |
To exit TELNET use the EXIT command or type Ctrl/Z.
TELNET exits with the last error status, if any. DCL command procedures can use the $STATUS and $SEVERITY symbols to test for success or failure of the TELNET commands issued. A success status indicates that all commands succeeded. A warning, error, or severe status indicates that one or more commands failed to execute, either because of syntax errors or because of operational problems.
When possible, the status code is a System Service (defined in $SSDEF), RMS (defined in $RMSDEF), or shared (defined in $SHRDEF) status. In some cases, status codes are TCPware private codes with a facility number of 1577.