Jtdcftul

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)?

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.

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. Original Unix had a login process ready and waiting on each line, with a pending I/O request that would not complete until the driver declared the device ready. Later that got replaced by an instance of getty which would set up the (software) tty device before exec'ing login. 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.

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.

First of, this question is impossible to be answered in a general context, so the assumption of a Unix(oide) system will prevail. Second, even in a Unix(oide) environment variations are way to 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 terminals (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 other 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, everyhing is a terminal. There are no 'other' devices.

Second, there is no secret detection process. When the terminal services are started, the loginprocess just blurs out to each port a login prompt. 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 promt 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 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 ilustrates 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 ist 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.

Form these questions it seams a bit as if you expect a serial port to be more than it is - and similar imply certain levels of drivers or OS handling. While this may be true for some OS and environments it's not guranteed by any default behaviour.
In a Unix(oide) 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 sent 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 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 :))