"getty" is a program that handles the login process when you log into
a Linux box. You will need to use some type of "getty" if you want
others to be able to dial in to your Linux PC with a modem. You
do not need to use getty if you only want to dial out with your
modem. There are three getty versions that modems may use with
Linux: mgetty, getty_ps, and agetty. agetty is the
simplest (and weakest) of the three and some consider it mainly for
text-terminals. The syntax for these programs differs, so be sure to
check that you are using the correct syntax for whatever getty you
use. If this sentence appears in the latest version of this howto,
then if you can write a few paragraphs comparing mgetty with getty_ps,
etc. please submit it so that it can be included here. Mgetty is
only a few years old and seems to be more popular for new
installations than the older getty_ps.
mgetty is a version of getty mainly for use with modems. It
may be used for hard-wired terminals but the documentation is about
99% related to modems. In addition to allowing dialup logins,
mgetty also provides FAX support and auto PPP detection. There
is a supplemental program called vgetty which handles voicemail
for some modems. mgetty documentation (supplied in texinfo
format) is good, and does not need supplementing. Please refer to it
for installation instructions. You can find the latest information on
mgetty at
http://www.leo.org/~doering/mgetty/ and
http://alpha.greenie.net/mgetty
getty_ps contains two programs: getty is used for console
and terminal devices, and uugetty for modems. Greg Hankins
(former author of Serial-HOWTO) used uugetty so his writings
about it are included here. See
Uugetty.
The other gettys are well covered by the documentation that comes with
them.
agetty is the third variation of getty. It's a simple,
completely functional implementation of getty which is best
suited for virtual consoles or terminals rather than modems. But it
works fine with modems under favorable conditions.
mingetty is a small getty that will work only for consoles
(monitors). While the previous 3 variations of getty will work for
both real terminals and dial-in modems, mingetty will not do this.
setserial is a program which allows you to tell the device driver
software the IO address of the serial port, which IRQ is set in the
port's hardware, etc. With appropriate options, it can also probe (at
a given IO address) for a serial port but you must guess the IO
address (or it may use whatever address the driver thinks your
/dev/ttySx is at). Setserial does not set either IRQ's nor IO
addresses in the serial port hardware itself. You must tell setserial
the identical values that have been set in the hardware. It's set in
the hardware either by jumpers or by plug-and-play. Do not just
invent some values that you think would be nice to use. However, if
you know the IO address but don't know the IRQ you may command
setserial to attempt to determine it.
You can see a list of possible commands to use (but not the one-letter
options such as -v for verbose --which you should normally use when
troubleshooting) by typing setserial with no arguments. Note
that setserial calls an IO address a "port". If the argument to
setserial is for example just /dev/ttyS1, then you'll see some info
about how that device driver is configured for that port. But this
doesn't tell you if the hardware actually has these values set in it.
If fact, you can run setserial and assign a purely fictitious IO
address, any IRQ, and whatever uart type you would like to have. Then
the next time you type "setserial ..." it will display these bogus
values without complaint. Note that assignments made by setserial are
lost when the PC is powered down so it is usually run automatically
somewhere each time that Linux is booted.
In order to try to find out if you have a certain piece of serial
hardware you must first know its IO address (or the device driver
must have an IO address for it, likely previously set by setserial).
To try to detect the physical hardware use the -v (verbose) and
autoconfig command to setserial. If the resulting message
shows a uart type such as 16550A, then you're OK. If instead it shows
"unknown" for the uart type, then there is likely no serial port
at all at that IO address. Some cheap serial ports don't identify
themselves correctly so if you see "unknown" you still might have
something there. See the file in which "setserial" is run at
boot-time. Besides auto-probing for uart type, setserial can
auto-probe for IRQ's but this doesn't always work right either.
There is usually a file somewhere that runs setserial at
boot-time. If it's not run at boot-time then your Linux system will
automatically configure only ttyS{0-3} using the default IRQs of
4 and 3 (with the default IRQ conflicts). In 1998 it was (temporarily
?) changed to only ttyS{0-1}. So if you have more than 2 serial
ports, or want to have control over how the ports are configured you
should configure using setserial. In fact, your distribution may have
set things up so that the setserial program runs automatically at
boot-time.
The file that runs setserial at boot-time is likely somewhere in the /etc directory-tree. You might use "locate" to find a file named: rc.serial, or 0setserial (Debian), etc. This supplied file which runs setserial at start-up may contain a number of commented-out examples. By uncommenting some of these and/or modifying them, you may be able to set things up correctly or run some tests. You could copy a few of them to another file and then execute it as a shell script but don't forget to also copy any capitalized definitions needed such as SETSERIAL=/bin/setserial.
If you use setserial you could test it on the command line first,
and then when you have it working, put it into the file which runs it
at boot-time: /etc/rc.d/rc.serial or
/etc/rc.boot/0setserial so that it is run at startup. If
those files don't exist try /etc/rc.d/rc.local (someone
reported that with one kernel, rc.local was executed too late after
the serial port had already been opened). Or you could just edit one
of the above files and cross your fingers. Make sure that you are
using a valid path for setserial, and a valid device name.
By default, both ttyS0 and ttyS2 share IRQ 4, while ttyS0 and ttyS3 share IRQ 3. But sharing serial interrupts is not permitted unless you have kernel 2.2 or better. If you don't have this modern kernel but only have two serial ports ttyS0 and ttyS1 you're still OK since IRQ sharing conflicts don't exist for non-existent devices.
But if you do have more than 2 serial ports, then for kernels < 2.2 such sharing may be dangerous if the two devices with the same IRQ are being used at the same time. If you add an internal modem and retain ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set it both on your modem card (or serial port) and then use setserial to assign it to your device driver. If IRQ 5 is not being used for a sound card, this may be one you can use for a modem. To set the IRQ in hardware you may need to use isapnp, a PnP BIOS (See Using a PnP BIOS to I0-IRQ Configure) or patch Linux to make it PnP. To help you determine which spare IRQ's you might have, type "man setserial" and search for say: "IRQ 11".
isapnp is a program to configure Plug-and-Play (PnP) devices
on the ISA bus including internal modems. It comes in a package
called "isapnptools" and includes another program, "pnpdump" which
finds all your ISA PnP devices and shows you options for configuring
them in a format which may be added to the PnP configuration file:
/etc/isapnp.conf. It may also be used with the --dumpregs option to
show the current IO address and IRQ of the modem's serial port. The
isapnp command may be put into a startup file so that it runs each
time you start the computer and thus will configure ISA PnP devices.
It is able to do this even if your BIOS doesn't support PnP. See
Plug-and-Play-HOWTO.
wvdialconf will try to find which serial port has a modem on
it. It also creates a configuration program for the wvdial program.
wvdial is used for simplified dialing out using the PPP protocol
to an ISP. But you don't need to install PPP in order to use
wvdialconf. It will not find a modem if it's in use. It will
also automatically devise a "suitable" init strings but sometimes
gets it wrong. Since this command has no options, it's simple to use
but you must give it the name of a file to put the init string (and
other data) into. For example type: wvdialconf my_file_name.
stty is like setserial but it sets the baud rate and other
parameters of a serial port. Typing "stty -a < /dev/ttyS2" should show
you how ttyS2 is configured. Most of the settings are for things that
you never need to use with modems (such as some used only for old
terminals of the 1970s). Your communication package should
automatically set up all the setting correctly for modems. But stty
is sometimes useful for trouble-shooting.
Two items set by stty are: 1. Hardware flow control by "crtscts" and 2. Ignore the DCD signal from the modem: "clocal". If the modem is not sending a DCD signal and clocal is disabled (stty shows -clocal) then a program may not be able to open the serial port. If the port can't open, the program may just hang, waiting (often in vain) for a DCD signal from the modem.
Minicom sets clocal automatically when it starts up so there is no problem. But version 6.0.192 of Kermit hung when I set -clocal and tried to "set line ..." If -clocal is set and there is no DCD signal then even the "stty" command will hang and there is seemingly no way to set clocal (except by running minicom). But minicom will restore -clocal when it exits. One way to get out of this is to use minicom to send the "AT&C" to the modem (to get the DCD signal) and then exit minicom with no reset so that the DCD signal remains on. Then you may use stty again.