What happens when a terminal (like a VT100) is connected to a computer?

Question

I'm wondering what's the sequence of actions when a terminal (like a VT100) is plugged into a serial port of a computer? Especially, how the connection of this terminal is detected, and how the terminal is connected with an application on the host system (e.g. the login process)?

One way I can currently imagine this is as follows (assuming "terminal drivers" in the style of UNIX TTY devices that act as middle-men between the physical serial ports and the applications that the terminal connects to):

When a terminal is connected to a computer (or is powered on), usually a login prompt appears on the screen (the output of some login process of the OS, I think on UNIX it is getty), and the user can log in to the system, upon which a shell is usually started.

Now if we consider a free serial port:

1. Does this mean that everything must be already set up for the user login on this port? Like a TTY driver already listening on the port, the login process already running, and probably the login prompt string already in the output buffer of the port? (And this must be the case for every port that can accept connections from terminals.) In that way, when a terminal connects, it immediately gets the login prompt string, and any characters it sends to the computer are immediately read by the TTY driver and passed to the login process.
2. Or is there just mechanism that detects the connection of a terminal to a given port (and detects that it is indeed a terminal and not some other type of device) upon which it starts a TTY process for this port, and a login process, and hooks them up so that the login can occur (i.e. the above diagram is incorrect)?

In either of these cases, there are the following further questions:

3. If my terminal is connected to a given port, and I'm already logged in, then I disconnect my terminal and connect it to another free port, do I have to repeat the login?
4. If my terminal is connected to a given port and I'm logged in, then I physically disconnect my terminal from the port (the port is now free) without logging out, and then some other user connects his terminal to the same port, is he then logged into my account (or is there an automatic logout when a terminal disconnects)?
5. If I'm logged in and I power off my terminal without logging out, then the next day turn it on again, am I still logged in, and connected to the same application that I left the day before?
6. Do ports used by terminals only work with terminals and not with other types of devices (because they must be set up in a way that the automatic detection of connections and the login process may occur)? Thus connecting, for example, a printer to a port that is usually used for terminals wouldn't work (except if the printer would "pretend" to be a terminal and simulate the manual login of a user)?

Answer 1

Does this mean that everything must be already set up for the user login on this port? Like a TTY driver already listening on the port, the login process already running,

Exactly. In every system I've worked with, a port is assigned at or before boot time to be a terminal (input/output TTY-style session), printer, modem (as an auxiliary port - if it is for a regular terminal session then the only difference is handshaking protocol) or other specialized device (e.g., touch screen, mouse, bar code scanner, etc.)

and probably the login prompt string already in the output buffer of the port? (And this must be the case for every port that can accept connections from terminals.)

Depends on the system. Typically yes, the prompt string will already be in the buffer. But in some cases there will be speed negotiation first (that's the "hit return a couple of times" thing). In some cases there will be hardware handshaking - either standard terminal handshaking (like CTS/RTS) or even detection of Carrier Detect (pin 8 on RS232 DB25). CD monitoring is the best for a remote connection because that way the modem can still use CTS/RTS for command transfers (e.g., Hayes Smartmodem AT commands) yet the system can still "know" whether there is a real connection or not via CD and disconnect and automatically logout when CD is dropped, which is a big security benefit.

In that way, when a terminal connects, it immediately gets the login prompt string, and any characters it sends to the computer are immediately read by the TTY driver and passed to the login process.

Correct.

Or is there just mechanism that detects the connection of a terminal to a given port (and detects that it is indeed a terminal and not some other type of device) upon which it starts a TTY process for this port, and a login process, and hooks them up so that the login can occur (i.e. the above diagram is incorrect)?

Typically I have seen that the login process is always running automatically. But there is sometimes a speed detection routine. That was especially the case before high-speed modems with buffers and hardware handshaking (which, to be honest, I found many "professionals" never quite understood). In the old days, you might have a 300bps modem answering a phone line and if it got a 300bps connection then the serial port would have to run at 300bps and if it got a 110bps connection then the serial port would have to switch to 110bps. Then when 1200bps modems came along, some systems would have a separate set of phone lines & modems for 1200bps and some would let the 1200 also run at 300 - but the system had to support it for that to work.

If my terminal is connected to a given port, and I'm already logged in, then I disconnect my terminal and connect it to another free port, do I have to repeat the login?

Yes. Each port is independent. They would be identified as tty1, tty2, etc. in Unix or similar for other operating systems. Security in a system could prevent a user from logging in on multiple terminals at the same time, but generally that was not (and still is not) a problem.

If my terminal is connected to a given port and I'm logged in, then I physically disconnect my terminal from the port (the port is now free) without logging out, and then some other user connects his terminal to the same port, is he then logged into my account (or is there an automatic logout when a terminal disconnects)?

That definitely has the potential for security problems. However, in most environments that was just not an issue. Where it becomes an issue is with remote connections via modem. If a system automatically logged a user out when CD was dropped then no problem. Otherwise, yes this could be a problem. Often systems would have an activity timeout - e.g., no activity in 15 minutes = automatic forced logout. But that would still leave a window of opportunity for someone to get in if they dialed in to a modem line where a user recently disconnected without logging out, either due to modem or phone line problems or just forgetting to logout.

If I'm logged in and I power off my terminal without logging out, then the next day turn it on again, am I still logged in, and connected to the same application that I left the day before?

Yes, unless the system has an automatic timeout or the system closes applications (and possibly even reboots) nightly to make sure backups can run. I have written systems like that, where I could send a signal to my application to force safe ending of the application (i.e., no file corruption) and would do that automatically at midnight (or whenever was convenient for the particular customer) in order to make sure backups would run.

Do ports used by terminals only work with terminals and not with other types of devices (because they must be set up in a way that the automatic detection of connections and the login process may occur)? Thus connecting, for example, a printer to a port that is usually used for terminals wouldn't work (except if the printer would "pretend" to be a terminal and simulate the manual login of a user)?

A port is a port, of course, of course.

Technically everything is the same. So I have hooked up computers to serial (and parallel) ports to capture data from other computers that thought they were just printing. Decwriters (e.g., LA36, LA120) were very popular terminals but as video terminals advanced they often got repurposed as printers. Bar code scanners and other specialized input devices were (still are) often connected on the input side of a serial port and the computer doesn't know the difference between terminal keyboard input and a bar code scan. But in most systems terminal ports are input/output and printer ports are output only and you don't mix them except in special situations.

Answer 2

If the line is using modems, then the modem knows when you've called it (carrier detect), and after some handshaking, signals the host OS that the line is now connected. Alternatively, for hardwired terminals, the line is 'always connected'.

In late 20th-century usage, the host end would 'autobaud' to detect the terminal speed, which typically required you to bang on the return key a few times.

After that we're in OS-dependent territory. Some DEC operating systems would have the terminal driver create a process to handle a newly-active terminal, and for VMS in particular, that process would be running LOGINOUT. Unix has a login(*) process ready and waiting on each configured terminal line. George 3 MOP terminals required an explicit ctrl/A, as far as I recall.

As for automatic logout: from memory, it rather depended on whether modem control was in use. If yes, then terminal power-off was detectable. If not, then it probably wasn't: but then the terminal was generally hardwired. In practice, no-one walked away leaving a public terminal logged in.

(*) The Unix "login" function appears to have been variously fulfilled by init (see here, section 6.6), login, or getty, depending on edition.

Answer 3

First of, this question is impossible to be answered in a general context, so the assumption of a Unix(oid) system will prevail. Second, even in a Unix(oid) environment variations are way too large for an exhaustive answer.

Does this mean that everything must be already set up for the user login on this port? Like a TTY driver already listening on the port, the login process already running, and probably the login prompt string already in the output buffer of the port? (And this must be the case for every port that can accept connections from terminals.) In that way, when a terminal connects, it immediately gets the login prompt string, and any characters it sends to the computer are immediately read by the TTY driver and passed to the login process.

No. Why - and even more, how? To start with, there is no guaranteed notification about a terminal being plugged in (or removed) - unless that terminal (and the host) also operates certain additional signals (DTR/DSR). These signals are optional. This is different if the connection is via a modem, as a modem does (usually) handle these signals plus others to inform the host about calls and so on.

Or is there just mechanism that detects the connection of a terminal to a given port (and detects that it is indeed a terminal and not some other type of device) upon which it starts a TTY process for this port, and a login process, and hooks them up so that the login can occur

First of all, on a serial line, everything is a terminal. There are no 'other' devices.

Second, there is no secret detection process. When the terminal services are started, the login process just blurts out a login prompt to each port. No matter if there's a terminal connected or not. If one is connected, the user will see it and may log in. If none is connected, or it was turned off during startup, one has to press CR to get a reaction. Usually the login prompt again. That's the way the login process notices that there is a terminal and someone wants to interact.

Always keep in mind, we are talking about a very simple environment here. something that can be operated with a teletype - a mechanical device.

(i.e. the above diagram is incorrect)?

No, it just does not describe that part of the process. It only illustrates that the Kernel offers access to the terminal interface via a device called TTY1

If my terminal is connected to a given port, and I'm already logged in, then I disconnect my terminal and connect it to another free port, do I have to repeat the login?

A login is tied to a port, not a terminal. The terminal has no way to tell the host that it moved - nor does the host know how to handle this. The host handles a port with an optional terminal connected, not a terminal

What happens with the login on the old port, or what state the new one is in depends on what happened before. Usually you need to login again - and then kill the process on the other port - as you will be still logged on on there.

If my terminal is connected to a given port and I'm logged in, then I physically disconnect my terminal from the port (the port is now free) without logging out, and then some other user connects his terminal to the same port, is he then logged into my account (or is there an automatic logout when a terminal disconnects)?

Again, depends on the hardware support for that interface. If DTR/DSR is supported, a host may decide to end a login. if it isn't, the login will stay present at this port.

If I'm logged in and I power off my terminal without logging out, then the next day turn it on again, am I still logged in, and connected to the same application that I left the day before?

Usually yes (again, depending on signal handling and program).

Do ports used by terminals only work with terminals and not with other types of devices (because they must be set up in a way that the automatic detection of connections and the login process may occur)?

There is no automatic detection per se. While it would be possible to do so, at least with some high level terminals, I'm not sure if that has ever been implemented.

Thus connecting, for example, a printer to a port that is usually used for terminals wouldn't work (except if the printer would "pretend" to be a terminal and simulate the manual login of a user)?

Again, these are features defined by the application. For the OS a serial port is just a serial port. Everything above exchange of data is already application layer.

---

From these questions it seems a bit as if you expect a serial port to be more than it is - and similarly imply certain levels of drivers or OS handling. While this may be true for some OS and environments it's not guaranteed by any default behaviour. In a Unix(oid) system there is just a serial port. It can have some process assigned. If that's getty, then its interaction on this line will be asking for a login, and when given hand the the execution over to a shell. This is already an application level. Nothing done by a driver. This means there is also no driver to hand over logins to other ports, or similar.

If at all, the only message the driver may send to whatever application right now controls the process is a SIGHUP when he identifies a disconnect. If and how this application reacts depends on the application.

On a serial port there is a serial device. What kind of device this is is not defined. It's up to the application to interact accordingly - that's why it may be a good idea to not start a getty on a port with a printer plugged in, but maybe some spool. But that's nothing the OS will check - or even offer a way to check.

Keep in mind, all of this is designed to communicate with some mechanical teletype - this is so far from a high level world you may have in mind as an ox-cart is from a semi truck - still, both can be used to transport stuff on the same road :))

Answer 4

The TTY port must be set up to handle the terminal otherwise it will not respond. It does not normally detect the connection of a terminal.

When you connect or power on a terminal to a RS232 port you normally have to send a CR or two to get the login: prompt. However, if your terminal is connected and powered up when the system boots you will see the login prompt when the boot is completed. (so 1 not 2).

In answer to (3) Yes: you have to login separately on each serial line.

In answer to (4) Yes: Someone else can steal your session if something else is plugged in. (However, do not think that remote sessions could be compromised. If the connection is via a modem the the disconnect signal (called HUP) from the modem would cause a logout. You only asked about physical plugging and unplugging).

In answer to (5) Yes.

In answer to (6) Its complicated. Serial lines can work with all kinds of devices, printers, modems, scanners, xray molecular probes, whatever. It is all just data.

Answer 5

It depends. There were several different things done over the ages.

Some system had automatic baud rate detection. Here the port adjusted itself to the baud rate of the terminal. After hitting some keys several times (such as Carriage Return), the port detected the sequence and adjusted itself until it cleanly got the right key.

On my systems back in college, there was a key on the terminal call LOCAL. When you approached the terminal, you had to toggle this key (it would lock in the up or down position) which would alert the terminal controller hardware about to disconnect and reconnect. At that point you'd hit CR and you'd get a login prompt. When you logged out of your session, you'd have to toggle LOCAL again. If you toggled LOCAL without logging out, it just killed your session anyway and you logged back in.

With Unix box, there's a program that was historically called 'getty'. In a generic Unix system, a serial port is tied to a /dev/ttyXX device. You'd have the start up routines (inittab back in the day) start a getty process that would listen to activity on the serial port. Plug in a terminal, and get a login prompt.

If you were using a modem, a couple of things could happen.

One, you could set the modem to auto-answer. Then it's like any other serial device. When it answers, you're connected to the computer (even getty) and on your merry way.

You could have a different process that's listening to the modem. When the modem rings, it sends the text RING to the computer. The computer listens for this, and then send the appropriate answer command to the modem to pick up the line, and, again, away you go.

Finally, you have the modem connected to the computer at a fix baud rate. You can have the modem set to auto answer (or not), but either way, when the modem does pick up, it will negotiate the baud rate with the other modem. This is how you can call a 9600 baud modem with a 300/1200/2400/9600 baud modem.

When the modem is done negotiating, it will send something like "CONNECT 2400", telling the computer that it's making (in this case) a 2400 baud connection. At this point, the computer needs to reset its baud rate from the original 9600, down to 2400 so it can continue to communicate with the modem. At the end of the session, the modem and the line resets.

Since the serial port is asynchronous, you can just start spewing data out whether you're connected or not, at any baud rate, etc. In the end, outside of handshaking, it's basic coincidence that both sides of the system are chatting at the proper baud rate. In fact, it's possible to send out at one baud rate, and receive at another. They're unrelated.

Answer 6

RS232 is a very simple protocol. In most basic form it just sends character data back and forth and there's very little more over that. Think of VT100 as a keyboard + monitor pair. You can unplug your monitor and keyboard from a running PC after you've logged in, then someone comes and plugs their own in... and they are logged into your account, because the computer really doesn't care what monitor or keyboard is plugged in.

With RS232 it's even more simple. If data gets lost or garbled on the way, that's what the other end receives (or fails to receive). If there's nothing listening on the port, the data will go down the drain, there's no check whether the other end received it or not. You can plug the VT100 into RS232 and only then, say, using SSH from a different workstation, set up the listening demon, like getty. Or you can plug it into a computer where getty is already running; the login prompt won't appear - it's awaiting input and it's quite likely even as you start typing your first login will fail as plugging RS232 generates a lot of line noise and may send some junk characters to getty over the TX line before you ever get any feedback on screen returning over the (still not firmly connected) RX line.

There are some extensions to basic RS232 - like hardware control that tells the other side 'Data transmit ready' and 'Clear to send' - preparing buffers for reception, halting sending until the buffers are processed and so on, but even with that if the message gets garbled in transfer, it's received garbled - and VT100 displays what it got if it sufficiently resembled a valid byte of transmission (...and on a noisy line a lot of noise resembles these...) - and similarly the computer sends what came in over RS232 to the processing application if there's any, or down the drain if there's none, and if it makes no sense, so be it, it's an error.

With smart terminal apps there's some communication behind the scenes arranging the feature set of the terminal - size in columns and rows, what key is backspace, what sequence is enter, is color supported and so on, but that's way outside the basic connection layer, not often supported and more than often buggy.