Browse Prior Art Database

BSD Rlogin (RFC1258)

IP.com Disclosure Number: IPCOM000002075D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 4 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Kantor: AUTHOR

Abstract

Status of this Memo

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 28% of the total text.

Network Working Group B. Kantor

Request for Comments: 1258 Univ. of Calif San Diego

September 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. 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:

client-user-name

server-user-name

terminal-type/speed

For example:

bostic

kbostic

vt100/9600

The server returns a zero byte to indicate that it has received these

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 thei...