BSD Rlogin
RFC 1282
Document | Type |
RFC - Informational
(December 1991; No errata)
Obsoletes RFC 1258
|
|
---|---|---|---|
Author | Brian Kantor | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1282 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Kantor Request for Comments: 1282 Univ. of Calif San Diego Obsoletes: RFC 1258 December 1991 BSD Rlogin Status of this Memo This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Protocol Description The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output [1]. It is widely used between Unix hosts because it provides transport of more of the Unix terminal environment semantics than does the Telnet protocol, and because on many Unix hosts it can be configured not to require user entry of passwords when connections originate from trusted hosts. The rlogin protocol requires the use of the TCP. The contact port is 513. An eight-bit transparent stream is assumed. Connection Establishment Upon connection establishment, the client sends four null-terminated strings to the server. The first is an empty string (i.e., it consists solely of a single zero byte), followed by three non-null strings: the client username, the server username, and the terminal type and speed. More explicitly: <null> client-user-name<null> server-user-name<null> terminal-type/speed<null> For example: <null> bostic<null> kbostic<null> vt100/9600<null> The server returns a zero byte to indicate that it has received these Kantor [Page 1] RFC 1282 BSD Rlogin December 1991 strings and is now in data transfer mode. Window size negotiation may follow this initial exchange (see below). From Client to Server (and Flow Control) Initially, the client begins operation in "cooked" (as opposed to to "raw") mode. In this mode, the START and STOP (usually ASCII DC1,DC3) characters are intercepted and interpreted by the client to start and stop output from the remote server to the local terminal, whereas all other characters are transmitted to the remote host as they are received. (But see below for the handling of the local-escape character.) In "raw" mode, the START and STOP characters are not processed locally, but are sent as any other character to the remote server. The server thus determines the semantics of the START and STOP characters when in "raw" mode; they may be used for flow control or have quite different meanings independent of their ordinary usage on the client. Screen/Window Size The remote server indicates to the client that it can accept window size change information by requesting a window size message (as out of band data) just after connection establishment and user identification exchange. The client should reply to this request with the current window size. If the remote server has indicated that it can accept client window size changes and the size of the client's window or screen dimensions changes, a 12-byte special sequence is sent to the remote server to indicate the current dimensions of the client's window, should the user process running on the server care to make use of that information. The window change control sequence is 12 bytes in length, consisting of a magic cookie (two consecutive bytes of hex FF), followed by two bytes containing lower-case ASCII "s", then 8 bytes containing the 16-bit values for the number of character rows, the number of characters per row, the number of pixels in the X direction, and the number of pixels in the Y direction, in network byte order. Thus: FF FF s s rr cc xp yp Other flags than "ss" may be used in future for other in-band control messages. None are currently defined. Kantor [Page 2] RFC 1282 BSD Rlogin December 1991 From Server to Client Data from the remote server is sent to the client as a stream of characters. Normal data is simply sent to the client's display, but may be processed before actual display (tabs expanded, etc.). The server can imbed single-byte control messages in the data stream by inserting the control byte in the stream of data and pointing the TCP "urgent-data" pointer at the control byte. When a TCP urgent- data pointer is received by the client, data in the TCP stream up to the urgent byte is buffered for possible display after the control byte is handled, and the control byte pointed to is received and interpreted as follows: 02 A control byte of hex 02 causes the client to discard all bufferedShow full document text