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 IO 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 IO 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). A major difference between jumpers and PnP is that the jumper setting remain the same after you turn off the PC. For PnP the equivalent settings are not remembered by the card and the settings must be supplied anew (via PnP) to the card each time the PC is powered up.
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 IO
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 very well. 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 and the isapnptools FAQ.
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. Not all PnP BIOS can do this. 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, these first two ports get set at the standard IO addresses and IRQs. See Serial Port Device Names & Numbers
Whether you like it or not, when you start up a PC a 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 probably 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 Windows9x on the same PC, the BIOS might ?? have saved the io-irq configuration used for MS Windows in its non-volatile memory. If you're now reading the latest version of this HOWTO let me know if Windows puts it there. If so the BIOS will use this 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 DOS/Windows.
But how do you find out what the BIOS has done so that you set up the device drivers with this info? The BIOS itself may provide some info, either in it's setup menus of via messages on the screen when you turn on your computer. 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 Setserial 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 IO address of the IBM 8514 video board (and it's clones) is
allegedly 0x2e8, the same as the IO address of ttyS3. That is
bad news if you try to use ttyS3 at this IO 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 IO 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 IO 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.
How do you find out what IO address and IRQ are actually set in the device hardware? Perhaps the BIOS messages will tell you some info before Linux starts booting. Use the shift-PageUp key to step back thru the boot-time messages and look at the very first ones which are from the BIOS. This is how it was before Linux started. Setserial can't change it but isapnp can.
For Plug-and-Play (PnP) modems (or PnP serial ports) on the ISA bus
one may try the pnpdump program (part of isapnptools). If
you use the --dumpregs option then it should tell you the actual IO
address and IRQ set in the modem card. The address it "trys" is not
the device's IO address, but a special read-port used only for PnP
purposes.
For an older card, the jumper setting may tell you how its set. If the modem is PCI look at /proc/pci or /proc/bus/pci/devices. 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.
Checking on how it's configured under MS-Windows may not be of much help. Windows stores its configuration info in its Registry which is not used by Linux. It may supply the BIOS's non-volatile memory with some info but it may not be kept in sync with the current Window configuration in the Registry ?? 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) then it should use whatever configuration is in the BIOS's non-volatile memory.
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
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/ttyS2 Look for "crtscts" (without a disabling minus sign).
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 (for example: AT&C1&D3 ). 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 configure the modem each time you use it by sending it a string of commands known as an "init string" (= initialization string). Normally a a communication program does this. What it sends will depend on how you configured the communications 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 it will 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 active profile has been modified since power-up. Since it could have been modified It's a good idea to use some kind of an init string even if it does nothing more than recalling a stored profile.
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. By doing it 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 modify it to suit your purposes.
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.