If you want to use a modem only for MS Windows/Dos, then you can just install almost any modem and it will work OK. With a Linux PC it's not usually this easy unless you use an external modem. All external modems should work OK (even if they are labeled "Plug and Play") But most new internal modems are also Plug-and-Play (PnP) and have PnP serial ports. You may need to use the Linux "isapnp" program to configure them. See the Plug-and-Play-HOWTO for more information.
Since each modem has an associated serial port there are two parts to configuring a modem:
Most of the above configurations are done by the communication program
that you use with the modem such as minicom
or seyon
, or by
the PPP part of your Web Browser. If you use the modem for dial-in,
then the getty
program which you use to present outsiders with a
login-prompt, will help configure. Thus to configure the modem (and
much of the serial port) you need to configure the communication
program (or PPP or getty
). The documentation for these programs
and the PPP-HOWTO may be helpful.
But note that not all of the configuration of the serial port is done by the communication program (or getty). The remaining configuring is fairly simple, mainly consisting of setting the I/O address of the port and its IRQ number. In fact, plug-and-play could set these without you doing a thing. But there's a serious problem: Linux (as of late 1998) doesn't support plug-and-play very well. This may create a difficult problem for you.
Prior to firing up (and configuring) your communication program, you must do the configuring that your communication program can't do. Oversimplified, this consists only of identifying the serial port on which the modem resides: Is it ttyS2 (=COM3) or ttyS1 (=COM2) etc.? If you know the answer for sure (and there are no IRQ conflicts), then there is nothing to do and you may start your communication program .
Otherwise, you must establish the serial port identification and assign it an IRQ number. This is done by putting two values (an IRQ number and I/O address) into two places:
setserial
" at
boot-time)For item 1. setting these numbers in modem card (or for the serial
port in the case of an external modem) was formerly done by jumpers.
Today it's supposed to be done by a plug-and-play operating system.
For item 2. if you accept the default settings there is no need to
use setserial
. But if you use "setserial
" the IRQ and IO
address you tell it must be exactly the same as what is set inside
the serial port hardware (or will be set via PnP). We might call all
of this "io-irq" configuring for short. In the Wintel world, the I/O
address and IRQ are called "resources" and we are configuring
resources.
Plug-and-Play was designed to automate this io-irq configuring, but
for Linux at present, this is a mixed blessing. The standard kernels
for Linux don't support plug-and-play. If you use a patch to
the Linux kernel to covert it to a plug-and-play operating system,
then all of the above is handled automatically by the OS (at least for
the serial port). If you use isapnptools
or the BIOS for configuring
plug-and-play this will only put the two values into the registers of
the serial port section of the modem card and you will likely still
need to set up setserial. See Plug-and-Play-HOWTO.
If you use an external modem and plug it into say the ttyS1 connector, then there's (usually) no io-irq configuring to do since ttyS1 has likely already been io-irq configured. See List of Methods for Setting I/O Addresses and IRQs
Normally you don't need to configure the first two serial ports that your computer comes with since the default configuration works fine. The Linux distribution you get probably has these defaults built into it so you have nothing to do. Everything is different when you want to add a third serial port. The io-irq configuring of it uses the same principles as for the first two serial ports but this time (unless you use a plug-and-play operating system) you have to do it yourself. To do this (as already mentioned) you'll need to run setserial: What is serial and also set the io-irq data into the modem card (formerly done by physical jumpers or switches on the card).
Here's a summary of what was just discussed (and more). The modem is entirely configured by sending commands to it from the computer (via the communication program) as is much of the serial port (such as the baud rate and hardware flow control). For more details on the PnP options see Plug-and-Play-HOWTO. You configure the io-irq of the serial port by:
isapnp
for a PnP internal modem (non-PCI)
No two devices which will run at the same time should share IRQ's
(unless there is special software to handle it). The I/O address of
the IBM 8514 video board (and it's clones) is allegedly 0x2e8, the
same as the I/O address of ttyS3
. That is bad news if you try to
use ttyS3
at this I/O address. Another story is that Linux will
not detect your internal modem on ttyS3
but that you can use
setserial
to put ttyS3
at this I/O address and the modem
will work fine.
There are two answers to this question: 1. What the device driver thinks it is. 2. What is set in the hardware. They both should be the same. If your having trouble (including communication programs that can't communicate) it may mean that these two items are not set the same. In other words, this means that the driver has incorrect info on the serial port. If the driver has the wrong I/O address it will try to send data to a non-existing serial port --or even worse, to an actual device that is not a serial port. If it has the wrong IRQ it will not get interrupt service requests from the serial port, often resulting in the overflow of the serial port's buffers. If it has the wrong model of UART there is also apt to be trouble.
How do you insure that the device driver has the correct info? Well, if everything seems OK then there's no need to look into this. But otherwise, it's easy to see what the device driver thinks. One way is to just type "setserial /dev/ttyS*" but you may need to be the superuser. At boot-time, a message on the console should show this. You may look at /proc/ioports but it only shows the I/O address which setserial has set. To see the IRQs for currently running processes (that have devices open) look at /proc/interrupts. It also shows how many interrupts have been issued. None of the above tests show what is actually set in the device.
But how do you find out what I/O address and IRQs are actually set in
the device hardware? This is not always so easy to do. Formerly one
did this by checking how the jumpers were set on a modem card, serial
card, or motherboard. For Plug-and-Play (PnP) modems (or serial
ports) on the ISA bus just use the pnpdump
program which is part
of isapnptools
. If they are on the pci bus look at /proc/pci ??
If it is not PnP then you may try probing with setserial using the
"autoconfig" option. See
What is Setserial.
See
Flow Control for an explanation of
it. You should always use hardware flow control (except for obsolete
modems that don't have it). Your communication program or
"getty
" should have an option for setting it (and if you're in
luck it might be enabled by default). It needs to be set both inside
your modem (by an init string or default) and in the device driver.
Your communication program should set both of these (if you configure
it right).
If none of the above will fully enable hardware flow control. Then
you must do it yourself. For the modem, make sure that it's either
done by the init string or is on by default. If you need to tell the
device driver to do it is best done on startup by putting a
"stty
" command in say /etc/rc.d/rc.local
or
/etc/rc.d/rc.serial
. Make sure that these files are being
run at startup. You need to add the following to such a file for each
serial port (example is ttyS2) you want to enable hardware flow
control on:
stty crtscts < /dev/ttyS2
If you want to see if flow control is enabled do the following: In
minicom (or the like) type AT&V to see how the modem is configured and
look for &K3 which means hardware flow control. Then see if the
device driver knows about it by typing: stty -a < /dev/ttyS1 Look for
"crtscts" (without a disabling minus sign).
When a modem is powered on, it automatically configures itself with one of the configurations it has stored in its non-volatile memory. If this configuration is satisfactory there is nothing further to do. If it's not satisfactory, then one may alter it. This is done by sending the modem commands to set it up the way you want it. One may then save this existing configuration and also specify that it is to be used when the modem is powered on again.
Another way to configure the modem is to send a sequence of configuration commands to it just before you use it. This sequence of such commands (with no spaces between the commands) is known as an "init string". Most communication programs automatically send the modem an init string and give you some choice as to what it should be.
You might think that if you have set up your power-on configuration correctly, you should use an empty init string (make no changes). This is not always a good idea since some other program might have sent the modem commands to change its configuration resulting in a configuration which is not what you want. Thus, for a Hayes-compatible modem a simple init string might be just: ATZ1. This starts the prefix AT which is required to be first in all init strings to say "ATtention; here's an init string". The Z1 says to reset the modem and load the saved configuration 1 (or profile 1). To save an existing configuration as configuration 1 (profile 1) the command is AT&W1. To have this configuration used at power-up the command is AT&Y1. There is also a profile 0 for which you use a 0 instead of a 1 in the above commands. Note that for USR (and some other) modems, the above Hayes-compatible commands don't work.
Many people don't bother saving a good configuration in their modem, but instead, send the modem a longer init string each time the modem is used. Another method is to restore the factory default configuration 1 by sending the modem AT&F1. Then you might include a few commands in an init string to modify the factory profile 1.
You may pick an init string supplied by someone else that they claim is good for your modem, etc. Some communication programs have a library of init strings to select from. The most difficult method (and one which will teach you the most about modems) is to study the modem manual and write one yourself. You could save this configuration inside the modem so that you don't need an init string. A third alternative is to start with an init string someone else wrote, but modify it a little yourself.
Future edition of Modem-HOWTO may contain more on this but the rest of this section is what was in the old Serial-HOWTO. All strings must start with AT. Here's a few codes that should be in the string (if they are not set by using the factory default or by a saved configuration).
E1 command echo ON
Q0 result codes are reported
V1 verbose ON
S0=0 never answer (uugetty does this with the WAITFOR option)
Here's some more codes concerning modem control lines DCD and DSR:
&C1 DCD is on after connect only
&S0 DSR is always on
DTR does what? (depends on configuration)
These affect what your modem does when calls start and end.
If your modem does not support a stored profile, you can set these
through the INIT
string in a config file (or the like). Some
older modems come with DIP switches that affect register settings. Be
sure these are set correctly, too.
Greg Hankins has a collection of modem setups for different types
of modems. If you would like to send him your working configuration,
please do so:
mailto:greg-hankins@cc.gatech.edu You can
get these setups at
ftp://ftp.cc.gatech.edu/pub/people/gregh/modem-configs
.
Note: to get his USR Courier V.34 modem to reset correctly when
DTR drops, Greg Hankins had to set &D2
and S13=1
(this
sets bit 0 of register S13). This has been confirmed to work on USR
Sportster V.34 modems as well.
Note: some Supra modems treat DCD differently than other modems.
If you are using a Supra, try setting &C0
and not
&C1
. You must also set &D2
to handle DTR correctly.