Mixing
What happens when a terminal (like a VT100) is connected to a computer?
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:
- 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.
- 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:
- 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?
- 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)?
- 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?
- 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)?
unix terminal vt100
asked Jan 22 at 23:16
weibeldweibeld
24617
add a comment |
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:
- 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.
- 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:
- 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?
- 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)?
- 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?
- 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)?
unix terminal vt100
asked Jan 22 at 23:16
weibeldweibeld
24617
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04
add a comment |
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:
- 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.
- 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:
- 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?
- 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)?
- 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?
- 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)?
unix terminal vt100
asked Jan 22 at 23:16
weibeldweibeld
24617
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:
- 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.
- 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:
- 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?
- 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)?
- 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?
- 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)?
unix terminal vt100
unix terminal vt100
asked Jan 22 at 23:16
weibeldweibeld
24617
asked Jan 22 at 23:16
weibeldweibeld
24617
edited Jan 22 at 23:23
weibeld
asked Jan 22 at 23:16
weibeldweibeld
24617
asked Jan 22 at 23:16
weibeldweibeld
24617
asked Jan 22 at 23:16
weibeldweibeld
24617
24617
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04
add a comment |
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04
add a comment |
5 Answers
5
active
oldest
votes
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.
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
add a comment |
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 :))
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
add a comment |
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.
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
The statements about Unix are wrong, here.gettywas there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, anopen()call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).
– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's notlogin, it's notgetty, it'sinitthat's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree onopennot completing until CD detected, I'd forgotten the detail.
– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
|
show 1 more comment
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.
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
Note that if you ranloginon a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.
– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
add a comment |
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.
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8896%2fwhat-happens-when-a-terminal-like-a-vt100-is-connected-to-a-computer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
add a comment |
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.
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
add a comment |
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.
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
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.
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
answered Jan 22 at 23:47
manassehkatzmanassehkatz
3,022623
3,022623
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
add a comment |
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
1
1
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
The "port is a port" concept is what makes terminals so powerful. They can control anything that prints text and accept bytes in serial - form mainframes to linux servers to phones (some older dumb phones had serial ports that implement modem AT commands - VT100 terminals could of course connect to them)
– slebetman
Jan 28 at 4:09
add a comment |
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 :))
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
add a comment |
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 :))
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
add a comment |
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 :))
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
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 :))
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
answered Jan 23 at 0:34
RaffzahnRaffzahn
52.8k6125213
52.8k6125213
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
add a comment |
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
Sure, a port is a port. And there must be some port driver running which simply allows to read/write bytes from/to this port. The port driver is totally agnostic to what application the bytes that it sends and receives belong. But with setting things up for a terminal connection, I mean that there must be a human decision to assign a TTY device to this port driver (or maybe it's hardcoded) and assign a login process (e.g. getty) to this TTY device. In this way, a given port would be "predestined" to be used by a terminal (by a human decision, not some mechanism on the kernel/driver level)?
– weibeld
Jan 23 at 10:28
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
@weibeld Exactly. It's all manual setup and human decision. Especially on classic Unix. One had to configure one line per port in /etc/inittab to have a process running and handling the port. Like ` 1:2345:respawn:/sbin/getty 9600 tty1` (repeated for each serial line). Ofc, instead of getty any other program could be used - like a BBS or in case of a company application whatever program that managed. Or in case of other hardware some different getty, like mgetty for modems (getty worked as well for simple modems, but could not handle anything but RI and DTR/DSR)
– Raffzahn
Jan 23 at 13:03
add a comment |
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.
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
The statements about Unix are wrong, here.gettywas there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, anopen()call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).
– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's notlogin, it's notgetty, it'sinitthat's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree onopennot completing until CD detected, I'd forgotten the detail.
– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
|
show 1 more comment
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.
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
The statements about Unix are wrong, here.gettywas there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, anopen()call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).
– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's notlogin, it's notgetty, it'sinitthat's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree onopennot completing until CD detected, I'd forgotten the detail.
– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
|
show 1 more comment
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.
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
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.
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
edited Jan 25 at 23:55
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
answered Jan 22 at 23:39
another-daveanother-dave
1,122111
1,122111
The statements about Unix are wrong, here.gettywas there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, anopen()call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).
– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's notlogin, it's notgetty, it'sinitthat's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree onopennot completing until CD detected, I'd forgotten the detail.
– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
|
show 1 more comment
The statements about Unix are wrong, here.gettywas there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, anopen()call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).
– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's notlogin, it's notgetty, it'sinitthat's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree onopennot completing until CD detected, I'd forgotten the detail.
– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
The statements about Unix are wrong, here.
getty was there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, an open() call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).– JdeBP
Jan 25 at 19:18
The statements about Unix are wrong, here.
getty was there right from the start, in 1st Edition. The pending I/O request was, for remote terminals, an open() call that would not complete until the carrier detect line was asserted by the DCE. And I quite a number of times encountered terminals that people had walked away from having left them logged in (but with the terminal powered off).– JdeBP
Jan 25 at 19:18
I was indeed wrong. It's not
login, it's not getty, it's init that's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree on open not completing until CD detected, I'd forgotten the detail.– another-dave
Jan 25 at 23:44
I was indeed wrong. It's not
login, it's not getty, it's init that's reading the tty. Or so say Ken and Dennis - section 6.6. The lesson for us here is that "original Unix" depends on where you were standing at the time. Agree on open not completing until CD detected, I'd forgotten the detail.– another-dave
Jan 25 at 23:44
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
@JdeBP - Edited answer to avoid getting bogged down in detail. Added footnote re init, login, getty.
– another-dave
Jan 25 at 23:56
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
The 2nd ed. manual (oldest I could find) admits to getty, and says that init execs getty when the tty open completes, i.e, the open was issued by init.
– another-dave
Jan 26 at 0:07
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
Found 1st ed manual online. Here is section 7 and under 'init', it appears that all of the login mechanism is still in init at this time.
– another-dave
Jan 26 at 0:39
|
show 1 more comment
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.
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
Note that if you ranloginon a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.
– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
add a comment |
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.
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
Note that if you ranloginon a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.
– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
add a comment |
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.
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
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.
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
edited Jan 22 at 23:33
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
answered Jan 22 at 23:24
Brian Tompsett - 汤莱恩Brian Tompsett - 汤莱恩
1,495521
1,495521
Note that if you ranloginon a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.
– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
add a comment |
Note that if you ranloginon a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.
– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
Note that if you ran
login on a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.– immibis
Jan 23 at 4:20
Note that if you ran
login on a serial port at the same time as your fancy x-ray device, it probably won't work very well. It's an unfortunate historical fact that the system doesn't distinguish between terminals, and other serial devices.– immibis
Jan 23 at 4:20
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
"The TTY port must be set up to handle the terminal otherwise it will not respond." Is this usually hardcoded in the OS for every port, or can you freely set up every port in any way you like?
– weibeld
Jan 23 at 10:23
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
@weibeld It's a matter of configuring the startup processes whether you want a login process on some TTY line or leave it free for printer usage, serial file transfer etc. Of course, it's wise to have at least one login process configured, so you can still login to the system after the next boot.
– Ralf Kleberhoff
Jan 23 at 19:22
add a comment |
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.
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
add a comment |
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.
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
add a comment |
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.
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
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.
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
answered Jan 26 at 6:53
Will HartungWill Hartung
3,9361022
3,9361022
add a comment |
add a comment |
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8896%2fwhat-happens-when-a-terminal-like-a-vt100-is-connected-to-a-computer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
In every system I've seen there is no detection mechanism. The serial port listens to input and generates output regardless of weather there is something connected to it or not.
– slebetman
Jan 28 at 4:04