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 Plug-and-Play (PnP) and have PnP serial ports. You may need to use the Linux "isapnp" program to configure these PnP serial ports. 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 configuring (but not necessarily most of the effort)
is 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/or the PPP-HOWTO should 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 simple to state (but sometimes difficult to do). It mainly consists 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 early 1999) 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)Both of the above are supposed to by done by a plug-and-play operating system (OS). For item 1. setting these numbers in a 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 at boot-time by plug-and-play (PnP).
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 thus configuring
certain resources.
Plug-and-Play was designed to automate this io-irq configuring,
but for Linux at present, it has made life more complicated. 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 should be handled automatically by the
OS. But when you want to use this to automate configuring devices
other that the serial port, you may find that you'll still have to
configure the drivers manually since many Linux drivers are not
written to support a Linux PnP OS. 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. None of this is easy
or very well documented as of early 1999. See Plug-and-Play-HOWTO.
While the explanation of how to use a PnP OS or isapnp for io-irq configuring should come with such software, this is not the case if you want to let a PnP BIOS do such configuring. The BIOS usually has a CMOS menu for setting up the first two serial ports. There is often little to choose from. Unless otherwise indicated in menus, the standard I/O addresses and IRQ's should be used by the BIOS. See Serial Port Device Names & Numbers
Whether you like it or not, when you start up a PC the PnP BIOS starts to do PnP (io-irq) configuring of hardware devices. It may do the job partially and turn the rest over to a PnP OS (which you don't have) or if thinks you don't have a PnP OS it may fully configure all the PnP devices but not configure the device drivers. This is what you want but it's not always easy to figure out exactly what the PnP BIOS has done.
If you tell the BIOS that you don't have a PnP OS, then the PnP BIOS should do the configuring of all PnP serial ports --not just the first two. If you have MS Windows on the same PC, the BIOS should have saved the io-irq configuration used for MS Windows in its non-volatile memory and use the same configuration for Linux. In this case if you can find out how MS Windows has set up io-irq then it should be the same under Linux.
If you add a new PnP device, the BIOS should change its PnP configuration to accommodate it. It could even change the io-irq of existing devices if required to avoid any conflicts. For this purpose, it keeps a list of non-PnP devices provided that you have told the BIOS how these non-PnP devices are io-irq configured. One way to tell the BIOS this is by running a program called ICU under MS Windows.
But how do you find out what the BIOS has done so that you set up the device drivers with this info? It would be nice the the BIOS's CMOS menus provided this info but they probably don't (except for COM1 and COM2). So it may be quite a hassle to find out. See What is set in my serial port hardware?
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. Your CMOS BIOS may have a menu to do this for COM1 and COM2.
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 by PnP methods (or by physical jumpers or switches on old cards).
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)
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.
There are two answers to this question: 1. What the device driver thinks has been set (This is what setserial "sets"). 2. What is actually set in the hardware. They both should be the same. If you're 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, resulting in the possible overflow of the serial port's buffer and in very slow response (due to fallback to very slow "polling" methods instead of interrupts). 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 -g /dev/ttyS*". At boot-time, a message on the console should show this. You may look at /proc/ioports but it only shows the same I/O address which setserial has "set" but are not necessarily the way its actually set in the hardware. To see the IRQs used by currently running processes (that have devices open) look at /proc/interrupts. It also shows how many actual interrupts have been issued (often thousands). None of the above tests show what is actually set in the device. But if everything works fine, the devices are likely actually set up that way in the hardware.
But how do you find out what I/O address and IRQ are actually set in the device hardware? If the modem is PCI look at /proc/pci. If it's ISA, 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. One crude method is try probing with setserial using the "autoconfig" option. You'll need to guess the addresses to probe at. See What is Setserial.
For Plug-and-Play (PnP) modems (or PnP serial ports) on the ISA bus
one may try the pnpdump program (part of isapnptools).
Pnpdump will "find" the port and show various configuration options,
but will not tell you its actual I/O address and IRQ. The address it
"trys" is not the device's I/O address, but a special read-port
used only for PnP purposes. After getting some info using pnpdump,
this info may be used in complex isapnp commands using the "PEEK"
keyword to attempt find out the I/O and IRQ. The isapnp command in
the isapnp-configuration file might look something like this (for
vendor GVC1601, serial number 1):
(CONFIGURE GVC1601/1 (LD 0
(IO 0 (PEEK))(INT 0 (PEEK)))) You'll need more than just this one
command and it isn't foolproof (see the man page for isapnp.conf). I
know that the above is not really adequate but if you succeed in doing
it you could write it up and send it to me for inclusion here. Do
this only if you see this request in the latest version of this HOWTO.
Another approach is to see how it's configured under MS-Windows (if you have it on the same machine). How it's configured under MS-Windows may not be the same as for Linux, but it's likely the same if you let a PnP BIOS automatically do the configuring when you start Linux (and have told the BIOS that you don't have a PnP operating system when running Linux).
See
Flow Control for an explanation of
it. You should always use hardware flow control if possible. 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 file that runs at boot-time. See the subsection Boot-time Configuration 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
While the serial port on which a modem resides requires configuring, so does the modem itself. The modem is configured by sending AT commands (or the like) to it on the same serial line that is used to send data.
Most modems use an AT command set. These are cryptic and short ASCII commands where all command strings are prefaced by the letters AT. For example: ATZ&K3 There are two commands here Z and &K3. Unfortunately there are many different variations of the AT command set so that what works for one modem may or may not work for another modem. Thus there is no guarantee that the AT commands given in this section will work on your modem. Another point is that to get the modem to act on the AT command string, a return character must be sent at the end of the string. Sometimes the AT is prefaced by a return character and sometimes there are symbols added to the string (such as ) which only tell the communication program to pause for a tiny interval of time at that point.
If you have a manual for your modem you can likely look up the AT command set in it. Otherwise, you may try to find it on the Internet. One may use a search engine and include some actual commands in the search terms to avoid finding sites that just talk about such commands but fail to list them. You might also try a few of the sites listed in the subsection Web Sites
The examples given in this subsection are from the Hayes AT modem command set. All command strings must be prefaced by the two letters AT. 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 either alter it or reconfigure the modem by sending it a string of commands known as an "init string" (= initialization string). Most of the time, an init string is automatically sent to the modem when you start up a communication program (will depend on how you configured the program or what script you wrote for it if you use Kermit). You can usually edit the init string and change it to whatever you want. Sometimes the communications program will let you select the model of your modem and then use an init string that it thinks is best for that modem.
So there is both a default "string" (called a profile) stored inside the modem and another (the init string) that the communications program sends it. The modem will wind up configured like the default set it except that it will be modified by the commands included in the init string. If the init string is empty then it will of course use the default configuration.
Actually there is more than one "default" configuration (or profile) stored in the modem's non-volatile memory (it's still there when you turn it off). In my modem there are two factory profiles (0 and 1, neither of which can be changed) and two user defined profiles (0 and 1) that the user may set and store. Your modem may have more. Which one of these user-defined profiles is used at power-up depends on another item stored in the profile. If the command &Y0 is given then in the future profile 0 will be used at power-on. If it's a 1 instead of a 0 then profile 1 will be used at power-on.
There are also commands to recall (use it now) any of the 4 stored profiles. One may put such a command in an init string. Of course if it recalls the same profile as was automatically loaded at power-up, nothing is changed (unless the init string is sent after the modem has been in use for a while and had it's configuration changed by software, etc.) It's a good idea to use some kind of an init string so that it may be reset by sending it the init string after it's been in use for a while (and may have had it's initial configuration modified).
Recalling a saved profile (use 1 instead of 0 for profile 1):
Z0 recalls user-defined profile 0 and resets (hangs up, etc.)
&F0 recalls factory profile 0
Once you have sent commands to the modem to configure it the way you
want (including recalling a factory profile and modifying it a little)
you may save this as a user-defined profile:
&W0 saves the current configuration to user-profile 0
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 at the start of the init string and then modify it a little by adding a few other commands to the end of the init string. This way no one can cause problems by modifying the user-defined profile which is loaded at power-on.
You may pick an init string supplied by someone else that they think is right for your modem. 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 improve on it a little yourself.
Future editions of Modem-HOWTO may contain more AT commands but the rest of this section is what was in the old Serial-HOWTO. All strings must start with AT. Here's a few Hayes AT codes that should be in the string (if they are not set by using a 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
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:gregh@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.