mirror of https://github.com/tLDP/LDP
6475 lines
329 KiB
Plaintext
6475 lines
329 KiB
Plaintext
<!doctype linuxdoc system>
|
|
<article>
|
|
<title> Modem-HOWTO
|
|
<author>David S.Lawyer
|
|
<tt><url url="mailto:dave@lafn.org"></tt>
|
|
<date> v0.39, January 2007
|
|
|
|
<!--
|
|
Change log:
|
|
v0.39 Jan. 2007 gromitkc url (modem list) seems to be no longer
|
|
maintained. Redefined "antique modems" as all under 56k speed.
|
|
setpci can't set IRQs. devfs is obsolete. vgetty supports ITU v.253
|
|
v0.38 June 2005: Eliminated section on Digital Modems in appendix since
|
|
it's already covered elsewhere. More on cable modems. ISDN serial
|
|
modems. Troubleshooting: Can't find winmodems if no driver.
|
|
v0.37 Feb. 2005: For AMR, codec is on motherboard. Fixed a few typos.
|
|
Better clarity for Dial-In. "NO CARRIER" likely not displayed when
|
|
remote hangs up.
|
|
v0.36 Feb. 2005: Rewrote "Quick Install" oriented towards PCI.
|
|
Some external RS-232 modems are winmodems. /dev/modem.
|
|
v0.35 Dec. 2004: send AT expect OK may not work, 2 modems back-to-back
|
|
work OK w/o a phone line
|
|
v0.34 Nov. 2004: Sentence fragment: ... "use up" fixed. url tag error.
|
|
Distinctive ring workaround. LPC bus.
|
|
v0.33 Aug. 2004: Modems use telco power, Some external serial modems
|
|
need Windows ?? Again: new gromitkc url
|
|
v0.32 Dec. 2003: Still newer gromitkc url w/o pop ups; more on devfs
|
|
v0.31 Nov. 2003: Mgetty dial-in, setserial rewritten
|
|
v0.30 August 2003 New gromitkc url, some internals have FIFO overrun
|
|
v0.29 July 2003 New gromitkc url, but many links in it are broken
|
|
v0.28 June 2003 Parallel port modems, lockfile permissions for wvdial
|
|
v0.27 May 2003: "Flow control" improved
|
|
v0.26 March 2003: USB clarity improved, v.92 modem "on hold" supported?,
|
|
3Com AT codes
|
|
v0.25 September 2002: Must restart minicom after configuring it unless
|
|
you used the -s option. HCF is not an all-software modem as was
|
|
incorrectly claimed. Better clarity for "Quick Install" and 56k
|
|
modems. Does my PC have a modem?
|
|
v0.24 June 2002: new callback link, "You are already online" error,
|
|
fixed several typos reported by Francesco Ronconi
|
|
v0.23 January 2002: dropped connection w/V.90, X3 to force dialing if
|
|
NO DIALTONE, more on USB, wvdial added to "Trying Out Your Modem",
|
|
major revision to "Antique Modems", several broken links fixed,
|
|
better clarity re RAS, digital modems.
|
|
v0.22 September 2001: &X3 -> X3, NO CARRIER, NO DIALTONE
|
|
v0.21 August 2001: clarity re autobauding, corrected linmodem
|
|
situation, more mention of USB, major revision of Configuring the
|
|
Serial Port now named: Locating ..., minor reorganization
|
|
v0.20 August 2001: fixed typo: done->down, more linmodems
|
|
v0.19 July 2001: Dialing Out while Waiting for a Call. Antique modems
|
|
using "CONNECT" to set DTE speed.
|
|
v0.18 June 2001 new section: modem doubling (bonding, teaming, multilink)
|
|
v0.17 April 2001 isapnp to pnpdump (with "dumpregs" option)
|
|
v0.16 March 2001 New url for winmodem.html, more obsolete protocols
|
|
v0.15 March 2001 Revision of Dial-In section (incl. problems with
|
|
agetty, interoperability with MS, VNC), blacklist, AT-cmds on Internet,
|
|
broken links fixed
|
|
v0.14 Feb. 2001 Fixed typos & revised: "Ending a Dial-in Call"
|
|
v0.13 Feb. 2001 serial-modem => digital-modem, fixed suse isdn link,
|
|
antique modems, typos fixed in "Getty", new section: "Ending a Dial-in
|
|
Call"
|
|
v0.12 Dec. 2000 Zoltrix and Cirrus Logic linmodems; don't omit 0 in X0
|
|
(for some modems) X3 if no dial-tone; init string locations; more on
|
|
"Modem is busy"; PCI non-winmodems are OK; terminology: software-based
|
|
modem, driver-based modem; Linmodem-HOWTO; types of software modems;
|
|
setserial irq5 to irq 5; Quick Install rewrite
|
|
v0.11 June 2000 Winmodems-and-Linux-HOWTO, removed general info re
|
|
obsolete modems: dip switches & no stored profiles, "modem busy", "no
|
|
OK from AT" apt to be a serial port problem. 2 serial drivers active
|
|
problem.
|
|
v0.10 May 2000 Modem-Sharing mini-howto, digital modems, Newcom modem,
|
|
more re "no response to AT" and "can't find modem"
|
|
v0.09 Mar. 2000 +mwave, K->k, fax data, typos
|
|
v0.08 Jan. 2000 Vern's url, leased line modems, finding modem, Lucent
|
|
winmodem, multiport modem cards, clarity for 56K sect
|
|
v0.07 28 Nov. 1999 digital-modems for ISP, duplicate info removed from
|
|
setserial
|
|
v0.06 Nov. 1999 Revised contact info with Ted T.
|
|
v0.05 Oct. 1999 Book, PCI per Ted T., Exist DSL & Cable howtos, fixed
|
|
suse isdn link
|
|
v0.04 Aug. 1999 What is a fax or voice modem?
|
|
Vern's getty, dialin + , flash upgrades +, stop and stop typo,
|
|
MWave +, removed interrupt problem details (since latest in Serial-HOWTO)
|
|
callback +, V.90 + uses 64k channel, remove : include files per
|
|
m4, serial voltage link, min. voice mail url
|
|
v0.03 May 1999 BIOS messages; fixed formatting, Windows doesn't ?
|
|
update ESCD, sunsite ->metalab, PnP settings on card are volatile,
|
|
license rev., wvdial
|
|
v0.02 Mar. 1999 25-pin serial ports still on new ones, Some modems
|
|
report both speeds, New versions at, dumpregs (flag to pnpdump)
|
|
v0.01 Jan. 1999 link to mgetty site, added -g to setserial /dev/ttyS*,
|
|
shared serial interrupts in Linux 2.2, pnpdump doesn't show config
|
|
warn about Winmodems being mislabeled. Use some of 20 items Bill Staehle
|
|
emailed to me. Link to voice-mail site. PCMCIA-HOWTO. Added: Problems
|
|
Explained section. Internal. doesn't overrun. /proc/pci signature ??
|
|
v0.00 Dec. 1998: Extracted Modem-HOWTO from Serial-HOWTO, edited it &
|
|
added much more info on modems.
|
|
|
|
-->
|
|
<abstract>
|
|
Help with selecting, connecting, configuring, trouble-shooting, and
|
|
understanding analog modems for a PC.
|
|
</abstract>
|
|
<toc>
|
|
|
|
<sect> Introduction
|
|
|
|
<sect1> DSL, Cable, and ISDN Modems in other HOWTOs
|
|
<p> This HOWTO covers conventional analog modems for PCs on the PCI,
|
|
USB, LPC, and ISA buses. USB and ISDN coverage is weak. For other
|
|
types of modems see:
|
|
|
|
<itemize>
|
|
<item> DSL-HOWTO
|
|
<item> ADSL-Bandwidth-Management-HOWTO
|
|
<item> Cable-Modems-HOWTO (same as Cable Modem Providers HOWTO)
|
|
<item> SuSE ISDN Howto (not a LDP Howto) <url
|
|
url="http://brenner.chemietechnik.uni-dortmund.de/doc/sdb/en/html/isdn.html">
|
|
<item> <url url="http://public.swbell.net/ISDN/overview.html">
|
|
tutorial on ISDN
|
|
<item> ISDN docs in the kernel documentation subdirectory: "isdn".
|
|
<item> <url url="http://www.isdn4linux.de">
|
|
<item> <ref id="other_modems" name="Appendix D: Other Types of
|
|
Modems">
|
|
</itemize>
|
|
|
|
<sect1> Also not well covered: PCMCIA Modems, PPP
|
|
<p> For modems on the PCMCIA bus see the PCMCIA-HOWTO: PCMCIA serial
|
|
and modem devices. This HOWTO also doesn't cover the details of PPP
|
|
(used to connect to the Internet via a modem) or communication
|
|
programs. If you want to use a modem to connect to the Internet then
|
|
you need to use a program that will automatically set up PPP for you
|
|
(such as wvdial). More documentation on ppp should be found in
|
|
/usr/doc/ppp, /usr/share/doc/ppp or the like.
|
|
|
|
<sect1> Copyright, Disclaimer, Trademarks, & Credits
|
|
|
|
<sect2> Copyright
|
|
<p> Copyright (c) 1998-2005 by David S. Lawyer <url url="mailto:dave@lafn.org">
|
|
<!-- license.D begin -->
|
|
|
|
Please freely copy and distribute (sell or give away) this document
|
|
in any format. Send any corrections and comments to the document
|
|
maintainer. You may create a derivative work and distribute it
|
|
provided that you:
|
|
|
|
<enum>
|
|
<item> If it's not a translation: Email a copy of your derivative work
|
|
(in a format LDP accepts) to the author(s) and maintainer (could be
|
|
the same person). If you don't get a response then email the LDP
|
|
(Linux Documentation Project): submit@en.tldp.org.
|
|
<item>License the derivative work in the spirit of this license or use
|
|
GPL. Include a copyright notice and at least a pointer to the
|
|
license used.
|
|
<item>Give due credit to previous authors and major contributors.
|
|
</enum>
|
|
|
|
If you're considering making a derived work other than a
|
|
translation, it's requested that you discuss your plans with the
|
|
current maintainer.
|
|
|
|
<sect2>Disclaimer
|
|
<p> While I haven't intentionally tried to mislead you, there are
|
|
likely a number of errors in this document. Please let me know about
|
|
them. Since this is free documentation, it should be obvious that I
|
|
cannot be held legally responsible for any errors.
|
|
|
|
<sect2>Trademarks.
|
|
<p> Any brand names (starts with a capital letter such as MS Windows)
|
|
should be assumed to be a trademark). Such trademarks belong to their
|
|
respective owners. <!-- license.D end -->
|
|
|
|
|
|
<p>"Hayes" is a trademark of Microcomputer Products Inc. I use
|
|
"winmodem" to mean any modem which originally required MS-Windows and
|
|
not in the trademark sense. All other trademarks belong to their
|
|
respective owners.
|
|
|
|
<sect2> Credits
|
|
<p> The following is only a rough approximation of how this this
|
|
document was created in the year 2000: About 1/4 of the material here
|
|
was lifted directly from Serial-HOWTO v. 1.11 (1997) by Greg Hankins.
|
|
<url url="mailto:gregh@twoguys.org"> (with his permission). About
|
|
another 1/4 was taken from that Serial-HOWTO and revised. The
|
|
remaining 1/2 is newly created by the new author: David S. Lawyer
|
|
<tt><url url="mailto:dave@lafn.org"></tt>. Since 2000 much more has
|
|
been added by the current author so that little remains of the modem
|
|
coverage in the old Serial-HOWTO.
|
|
|
|
<sect1> Contacting the Author
|
|
<p> Since I don't follow the many different brands/models of modems
|
|
please don't email me with questions about them (or suggestions of
|
|
which one to buy). If you are interested in a certain model (to find
|
|
out if it works under Linux, etc.) see the huge list at <ref
|
|
id="web_sites" name="Web Sites">. Also, please don't ask me how to
|
|
configure a modem unless you've looked over this HOWTO and still can't
|
|
do it. I've no personal experience with software-based modems.
|
|
|
|
Please let me know of any errors in facts, opinions, logic, spelling,
|
|
grammar, clarity, links, etc. But first, if the date is over a month
|
|
or two old, check to see that you have the latest version. Please
|
|
send me any other info that you think belongs in this document.
|
|
|
|
<sect1> New Versions of this HOWTO <label id="new_vers">
|
|
<p> New versions of this Modem-HOWTO should come out every few months.
|
|
Your problem might be solved in the latest version. It will be
|
|
available to browse and/or download at LDP mirror sites. For a list
|
|
of such sites see: <url url="http://www.tldp.org/mirrors.html"> If you
|
|
only want to quickly compare the date of this the version v0.39, January 2007 with
|
|
the date of the latest version go to: <url
|
|
url="http://www.tldp.org/HOWTO/Modem-HOWTO.html">
|
|
|
|
<sect1> New in Recent Versions
|
|
<p> For a full revision history going back to the first version see
|
|
the source file (in linuxdoc format) at <url url=
|
|
"http://cvsview.tldp.org/index.cgi/LDP/howto/linuxdoc/Modem-HOWTO.sgml">.
|
|
|
|
<itemize>
|
|
<item>v0.39 Jan. 2007 gromitkc url (modem list) seems to be no longer
|
|
maintained. Redefined "antique modems" as all under 56k speed.
|
|
setpci can't set IRQs. devfs is obsolete. vgetty supports ITU v.253
|
|
<item>v0.38 May 2005: Eliminated section on Digital Modems in appendix
|
|
since it's already covered elsewhere. More on cable modems. ISDN
|
|
serial modems. Troubleshooting: Can't find winmodems if no driver.
|
|
<item>v0.37 Feb. 2005: For AMR, codec is on motherboard. Fixed a few typos.
|
|
Better clarity for Dial-In. "NO CARRIER" likely not displayed when
|
|
remote hangs up.
|
|
<item>v0.36 Feb. 2005 Rewrote "Quick Install" oriented towards PCI.
|
|
Some external RS-232 modems are winmodems. /dev/modem.
|
|
</itemize>
|
|
|
|
<sect1> What is a Modem ? <label id="what_is_modem">
|
|
<p> A modem (or analog modem) is a device that lets one send digital
|
|
signals over an ordinary telephone line not designed for digital
|
|
signals. If telephone lines were all digital then you wouldn't need a
|
|
modem. But sometimes, a substitute for an analog modem, connected to
|
|
a digital phone line, is imprecisely called a "digital modem". A
|
|
modem permits your computer to connect to and communicate with the
|
|
rest of the world. When you use a modem, you normally use a
|
|
communication program or web browser to utilize the modem and dial-out
|
|
on a telephone line. Advanced modem users can set things up so that
|
|
others may phone in to them and use the computer remotely. This is
|
|
called "dial-in".
|
|
|
|
Oversimplified, there are four basic types of analog modems for a PC:
|
|
external serial (RS-232), USB (= external USB), internal, and
|
|
built-in. The external serial and USB set on your desk outside the PC
|
|
while the other two types are not visible since they're inside the PC.
|
|
The external serial modem plugs into a connector on the back of the PC
|
|
known as a "serial port". The USB modem plugs into a USB cable. See
|
|
<ref id="usb_" name="USB Modems">. The internal modem is a card that
|
|
is inserted inside the computer. The built-in modem is a chip on the
|
|
motherboard used primarily in laptops. What is said in this HOWTO
|
|
regarding internal modems will generally apply also to built-in
|
|
modems. Internal modems are further subdivided into PCI, ISA, and
|
|
AMR, depending on whether they are designed for the PCI or ISA bus, or
|
|
for an AMR slot.
|
|
|
|
For an external vs internal comparison see <ref id="int_vs_ext"
|
|
name="External vs. Internal">. When you get an internal or built-in
|
|
modem, you also get a dedicated serial port (which can only be used
|
|
with the modem and not with anything else such as an external modem or
|
|
console terminal). In Linux, the common serial ports are named ttyS0,
|
|
ttyS1, etc. These ports usually corresponding respectively to COM1,
|
|
COM2, etc. in Dos/Windows). But in special cases, the names are
|
|
longer such as: ttySHCF0 is the 0th serial port for a type of winmodem
|
|
(HCF = Host Controlled Family). New types of serial ports just add
|
|
some more letters to ttyS.
|
|
|
|
See <ref id="basics_" name="Modem & Serial Port Basics"> for more
|
|
details on how modems and serial ports work. With a USB modem, the
|
|
driver simulates a serial port at for example /dev/ttySHCFUSB.
|
|
|
|
Modems usually include the ability to send Faxes (Fax Modems). See
|
|
<ref id="fax_" name="Fax"> for a list of fax software. "Voice" modems
|
|
can work like an automatic answering machine and handle voicemail.
|
|
See <ref id="voice_" name="Voicemail Software">.
|
|
|
|
The v.92 protocol can put the modem "on hold" when someone makes an
|
|
ordinary voice call to your telephone, provided that you have "call
|
|
waiting" from your telephone company. Thus you can get a phone call
|
|
while online. As of Jan. 2003 Linux doesn't seem to support it. If
|
|
this is the latest version of this HOWTO, let me know about any
|
|
Linux support for it. Some linmodem drivers may support it (but what
|
|
if you have a hardware modem that doesn't use any linmodem driver?).
|
|
|
|
<sect1> Does My Computer Contain an Internal Modem ?
|
|
<p> Internal modems usually have a pair of modular telephone jacks on
|
|
the back of the computer. They should be right next to each other and
|
|
each one looks like a jack on the interior wall of a building where a
|
|
telephone plugs in. One of the pair should be labeled "line" (or the
|
|
like) which is where you plug in the telephone line.
|
|
|
|
Network cards also have modular jacks, but they are seldom in pairs
|
|
and are slightly wider since they normally have 8 pins. Internal DSL
|
|
"modems" exist and also have modular telephone jacks, but I think they
|
|
are not very common (most DSL modems are external) as of 2002.
|
|
|
|
<sect1>Quick Install <label id="quick_install">
|
|
|
|
<sect2>Very Quick Install
|
|
<p> If you think your modem will work under Linux and needs no special
|
|
driver, then just physically install/connect it. Start you computer,
|
|
watch the boot-time messages for Linux to find the modem. Note it's
|
|
the serial port number such as ttyS2 (/dev/ttyS2). Connect a phone
|
|
line to it and dial out with say wvdial (after configuring wvdial).
|
|
If the above doesn't work, read on.
|
|
|
|
<sect2>Will my modem work under Linux?
|
|
<p>So called "winmodems" will work under Linux only if a driver for it
|
|
exists and gets installed. In this case it's called a "linmodem"
|
|
since it can be made to work under Linux. If it's made prior to 2004
|
|
see <url url="http://64.126.95.102:8080/gromitkc/winmodem.html"
|
|
name="old modem list"> and <ref id="soft_modem" name="Software-based
|
|
Modems (winmodems)">. There's no point of installing a modem that
|
|
will not work with Linux.
|
|
|
|
<sect2> External Serial Modem Install
|
|
<p> At one time (2002 ?) no external serial modem was a winmodem but
|
|
that's no longer the case. With a straight-thru or modem cable,
|
|
connect the modem to an unused serial port on the PC. Make sure you
|
|
know the name of the serial port: in most cases COM1 is ttyS0, COM2 is
|
|
ttyS1, etc. You may need to check the BIOS setup menu to determine
|
|
this. Plug in the power cord to provide power to the modem. See <ref
|
|
id="all_modems" name="All Modems"> for further instructions.
|
|
|
|
<sect2> Internal Modems (ISA, PCI and AMR)
|
|
<p>If the modem is both PnP and directly supported by the
|
|
serial driver (kernel 2.4 +) or by a winmodem driver that you've
|
|
installed, then there is no configuring for you to do since the driver
|
|
should configure it.
|
|
|
|
To physically install a modem card, remove the cover of the PC by
|
|
/removing some screws. Find a matching vacant slot for the card next
|
|
to the other adapter cards. Before inserting the card in the slot,
|
|
remove a small cover plate on the back of the PC so that the telephone
|
|
jacks on the card will be accessible from the rear of the PC. Then
|
|
carefully align the card with the slot and push the card all the way
|
|
down into the slot. Attach the card with a mounting screw (usually
|
|
3mm, .5mm pitch --don't use the wrong size).
|
|
|
|
You may watch the boot-time messages to see if your modem is detected.
|
|
Use "dmesg" to see them or shift-page-up to scroll the screen back
|
|
after they have flashed by.
|
|
|
|
<sect2> Internal Modems: Manual configuration
|
|
<p>Normally, you don't need to do this manual configuration since the
|
|
modem's serial port may be detected and assigned a port at boot-time.
|
|
For example: ttyS14 at I/O 0x6450 (IRQ = 10). Otherwise (or if there
|
|
is some special reason to change the configuration) then you need to
|
|
configure it yourself (or perhaps update your kernel to increases the
|
|
likelihood that the modem gets detected). If your modem has no ttyS
|
|
number assigned to it, it can't be used until it gets a ttyS number
|
|
(like ttyS10). It thus can't be detected by application programs such
|
|
as dialers or minicom. But it might be found by using say "lspci -v"
|
|
if it's on the PCI bus.
|
|
|
|
Finding a lost modem may not be easy and you may need to read a lot
|
|
more of this HOWTO. Once found, you need to use the "setserial"
|
|
program to manually assign it to an available ttyS? port of your
|
|
choice . For this you need to know both it's IO address (such as
|
|
0x6450) and its IRQ (such as 10). In the worst case, the modem has
|
|
been disabled by a failing to be detected and enabled by the BIOS (or
|
|
Linux) and doesn't have any IO address nor IRQ number. But you may
|
|
still be able to find it. Older modems could be disabled by a jumper
|
|
on the card or in rare cases by MS software.
|
|
|
|
You may have some choice of IRQs and IO addresses (including the case
|
|
where you are able to change what the BIOS has set). See <ref
|
|
id="choose_IRQ"name= "Choosing Serial IRQs"> and <ref
|
|
id="choose_address" name="Choosing Addresses">.
|
|
|
|
<sect3> Old ISA Modems
|
|
<p>ISA modems normally use ttyS0 - ttyS3. For old modems with jumpers
|
|
look at the modem manual or look for printing on the modem card that
|
|
tells you what the jumpers do. They have standard IO addresses
|
|
corresponding to the ttySx. For example you may find it feasible to
|
|
use /dev/ttyS2 at IO address 0x3e8 and IRQ 11.
|
|
|
|
If it has no jumpers then it's likely a Plug-and-Play modem which the
|
|
BIOS may configure when you power one your PC. Typing "pnpdump
|
|
--dumpregs" should find it. If you need to set or change them use
|
|
"isapnp". Use the "pnpdump" program to see what changes are possible.
|
|
|
|
<sect3> Both PCI and ISA: Use setserial to tell the serial driver
|
|
<p> You must find the file where "setserial" is run at boot-time and
|
|
add a line something like: "setserial /dev/ttyS2 irq 5 port 0x0b8".
|
|
For setserial v2.15 and later the results of running "setserial" on
|
|
the command line may (or may not) be saved to file named serial.conf
|
|
or autoserial.conf. It might be in say the /etc directory or in the
|
|
/var/lib/setserial directory (use "locate to find it). it runs each
|
|
time you boot. See <ref id="set_serial" name="What is Setserial"> for
|
|
more info. See the next subsection <ref id="all_modems" name="All
|
|
Modems"> for further instructions on quick installation.
|
|
|
|
<sect3> Use MS Windows to set the BIOS (A last resort method)
|
|
<p> If you are using the BIOS to configure you may attempt to use MS
|
|
Windows9x to "force" the BIOS to set a certain IRQ and/or IO. It can
|
|
set them into the PnP BIOS's flash memory where they will be used to
|
|
configure for Linux as well as Windows. See "Plug-and-Play-HOWTO and
|
|
search for "forced" (occurs in several places). For Windows3.x you
|
|
can do the same thing using the ICU under Windows 3.x. A few modems
|
|
have a way to disable PnP in the modem hardware using software (under
|
|
Windows) that came with the modem.
|
|
|
|
<sect2> All Modems <label id="all_modems">
|
|
<p> Plug the modem into a telephone line. Then configure a
|
|
dialing program. If you have an Internet Service Provider (ISP) you
|
|
might configure one of these : wvdial, pppconfig, gnome-ppp, modem
|
|
lights (Gnome) or kppp. They not only dial out but start PPP, which
|
|
you need to connect to the Internet. Otherwise, you might try
|
|
configuring the minicom dialer which isn't designed for connecting to
|
|
the Internet, but is good for testing. Whether it's minicom or a
|
|
dialer that starts PPP, set the serial port speed to a baud rate a few
|
|
times higher than the bit rate of your modem. See <ref
|
|
id="speed_table" name="Speed Table"> for more details on the "best"
|
|
speeds to use. Tell it the full name of your serial port such as
|
|
/dev/ttyS1 (or /dev/ttys/1).
|
|
|
|
Minicom is one way to set up and test your modem. Set hardware flow
|
|
control (RTS/CTS). With minicom you may check to see if your modem is
|
|
there (and ready to dial). Once you've set up minicom, type the
|
|
command: AT, hit enter and you should see an "OK" response which comes
|
|
directly from the modem. See <ref id="minicom_" name="Dialing Out
|
|
with Minicom">.
|
|
|
|
<sect1> dev/modem
|
|
<p> If your modem is on say /dev/ttyS2, you may want to link that to
|
|
/dev/modem. It's not really necessary to do this since you can write
|
|
down (or remember) say ttyS2 and tell it to programs that use the
|
|
modem. It may be simpler to just link it. To link it, type say
|
|
<tt>ln -s /dev/ttyS2 /dev/modem </tt>. Note "ttyS2" is just for
|
|
example. It might actually be ttyS14, etc. Or use Red Hat's
|
|
modemtool (or the like) to link it. But once you link it, be sure
|
|
that all programs that use the modem use /dev/modem and not
|
|
/dev/ttyS2, otherwise two programs may try to use the modem at the
|
|
same time without knowing they are doing this. System software was
|
|
written around 2000 to fix this problem but it may not be in recent
|
|
kernels (like 2.6).
|
|
|
|
<sect> Modems for a Linux PC
|
|
<sect1> Many Winmodems Will Not Work with Linux
|
|
<p>Unfortunately, some software modems (winmodems) will not work with
|
|
Linux due to lack of Linux drivers. Configuring the software modems
|
|
that can be made to work with Linux ranges from very easy
|
|
(automatically) to difficult, depending on both the modem, your skills,
|
|
and how easy it is to find info about your modem --info that is not
|
|
all in this HOWTO. If you buy a new one that you're not sure will
|
|
work under Linux, try to get an agreement that you can return it for a
|
|
refund if it doesn't work out.
|
|
|
|
Even if your modem works with Linux it can't be used until the serial
|
|
port it's located on is enabled and made known to the operating
|
|
system. For a detailed explanation of this (or if boot-time messages
|
|
don't show your modem's serial port) study this HOWTO or see
|
|
Plug-and-Play-HOWTO.
|
|
|
|
<sect1> External vs. Internal <label id="int_vs_ext">
|
|
<p> A modem for a PC may be either internal, external serial, or
|
|
external USB. The internal one is installed inside of your PC (you
|
|
must remove screws, etc. to install it). An external one just plugs
|
|
in to a cable: USB cable (USB modem) or to the serial port (RS-232
|
|
serial modem). As compared to external serial modems, the internal
|
|
modems are less expensive, are less likely to to suffer data loss due
|
|
to buffer overrun, and usually use less electricity. An internal
|
|
modem obviously doesn't use up any desk space.
|
|
|
|
External serial modems are usually easier to install and usually
|
|
has less configuration problems provided the serial port you'll
|
|
connect it to is configured OK. External USB modems are more likely
|
|
to be winmodems and are reportedly usually more difficult to deal with
|
|
than external serial modems. External modems have lights which may
|
|
give you a clue as to what is happening and aid in troubleshooting.
|
|
The fact that the serial port and modem can be physically separated
|
|
also aids in troubleshooting. External modems are easy to move to
|
|
another computer. If you need to turn the power off to reset your
|
|
modem (this is seldom necessary) then with an external you don't have
|
|
to power down the entire PC.
|
|
|
|
Unfortunately, most external serial modems have no switch to turn off
|
|
the power supply when not in use and thus are likely to consume a
|
|
little electricity even when turned off (unless you unplug the power
|
|
supply from the wall). Each watt they draw usually costs you over
|
|
$1/yr. Another possible disadvantage of an external is that you will
|
|
be forced to use an existing serial port which may not support a speed
|
|
of over 115,200 bps (although as of late 2000 most new internal modems
|
|
don't either --but some do). For details <ref id="high_speed"
|
|
name="Can't Set a High Enough Speed">
|
|
|
|
<sect1> Is a Driver Needed ?
|
|
<p> Any modem, of course, needs the serial driver that comes with Linux
|
|
(either built into the kernel or as a module). For PCI, this driver
|
|
should also detect the modem but it's not really a modem driver since
|
|
it just detects which serial port the modem is on.
|
|
|
|
But what about modem drivers? Any software modem (winmodem, linmodem)
|
|
must have a modem driver (if it exists for Linux). Hardware modems
|
|
don't really need any modem driver unless you want to use special
|
|
features such as voice and "modem on hold".
|
|
|
|
Software modems require software to run them and obviously do need a
|
|
driver. The drivers for MS Windows are *.exe programs which will not
|
|
run under Linux. So you must use a Linux driver (if it exists). See
|
|
<ref id="soft_modem" name="Software-based Modems (winmodems,
|
|
linmodems)">
|
|
|
|
<sect1> External Modems
|
|
<sect2>Do they all work under Linux?
|
|
<p>At one time (2002 ?) all external modems would work under Linux.
|
|
But then came the controllerless external modem which wouldn't. If
|
|
the box says it requires Windows with no mention of Linux it could
|
|
mean just that. Could it be that Windows software is provided for
|
|
"modem on hold" and for use as an answering machine, etc., but that
|
|
otherwise it will work under Linux? Linux may not support these
|
|
features very well if at all. If this is a recent version of
|
|
Modem-HOWTO, let me know of your experience with this.
|
|
|
|
<sect2>PnP External Modems
|
|
<p> Many external modems are labeled "Plug and Play" (PnP). If they
|
|
are hardware modems, they should all work as non-PnP modems. While
|
|
the serial port itself may need to be configured (IRQ number and IO
|
|
address) unless the default configuration is OK, an external modem
|
|
uses no such IRQ/IO configuration. You just plug the modem into the
|
|
serial port.
|
|
|
|
The PnP modem has a special PnP identification built into it that
|
|
can be read (thru the serial port) by a PnP operating system. Such an
|
|
operating system would then know that you have a modem on a certain
|
|
port and would also know the id number. If it's a controllerless
|
|
modem, it could try to locate a driver for it. It could also tell
|
|
application programs what port your modem is on (such as /dev/ttyS2 or
|
|
COM3). But Linux may not be able to do this. Thus you may need to
|
|
configure your application program manually by giving it the ttyS
|
|
number (such as /dev/ttyS2). Some programs like wvdial can probe for
|
|
a modem on various ports.
|
|
|
|
<sect2> Cabling & Installation
|
|
<p> Connecting an external modem is simple compared to connecting
|
|
most other devices to a serial port that require various types of
|
|
"null modem" cables (which will not work for modems). Modems use
|
|
a straight through cable, with no pins crossed over. Most computer
|
|
stores should have one. Make sure you get the correct gender and
|
|
number of pins. Hook up your modem to one of your serial ports. If
|
|
you are willing to accept the default IRQ and IO address of the port
|
|
you connect it to, then you are ready to start your communication
|
|
program and configure the modem itself.
|
|
|
|
<sect2> What the Lights (LED's) Mean (for some external modems)
|
|
<p>
|
|
<itemize>
|
|
<item> TM Test Modem
|
|
<item> AA Auto Answer (If on, your modem will answer an incoming call)
|
|
<item> RD Receive Data line = RxD
|
|
<item> SD Send Data line = TxD
|
|
<item> TR data Terminal Ready = DTR (set by your PC)
|
|
<item> RI Ring Indicator (If on, someone is "ringing" your modem)
|
|
<item> OH Off Hook (If off, your modem has hung up the phone line)
|
|
<item> MR Modem Ready = DSR ??
|
|
<item> EC Error Correction
|
|
<item> DC Data Compression
|
|
<item> HS High Speed (for this modem)
|
|
</itemize>
|
|
|
|
<sect1> Internal Modems
|
|
<p> An internal modem is installed in a PC by taking off the cover of
|
|
the PC and inserting the modem card into a vacant slot on the
|
|
motherboard. There are modems for PCI slots, other modems for the
|
|
older ISA slots, and ARM software "modems" for the new small AMR slot.
|
|
Only some newer PCs will have ARM slots. While external modems plug
|
|
into the serial port (via a short cable) the internal modems have the
|
|
serial port built into the modem. In other words, the modem card is
|
|
both a serial port and a modem.
|
|
|
|
Setting the IO address and IRQ for a serial port was formerly done by
|
|
jumpers on the card. These are little black rectangular "cubes" about
|
|
5x4x2 mm in size which push in over pins on the card. Plug-and-Play
|
|
modems (actually the serial port part of the modems) don't use jumpers
|
|
for setting these but instead are configured by sending configuration
|
|
commands to them over the bus inside the computer. Such configuration
|
|
commands can be sent by a PnP BIOS, by the isapnp program (for the ISA
|
|
bus only), by setpci (PCI bus: can't set IRQs), or by newer serial
|
|
of how to configure the ones that don't get io-irq configured by the
|
|
serial driver.
|
|
|
|
<enum>
|
|
<item>ISA bus: Use "isapnp" which may be run automatically at
|
|
every boot-time
|
|
<item> Let a PnP BIOS do it, and then maybe tell setserial the IO and
|
|
IRQ
|
|
<item>PCI bus: Use lspci -vv to look at it and setpci to configure the
|
|
IO only (can't set the IRQ).
|
|
</enum>
|
|
|
|
See <ref id="quick_install" name="Quick Install"> for more details,
|
|
especially for the PCI bus.
|
|
|
|
<sect1> Software-based Modems (winmodems, linmodems)
|
|
<label id="soft_modem">
|
|
<sect2> Introduction to software modems (winmodems)
|
|
<p> Software modems turn over some (or even almost all) of the work of
|
|
the modem to the main processor (CPU) chip of your computer (such as a
|
|
Pentium chip). This requires special software (a modem driver) to do
|
|
the job. Until late 1999, such software was released only for MS
|
|
Windows and wouldn't work with Linux. Even worse was that the maker
|
|
of the modem kept the interface to the modem secret so that no one
|
|
could write a Linux driver for it (even though a few volunteers were
|
|
willing to write Linux drivers).
|
|
|
|
But things have improved some since then so that today (late 2001)
|
|
many such modems do have a linux driver. There is no standard
|
|
interface so that different brands/models of software-modems need
|
|
different drivers (unless the different brands/models happen to use
|
|
the same chipset internally). But some drivers may not work perfectly
|
|
nor have all the features that a MS Windows driver has.
|
|
|
|
Another name for a software modem (used by MS) is "driver-based
|
|
modem". The conventional hardware-based modem (that works with Linux)
|
|
doesn't need a modem driver (but does use the Linux serial driver)
|
|
After about mid-1998 most new internal modems were software modems.
|
|
|
|
Software modems fall into 2 categories: linmodems and winmodems.
|
|
Winmodems will only work under MS Windows. Linmodems will work under
|
|
Linux. They formerly were mostly winmodems so some also call them
|
|
"winmodems". The term "Winmodem" is also a trademark for a certain
|
|
model of "winmodem" but that's not the meaning of it in this document.
|
|
|
|
<sect2> Linmodems
|
|
<p> In late 1999, two software-based modems appeared that could work
|
|
under Linux and were thus called "linmodems". Lucent Technologies
|
|
(LT) unofficially released a Linux binary-only code to support most of
|
|
its PCI modems. PC-TEL (includes "Zoltrix") introduced a new
|
|
software-based modem for Linux. After that, interest increased for
|
|
getting winmodems to work under linux. There is a GPL'ed driver for
|
|
Intel's (Modem Silicon Operations) MD563x HaM chipset (nee Ambient
|
|
division of Cirrus Logic). As of mid-2001 there are also drivers for:
|
|
Conexant HSF and HCF, Motorola SM56 (support terminated), ESS (ISA
|
|
only), and IBM's Mwave for Thinkpads 600+. See <url
|
|
url="http://linmodems.org">.
|
|
|
|
What percent of software modems now (2001) work under Linux? Well,
|
|
there's a number of modem chips not supported: Lucent/Agere ARM
|
|
(Scorpio), 3COM/US Robotics, some SmartLink (3 different chipsets),
|
|
Ambient HSP, and possibly others. So it seems that over half the
|
|
software modem chips were supported as of late 2001. As of 2005 it
|
|
seems that the situation has gotten worse. Why? Well, Linux on the
|
|
Desktop didn't grow as fast as expected and many PC users went for
|
|
higher speed cable modems and DSL.
|
|
|
|
Another reason is that many of the drivers were written years ago and
|
|
will only work for older versions of the Linux kernels. The driver
|
|
code is secret and the companies don't want to update drivers for
|
|
hardware they are no longer selling.
|
|
|
|
Be warned in advance that determining if your modem is a linmodem may
|
|
not be very easy. You may need to first find out what chipset you
|
|
have and who makes it. Just knowing the brand and model number of
|
|
your modem may not be sufficient. One method is to download the
|
|
scanModem tool from <url url="http://linmodems.org"> but the results
|
|
may be hard to decipher and you may need to ask for help from the
|
|
linmodems mailing list. Another way to find this out using say "lspci
|
|
-v" and then looking up the chip maker using the long modem number.
|
|
This requires checking a database or searching the Internet. Still
|
|
another way is to look at the fine print on the chips on the modem
|
|
card. All this is not always simple. It could happen that you will
|
|
put a lot of effort into this only to get the bad news that your modem
|
|
isn't supported. But even if it is supported, support may only be for
|
|
an old version of the kernel. See Linmodem-HOWTO for more details.
|
|
|
|
<sect2> Linmodem sites and documentation
|
|
<p>
|
|
<itemize>
|
|
<item>Linmodem-HOWTO
|
|
<item>Winmodems-and-Linux-HOWTO (not as well written as Linmodem-HOWTO)
|
|
<item> <url url="http://linmodems.org"> is a project to turn winmodems
|
|
into linmodems. Has a mailing list.
|
|
<item>Conexant+Rockwell-modem-HOWTO
|
|
<item><url url="http://64.126.95.102:8080/gromitkc/winmodem.html"
|
|
name="old modem list"> Has links to linmodem info, but not
|
|
maintained after 2003.
|
|
<item> PCTel-HSP-MicroModem-Configuration-mini-HOWTO
|
|
</itemize>
|
|
|
|
<sect2> Software-based modem types
|
|
<p> There are two basic types of software modems. In one type the
|
|
software does almost all of the work. The other is where the software
|
|
only does the "control" operations (which is everything except
|
|
processing the digital waveshapes --to be explained later). Since the
|
|
hardware doesn't do the control it's called a "controllerless" modem.
|
|
The first type is an all-software modem (sometimes just called a
|
|
software modem).
|
|
|
|
For both of these types there must be analog hardware in the modem (or
|
|
on the motherboard) to generate an electrical waveshape to send out
|
|
the phone line. It's generated from a digital signal (which is sort
|
|
of a "digital waveshape"). It's something like the digital
|
|
electronics creates a lot of discrete points on graph paper and then
|
|
the modem draws a smooth voltage curve thru them. There must also be
|
|
hardware to convert the incoming waveshape to digital. This is just
|
|
analog-to-digital conversion (and conversely). It's done by a codec
|
|
(coder-decoder).
|
|
|
|
The incoming digital waveshape must be converted to a data byte
|
|
stream. This is part of the demodulation process. Recall that these
|
|
data bytes have likely been compressed, so they are not at all like
|
|
the original message. Turning data bytes into a digital waveshape is
|
|
part of the modulation process. Even after demodulation is done, the
|
|
modem can't just send the resulting incoming data byte stream to the
|
|
serial port input buffers, but must first do decompression, error
|
|
correction, and convert from serial to the parallel bus of the
|
|
computer. But the modem may get the CPU to do the actual work. It's
|
|
the reverse sequence for an outgoing data byte stream.
|
|
|
|
The difference between the two types of software-based modems is where
|
|
the digital modulation takes place. In the all-software modem this
|
|
modulation is done in the CPU and it's called a Host Signal Processor
|
|
(HSP). In the controllerless modem it's done in the modem but all
|
|
other digital work is done by the CPU. This other digital work
|
|
consists of dealing with AT-commands, data compression, error
|
|
correction, and simulating a serial port. In the all-software modem,
|
|
there are still two items handled by hardware: the A/D conversion of
|
|
waveshapes by the codec and echo cancellation.
|
|
|
|
<sect2> Is this modem a software modem?
|
|
<p> How do you determine if an internal modem is a software modem?
|
|
First see if the name, description of it, or even the name of the MS
|
|
Windows driver for it indicates it's a software modem: HSP (Host
|
|
Signal Processor) , HCF (Host Controlled Family), HSF (Host Signal
|
|
Family), controllerless, host-controlled, host-based, and soft-...
|
|
modem. If it's one of these modem it will only work for the cases
|
|
where a Linux driver is available. Since software modems cost less, a
|
|
low price is a clue that it's a software modem.
|
|
|
|
If you don't know the model of the modem and you also have Windows on
|
|
your Linux PC, click on the "Modem" icon in the "Control Panel". Then
|
|
see the <url url="http://64.126.95.102:8080/gromitkc/winmodem.html"
|
|
name="modem list"> (not maintained after 2003). If the above doesn't
|
|
work (or isn't feasible), you can look at the package the modem came
|
|
in (or a manual). Read the section on the package that says
|
|
something like "Minimum System Requirements" or just "System
|
|
Requirements".
|
|
|
|
A hardware modem will work fine on old CPUs (such as the 386 or
|
|
better). So if it requires a modern CPU (such as a Pentium or other
|
|
"high speed" CPU of say over 150 MHz) this is a clue that it's a
|
|
all-software modem. If it only requires a 486 CPU (or better) then
|
|
it's likely a host-controlled software modem. Saying that it only
|
|
works with Windows is also bad news. However, even in this case there
|
|
may be a Linux driver for it or it could be a mistake in labeling.
|
|
|
|
Otherwise, it may be a hardware modem if it fails to state explicitly
|
|
that you must have Windows. By saying it's "designed for Windows" it
|
|
may only mean that it fully supports Microsoft's plug-and-play which
|
|
is OK since Linux uses the same plug-and-play specs (but it's harder
|
|
to configure under Linux). Being "designed for Windows" thus gives no
|
|
clue as to whether or not it will work under Linux. You might check
|
|
the Website of the manufacturer or inquire via email. Some
|
|
manufacturers are specifically stating that certain models work under
|
|
Linux. Sometimes they are linmodems that require you to obtain and
|
|
install a certain linmodem driver.
|
|
|
|
<sect2> Should I get a software modem?
|
|
<p> Only if you know there is a Linux driver for it that works OK.
|
|
But there may be a problem if the driver isn't being maintained and as
|
|
a result doesn't work with future versions of the kernel. Also, the
|
|
driver may not have full functionality. Besides the problems of
|
|
getting a satisfactory driver, what are the pros and cons of software
|
|
modems? Since the software modem uses the CPU to do some (or all) of
|
|
its work, the software modem requires less on-board electronics on the
|
|
modem card and thus costs less. At the same time, the CPU work load
|
|
is increased by the modem which may result in slower operation.
|
|
|
|
The percentage of loading of the CPU by the modem depends on both what
|
|
CPU you have and whether or not it's an all-software modem. For a
|
|
modern CPU and a modem that only uses the CPU as a controller, there's
|
|
little loss of performance. Even if it's an all-software modem, you
|
|
will not suffer a loss of performance if there are no other
|
|
CPU-intensive tasks are running at the same time. Of course, when
|
|
you're not using the software modem there is no degradation in
|
|
performance at all.
|
|
|
|
Is the modem cost savings worth it? In many cases yes, especially if
|
|
you don't use the modem much and/or are not running any other CPU
|
|
intensive tasks when the modem is in use. The savings in modem cost
|
|
could be used for a better CPU which would speed things up a little.
|
|
But the on-board electronics of a hardware modem can do the job more
|
|
efficiently than a general purpose CPU (except that it's not efficient
|
|
at all when it's not in use). So if you use the modem a lot it's
|
|
probably better to avoid all-software modems.
|
|
|
|
<sect1> PCI Modems <label id="PCIm">
|
|
<p> A PCI modem card is one which inserts into a PCI-bus slot on the
|
|
motherboard of a PC. While many PCI winmodems will not work under
|
|
Linux (no driver available) other PCI modems will work under Linux.
|
|
The Linux serial driver has been modified to support certain PCI
|
|
hardware modem cards (but not winmodems/linmodems). If it's a
|
|
linmodem, it will work only if you install a certain linmodem driver.
|
|
If the Linux serial driver supports your hardware modem then the
|
|
driver will set up the PnP configuration for you. See <ref
|
|
id="PCI_ser_conf" name="PCI Bus Support Underway">. If no special
|
|
support for your PCI hardware modem is in the Linux serial driver it
|
|
may still work OK but you have to do some work to configure it.
|
|
|
|
<sect1>AMR Modems
|
|
<p>These are mainly used in laptops. They are all winmodems that
|
|
insert into a special AMR (Audio Modem Riser) slot on the motherboard.
|
|
Audio cards or combined audio-modem cards are sometimes used in this
|
|
slot. The slot's main use is for HSF type modems where the CPU does
|
|
almost all of the work. This results in a small "modem" card and thus
|
|
a short AMR slot. The motherboard has a codec which takes digital
|
|
output from the CPU and generates analog voltage waves at the ARM
|
|
slot (and conversely). Thus the "modem" that plugs into the slot has
|
|
little to do except to interface the telephone line with the codec.
|
|
Linux supports at least one AMR modem. lspci -v should display it.
|
|
|
|
<sect1> USB Modems <label id="usb_">
|
|
<p>USB = Universal Serial Bus. Most USB modems are winmodems, so many
|
|
will not work with Linux. Linux has support for modems that conform
|
|
to the USB Communication Device Class Abstract Control Model (= USB
|
|
CDC ACM). There's a module for ACM named acm.o. See the /usb/acm.txt
|
|
document in the kernel documentation directory
|
|
(/usr/share/doc/kernel-doc-2.6.x in Debian, perhaps /usr/doc/kernel...
|
|
in some distributions). The ACM "serial port" for the first (0th)
|
|
such modem is: /dev/usb/acm/0 or possibly /dev/usb/ttyACM0. This
|
|
should be the case regardless of whether or not you use the new
|
|
"device file system". It's not really a serial port, but the driver
|
|
makes it look like a serial port to software which uses the modem.
|
|
|
|
Since the bandwidth on the USB is high it's possible to send a lot
|
|
more that just data to a USB modem. This means that it's feasible to
|
|
create a USB winmodem where the driver does most of the modem's work
|
|
on the CPU and sends the results to the modem. So beware of USB
|
|
winmodems (unless they have Linux support).
|
|
|
|
<sect1> Which Internal Modems might not work with Linux <label id="m_to_avoid">
|
|
<p>
|
|
<itemize>
|
|
<item> <ref id="soft_modem" name="Software-based Modems (winmodems,
|
|
linmodems)"> Only about half have a Linux driver available.
|
|
<item> <ref id="dsp_" name="MWave and DSP Modems"> might work, but only if
|
|
you first start Windows/Dos each time you power on your PC.
|
|
<item> Modems with <ref id="rpi_" name="Old Rockwell (RPI) Drivers">
|
|
work but with reduced performance.
|
|
</itemize>
|
|
|
|
<sect2> MWave and some DSP Modems <label id="dsp_">
|
|
<p> Note that there's now a Linux driver for the ACP (Mwave) modem
|
|
used in IBM Thinkpads 600+. See the mini-HOWTO: ACP-Modem.
|
|
|
|
While hardware modems used use DSPs (Digital Signal Processors) some
|
|
of these DSPs are programmed by a driver which must be downloaded from
|
|
the hard disk to the DSPs memory just before using the modem.
|
|
Unfortunately, such downloading is normally done by Dos/Windows
|
|
programs (which doesn't work for Linux). But there has been
|
|
substantial success in getting some of these modems to work with
|
|
Linux. For example, there is a Linux driver available to run a Lucent
|
|
(DSP) modem.
|
|
|
|
Ordinary modems that work fine with Linux (without needing a driver
|
|
for the modem) often have a DSP too (and may mention this on the
|
|
packaging), but the program that runs the DSP is stored inside the
|
|
modem. These work fine under Linux. An example of a DSP modem that
|
|
has problems working under Linux is the old IBM's Aptiva MWAVE.
|
|
|
|
One way to get some DSP modems to work with Linux is to boot from DOS
|
|
(if you have it on your Linux PC). You first install the driver under
|
|
DOS (using DOS and not Window drivers). Then start Dos/Windows and
|
|
start the driver for the modem so as to program the DSP. Then without
|
|
turning off the computer, start Linux.
|
|
|
|
One may write a "batch" file (actually a script) to do this. Here is
|
|
an example but you must modify it to suit your situation.
|
|
<tscreen><verb>
|
|
rem mwave is a batch file supplied by the modem maker
|
|
call c:\mww\dll\mwave start
|
|
rem loadlin.exe is a DOS program that will boot Linux from DOS (See
|
|
rem Config-HOWTO).
|
|
c:\linux\loadlin f:\vmlinuz root=/dev/hda3 ro
|
|
</verb></tscreen>
|
|
|
|
One may create an icon for the Window's desktop which points to such a
|
|
batch file and set the icon properties to "Run in MSDOS Mode". Then
|
|
by clicking on this icon one sets up the modem and goes to Linux.
|
|
Another possible way to boot Linux from DOS is to press CTRL-ALT-DEL
|
|
and tell it to reboot (assuming that you have set things up so that
|
|
you can boot directly into Linux). The modem remains on the same com
|
|
port (same IO address) that it used under DOS.
|
|
|
|
The Newcom ifx modem needs a small kernel patch to work correctly
|
|
since its simulation of a serial port is non-standard. The patch and
|
|
other info for using this modem with Linux is at <url
|
|
url="http://quinine.pharmacy.ohio-state.edu/~ejolson/linux/newcom.html">.
|
|
|
|
<sect2> Old Rockwell (RPI) Drivers <label id="rpi_">
|
|
<p> Some older Rockwell chips need Rockwell RPI (Rockwell
|
|
Protocol Interface) drivers for compression and error correction.
|
|
They can still be used with Linux even though the driver software
|
|
works only under MS Windows. This is because the MS Windows software
|
|
(which you don't have) does only compression and error correction. If
|
|
you are willing to operate the modem without compression and error
|
|
correction then it's feasible to use it with Linux. To do this you
|
|
will need to disable RPI by sending the modem (via the initialization
|
|
string) a "RPI disable" command each time you power on your modem. On
|
|
my old modem this command was +H0. Not having data compression
|
|
available makes it slower to get webpages but is just as fast when
|
|
downloading files that are already compressed.
|
|
|
|
<sect> Modem Pools, RAS
|
|
<sect1> Introduction
|
|
<p> A "modem pool" is a group of modems which are normally used to
|
|
receive incoming calls. Today, many such modems may be on a single
|
|
card. ISPs once used modem pools so that customers could call in to
|
|
the ISP, but today, the RAS (Remote Access Server) has replaced modem
|
|
pools for ISPs. RAS works for incoming calls at near 56k (V.90 and
|
|
V.92) and uses what amounts to "digital modems". Modem pools use the
|
|
older analog modems and can only go to 33.6 kbps for incoming calls.
|
|
Thus analog modem pools are more likely to be used by small
|
|
organizations that don't want to use the more expensive RAS. A RAS is
|
|
in a sense a digital modem pool.
|
|
|
|
An analog modem pool may be provided by an analog multi-port modem card.
|
|
In olden days it was many modems in an external chassis (something
|
|
like an external modem). Such modems could be analog modems similar to
|
|
modems used for home/office PCs (can't send above 33.6k even if they
|
|
are labeled "56k modems"). A RAS will use "digital modems" which
|
|
can send at nearly 56k (if you have a good line). The "digital
|
|
modems" require a digital connection to the telephone line and don't
|
|
use any serial ports at all. All of these modem pools (or RAS's) will
|
|
require that you install special drivers for them.
|
|
|
|
<sect1> Analog Modem Pools, Multi-modem Cards
|
|
|
|
<p> A "multimodem card" is short for "multiport modem card". Some put
|
|
a hyphen after "multi": multi-modem or multi-port. An analog modem
|
|
pool is just many analog modems (the common home/office modem)
|
|
provided either on an internal plug-in card or in an external chassis.
|
|
Each modem comes with a built-in serial port. There is usually a
|
|
system of sharing interrupts or of handling interrupts by their own
|
|
electronics, thus removing much of this burden from the CPU. Note
|
|
that these modems are not "digital modems" and will thus not be able
|
|
to use 56k for people who dial-in.
|
|
|
|
Here is a list of some companies that make analog multiport modem
|
|
cards which plug into slots in a PC. 8 modems/card is common. The
|
|
cards listed claim to work with Linux and the websites should point
|
|
you to a driver for them.
|
|
|
|
Multi-modem Cards (analog, not digital):
|
|
<itemize>
|
|
<item> Equinox SST Multi-modem. PCI, 56k, 4 or 8 ports<newline>
|
|
<url url="http://www.equinox.com/product/multi-modem.htm">
|
|
|
|
<item> MultiModemISI by Multi-Tech Systems. 56k or 33.6k, PCI,
|
|
4 or 8 ports. ISDN/56k hybrids.<newline>
|
|
<url url="http://www.multitech.com/PRODUCTS/MultiModemISI/">
|
|
|
|
<item> PCI-RAS cards by Perle. 56k, 4 or 8 ports.<newline>
|
|
<url
|
|
url=" http://www.perle.com/products/default.asp?cat=C007">
|
|
|
|
<item> RocketModem by Comtrol. ISA 33.6k, 4 or 8 port.<newline>
|
|
<url url="http://www.comtrol.com/sales/specs/rm.htm">
|
|
|
|
<item> RocketModem II by Comtrol. PCI 56k, 4 or 6 port<newline>
|
|
<url url="http://www.comtrol.com/sales/specs/rmii.htm">
|
|
|
|
<item> RockForce. 56k, 2 or 4 port Two port V.92/V.44<newline>
|
|
<url url="http://www.mainpine.com/">
|
|
#RockForce+ Two port V.90 (www.mainpine.com/prodrockplus.html)
|
|
#RockForceDUO Two port V.92/V.44 (www.mainpine.com/prodduo.html)
|
|
#RockForceQUATRO Four port V.92/V.44 (www.mainpine.com/prodquatro.html)
|
|
#RockForceDUO+ Two port V.92/V.44/V.34 SuperG3 Fax =
|
|
#(www.mainpine.com/prodduoplus.html)
|
|
#RockForceQUATRO+ Four port V.92/V.44/V.34 SuperG3 Fax =
|
|
#(www.mainpine.com/prodquatroplus.html)
|
|
#
|
|
<item> Multi-modem communication adapters by Digi.
|
|
<url
|
|
url="http:/www.dgii.com/solutions/mmcommadapters/index.html">
|
|
</itemize>
|
|
|
|
<sect1> Digital Modems, RAS <label id="digital_modem">
|
|
<p> "Digital modems" are much different than the analog modems that
|
|
most people use in their PCs. But they can communicate with analog
|
|
modems at the other end of the phone line. ISP's use "digital modems"
|
|
to send out data at almost 56k bps to 56k modems in homes and offices.
|
|
The "digital modem" requires a digital connection to the telephone
|
|
line (such as T1, EI, ISDN PRI, etc.). Except for some serial ISDN
|
|
"modems", they don't use serial ports for the interface to the
|
|
computer. Instead, they interface directly to a computer bus via a
|
|
special card(s) (which may also contain the "digital modems"). They
|
|
are often a component of "remote access servers" (RASs) or "digital
|
|
modem pools"
|
|
|
|
You may already know that each time you make a telephone call from an
|
|
analog device (a telephone or a modem) it gets converted by the
|
|
telephone company to a digital signal. Then it's transmitted to near
|
|
its destination as a digital signal and finally converted back into an
|
|
analog signal just before it reaches it's destination. But it's also
|
|
possible to receive this digital signal directly from the telephone
|
|
company if you have what is called a "T1" line, etc.
|
|
|
|
The cables from the phone company that carry digital signals have been
|
|
designed for high bandwidth so that the same cable carries many
|
|
telephone calls. It's done by what's called "time-division
|
|
multiplexing". A single phone call in a cable is carried on two
|
|
different channels, one for each direction. So the RAS must connect
|
|
each such channel-pair to the appropriate "digital modem" that
|
|
services that phone call. Such tasks are done by what is sometimes
|
|
called a "... concentrator".
|
|
|
|
Now the digital signal received by a "digital modem" may really
|
|
represent an analog signal which has been sent to it by an analog
|
|
modem. This is because when you send an analog signal (including
|
|
ordinary voice) to the telephone company, it gets converted into
|
|
digital by the phone company. One way for the digital modem to deal
|
|
with this digital signal would be to convert it to an analog signal
|
|
and then put that thru an analog modem to get the digital data sent by
|
|
the analog modem. But why do all this work? Since the signal is
|
|
already in digital form, why not process it digitally? That's how
|
|
it's done. The digital signal is processed and converted to another
|
|
digital stream of bytes which represents data bytes sent by the analog
|
|
modem. A "digital signal processor" (DSP) is commonly used for this
|
|
task. A CPU could also handle it but it would be heavily loaded.
|
|
|
|
Likewise, a "digital modem" must handle sending digital signals in the
|
|
opposite direction from a RAS to a digital telephone line. Thus it
|
|
only makes digital-to-digital conversions and doesn't deal in analog
|
|
at all. It thus is not really a modem at all since it doesn't
|
|
modulate any analog carrier. So the name "digital modem" is a
|
|
misnomer but it does do the job formerly done by modems. Thus some
|
|
"digital modems" call themselves "digital signal processors", or
|
|
"remote access servers", etc. and may not even mention the word
|
|
"modem".
|
|
|
|
Such a RAS system may be a stand-alone proprietary server, a chassis
|
|
containing digital modems that connects to a PC via a special
|
|
interface card, or just a card itself. Digi calls one such card a
|
|
"remote access server concentrator adapter". One incomplete
|
|
description of what is needed to become an ISP is: See <url
|
|
url="/http://www.cyclades.com/solutions/techtalk/techtalk0l.php"
|
|
name="What do I need to be an ISP?">. Cyclades promotes their own
|
|
products here so please do comparison shopping before buying anything.
|
|
|
|
<sect> Serial Port and Modem Basics <label id="basics_">
|
|
<!-- basics.D begin <sect> Serial Port and Modem Basics
|
|
or <sect> Serial Port Basics In SS and MM -->
|
|
<!-- Change log:
|
|
Nov. '99: 2 serial drivers concurrently NG
|
|
Sept. '00: data flow diagram
|
|
Dec. '00 flow control +
|
|
July '01 done -> down
|
|
Feb. '02 4k buffer -> 8k
|
|
Feb. '03: UARTs with auto flow control. Rewrite of Flow Control.
|
|
Mar. '03: Flip buffer (the 4th buffer)
|
|
Apr. '03: flow control clarity, RTS -> CTS re modems
|
|
Nov. '04: Better clarity re Data Flow, Winmodem support
|
|
-->
|
|
<!-- ifdef MODEM_ -->
|
|
<p> You don't have to understand the basics to use and install a
|
|
modem. But understanding it may help to determine what is wrong if
|
|
you run into problems. After reading this section, if you want to
|
|
understand it even better you may want to see <ref
|
|
id="how_modems_work" name="How Modems Work"> in this document (not yet
|
|
complete). More details on the serial port (including much of this
|
|
section) will be found in Serial-HOWTO.
|
|
|
|
<sect1> Modem Converts Digital to Analog (and conversely)
|
|
<p> Most all telephone main lines are digital already but the lines
|
|
leading to your house (or business) are usually analog which means
|
|
that they were designed to transmit a voltage wave which is an exact
|
|
replica of the sound wave coming out of your mouth. Such a voltage
|
|
wave is called "analog". If viewed on an oscilloscope it looks like a
|
|
sine wave of varying frequency and amplitude. A digital signal is
|
|
like a square wave. For example 3 v (volts) might be a 1-bit and 0 v
|
|
could be a 0-bit. For most serial ports (used by external modems) +12
|
|
v is a 0-bit and -12 v is a 1-bit (some are + or - 5 v).
|
|
|
|
To send data from your computer over the phone line, the modem takes
|
|
the digital signal from your computer and converts it to "analog". It
|
|
does this by both creating an analog sine wave and then "MODulating"
|
|
it. Since the result still represents digital data, it could also be
|
|
called a digital signal instead of analog. But it looks something
|
|
like an analog signal and almost everyone calls it analog. At the
|
|
other end of the phone line another modem "DEModulates" this signal
|
|
and the pure digital signal is recovered. Put together the "mod" and
|
|
"dem" parts of the two words above and you get "modem" (if you drop
|
|
one of the two d's). A "modem" is thus a MODulator-DEModulator. Just
|
|
what modulation is may be found in the section <ref id="modulate_"
|
|
name="Modulation Details">.
|
|
<!-- ifdef MODEM end -->
|
|
|
|
|
|
|
|
<sect1> What is a Serial Port ?
|
|
<sect2> Intro to Serial
|
|
<p> The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.
|
|
<!-- ifdef MODEM_ -->
|
|
Since modems have a serial port between them and the computer,
|
|
it's necessary to understand the serial port as well as the modem.
|
|
<!-- ifdef MODEM end -->
|
|
|
|
Most PC's have one or two serial ports. Each has a 9-pin connector
|
|
(sometimes 25-pin) on the back of the computer. Computer programs can
|
|
send data (bytes) to the transmit pin (output) and receive bytes from
|
|
the receive pin (input). The other pins are for control purposes and
|
|
ground.
|
|
|
|
The serial port is much more than just a connector. It converts the
|
|
data from parallel to serial and changes the electrical representation
|
|
of the data. Inside the computer, data bits flow in parallel (using
|
|
many wires at the same time). Serial flow is a stream of bits over a
|
|
single wire (such as on the transmit or receive pin of the serial
|
|
connector). For the serial port to create such a flow, it must
|
|
convert data from parallel (inside the computer) to serial on the
|
|
transmit pin (and conversely).
|
|
|
|
Most of the electronics of the serial port is found in a computer chip
|
|
(or a part of a chip) known as a UART. For more details on UARTs
|
|
see the section
|
|
"What are UARTS" in the Serial-HOWTO. But you may want to finish this section first so that you will
|
|
hopefully understand how the UART fits into the overall scheme of
|
|
things.
|
|
|
|
<sect2> Pins and Wires
|
|
<p> Old PC's used 25 pin connectors but only about 9 pins were
|
|
actually used so today most connectors are only 9-pin. Each of the 9
|
|
pins usually connects to a wire. Besides the two wires used for
|
|
transmitting and receiving data, another pin (wire) is signal ground.
|
|
The voltage on any wire is measured with respect to this ground. Thus
|
|
the minimum number of wires to use for 2-way transmission of data is
|
|
3. Except that it has been known to work with no signal ground wire
|
|
but with degraded performance and sometimes with errors.
|
|
|
|
There are still more wires which are for control purposes (signalling)
|
|
only and not for sending bytes. All of these signals could have been
|
|
shared on a single wire, but instead, there is a separate dedicated
|
|
wire for every type of signal. Some (or all) of these control wires
|
|
are called "modem control lines". Modem control wires are either in
|
|
the asserted state (on) of +12 volts or in the negated state (off) of
|
|
-12 volts. One of these wires is to signal the computer to stop
|
|
sending bytes out the serial port cable. Conversely, another wire
|
|
signals the device attached to the serial port to stop sending bytes
|
|
to the computer. If the attached device is a modem, other wires may
|
|
tell the modem to hang up the telephone line or tell the computer that
|
|
a connection has been made or that the telephone line is ringing
|
|
(someone is attempting to call in). See the Serial-HOWTO:
|
|
Pinout and Signals for more details.
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
<sect2> Internal Modem Contains Serial Port
|
|
<p> For an internal modem there is no 9-pin connector but the behavior
|
|
is almost exactly as if the above mentioned cable wires existed.
|
|
Instead of a a 12 volt signal in a wire giving the state of a modem
|
|
control line, the internal modem may just use a status bit in its own
|
|
memory (a register) to determine the state of this non-existent
|
|
"wire". The internal modem's serial port looks just like a real
|
|
serial port to the computer. It even includes the speed limits that
|
|
one may set at ordinary serial ports such as 115200 bits/sec.
|
|
|
|
Unfortunately for Linux, many internal modems today use software
|
|
(running on the CPU) to do much of the modem's work. Unfortunately,
|
|
such software may be only available for the MS Windows OS (it hasn't
|
|
been ported to Linux). Thus you can't use some of these modems with
|
|
Linux See <ref id="soft_modem" name="Software-based Modems
|
|
(winmodems)">.
|
|
|
|
|
|
|
|
<sect1> IO Address & IRQ
|
|
<p> Since the computer needs to communicate with each serial port, the
|
|
operating system must know that each serial port exists and where it
|
|
is (its I/O address). It also needs to know which wire (IRQ number)
|
|
the serial port must use to request service from the computer's CPU.
|
|
It requests service by sending an interrupt voltage on this wire.
|
|
Thus every serial port device must store in its non-volatile memory
|
|
both its I/O address and its Interrupt ReQuest number: IRQ. See <ref
|
|
id="interrupt_" name="Interrupts">. The PCI bus has its own system of
|
|
interrupts. But since the PCI-aware BIOS sets up these PCI interrupts
|
|
to map to IRQs, it seemingly behaves just as described above. Except
|
|
that sharing of PCI interrupts is allowed (2 or more devices may use
|
|
the same IRQ number).
|
|
|
|
I/O addresses are not the same as memory addresses. When an I/O
|
|
addresses is put onto the computer's address bus, another wire is
|
|
energized. This both tells main memory to ignore the address and
|
|
tells all devices which have I/O addresses (such as the serial port)
|
|
to listen to the address sent on the bus to see if it matches the
|
|
device's. If the address matches, then the I/O device reads the data
|
|
on the data bus.
|
|
|
|
The I/O address of a certain device (such as ttyS2) will actually be a
|
|
range of addresses. The lower address in this range is the base
|
|
address. "address" usually means just the "base address".
|
|
|
|
<sect1> Names: ttyS0, ttyS1, etc.
|
|
<p> The serial ports are named ttyS0, ttyS1, etc. (and usually
|
|
correspond respectively to COM1, COM2, etc. in DOS/Windows). The /dev
|
|
directory has a special file for each port. Type "ls /dev/ttyS*" to
|
|
see them. Just because there may be (for example) a ttyS3 file,
|
|
doesn't necessarily mean that there exists a physical serial port
|
|
there.
|
|
|
|
Which one of these names (ttyS0, ttyS1, etc.) refers to which
|
|
physical serial port is determined as follows. The serial driver
|
|
(software) maintains a table showing which I/O address corresponds to
|
|
which ttyS. This mapping of names (such as ttyS1) to I/O addresses
|
|
(and IRQ's) may be both set and viewed by the "setserial" command.
|
|
See <ref id="set_serial" name="What is Setserial">. This does
|
|
<tt/not/ set the I/O address and IRQ in the hardware itself (which is
|
|
set by jumpers or by plug-and-play software). Thus which physical port
|
|
corresponds to say ttyS1 depends both on what the serial driver thinks
|
|
(per setserial) and what is set in the hardware. If a mistake has
|
|
been made, the physical port may not correspond to any name (such as
|
|
ttyS2) and thus it can't be used. See <ref id="ttySN_" name="Serial
|
|
Port Devices /dev/ttyS2, etc."> for more details.
|
|
|
|
<sect1> Interrupts <label id="interrupt_">
|
|
<p>
|
|
<!-- ifdef MODEM_ -->
|
|
Bytes come in over the phone line to the modem, are converted from
|
|
analog to digital by the modem and passed along to the serial port on
|
|
their way to their destination inside your computer.
|
|
<!-- ifdef MODEM end -->
|
|
When the serial port receives a number of bytes (may be set to 1, 4,
|
|
8, or 14) into its FIFO buffer, it signals the CPU to fetch them by
|
|
sending an electrical signal known as an interrupt on a certain wire
|
|
normally used only by that port. Thus the FIFO waits until it has
|
|
received a number of bytes and then issues an interrupt.
|
|
|
|
However, this interrupt will also be sent if there is an unexpected
|
|
delay while waiting for the next byte to arrive (known as a timeout).
|
|
Thus if the bytes are being received slowly (such as from someone
|
|
typing on a terminal keyboard) there may be an interrupt issued for
|
|
every byte received. For some UART chips the rule is like this: If 4
|
|
bytes in a row could have been received in an interval of time, but
|
|
none of these 4 show up, then the port gives up waiting for more bytes
|
|
and issues an interrupt to fetch the bytes currently in the FIFO. Of
|
|
course, if the FIFO is empty, no interrupt will be issued.
|
|
|
|
Each interrupt conductor (inside the computer) has a number (IRQ) and
|
|
the serial port must know which conductor to use to signal on. For
|
|
example, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). A
|
|
list of them and more will be found in "man setserial" (search for
|
|
"Configuring Serial Ports"). Interrupts are issued whenever the
|
|
serial port needs to get the CPU's attention. It's important to do
|
|
this in a timely manner since the buffer inside the serial port can
|
|
hold only 16 incoming bytes. If the CPU fails to remove such received
|
|
bytes promptly, then there will not be any space left for any more
|
|
incoming bytes and the small buffer may overflow (overrun) resulting
|
|
in a loss of data bytes.
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
For an external modem, there may be no way (such as flow control) to
|
|
stop the flow rapidly enough to prevent such an overrun. For an
|
|
internal modem, the 16-byte FIFO buffer is on the same card and most
|
|
modems will not write to it if it's full. Thus it will not overrun
|
|
the 16-byte buffers but it may need to use <ref id="M-M_flow_c"
|
|
name="Modem-to-Modem Flow Control"> to prevent the modem itself from
|
|
being overrun. This is one advantage of internal modems over an
|
|
external. <!-- ifdef MODEM end -->
|
|
|
|
Interrupts are also issued when the serial port has just sent out all
|
|
of its bytes from its small transmit FIFO buffer out the external
|
|
cable. It then has space for 16 more outgoing bytes. The interrupt
|
|
is to notify the CPU of that fact so that it may put more bytes in the
|
|
small transmit buffer to be transmitted. Also, when a modem control
|
|
line changes state, an interrupt is issued.
|
|
|
|
The buffers mentioned above are all hardware buffers. The serial port
|
|
also has large buffers in main memory. This will be explained later
|
|
|
|
Interrupts convey a lot of information but only indirectly. The
|
|
interrupt itself just tells a chip called the interrupt controller
|
|
that a certain serial port needs attention. The interrupt controller
|
|
then signals the CPU. The CPU then runs a special program to service
|
|
the serial port. That program is called an interrupt service routine
|
|
(part of the serial driver software). It tries to find out what has
|
|
happened at the serial port and then deals with the problem such a
|
|
transferring bytes from (or to) the serial port's hardware buffer.
|
|
This program can easily find out what has happened since the serial
|
|
port has registers at IO addresses known to the serial driver
|
|
software. These registers contain status information about the serial
|
|
port. The software reads these registers and by inspecting the
|
|
contents, finds out what has happened and takes appropriate action.
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
<sect1> Data Compression (by the Modem)
|
|
<p> Before continuing with the basics of the serial port, one needs to
|
|
understand about something done by the modem: data compression. In
|
|
some cases this task is actually done by software run on the
|
|
computer's CPU but unfortunately at present, such software only works
|
|
for MS Windows. The discussion here will be for the case where the
|
|
modem itself does the compression since this is what must happen in
|
|
order for the modem to work under Linux.
|
|
|
|
In order to send data faster over the phone line, one may compress
|
|
(encode it) using a custom encoding scheme which itself depends on the
|
|
data. The encoded data is smaller than the original (less bytes) and
|
|
can be sent over the Internet in less time. This process is called
|
|
"data compression".
|
|
|
|
If you download files from the Internet, they are likely already
|
|
compressed and it is not feasible for the modem to try to compress
|
|
them further. Your modem may sense that what is passing thru has
|
|
already been compressed and refrain from trying a compress it any
|
|
more. If you are receiving data which has been compressed by the
|
|
other modem, your modem will decompress it and create many more bytes
|
|
than were sent over the phone line. Thus the flow of data from your
|
|
modem into your computer will be higher than the flow over the phone
|
|
line to you. The ratio of this flow is called the compression ratio.
|
|
Compression ratios as high as 4 are possible, but not very likely.
|
|
|
|
<sect1> Error Correction
|
|
<p> Similar to data compression, modems may be set to do error
|
|
correction. While there is some overhead cost involved which slows
|
|
down the byte/sec flow rate, the fact that error correction strips off
|
|
start and stop bits actually increases the data byte/sec flow rate.
|
|
|
|
For the serial port's interface with the external world, each 8-bit
|
|
byte has 2 extra bits added to it: a start-bit and a stop-bit.
|
|
Without error correction, these extra start and stop bits usually go
|
|
right thru the modem and out over the phone lines. But when error
|
|
correction is enabled, these extra bits are stripped off and the 8-bit
|
|
bytes are put into packets. This is more efficient and results in
|
|
higher byte/sec flow in spite of the fact that there are a few more
|
|
bytes added for packet headers and error correction purposes.
|
|
<!-- ifdef MODEM end -->
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
<sect1> Data Flow (Speeds)
|
|
<p> Data (bytes representing letters, pictures, etc.) flows from your
|
|
computer to your modem and then out on the telephone line (and
|
|
conversely). Flow rates (such as 56k (56000) bits/sec) are
|
|
(incorrectly) called "speed". But almost everyone says "speed"
|
|
instead of "flow rate". If there were no data compression the flow
|
|
rate from the computer to the modem would be about the same as the
|
|
flow rate over the telephone line.
|
|
|
|
Actually there are two different speeds to consider at your end of the
|
|
phone line:
|
|
|
|
<itemize>
|
|
<item> The speed on the phone line itself (DCE speed) modem-to-modem
|
|
<item> The speed from your computer's serial port to your modem (DTE speed)
|
|
</itemize>
|
|
|
|
When you dial out and connect to another modem on the other end of the
|
|
phone line, your modem often sends you a message like "CONNECT 28800"
|
|
or "CONNECT 115200". What do these mean? Well, its either the DCE
|
|
speed or the DTE speed. If it's higher than the advertised modem speed
|
|
it must be the DTE modem-to-computer speed. This is the case for the
|
|
115200 speed shown above. The 28800 must be a DCE (modem-to-modem)
|
|
speed since the serial port has no such speed. One may configure the
|
|
modem to report either speed. Some modems report both speeds and
|
|
report the modem-to-modem speed as (for example): CARRIER 28800.
|
|
|
|
If you have an internal modem you would not expect that there would be
|
|
any speed limit on the DTE speed from your modem to your computer
|
|
since you modem is inside your computer and is almost part of your
|
|
computer. But there usually is since the modem contains a dedicated
|
|
serial port within it. On some software modems there is no such speed
|
|
limit.
|
|
|
|
It's important to understand that the average speed is often less than
|
|
the specified speed, especially on the short DTE computer-to-modem
|
|
line. Waits (or idle time) result in a lower average speed. These
|
|
waits may include long waits of perhaps a second due to <ref
|
|
id="flow_control" name="Flow Control">. At the other extreme there
|
|
may be very short waits (idle time) of several micro-seconds
|
|
separating the end of one byte and the start of the next byte. In
|
|
addition, modems will fallback to lower speeds if the telephone line
|
|
conditions are less than pristine.
|
|
|
|
For a discussion of what DTE speed is best to use see section <ref
|
|
id="speed_" name="What Speed Should I Use">.
|
|
<!-- ifdef MODEM end -->
|
|
|
|
|
|
|
|
<sect1> Flow Control <label id="flow_control">
|
|
<p> Flow control means the ability to slow down the flow of bytes in a
|
|
wire. For serial ports this means the ability to stop and then
|
|
restart the flow without any loss of bytes. Flow control is needed
|
|
for modems and other hardware to allow a jump in instantaneous flow rates.
|
|
|
|
<sect2> Example of Flow Control
|
|
<p> For example, consider the case where you connect a 33.6k external
|
|
modem via a short cable to your serial port. The modem sends and
|
|
receives bytes over the phone line at 33.6k bits per second (bps).
|
|
Assume it's not doing any data compression or error correction. You
|
|
have set the serial port speed to 115,200 bits/sec (bps), and you are
|
|
sending data from your computer to the phone line. Then the flow from
|
|
the your computer to your modem over the short cable is at 115.2k bps.
|
|
However the flow from your modem out the phone line is only 33.6k bps.
|
|
Since a faster flow (115.2k) is going into your modem than is coming
|
|
out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k
|
|
bps) in one of its buffers. This buffer would soon overrun (run out
|
|
of free storage space) unless the high 115.2k flow is stopped.
|
|
|
|
But now flow control comes to the rescue. When the modem's buffer is
|
|
almost full, the modem sends a stop signal to the serial port. The
|
|
serial port passes on the stop signal on to the device driver and the
|
|
115.2k bps flow is halted. Then the modem continues to send out data
|
|
at 33.6k bps drawing on the data it previous accumulated in its
|
|
buffer. Since nothing is coming into this buffer, the number of bytes
|
|
in it starts to drop. When almost no bytes are left in the buffer,
|
|
the modem sends a start signal to the serial port and the 115.2k flow
|
|
from the computer to the modem resumes. In effect, flow control
|
|
creates an average flow rate in the short cable (in this case 33.6k)
|
|
which is significantly less than the "on" flow rate of 115.2k bps.
|
|
This is "start-stop" flow control.
|
|
|
|
In the above simple example it was assumed that the modem did no data
|
|
compression. This could happen when the modem is sending a file
|
|
which is already compressed and can't be compressed further. Now
|
|
let's consider the opposite extreme where the modem is compressing the
|
|
data with a high compression ratio. In such a case the modem might
|
|
need an input flow rate of say 115.2k bps to provide an output (to the
|
|
phone line) of 33.6k bps (compressed data). This compression ratio is
|
|
3.43 (115.2/33.6). In this case the modem is able to compress the
|
|
115.2 bps PC-to-modem flow and send the same data (in compressed form)
|
|
out the phone line at 33.6bps. There's no need for flow control here
|
|
so long as the compression ratio remains higher than 3.43. But the
|
|
compression ratio varies from second to second and if it should drop
|
|
below 3.43, flow control will be needed
|
|
|
|
In the above example, the modem was an external modem. But the same
|
|
situation exists (as of early 2003) for most internal modems. There is
|
|
still a speed limit on the PC-to-modem speed even though this flow
|
|
doesn't take place over an external cable. This makes the internal
|
|
modems compatible with the external modems.
|
|
|
|
In the above example of flow control, the flow was from the computer to
|
|
a modem. But there is also flow control which is used for the
|
|
opposite direction of flow: from a modem (or other device) to a
|
|
computer. Each direction of flow involves 3 buffers: 1. in the modem
|
|
2. in the UART chip (called FIFOs) and 3. in main memory managed by the
|
|
serial driver. Flow control protects all buffers (except the FIFOs)
|
|
from overflowing.
|
|
|
|
Under Linux, the small UART FIFO buffers are not protected by flow
|
|
control but instead rely on a fast response to the interrupts they
|
|
issue. Some UART chips can be set to do hardware flow control to
|
|
protect their FIFOs but Linux (as of early 2003) doesn't seem to
|
|
support it. FIFO stand for "First In, First Out" which is the way it
|
|
handles bytes in a queue. All the 3 buffers use the FIFO rule but
|
|
only the one in the UART is named "FIFO". This is the essence of flow
|
|
control but there are still some more details.
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
If you have set the highest PC-to-modem speed, you may not need flow
|
|
control in the direction from the modem to a PC. For a complex
|
|
example of a case where it's needed see "Complex Flow Control Example"
|
|
in the Serial-HOWTO. To slow down this incoming flow, your modem must
|
|
tell the other modem to stop sending. See <ref id="M-M_flow_c">
|
|
name="Modem-to-Modem Flow Control">.
|
|
<!-- ifdef MODEM end -->
|
|
|
|
|
|
|
|
<sect2> Hardware vs. Software Flow Control
|
|
<p> If feasible, it's best to use "hardware" flow control that uses two
|
|
dedicated "modem control" wires to send the "stop" and "start"
|
|
signals. Hardware flow control at the serial port works like this:
|
|
The two pins, RTS (Request to send) and CTS (Clear to send) are used.
|
|
When the computer is ready to receive date it asserts RTS by putting a
|
|
positive voltage on the RTS pin (meaning "Request To Send to me").
|
|
When the computer is not able to receive any more bytes, it negates
|
|
RTS by putting a negative voltage on the pin saying: "stop sending to
|
|
me". The RTS pin is connected by the serial cable to another pin on
|
|
the modem, printer, terminal, etc. This other pin's only function is
|
|
to receive this signal.
|
|
|
|
For the case of a modem, this "other" pin will be the modem's RTS pin.
|
|
But for a printer, another PC, or a non-modem device, it's usually a
|
|
CTS pin so a "crossover" or "null modem" cable is required. This
|
|
cable connects the CTS pin at one end with the RTS pin at the other
|
|
end (two wires since each end of the cable has a CTS pin). For a
|
|
modem, a straight-thru cable is used.
|
|
|
|
For the opposite direction of flow a similar scheme is used. For a
|
|
modem, the CTS pin is used to send the flow control signal to the CTS
|
|
pin on the PC. For a non-modem, the RTS pin sends the signal. Thus
|
|
modems and non-modems have the roles of their RTS and CTS pins
|
|
interchanged. Some non-modems such as dumb terminals may use other
|
|
pins for flow control such as the DTR pin instead of RTS.
|
|
|
|
Software flow control uses the main receive and transmit data wires to
|
|
send the start and stop signals. It uses the ASCII control characters
|
|
DC1 (start) and DC3 (stop) for this purpose. They are just inserted
|
|
into the regular stream of data. Software flow control is not only
|
|
slower in reacting but also does not allow the sending of binary data
|
|
unless special precautions are taken. Since binary data will likely
|
|
contain DC1 and DC3 characters, special means must be taken to
|
|
distinguish between a DC3 that means a flow control stop and a DC3
|
|
that is part of the binary code. Likewise for DC1. <!-- ifdef MODEM_
|
|
--> To get software flow control to work for
|
|
binary data requires both modem (hardware) and software support.
|
|
|
|
<sect2> Symptoms of No Flow Control
|
|
<p> Understanding flow-control theory can be of practical use. For
|
|
example I used my modem to access the Internet and it seemed to work
|
|
fine. But after a few months, I tried to send out long files from my PC
|
|
and a huge amount of retries and errors resulted but it finally
|
|
succeeded. Receiving in the other direction (from my ISP to me) worked
|
|
fine. The problem turned out to be a modem with flow control disabled.
|
|
My modem's buffer was overflowing (overrunning) on long outgoing files
|
|
since no "stop" signal was ever sent to my computer to halt sending to
|
|
the modem. There was no problem in the direction from the modem to my
|
|
computer since the capacity (say 115.2 kbps) of the serial port was
|
|
always higher than the flow from the telephone line. But it was a
|
|
problem in the other direction where the PC would send at 115.2 kbps
|
|
and the modem couldn't handle this high flow resulting in overruns of
|
|
the modem's buffer. The fix was to enable flow control by putting
|
|
into the modem's init string an enable-flow-control command.
|
|
|
|
<sect2> Modem-to-Modem Flow Control <label id="M-M_flow_c">
|
|
|
|
<p> This is the flow control of the data sent over the telephone lines
|
|
between two modems. It works as long as error correction is enabled.
|
|
Actually, even without error correction it's possible to enable
|
|
software flow control between modems but it may interfere with sending
|
|
binary data so it's not often used. <!-- ifdef MODEM end -->
|
|
|
|
<sect1> Data Flow Path; Buffers
|
|
<p>It's been mentioned that there are 3 buffers for each direction of
|
|
flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair
|
|
of larger buffers inside a device connected to the serial port (such
|
|
as a modem), and a pair of buffers (say 8k) in main memory. When an
|
|
application program sends bytes to the serial port they first get
|
|
stashed in the transmit serial port buffer in main memory. The other
|
|
member of this pair consists of a receive buffer for the opposite
|
|
direction of byte-flow. Here's an example diagram for the case of
|
|
browsing the Internet with a browser. Transmit data flow is left to
|
|
right while receive flow is right to left. There is a separate buffer
|
|
for each direction of flow.
|
|
|
|
<verb>
|
|
application 8k-byte 16-byte 1k-byte tele-
|
|
BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
|
|
program buffer buffer buffer line
|
|
</verb>
|
|
|
|
For the transmit case, the serial device driver takes out say 15 bytes
|
|
from this transmit buffer (in main memory), one byte at a time and
|
|
puts them into the 16-byte transmit buffer in the serial UART for
|
|
transmission. Once in that transmit buffer, there is no way to stop
|
|
them from being transmitted. They are then transmitted to the
|
|
modem or (other device connected to the serial port) which also has a
|
|
fair sized (say 1k) buffer. When the device driver (on orders from
|
|
flow control sent from the modem) stops the flow of outgoing bytes
|
|
from the computer, what it actually stops is the flow of outgoing
|
|
bytes from the large transmit buffer in main memory. Even after this
|
|
has happened and the flow to the modem has stopped, an application
|
|
program may keep sending bytes to the 8k transmit buffer until it
|
|
becomes fill. At the same time, the bytes stored in the FIFO and
|
|
continue to be sent out. Bytes stored in the modem will continue to
|
|
be sent out the phone line unless the modem has gotten a
|
|
modem-to-modem flow control stop from the modem at the other end of
|
|
the phone line.
|
|
|
|
When the memory buffer gets fill, the application program can't send
|
|
any more bytes to it (a "write" statement in a C-program blocks) and
|
|
the application program temporarily stops running and waits until some
|
|
buffer space becomes available. Thus a flow control "stop" is
|
|
ultimately able to stop the program that is sending the bytes. Even
|
|
though this program stops, the computer does not necessarily stop
|
|
computing since it may switch to running other processes while it's
|
|
waiting at a flow control stop.
|
|
|
|
The above was a little oversimplified in three ways. First, some UARTs
|
|
can do automatic hardware flow control which can stop the transmission
|
|
out of the FIFO buffers if needed (not yet supported by Linux).
|
|
Second, while an application process is waiting to write to the
|
|
transmit buffer, it could possibly perform other tasks. Third, the
|
|
serial driver (located between the memory buffer and the FIFO) has
|
|
it's own small buffer (in main memory) used to process characters.
|
|
|
|
<!-- ifdef MODEM_ -->
|
|
<sect1> Modem Commands
|
|
<p> Commands to the modem are sent to it from the communication
|
|
software over the same conductor as used to send data. The commands
|
|
are short ASCII strings. Examples are "AT&K3" for enabling
|
|
hardware flow control (RTS/CTS) between your computer and modem; and
|
|
"ATDT5393401 for Dialing the number 5393401. Note all commands are
|
|
prefaced by "AT". Some commands such as enabling flow control help
|
|
configure the modem. Other commands such as dialing a number actually
|
|
do something. There are about a hundred or so different possible
|
|
commands. When your communication software starts running, it first
|
|
sends an "init" string of commands to the modem to configure it. All
|
|
commands are sent on the ordinary data line before the modem dials (or
|
|
receives a call).
|
|
|
|
Once the modem is connected to another modem (on-line mode),
|
|
everything that is sent from your computer to your modem goes directly
|
|
to the other modem and is not interpreted by the modem as a command.
|
|
There is a way to "escape" from this mode of operation and go back to
|
|
command mode where everything sent to the modem will be interpreted as
|
|
a command. The computer just sends "+++" with a specified time
|
|
spacing before and after it. If this time spacing is correct, the
|
|
modem reverts to command mode. Another way to do this is by a signal
|
|
on a certain modem control line.
|
|
|
|
There are a number of lists of modem commands on the Internet. The
|
|
section <ref id="web_sites" name="Web Sites"> has links to a couple of
|
|
such web-sites. Different models and brands of modems do not use
|
|
exactly the same set of such commands. So what works for one modem
|
|
might not work for another. Some common commands (not guaranteed to
|
|
work on all modems) are listed in this HOWTO in the section <ref
|
|
id="modem_conf" name="Modem Configuration">
|
|
<!-- ifdef MODEM end -->
|
|
|
|
|
|
|
|
<sect1> Serial Driver Module
|
|
<p> The device driver for the serial port is the software that
|
|
operates the serial port. It is now provided as a serial module.
|
|
From kernel 2.2 on, this module will normally get loaded automatically
|
|
if it's needed. In earlier kernels, you had to have <tt/kerneld/
|
|
running in order to do auto-load modules on demand. Otherwise the
|
|
serial module needed to be explicitly listed in /etc/modules. Before
|
|
modules became popular with Linux, the serial driver was usually built
|
|
into the kernel (and sometimes still is). If it's built-in don't let
|
|
the serial module load or else you will have two serial drivers
|
|
running at the same time. With 2 drivers there are all sorts of
|
|
errors including a possible "I/O error" when attempting to open a
|
|
serial port. Use "lsmod" to see if the module is loaded.
|
|
|
|
When the serial module is loaded it displays a message on the screen
|
|
about the existing serial ports (often showing a wrong IRQ). But once
|
|
the module is used by <tt/setserial/ to tell the device driver the
|
|
(hopefully) correct IRQ then you should see a second display similar
|
|
to the first but with the correct IRQ, etc. See
|
|
"Serial Module" in the Serial-HOWTO.
|
|
See <ref id="set_serial" name="What is Setserial"> for more info on
|
|
<tt/setserial/.
|
|
|
|
<!-- basics.D end -->
|
|
|
|
|
|
<sect> Configuring Overview
|
|
<p>Since each modem has an associated serial port and the port has both
|
|
hardware and software, there are three parts to configuring a modem:
|
|
|
|
<itemize>
|
|
<item>Locate the serial port hardware: IO address, IRQ; Done by PnP
|
|
methods or jumpers, setserial. See <ref id="locate_port" name="Locating
|
|
the Serial Port: IO address IRQs"> <ref id="set_serial" name="What is
|
|
Setserial">
|
|
<item> Configure the serial port driver (high-level): Done by the
|
|
communication program (stty-like). Sets speed, flow control, etc.
|
|
See <ref id="config_stty" name="Configuring the Serial Driver
|
|
(high-level)"> See <ref id="stty_" name="What is stty ?">
|
|
<item> Configure the modem itself: Done by the communication program
|
|
See <ref id="modem_conf" name="Modem Configuration">
|
|
</itemize>
|
|
|
|
The above omits a few other things that "setserial" can do besides
|
|
locating the serial ports. But normally you don't need to use them.
|
|
Setserial may be used in the future to enable super-high speed.
|
|
|
|
Communication programs include <tt/minicom/, <tt/seyon/, or
|
|
<tt/wvdial/ (for PPP) and <tt/mgetty/ for dial-in. Such
|
|
communication programs require that you configure them, although the
|
|
default configuration they come with may only need a little tweaking.
|
|
|
|
Unfortunately the communication program doesn't locate the serial
|
|
port. This "locating" is the low-level PnP configuring of the serial
|
|
port: setting its IO address and IRQ in both the hardware and the
|
|
driver. If you are lucky, this will happen automatically when you
|
|
boot Linux. Setting these in the hardware was formerly done by
|
|
jumpers and then running "setserial" but today it's done by
|
|
"Plug-and-Play" software. You may still need "setserial". So if
|
|
Linux (or the wvdial program, etc.) doesn't report what serial port
|
|
your modem is on, then you can try to find it yourself per the next
|
|
section but it may not be easy.
|
|
|
|
<sect>Locating the Serial Port: IO address, IRQs <label id="locate_port">
|
|
<!-- locate.D begin (in MM, SS)
|
|
<sect>Configuring the Serial Port
|
|
Change-log:
|
|
Aug. 2001: removed mention of patch to convert Linux to a PnP OS;
|
|
Better explanation of PCI
|
|
July 2001: Improve PCI part. Remove "card" since serial ports are
|
|
often built into the motherboard.
|
|
Feb. 2003: Removed request to send info to Ted Tso.
|
|
Dec. 2003: May need to create /dev/ttyS4 even if its auto detected
|
|
Nov. 2004: Added: What Bus is my Serial Port On? LPC: More work
|
|
Mar. 2006: Fixed typos, etc.
|
|
needed.
|
|
-->
|
|
|
|
<sect1>What Bus is my Serial Port On?
|
|
<p>If you need to find a serial port it often helps if you know what
|
|
bus it's on. If the serial port is on a card, you may know what bus
|
|
the card inserts into such as a PCI slot. But if the serial port is
|
|
built into the motherboard it may not be clear what bus it's on. For
|
|
old motherboards that have ISA bus slots, it's likely on the ISA bus
|
|
and may not even be Plug-and-Play. But even if all your slots are
|
|
PCI, the serial port is likely to be on either an ISA bus or LPC bus
|
|
(also called a "LPC interface"). LPC is common on laptop computers.
|
|
Type "lspci" to see if it shows "LPC". Unfortunately, the LPC bus has
|
|
no standard Plug-and-Play method for low-level configuring devices on
|
|
it. But according to the specs, the BIOS is supposed to do such
|
|
configuring (using ACPI ??). To see if you have a LPC bus, type
|
|
"lspci" and look for a LPC bridge or the like.
|
|
|
|
<sect1> IO & IRQ Overview
|
|
<p> For a serial port to work properly it first must be given both an
|
|
IO address and an IRQ. For old hardware (of mid 1990s), jumpers on a
|
|
card or a saved BIOS setting does it. For newer hardware the BIOS
|
|
or Linux must set them at boot-time, and the new hardware doesn't
|
|
remember how it was set once it's powered down. Enabling the hardware
|
|
(by using software) gives it both an IRQ and an IO address. Without
|
|
an IO address, it can't be used. Without an IRQ it will need to use
|
|
inefficient polling methods for which one must set the IRQ to 0 in the
|
|
serial driver. Using digital signals sent to the hardware by the BIOS
|
|
or Linux, it all should get configured automatically (provided the
|
|
BIOS has not been previously set up to disable it). So you only
|
|
need to read this if you're having problems or if you want to
|
|
understand how it works.
|
|
|
|
The driver must of course know both the IO address and IRQ so that it
|
|
can talk to the serial port chip. Modern serial port drivers (kernel
|
|
2.4) try to determine this by PnP methods so one doesn't normally need
|
|
to tell the driver (by using "setserial"). A driver may also set an
|
|
IO address or IRQ in the hardware. But unfortunately, there is some
|
|
PCI serial port hardware that the driver doesn't recognize so you
|
|
might need to enable the port yourself. See <ref id="pci_enabled"
|
|
name="PCI: Enabling a disabled port">
|
|
|
|
For the old ISA bus, the driver also probes likely serial port
|
|
addresses to see if there are any serial ports there. This works for
|
|
the case of jumpers and sometimes works for a ISA PnP port when the
|
|
driver doesn't do ISA PnP (prior to kernel 2.4).
|
|
|
|
Locating the serial port by giving it an IRQ and IO address is
|
|
low-level configuring. It's often automatically done by the serial
|
|
driver but sometimes you have to do it yourself. What follows repeats
|
|
what was said above but in more detail.
|
|
|
|
The low-level configuring consists of assigning an IO address, IRQ,
|
|
and names (such as ttyS2 = tts/2). This IO-IRQ pair must be set in
|
|
both the hardware and told to the serial driver. And the driver needs
|
|
to call this pair a name (such as ttyS2). We could call this "io-irq"
|
|
configuring for short. The modern way to do this is for the driver to
|
|
use PnP methods to detect/set the IO/IRQ and then remember what it
|
|
did. An easy way for a driver to do this is for the driver to ask the
|
|
kernel to enable the device and then the kernel tells the driver what
|
|
IO/IRQ it has used. The old way is using the "setserial" program to
|
|
tell the driver. For jumpers, there is no PnP but the driver might
|
|
detect the port if the jumpers are set to the usual I0/IRQ. If you
|
|
need to configure but don't understand certain details it's easy to
|
|
get into trouble.
|
|
|
|
When Linux starts, an effort is made to detect and configure
|
|
(low-level) the serial ports. Exactly what happens depends on your
|
|
BIOS, hardware, Linux distribution, kernel version, etc. If the
|
|
serial ports work OK, there may be no need for you to do any more
|
|
low-level configuring.
|
|
|
|
If you're having problems with the serial ports, then you may need to
|
|
do low-level configuring. If you have kernel 2.2 or lower,
|
|
then you need to do it if you:
|
|
|
|
<itemize>
|
|
<item> Plan to use more than 2 ISA serial ports
|
|
<item> Are installing a new serial port (such as an internal modem)
|
|
<item> One or more of your serial ports have non-standard IRQs or IO
|
|
addresses
|
|
</itemize>
|
|
|
|
Starting with kernel 2.2 you may be able to use more that 2 serial
|
|
ports without doing any low-level configuring by sharing interrupts.
|
|
All PCI ports should support this but for ISA it only works for some
|
|
hardware. It may be just as easy to give each port a unique interrupt
|
|
if they are available. See <ref id="int_share-2.2" name="Interrupt
|
|
sharing and Kernels 2.2+">
|
|
|
|
The low-level configuring (setting the IRQ and IO address) seems to
|
|
cause people more trouble than the high-level stuff, although for many
|
|
it's fully automatic and there is no configuring to be done. Until
|
|
the port is enabled and the serial driver knows the correct IRQ and IO
|
|
address, the port will not usually not work at all.
|
|
|
|
A port may be disabled, either by the BIOS or by failure of Linux to
|
|
find and enable the port. For modern ports (provided the BIOS hasn't
|
|
disabled them) manual PnP tools such as lspci should be able to find
|
|
them. Applications, and utilities such as "setserial" and "scanport"
|
|
(Debian only ??) only probe I0 addresses, don't use PnP tools, and
|
|
thus can't detect disabled ports.
|
|
|
|
Even if an ISA port can be found by the probing done by the serial
|
|
driver it may work extremely slow if the IRQ is wrong. See <ref
|
|
id="slow_" name="Extremely Slow: Text appears on the screen slowly
|
|
after long delays">. PCI ports are less likely to get the IRQ wrong.
|
|
|
|
IO address, IRQs, etc. are called "resources" and we are thus
|
|
configuring certain resources. But there are many other types of
|
|
"resources" so the term has many other meanings. In summary, the
|
|
low-level configuring consists of enabling the device, giving it a
|
|
name (ttyS2 for example) and putting two values (an IRQ number and IO
|
|
address) into two places:
|
|
|
|
<enum>
|
|
<item> The device driver (done by PnP or "<tt/setserial/")
|
|
<item> Configuration registers of the serial port hardware itself,
|
|
done by PnP software (or jumpers on legacy hardware).
|
|
</enum>
|
|
|
|
You may watch the start-up (= boot-time) messages. They are usually
|
|
correct. But if you're having problems, your serial port may not show
|
|
up at all or if you do see a message from "setserial" it may not
|
|
show the true configuration of the hardware (and it is not necessarily
|
|
supposed to). See <ref id="boot_mesgs" name="I/O Address & IRQ:
|
|
Boot-time messages">.
|
|
|
|
<sect1> PCI Bus Support <label id="PCI_ser_conf">
|
|
<sect2>Introduction
|
|
<p>
|
|
Although some PCI modems are "winmodems" without a Linux driver
|
|
(and will not work under Linux), other PCI modems will often work OK
|
|
under Linux. If it's a software modem, then you need to find a driver
|
|
for it since support for "winmodems" is not built into their serial
|
|
driver. See Linmodem-HOWTO.
|
|
|
|
If you have kernel 2.4 or better, then there should be support for PnP
|
|
for both the PCI and ISA buses (either built-in or by modules). Some
|
|
PCI serial ports can be automatically detected and low-level
|
|
configured by the serial driver. Others may not be.
|
|
|
|
While kernel 2.2 supported PCI in general, it had no support for PCI
|
|
serial ports (although some people got them working anyway). Starting
|
|
with kernel 2.4, the serial driver will read the id number digitally
|
|
stored in the serial hardware to determine how to support it (if it
|
|
knows how). It should assign an I/O address to it, determine its
|
|
IRQ, etc. So you don't need to use "setserial" for it.
|
|
|
|
There is a possible problem if you don't use the device filesystem.
|
|
The driver may assign the port to say tt/ttyS4 per a boot-time
|
|
message (use <tt/dmesg/ to see it). But if you don't have a "file"
|
|
/dev/ttyS4 then the port will not work. So you will then need to
|
|
create it, using<newline>
|
|
<tt>cd /dev; ./MAKEDEV ttyS4</tt><newline>
|
|
For the device filesystem, the driver should create the device <tt>tts/1</tt>
|
|
|
|
<!--
|
|
<sect2> Requesting that future drivers support your serial port
|
|
<p>If you have a
|
|
PCI internal modem which you are convinced is not a winmodem
|
|
but it will not work because the latest serial driver doesn't support
|
|
it, you can help in attempting to create a driver for it. To do this
|
|
you'll need to contact the maintainer of the serial driver, Theodore
|
|
(Ted) Y. Ts'o.
|
|
But first check out the modem list site <url
|
|
url="http://www.idir.net/~gromitkc/winmodem.html"> for the latest info
|
|
on PCI modems and related topic.
|
|
|
|
Look at <url url="http://serial.sourceforge.net" name="Ted Ts'o's
|
|
site"> for the details of what you need to do. Here's a summary of
|
|
what you need to do to help him. You will need to email Ted Ts'o a
|
|
copy of the output of "lspci -vv" with full information about the
|
|
model and manufacturer of the PCI modem (or serial port). Then he
|
|
will try to point you to a test driver which might work for it. You
|
|
will then need to get it, compile it and possibly recompile your
|
|
kernel. Then you will test the driver to see if it works OK for you
|
|
and report the results to Ted Ts'o. If you are willing to do all the
|
|
above (and this is the latest version of this HOWTO) then email the
|
|
needed info to him at: <url url="mailto:tytso@mit.edu">.
|
|
-->
|
|
<sect2>More info on PCI
|
|
<p>PCI ports are not well standardized. Some use main memory for
|
|
communication with the PC. Some require special enabling of the IRQ.
|
|
The output of "lspci -vv" can help determine if one can be supported.
|
|
If you see a 4-digit IO port, the port might work by just telling
|
|
"setserial" the IO port and the IRQ.
|
|
Some people have gotten a 3COM 3CP5610 PCI Modem to work that
|
|
way.For example, if lspci shows IRQ 10, I/O at 0xecb8 and you decide to
|
|
name it ttyS2 then the command is:
|
|
|
|
setserial /dev/ttyS2 irq 10 port 0xecb8 autoconfig
|
|
|
|
Note that the boot-time message "Probing PCI hardware" means reading
|
|
the PnP configuration registers in the PCI devices which detects info
|
|
about all PCI cards and on-board PCI devices This is different that
|
|
the probing of IO addresses by the serial driver which means reading
|
|
certain IO addresses to see if what's read looks like there's a serial
|
|
port at that address.
|
|
|
|
<sect1> Common mistakes made re low-level configuring
|
|
<p> Here are some common mistakes people make:
|
|
<itemize>
|
|
<item>setserial command: They run it (without the "autoconfig" and
|
|
auto_irq options) and think it has checked the hardware to see if
|
|
what it shows is correct (it hasn't).
|
|
<item>setserial messages: They see them displayed on the screen at
|
|
boot-time (or by giving the setserial command) and erroneously think
|
|
that the result always shows how their hardware is actually
|
|
configured.
|
|
<item>/proc/interrupts: When their serial device isn't in use they
|
|
don't see its interrupt there, and erroneously conclude that their
|
|
serial port can't be found (or doesn't have an interrupt set).
|
|
<item>/proc/ioports and /proc/tty/driver/serial: People think this
|
|
shows the actual hardware configuration when it only shows about the
|
|
same info (possibly erroneous) as setserial.
|
|
</itemize>
|
|
|
|
<sect1> IRQ & IO Address Must be Correct <label id="what_is_io_irq">
|
|
<p>There are really two answers to the question "What is my IO and
|
|
IRQ?" 1. What the device driver thinks has been set (This is what
|
|
setserial usually sets and shows.). 2. What is actually set in the
|
|
hardware. Both 1. and 2. above should be the same. If they're not it
|
|
spells trouble since the driver has incorrect info on the physical
|
|
serial port. In some cases the hardware is disabled so it has no IO
|
|
address or IRQ.
|
|
|
|
If the driver has the wrong IO address it will try to send data to a
|
|
non-existing serial port --or even worse, to some other device. If it
|
|
has the wrong IRQ the driver will not get interrupt service requests
|
|
from the serial port, resulting in a very slow or no response. See
|
|
<ref id="slow_" name="Extremely Slow: Text appears on the screen
|
|
slowly after long delays">. If it has the wrong model of UART there
|
|
is also apt to be trouble. To determine if both I0-IRQ pairs are
|
|
identical you must find out how they are set in both the driver and
|
|
the hardware.
|
|
|
|
<sect1> What is the IO Address and IRQ per the driver ?
|
|
<sect2> Introduction
|
|
<p>What the driver thinks is not necessarily how the hardware is
|
|
actually set. If everything works OK then what the driver thinks is
|
|
likely correct (set in the hardware) and you don't need to investigate
|
|
(unless you're curious or want to become a guru). Ways to determine
|
|
what the driver thinks include: boot-time messages <ref
|
|
id="boot_mesgs" name="I/O Address & IRQ: Boot-time messages">, the
|
|
/proc directory "files" <ref id="proc_dir" name="The /proc directory
|
|
and setserial">, and the "setserial" command.
|
|
|
|
|
|
<sect2> I/O Address & IRQ: Boot-time messages <label id="boot_mesgs">
|
|
<p> In many cases your ports will automatically get low-level
|
|
configured at boot-time (but not always correctly). To see what is
|
|
happening, look at the start-up messages on the screen. Don't neglect
|
|
to check the messages from the BIOS before Linux is loaded (no
|
|
examples shown here). These BIOS messages may be frozen by pressing
|
|
the Pause key (while holding down shift). It's often tricky to freeze
|
|
them and you may need to hit Ctrl-Alt-Del while Linux is booting to
|
|
start rebooting and try again. What these messages display may change
|
|
as booting progresses and it's often tricky to freeze it at exactly the
|
|
right words.
|
|
|
|
Use Shift-PageUp to scroll back to the messages after they have
|
|
flashed by. Shift-PageDown will scroll in the opposite direction.
|
|
The <tt/dmesg/ command (or looking at logs in /var/log) will show only
|
|
the first of these two messages. Here's an example of the start-up
|
|
messages (as of 2004, almost the same as for 1999). Note that in
|
|
older versions ttyS1 was displayed in these messages as ttyS01, etc.
|
|
|
|
At first you see what was detected (but the irq is only a wild guess):
|
|
|
|
<tscreen><verb>
|
|
Serial driver version 4.27 with no serial options enabled
|
|
ttyS0 at 0x03f8 (irq = 4) is a 16550A
|
|
ttyS1 at 0x02f8 (irq = 3) is a 16550A
|
|
ttyS2 at 0x03e8 (irq = 4) is a 16550A
|
|
ttyS4 at port 0xeff0 (irq = 10) is a 16550A
|
|
</verb></tscreen>
|
|
|
|
Note that ttyS0-ttyS2 were detected by probing the standard addresses
|
|
while ttyS4 is a PCI port detected by probing the PCI configuration.
|
|
Later setserial shows you what was saved in a configuration file
|
|
(which you may edit), but it's not necessarily correct either:
|
|
|
|
<tscreen><verb>
|
|
Loading the saved-state of the serial devices...
|
|
/dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A
|
|
/dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A
|
|
</verb></tscreen>
|
|
|
|
Note that the configuration file only had ttyS1-2 in it so that ttyS0
|
|
and ttyS4 were not affected by it. There is also a slight
|
|
discrepancy: The first message shows ttyS2 at irq=4 while the second
|
|
shows it at irq=5. In most cases the second message is the correct
|
|
one. But if you're having trouble, it may be misleading. Before reading
|
|
the explanation of all of this complexity in the rest of this section,
|
|
you might just try using your serial port and see if it works OK. If
|
|
so it may not be essential to read further.
|
|
|
|
The second message is from the <tt/setserial/ program being run at
|
|
boot-time from a script in the /etc directory tree. It shows what the
|
|
device driver thinks is the correct configuration. But this too could
|
|
be wrong. For example, the irq could actually be set to irq=8 in the
|
|
hardware (both messages wrong). The irq=5 could be there because the
|
|
configuration file is incorrect.
|
|
|
|
With old jumper-set serial ports Linux sometimes gets IRQs wrong
|
|
because it doesn't by default probe for IRQs. It just assumes the
|
|
"standard" ones (first message) or accepts what is in a configuration
|
|
file (second message). Neither of these is necessarily correct. If
|
|
the serial driver has the wrong IRQ, the serial port is very slow or
|
|
doesn't seem to work at all.
|
|
|
|
The first message is a result of Linux probing the ISA serial port
|
|
addresses but it doesn't probe for IRQs. If a port shows up here it
|
|
exists but the IRQ may be wrong. Linux doesn't check IRQs because
|
|
doing so is not foolproof. It just assumes the IRQs are as shown
|
|
because they are the "standard" values. You may check them manually
|
|
with <tt/setserial/ using the <tt/autoconfig/ and <tt/auto_irq/
|
|
options but this isn't guaranteed to be correct either.
|
|
|
|
The data shown by the BIOS messages (which you see at first before
|
|
Linux is booted) are what is initially set in the hardware. If your
|
|
serial port is Plug-and-Play (PnP) then it's possible that "isapnp" or
|
|
"setpci" will run and change these settings. Look for messages about
|
|
this after Linux starts. The last serial port message shown in the
|
|
example above should agree with the BIOS messages (as possibly
|
|
modified by isapnp or setpci). If they don't agree then you either
|
|
need to change the setting in the port hardware or use setserial to
|
|
tell the driver what is actually set in the hardware.
|
|
|
|
Also, if you have Plug-and-Play (PnP) serial ports, they can only be
|
|
found by PnP software unless the IRQ and IO has been set inside the
|
|
hardware by Plug-and-Play software. Prior to kernel 2.4 this was a
|
|
common reason why the start-up messages did not show a serial port
|
|
that physically exists. A PnP BIOS may automatically low-level
|
|
configure them. PnP configuring will be explained later.
|
|
|
|
<sect2> The /proc directory and setserial <label id="proc_dir">
|
|
<p> Type "setserial -g /dev/ttyS*". There are some other
|
|
ways to find this info by looking at "files" in the /proc directory.
|
|
Be warned that there is no guarantee that the same is set in the
|
|
hardware.
|
|
|
|
<tt>/proc/ioports</tt> will show the IO addresses that the drivers are using.
|
|
<tt>/proc/interrupts</tt> shows the IRQs that are used by drivers of
|
|
currently running processes (that have devices open). It shows how
|
|
many interrupts have actually be issued.
|
|
<tt>/proc/tty/driver/serial</tt> shows much of the above, plus the
|
|
number of bytes that have been received and sent (even if the device
|
|
is not now open).
|
|
|
|
Note that for the IO addresses and IRQ assignments, you are only seeing
|
|
what the driver thinks and not necessarily what is actually set in the
|
|
hardware. The data on the actual number of interrupts issued and
|
|
bytes processed is real however. If you see a large number of
|
|
interrupts and/or bytes then it probably means that the device is (or
|
|
was) working. But the interrupts might be from another device. If
|
|
there are no bytes received (rx:0) but bytes were transmitted (tx:3749
|
|
for example), then only one direction of flow is working (or being
|
|
utilized).
|
|
|
|
Sometimes a showing of just a few interrupts doesn't mean that the
|
|
interrupt is actually being physically generated by any serial port.
|
|
Thus if you see almost no interrupts for a port that you're trying to
|
|
use, that interrupt might not be set in the hardware. To view
|
|
/proc/interrupts to check on a program that you're currently running
|
|
(such as "minicom") you need to keep the program running while you
|
|
view it.
|
|
|
|
<sect1>What is the IO Address & IRQ of my Serial Port Hardware?
|
|
<label id="io-irq_in_hdw">
|
|
<sect2>Introduction
|
|
<p>If it's PCI or ISA PnP then what's set in the hardware has been done
|
|
by PnP methods. Even if nothing has been set or the port disabled,
|
|
PnP ports may still be found by using "lspci -v" or "isapnp
|
|
--dumpregs". Ports disabled by jumpers (or hardware failures) are
|
|
completely lost. See <ref id="isa_pnp_dump" name="ISA PnP ports">,
|
|
<ref id="pci_io_irq" name="PCI: What IOs and IRQs have been set?">,
|
|
<ref id="pci_enabled" name="PCI: Enabling a disabled port">
|
|
|
|
PnP ports don't store their configuration in the hardware when the
|
|
power is turned off. This is in contrast to Jumpers (non-PnP) which
|
|
remain the same with the power off. That's why a PnP port is more
|
|
likely to be found in a disabled state than an old non-PnP one.
|
|
|
|
<sect2> PCI: What IOs and IRQs have been set? <label id="pci_io_irq">
|
|
<p> For PCI, the BIOS almost always sets the IRQ and may set the IO
|
|
address as well. To see how it's set use "lspci -vv" (best) or look
|
|
in /proc/bus/pci (or for kernels <2.2 /proc/pci). The modem's
|
|
serial port is often called a "Communication controller". Look for
|
|
this. If lspci shows "I/O ports at ... [disabled]" then the serial
|
|
port is disabled and the hardware has no IO address so it's lost and
|
|
can't be used. See <ref id="pci_enabled" name="PCI: Enabling a
|
|
disabled port"> for how to enable it.
|
|
|
|
If more than one IO address is shown, the first one is more likely to
|
|
be it. You can't change the IRQ (at least not with "setpci") This
|
|
is because if one writes an IRQ it it's hardware register no action is
|
|
taken on it. It's the BIOS that should actually set up the IRQs and
|
|
then write the correct value to this register for lspci to view. If
|
|
you must, change the IO address with "setpci" by changing the
|
|
BASE_ADDRESS_0 or the like.
|
|
|
|
<sect2> PCI: Enabling a disabled port <label id="pci_enabled">
|
|
<p>If the port communicates via an IO address then "lspci -vv" should
|
|
show "Control: I/O+ ..." with + meaning that the IO address is
|
|
enabled. If it shows "I/O-" (and "I/O ports at ... [disabled]") then
|
|
you may need to use the setpci command to enable it. For example
|
|
"setpci -d 151f:000 command=101". 151f is the vendor id, and 000 is
|
|
the device id both obtained from "lspci -n -v" or from /proc/bus/pci
|
|
or from "scanpci -v". The "command=101" means that 101 is put into
|
|
the command register which is the same as the "Control" register
|
|
displayed by "lspci". The 101h sets two bits: the 1 sets I/O to + and
|
|
the 100 part keeps SERR# set to +. In this case only the SERR# bit
|
|
of the Control register was initially observed to be + when the lspci
|
|
command was run. So we kept it enabled to + by setting bit 8 (where
|
|
bit 0 is I/O) to 1 by the first 1 in 101. Some serial cards don't use
|
|
SERR# so if you see SERR#- then there's no need to enable it so then
|
|
use: command=1. Then you'll need to set up "setserial" to tell the
|
|
driver the IO and IRQ.
|
|
|
|
Bit 8 is actually the 9th bit since we started counting bits from 0.
|
|
Don't be alarmed that lspci shows a lot of - signs showing that the
|
|
card doesn't have many features available (or enabled). Serial ports
|
|
are relatively slow and don't need these features.
|
|
|
|
Another way to enable it is to let the BIOS do it by telling the BIOS
|
|
that you don't have a plug-and-play operating system. Then the BIOS
|
|
should enable it when you start your PC. If you have MS Windows9x on
|
|
the same PC then doing this might cause problems with Windows (see
|
|
Plug-and-Play-HOWTO).
|
|
|
|
<sect2>ISA PnP ports <label id="isa_pnp_dump">
|
|
<p>For an ISA Plug-and-Play (PnP) port one may try the <tt/pnpdump/
|
|
program (part of <tt/isapnptools/). If you use the --dumpregs option
|
|
then it should tell you the actual IO address and IRQ set in the port.
|
|
It should also find an ISA PnP port that is disabled. The address it
|
|
"trys" is not the device's IO address, but a special address used for
|
|
communicating with PnP cards.
|
|
|
|
<sect2>Finding a port that is not disabled (ISA, PCI, PnP, non-PnP)
|
|
<p> 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 or setpci can. Starting with kernel 2.4, the
|
|
serial driver can make such changes for many (but not all) serial
|
|
ports.
|
|
|
|
Using "scanport" (Debian only ??) will probe all I/O ports and will
|
|
indicate what it thinks may be serial port. After this you could try
|
|
probing with setserial using the "autoconfig" option. You'll need to
|
|
guess the addresses to probe at (using clues from "scanport"). See
|
|
<ref id="set_serial" name="What is Setserial">.
|
|
|
|
For a port set with jumpers, the IO ports and IRQs are set per the
|
|
jumpers. If the port is not Plug-and-Play (PnP) but has been setup by
|
|
using a DOS program, then it's set at whatever the person who ran that
|
|
program set it to.
|
|
|
|
<sect2>Exploring via MS Windows (a last resort)
|
|
<p>For PnP ports, checking on how it's configured under DOS/Windows
|
|
may (or may not) imply how it's under Linux. MS Windows stores its
|
|
configuration info in its Registry which is not used by Linux so they
|
|
are not necessarily configured 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 starting
|
|
Linux) then Linux should use whatever configuration is in the BIOS's
|
|
non-volatile memory. Windows also makes use of the same non-volatile
|
|
memory but doesn't necessarily configure it that way.
|
|
|
|
<sect1>Choosing Serial IRQs <label id="choose_IRQ">
|
|
|
|
<p> If you have Plug-and-Play ports then either a PnP BIOS or a
|
|
serial driver may configure all your devices for you so then you may
|
|
not need to choose any IRQs. PnP software determines what it thinks
|
|
is best and assigns them (but it's not always best). But if you
|
|
directly use isapnp (ISA bus) or jumpers then you have to choose. If
|
|
you already know what IRQ you want to use you could skip this section
|
|
except that you may want to know that IRQ 0 has a special use (see the
|
|
following paragraph).
|
|
|
|
<sect2> IRQ 0 is not an IRQ
|
|
<p> While IRQ 0 is actually the timer (in hardware) it has a special
|
|
meaning for setting a serial port with setserial. It tells the driver
|
|
that there is no interrupt for the port and the driver then will use
|
|
polling methods. Such polling puts more load on the CPU but can be
|
|
tried if there is an interrupt conflict or mis-set interrupt. The
|
|
advantage of assigning IRQ 0 is that you don't need to know what
|
|
interrupt is set in the hardware. It should be used only as a
|
|
temporary expedient until you are able to find a real interrupt to
|
|
use.
|
|
|
|
<sect2> Interrupt sharing, Kernels 2.2+ <label id="int_share-2.2">
|
|
<p> Sharing of IRQs is where two devices use the same IRQ. As a
|
|
general rule, this wasn't allowed for the ISA bus. The PCI bus may
|
|
share IRQs but one can't share the same IRQ between the ISA and the
|
|
PCI bus. Most multi-port boards may share IRQs. Sharing is not as
|
|
efficient since every time a shared interrupt is given a check must be
|
|
made to determine where it came from. Thus if it's feasible, it's
|
|
nicer to allocate every device its own interrupt.
|
|
|
|
Prior to kernel 2.2, serial IRQs could not be shared with each other
|
|
except for most multiport boards. Starting with kernel 2.2 serial
|
|
IRQs may be sometimes shared between serial ports. In order for
|
|
sharing to work in 2.2 the kernel must have been compiled with
|
|
CONFIG_SERIAL_SHARE_IRQ, and the serial port hardware must support
|
|
sharing (so that if two serial cards put different voltages on the
|
|
same interrupt wire, only the voltage that means "this is an
|
|
interrupt" will prevail). Since the PCI bus specs permit sharing, any
|
|
PCI card should allow sharing.
|
|
|
|
<sect2> What IRQs to choose?
|
|
|
|
<p> The serial hardware often has only a limited number of IRQs. Also
|
|
you don't want IRQ conflicts. So there may not be much of a choice.
|
|
Your PC may normally come with <tt/ttyS0/ and <tt/ttyS2/ at IRQ 4, and
|
|
<tt/ttyS1/ and <tt/ttyS3/ at IRQ 3. Looking at
|
|
<tt>/proc/interrupts</tt> will show which IRQs are being used by
|
|
programs currently running. You likely don't want to use one of
|
|
these. Before IRQ 5 was used for sound cards, it was often used for a
|
|
serial port.
|
|
|
|
Here is how Greg (original author of Serial-HOWTO) set his up in
|
|
/etc/rc.d/rc.serial. rc.serial is a file (shell script) which runs at
|
|
start-up (it may have a different name or location). For versions of
|
|
"setserial" after 2.15 it's not always done this way anymore but this
|
|
example does show the choice of IRQs.
|
|
|
|
<tscreen><verb>
|
|
/sbin/setserial /dev/ttyS0 irq 3 # my serial mouse
|
|
/sbin/setserial /dev/ttyS1 irq 4 # my Wyse dumb terminal
|
|
/sbin/setserial /dev/ttyS2 irq 5 # my Zoom modem
|
|
/sbin/setserial /dev/ttyS3 irq 9 # my USR modem
|
|
</verb></tscreen>
|
|
<p>
|
|
Standard IRQ assignments:
|
|
<verb>
|
|
IRQ 0 Timer channel 0 (May mean "no interrupt". See below.)
|
|
IRQ 1 Keyboard
|
|
IRQ 2 Cascade for controller 2
|
|
IRQ 3 Serial port 2
|
|
IRQ 4 Serial port 1
|
|
IRQ 5 Parallel port 2, Sound card
|
|
IRQ 6 Floppy diskette
|
|
IRQ 7 Parallel port 1
|
|
IRQ 8 Real-time clock
|
|
IRQ 9 Redirected to IRQ2
|
|
IRQ 10 not assigned
|
|
IRQ 11 not assigned
|
|
IRQ 12 not assigned
|
|
IRQ 13 Math co-processor
|
|
IRQ 14 Hard disk controller 1
|
|
IRQ 15 Hard disk controller 2
|
|
</verb>
|
|
<p>
|
|
|
|
There is really no Right Thing to do when choosing interrupts. Try to
|
|
find one that isn't being used by the motherboard, or any other
|
|
boards. 2, 3, 4, 5, 7, 10, 11, 12 or 15 are possible choices. Note
|
|
that IRQ 2 is the same as IRQ 9. You can call it either 2 or 9, the
|
|
serial driver is very understanding. If you have a very old serial
|
|
board it may not be able to use IRQs 8 and above.
|
|
|
|
Make sure you don't use IRQs 1, 6, 8, 13 or 14! These are used by
|
|
your motherboard. You will make her very unhappy by taking her IRQs.
|
|
When you are done you might want to double-check
|
|
<tt>/proc/interrupts</tt> when programs that use interrupts are being
|
|
run and make sure there are no conflicts.
|
|
|
|
<sect1> Choosing Addresses --Video card conflict with ttyS3
|
|
<label id="choose_address">
|
|
<p> Here's a problem with some old serial cards. The IO address of
|
|
the IBM 8514 video board (and others like it) is allegedly 0x?2e8
|
|
where ? is 2, 4, 8, or 9. This may conflict with the IO address of
|
|
<tt/ttyS3/ at 0x02e8. Your may think that this shouldn't happen since
|
|
the addresses are different in the high order digit (the leading 0 in
|
|
02e8). You're right, but a poorly designed serial port may ignore the
|
|
high order digit and respond to any address that ends in 2e8. That is
|
|
bad news if you try to use <tt/ttyS3/ (ISA bus) at this IO address.
|
|
|
|
For the ISA bus you should try to use the default addresses shown
|
|
below. PCI cards use different addresses so as not to conflict with
|
|
ISA addresses. The addresses shown below represent the first address
|
|
of an 8-byte range. For example 3f8 is really the range 3f8-3ff.
|
|
Each serial device (as well as other types of devices that use IO
|
|
addresses) needs its own unique address range. There should be no
|
|
overlaps (conflicts). Here are the default addresses for commonly
|
|
used serial ports on the ISA bus:
|
|
|
|
<tscreen><verb>
|
|
ttyS0 address 0x3f8
|
|
ttyS1 address 0x2f8
|
|
ttyS2 address 0x3e8
|
|
ttyS3 address 0x2e8
|
|
</verb></tscreen>
|
|
|
|
Suppose there is an address conflict (as reported by <tt>setserial -g
|
|
/dev/ttyS*</tt>) between a real serial port and another port which
|
|
does not physically exist (and shows UART: unknown). Such a conflict
|
|
shouldn't cause problems but it sometimes does in older kernels. To
|
|
avoid this problem don't permit such address conflicts or delete
|
|
/dev/ttySx if it doesn't physically exist.
|
|
|
|
<sect1> Set IO Address & IRQ in the hardware (mostly for PnP)
|
|
<label id="io-irq_methods">
|
|
|
|
<p> After it's set in the hardware don't forget to insure that it also
|
|
gets set in the driver by using <tt/setserial/. For non-PnP serial
|
|
ports they are either set in hardware by jumpers or by running a DOS
|
|
program ("jumperless") to set them (it may disable PnP). The rest of
|
|
this subsection is only for PnP serial ports. Here's a list of the
|
|
possible methods of configuring PnP serial ports:
|
|
|
|
<itemize>
|
|
<item> Using a PnP BIOS CMOS setup menu
|
|
(usually only for external
|
|
modems
|
|
on ttyS0 (Com1) and ttyS1 (Com2))
|
|
<item> Letting a PnP BIOS automatically configure a PnP serial port
|
|
See <ref id="bios_conf" name="Using a PnP BIOS to I0-IRQ Configure">
|
|
<item> Doing nothing if the serial driver recognized your card OK
|
|
<item> Using <tt/isapnp/ for a PnP serial port (non-PCI)
|
|
<item> Using setpci (pciutils or pcitools) for the PCI bus
|
|
</itemize>
|
|
|
|
The IO address and IRQ must be set (by PnP) in their registers each
|
|
time the system is powered on since PnP hardware doesn't remember how
|
|
it was set when the power is shut off. A simple way to do this is to
|
|
let a PnP BIOS know that you don't have a PnP OS and the BIOS will
|
|
automatically do this each time you start. This might cause problems
|
|
in Windows (which is a PnP OS) if you start Windows with the BIOS
|
|
thinking that Windows is not a PnP OS. See Plug-and-Play-HOWTO.
|
|
|
|
Plug-and-Play (PnP) was designed to automate this io-irq configuring,
|
|
but for Linux it initially made life much more complicated. In modern
|
|
Linux (2.4 kernels --partially in 2.2 kernels), each device driver has
|
|
to do its own PnP (using supplied software which it may utilize).
|
|
There is unfortunately no centralized planning for assigning IO
|
|
addresses and IRQs as there is in MS Windows. But it usually works
|
|
out OK in Linux anyway.
|
|
|
|
<sect2> Using a PnP BIOS to I0-IRQ Configure <label id="bios_conf">
|
|
<p> While the explanation of how to use setpci 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. This menu may be hard to find. For an "Award"
|
|
BIOS it was found under "chipset features setup" There is often
|
|
little to choose from. For ISA serial ports, the first two ports
|
|
normally get set at the standard IO addresses and IRQs. See <ref
|
|
id="dev_nos" name="More on Serial Port Names">
|
|
|
|
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 Linux is in some
|
|
sense) or if thinks you don't have a PnP OS it may fully configure all
|
|
the PnP devices but not configure the device drivers.
|
|
|
|
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. An indirect way to control what the BIOS does (if you have
|
|
Windows 9x on the same PC) is to "force" a configuration under
|
|
Windows. See Plug-and-Play-HOWTO and search for "forced". It's
|
|
easier to use the CMOS BIOS menu which may override what you
|
|
"forced" under Windows. There could be a BIOS option that can set or
|
|
disable this "override" capability.
|
|
|
|
If you add a new PnP device, the BIOS should PnP configure 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 its setup menus of via messages on the screen when you turn
|
|
on your computer. See <ref id="io-irq_in_hdw" name="What is set in my
|
|
serial port hardware?">. Other ways of finding out is to use lspci for
|
|
the PCI bus or isapnp --dumpregs for the ISA bus. The cryptic results
|
|
it shows you may not be clear to a novice.
|
|
|
|
<sect1> Giving the IRQ and IO Address to Setserial
|
|
<p> Once you've set the IRQ and IO address in the hardware (or arranged
|
|
for it to be done by PnP) you also need to insure that the "setserial"
|
|
command is run each time you start Linux. See the subsection <ref
|
|
id="sets_boot_time" name="Boot-time Configuration">
|
|
<!-- configure.D end-->
|
|
|
|
|
|
<sect> Configuring the Serial Driver (high-level) "stty"
|
|
<label id="config_stty">
|
|
|
|
<sect1> Introduction
|
|
<p>This configuring is normally done by your communications program
|
|
such as wvdial. It may do much of it without even letting you know what
|
|
it's done. In olden days it was done with the "stty" utility. If you
|
|
set something manually with stty, the communications program may
|
|
change the setting to something else so it's usually best to just let
|
|
the communications program handle it. See <ref id="stty_" name="What
|
|
is stty ?">
|
|
|
|
<sect1> Hardware flow control (RTS/CTS)
|
|
<p> See <ref id="flow_control" name="Flow Control"> for an explanation of
|
|
it. You should always use hardware flow control if possible. Your
|
|
communication program or "<tt/getty/" should have an option for
|
|
setting it (and hopefully it's 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 it in a file
|
|
that runs at boot-time. See the subsection <ref id="sets_boot_time"
|
|
name="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:
|
|
|
|
<tscreen><verb>
|
|
stty -F /dev/ttyS2 crtscts
|
|
or
|
|
stty crtscts < /dev/ttyS2
|
|
</verb></tscreen>
|
|
|
|
If you want to see if flow control is enabled do the following: In
|
|
minicom (or the like) type AT&V (or ATI4 on 3Com modems) to see
|
|
how the modem is configured and look for &K3 (or &H1 on 3Com
|
|
modems) which means hardware flow control. Then without exiting the
|
|
communications program (such as minicom) see if the device driver
|
|
knows about it by typing: stty -F /dev/ttyS2 -a. Look for "crtscts"
|
|
(without a disabling minus sign). Remember that communication
|
|
programs change these settings so you may want to check them after you
|
|
have started up your communication program.
|
|
|
|
<sect1> Speed Settings
|
|
<p> Besides flow control there is speed. See <ref id="speed_"
|
|
name="What Speed Should I Use with My Modem">. There's also are
|
|
parity and bits-per-byte settings. Normally the port is set by the
|
|
communications program at 8N1 (8-bits per byte, No parity, and 1 stop
|
|
bit). If you're running PPP then you must use 8N1. So if you get a
|
|
complaint that it's not 8-bit clean then it's likely not 8N1 like it
|
|
should be.
|
|
|
|
<sect1> Ignore CD Setting: clocal
|
|
<p>Normally a CD (Carrier Detect) signal (on the CD wire for an
|
|
external modem) is required before a serial port can be opened. But
|
|
if stty has negated clocal (-clocal), then the port requires CD
|
|
raised for the port to open and remain open. Actually, a skilled
|
|
programmer can write the program in such a way as to force the port to
|
|
open even when CD and clocal say not to. So if stty shows -clocal
|
|
then there might be a problem with opening the port. But for dial-in,
|
|
in some cases you may want -clocal so that when the remote modem stops
|
|
sending a carrier and CD drops, the port will close and terminate all
|
|
processes running on it.
|
|
|
|
One way to keep CD raised is to send "AT&C" to the modem so that
|
|
CD from the modem will always be on. CD always-on is fine for
|
|
dial-out but for dial-in, the CD signal is sometimes (but rarely) used
|
|
to detected an incoming call.
|
|
|
|
clocal may be asserted by default in recent serial drivers. Minicom
|
|
raises clocal automatically when it starts up so there is no problem
|
|
with it opening the port. But it restores the clocal setting to it's
|
|
original when you exit minicom. But version 6.0.192 of Kermit hung
|
|
when I set -clocal and tried to "set line ...".
|
|
|
|
<sect1> What is stty ? <label id="stty_">
|
|
<p> <tt/stty/ is something like setserial but it sets the speed (baud
|
|
rate), hardware flow control, and other parameters of a serial port.
|
|
Typing "stty -F /dev/ttyS2 -a" should show you how ttyS2 is
|
|
configured. Most of the stty settings are for things that you never
|
|
need to use with modems. Many of the setting are only needed for
|
|
Text-Terminals (and some are only needed for antique terminals of the
|
|
1970s). Your communication package should automatically set up the
|
|
several settings needed for modems. For this reason you normally don't
|
|
need to use stty so it's not covered much in this Modem-HOWTO. But
|
|
stty is sometimes useful for trouble-shooting. More is said about
|
|
stty in the Serial-HOWTO or Text-Terminal-HOWTO..
|
|
|
|
<sect> Modem Configuration (excluding serial port) <label id="modem_conf">
|
|
|
|
<sect1> Finding Your Modem
|
|
<p> Before spending a lot of time deciding how to configure your
|
|
modem, you first need to make sure it can be found and that
|
|
AT-commands and the like can be sent to it. So I suggest you first
|
|
give it a very simple configuration using the communication program
|
|
you will be using on the port and see it it works. If this works you
|
|
may then want to improve on the configuration, If not then see <ref
|
|
id="cant_find_modem" name="My Modem is Physically There but Can't be
|
|
Found">. A winmodem may be hard to find and will not work under
|
|
Linux.
|
|
|
|
<sect1> AT Commands
|
|
<p> 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 must be prefaced by the letters AT.
|
|
AT means: ATtention, expect a command to follow. For example:
|
|
ATZ&K3<return> This is an AT-command string with two
|
|
commands here: Z and &K3. Z is short for Z0 and a few modems
|
|
require that you use Z0 instead of just Z. It's like this for other
|
|
commands ending in 0. The command string is terminated by a return
|
|
character (use the <enter> key if you are manually typing it). A
|
|
string that's too long (40 or more characters) may not work on older
|
|
modems. You may use either uppercase or lowercase letters.
|
|
|
|
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.
|
|
|
|
Such command strings are either automatically sent to the modem by
|
|
communication programs or are manually typed in by you. Most
|
|
communication programs provide a screen where you may change (edit)
|
|
and save the init string that the communication program will use.
|
|
The modem itself has a stored configuration (profile) which is like a
|
|
long init string. It represents the configuration of the modem when
|
|
it's first tuned on. You may change it to suit your taste. In most
|
|
cases there are a few different such configurations (profiles) and
|
|
there are ways to designate one of them to be active.
|
|
|
|
If you have a manual for your modem (either on paper or on floppy
|
|
disk) you might find AT-commands there. 3Com modems (and others ??)
|
|
have AT-Command help files built into the modem so if you type say
|
|
"AT$" to the modem it will display some "online help".
|
|
|
|
You can also find info on AT commands on the Internet. You should
|
|
first try a site for your modem manufacturer. If this doesn't work
|
|
out then you can search the Internet using terms that are from AT
|
|
commands such as &C1, &D3, etc. This will tend to find sites
|
|
that actually list AT-Commands instead of sites that just talk about
|
|
them in general. You might also try a few of the sites listed in the
|
|
subsection <ref id="web_sites" name="Web Sites">. Be warned that the
|
|
AT-commands for a different brand of modem may be somewhat different.
|
|
|
|
<sect1> Init Strings: Saving and Recalling <label id="init_str">
|
|
<p> 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^M (^M is the return character).
|
|
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 the stored
|
|
configuration 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 communication program does this. What it
|
|
sends will depend on how you configured the communications program.
|
|
Your communication program should allow you to 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.
|
|
|
|
The configuration of the modem when it's first powered on may be
|
|
expressed by an init string. You might think of this as the default
|
|
"string" (called a profile). If your communications program sends the
|
|
modem another string (the init string), then this string will modify
|
|
the default configuration. For example, if the init string only
|
|
contains two commands, then only those two items will be changed.
|
|
However, some commands will recall a stored profile from inside the
|
|
modem so a single such command in the init string can thereby change
|
|
everything in the configuration.
|
|
|
|
Modern modems have a few different stored profiles to choose from that
|
|
are 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 you can change) and two user defined profiles (0
|
|
and 1) that the user may set and store. Your modem may have more. To
|
|
view some of these profiles send the command &V. At power-up one
|
|
of the user-defined profiles is loaded. For example, if you type the
|
|
command &Y0 (just Y0 for a 3Com modem) then in the future profile
|
|
0 will be used at power-on.
|
|
|
|
There are also commands to load (activate) any of the stored profiles.
|
|
Such a load command may be put in an init string. Of course if it
|
|
loads the same profile that was automatically loaded at power-up,
|
|
nothing is changed (unless the active profile has been modified since
|
|
power-up). Since your profile could have thus been modified it's a
|
|
good idea to use some kind of an init string even if it does nothing
|
|
more than load a stored profile.
|
|
|
|
Examples of loading saved profiles:<newline>
|
|
Z0 loads user-defined profile 0 and resets (hangs up, etc.)<newline>
|
|
&F1 loads factory profile 1
|
|
|
|
Once you have sent commands to the modem to configure it the way you
|
|
want (such as loading a factory profile and modifying it a little)
|
|
you may save this as a user-defined profile:<newline>
|
|
&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 by &F1
|
|
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. Since there is no
|
|
way to modify the factory default this prevents anyone from changing
|
|
the configuration by modifying (and saving) the user-defined profile.
|
|
|
|
You may choose 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 that someone else wrote,
|
|
but modify it to suit your purposes.
|
|
|
|
If you look at init strings used by communication programs you may see
|
|
symbols which are not valid modem commands. These symbols are
|
|
commands to the communication program itself and will not be sent to
|
|
the modem. For example, &tilde may mean to pause briefly.
|
|
|
|
<sect2> Where is my "init string" so I can modify it ?
|
|
<p> This depends on your communication program (often a PPP program).
|
|
If this is the latest version of Modem-HOWTO send me info for other
|
|
cases.
|
|
<itemize>
|
|
<item> Gnome: run pppsetup
|
|
<item> wvdial: edit /etc/wvdial.conf
|
|
<item> minicom: hit ^Ao (or possibly ALT-o), then select "Modem and
|
|
Dialing"
|
|
</itemize>
|
|
|
|
<sect1>Other AT Modem Commands <label id="modem_commands">
|
|
<p> For dial-in see <ref
|
|
id="dial-in_conf" name="Dial-in Modem Configuration">. The rest of
|
|
this section is mostly 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).
|
|
|
|
<itemize>
|
|
<item>E1 command echo ON
|
|
<item>Q0 result codes are reported
|
|
<item>V1 result codes are verbose
|
|
<item>S0=0 never answer (uugetty does this with the WAITFOR option)
|
|
</itemize>
|
|
|
|
Here's some more AT commands for special purposes:
|
|
<itemize>
|
|
<item>&C1 CD is only on when you're connected
|
|
<item>&S0 DSR is always on
|
|
<item>X3 Dial even if there is no dialtone (Blind dial. Use where
|
|
dial-tones don't exist).
|
|
</itemize>
|
|
|
|
<p> Note: to get his old USR Courier V.34 modem to reset correctly
|
|
when DTR drops, Greg Hankins had to set <tt/&D2/ and <tt/S13=1/
|
|
(this sets bit 0 of register S13). This has been confirmed to work on
|
|
USR Sportster V.34 modems as well.
|
|
|
|
<p> Note: some old Supra modems treat CD differently than other
|
|
modems. If you are using a Supra, try setting <tt/&C0/ and
|
|
<em/not/ <tt/&C1/. You must also set <tt/&D2/ to handle DTR
|
|
correctly.
|
|
|
|
<sect1> Blacklisting
|
|
<p>If phone number is dialed a few times with no success, some
|
|
modems may blacklist a phone number. After a certain time you may try
|
|
again. Some countries require this to reduce needless repeated
|
|
dialing. To view the blacklist try %B. To delete the blacklist use
|
|
these AT commands:
|
|
<itemize>
|
|
<item> SR Robotics o 3COM: s40=2 or if NG try s40=7
|
|
<item> Lucent: %t21,18,0
|
|
<item> Rockwell: %tcb
|
|
<item> Cirrus Logic: *nc9
|
|
</itemize>
|
|
|
|
<sect1> What AT Commands are Now Set in my Modem?
|
|
<p> You may try to use minicom for viewing your modem profile. It's
|
|
best not to have any other process running on the modem port when you
|
|
do this. If you have set up minicom for your modem, then you may type
|
|
on the command line: <tt>minicom -o</tt> to start minicom without
|
|
restoring the saved modem profile. Then type <tt>at&v</tt> (or
|
|
atI4 on 3Com modems) to display the profile. To exit minicom without
|
|
disturbing this profile, use the q (quit) command for exiting without
|
|
resetting.
|
|
|
|
The above may not work for various reasons. If the modem has been set
|
|
not to echo result codes it may not even display any profile. If there
|
|
is another process running on the modem port at the same time, some of
|
|
what the modem sends to you is likely to be read by the other process
|
|
so you will see only part of the profile. Is there some way to
|
|
temporarily stop the other process on the port so it will not
|
|
interfere? I tried the "stop" signal using the "kill" command but it
|
|
didn't work. If this is the latest version of this HOWTO, let me know
|
|
if you find a way to do it.
|
|
|
|
If you have at least one process running on the modem port and kill
|
|
them, the modem's profile may be reset so you will not observe
|
|
what the original profile was. This will happen if you kill getty (or
|
|
it's replacements: login or bash) and have &D3 set. The killing
|
|
of getty (or the like) will drop DTR and reset the modem's profile to
|
|
the power-on state. To keep getty from respawning when killed, comment
|
|
it out in /etc/inittab and do an "init q".
|
|
|
|
<sect1> Modem States (or Modes)
|
|
<p> Since the channel for sending AT commands to the modem is the same
|
|
channel that is used for the flow of data (files, packets, etc.) then
|
|
it's important to cleanly separate the AT commands from the data.
|
|
|
|
When the modem is first turned on it's in the command mode (also
|
|
called terminal mode, idle state or AT-command mode). Anything sent
|
|
to it from the PC is assumed to be an AT command and not data. Then
|
|
if a dial command is sent to it (ATD...), it dials and connects to
|
|
another modem. It's now in the on-line data mode (connected) and
|
|
sends and receives data (such as Internet pages). In this mode, any
|
|
AT command one trys to send it will not work but will be transmitted
|
|
to the other modem instead. Except for the escape command. This is
|
|
+++ with a minimum time delay both at the start and end. The time
|
|
delay allows the modem to determine that it is likely a real escape
|
|
and not just +++ in a file being transmitted.
|
|
|
|
So we have two states so far: AT-command and on-line data. But there
|
|
is a third important state which is sort of a combination of these
|
|
two. It's the on-line command mode. This is when the modem maintains
|
|
a connection (without sending/receiving data) but anything sent from
|
|
the PC is interpreted as an AT command. This is the state reached
|
|
with a +++ escape signal or by a DTR drop from the PC provided the
|
|
&D1 has been set. Then one can send AT commands to the modem
|
|
including commands which will leave this state and go to one of the
|
|
other two states.
|
|
|
|
There are other states also: dialing state and handshaking state but
|
|
they normally lead to the connected (on-line) state. If they don't
|
|
then the modem should hang up, thereby returning to the initial
|
|
AT-command (or idle) state.
|
|
|
|
<sect> Serial Port Devices /dev/ttyS4, (or /dev/ttys/4) etc.
|
|
<label id="ttySN_">
|
|
<!-- dev_names.D begin
|
|
in Modem and Serial HOWTOs
|
|
Nov. 2003: rewrite
|
|
May 2003: PCI uses higher numbers
|
|
Nov. 2004: All-PCI slot motherboards may not use PCI serial ports
|
|
Apr. 2006: ttyS2 may be used on PCI cards instead of ttyS4 or ttyS14.
|
|
Aug. 2006: udev uses old names
|
|
Dec. 2006: cleaned up on above
|
|
<sect> Serial Port Devices /dev/ttyS2, etc. -->
|
|
|
|
<sect1>Serial Port Names: ttyS4, etc
|
|
<p>Once upon a time the names of the serial ports were simple. Except
|
|
for some multiport serial cards they were named /dev/ttyS0,
|
|
/dev/ttyS1, etc. Then around the year 2000 came the USB bus with
|
|
names like /dev/ttyUSB0 and /dev/ttyACM1 (for the ACM modem on the USB
|
|
bus).
|
|
|
|
<sect1>The PCI Bus
|
|
<p>Since DOS provided for 4 serial ports on the old ISA bus:
|
|
COM1-COM4, ttyS0-ttyS3 most serial ports on the newer PCI bus used
|
|
higher numbers such as ttyS4 or ttyS14 (prior to kernel 2.6.13). But
|
|
since most PCs only came with one or two serial ports, ttyS0 and
|
|
possibly ttyS1 (for the second port) the PCI bus now may use ttyS2
|
|
(kernel 2.6.15 on). All this permits one to have both ISA serial ports
|
|
and PCI serial ports on the same PC with no name conflicts. 0-1 (or
|
|
0-3) are reserved for the old ISA bus (or the newer LPC bus) and
|
|
2-upward (or 4-upward or 14-upward) are used for PCI. It's not
|
|
required to be this way but it often is. On-board serial ports on
|
|
motherboards which have both PCI and ISA slots are likely to still be
|
|
ISA ports. Even for all-PCI-slot motherboards, the serial ports are
|
|
often not PCI. Instead, they are either ISA, on an internal ISA bus
|
|
or on a LPC bus which is intended for slow legacy I/O devices:
|
|
serial/parallel ports and floppy drives.
|
|
|
|
|
|
<sect1>Serial Port Device Names & Numbers
|
|
<p>Devices in Linux have major and minor numbers. The serial port
|
|
ttySx (x=0,1,2, etc.) is major number 4. You can see this (and the
|
|
minor numbers too) by typing: "ls -l ttyS*" in the /dev directory. To
|
|
find the device names for various devices, see the "devices" file in
|
|
the kernel documentation.
|
|
|
|
There formerly was a "cua" name for each serial port and it behaved
|
|
just a little differently. For example, ttyS2 would correspond to
|
|
cua2. It was mainly used for modems. The cua major number was 5 and
|
|
minor numbers started at 64. You may still have the cua devices in
|
|
your /dev directory but they are now deprecated. For details see
|
|
Modem-HOWTO, section: cua Device Obsolete.
|
|
|
|
For creating the old devices in the device directory see:
|
|
the Serial-HOWTO: "Creating Devices In the /dev directory".
|
|
|
|
|
|
<sect1>More on Serial Port Names <label id="dev_nos">
|
|
<p>Dos/Windows use the COM name while the messages from the serial driver
|
|
use ttyS00, ttyS01, etc. Older serial drivers (2001 ?) used just
|
|
tty00, tty01, etc.
|
|
|
|
<p>The tables below shows some examples of serial device names. The
|
|
IO addresses are the default addresses for the old ISA bus (not for
|
|
the newer PCI and USB buses).
|
|
|
|
<tscreen><verb>
|
|
dos common IO USB-BUS ( ACM => acm modem )
|
|
name name major minor address || common name common name
|
|
COM1 /dev/ttyS0 4, 64; 3F8 || /dev/ttyUSB0 | /dev/ttyACM0
|
|
COM2 /dev/ttyS1 4, 65; 2F8 || /dev/ttyUSB1 | /dev/ttyACM1
|
|
COM3 /dev/ttyS2 4, 66; 3E8 || /dev/ttyUSB2 | /dev/ttyACM2
|
|
COM4 /dev/ttyS3 4, 67; 2E8 || /dev/ttyUSB3 | /dev/ttyACM3
|
|
- /dev/ttyS4 4, 68; various
|
|
</verb></tscreen>
|
|
|
|
<sect1> USB (Universal Serial Bus) Serial Ports
|
|
<p> For more info see the usb subdirectory in the kernel documentation
|
|
directory for files: usb-serial, acm, etc.
|
|
|
|
<sect1> Link ttySN to /dev/modem
|
|
<p> On some installations, two extra devices will be created,
|
|
<tt>/dev/modem</tt> for your modem and <tt>/dev/mouse</tt> for a
|
|
mouse. Both of these are symbolic links to the appropriate
|
|
device in <tt>/dev</tt>.
|
|
|
|
Historical note: Formerly (in the 1990s) the use of
|
|
<tt>/dev/modem</tt> (as a link to the modem's serial port) was
|
|
discouraged since lock files might not realize that it was really say
|
|
<tt>/dev/ttyS2</tt>. The newer lock file system doesn't fall into
|
|
this trap so it's now OK to use such links.
|
|
|
|
<sect1>Devfs (The Improved but Obsolete Device File System)
|
|
|
|
<p>Kernel 2.4 introduced the now obsolete optional "device file system"
|
|
(devfs) with a whole new set of names for everything. But in 2003-4,
|
|
it was claimed that devfs had unsolvable problems and starting with
|
|
kernel 2.6.12 it was replaced with "udev" (kernels prior to 2.6.12
|
|
also could use udev but with some problems). Although udev doesn't
|
|
provide all the functionality of devfs, it does handle hot plugging.
|
|
Also, the use of udev isn't required to run Linux so some people don't
|
|
use it. But many distributions install it by default.
|
|
|
|
Devfs was a good idea and was claimed to be more efficient than udev.
|
|
But unfortunately, the author of devfs didn't maintain it for long and
|
|
it allegedly became not too well maintained. So for better or worse
|
|
we now have udev instead although the debate of devfs vs. udev still
|
|
continues. For a detailed description of devfs see: <url
|
|
url="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html"> Also see
|
|
the kernel documentation tree: filesystems/devfs.
|
|
|
|
The names of devices for the devfs can be used in udev, but usually
|
|
are not and may not be simple to activate. Here's the devfs names for
|
|
serial devices: ttyS1 becomes tts/1, ttyUSB1 becomes /usb/tts/1, and
|
|
ttyACM1 is /usb/acm/1. Note that the number 1 above is just an
|
|
example. It could be replaced by 0, 2, 3, 4, etc. Some more examples
|
|
of udev names: ttyS2 becomes tts/2 (Serial port), tty3 becomes vc/3
|
|
(Virtual Console), ptyp1 becomes pty/m1 (PTY master), ttyp2 becomes
|
|
pty/s2 (PTY slave). "tts" looks like a directory which contains
|
|
devices "files": 0, 1, 2, etc. All of these new names should still be
|
|
in the /dev directory although optionally one may put them elsewhere.
|
|
|
|
For devfs device names in the /dev directory are created automatically
|
|
by the corresponding driver. Thus, if serial support comes from a
|
|
module and that module isn't loaded yet, there will not be any serial
|
|
devices in the /dev directory. This can be confusing: you physically
|
|
have serial ports but don't see them in the /dev directory. However,
|
|
if a device name is told to a communication program and the serial
|
|
module isn't loaded, the kernel is supposed to try to find a driver
|
|
for it and create a name for it in the /dev directory.
|
|
|
|
This works OK if it finds a driver. But suppose there is no driver
|
|
found for it. For example, if you try to use "setserial" to configure
|
|
a port that the driver failed to detect, it claims there is no such
|
|
port. How does one create a devfs port in this case?
|
|
|
|
For multiport devices for example, /dev/ttyF9 becomes /dev/ttf/9, or
|
|
in a later version /dev/tts/F9. Substitute for F (or f) whatever
|
|
letter(s) your multiport board uses for this purpose. A multiport
|
|
driver is supposed to create a devfs name similar to the above and put
|
|
it into the /dev directory
|
|
|
|
<!-- dev_names.D end -->
|
|
|
|
|
|
<sect1> cua Device Obsolete <label id="cua_dev">
|
|
<p> Each ttyS device has a corresponding cua device. But the cua
|
|
device is deprecated so it's best to use ttyS (unless cua is
|
|
required). There is a difference between cua and ttyS but a savvy
|
|
programmer can make a ttyS port behave just like a cua port so there
|
|
is no real need for the cua anymore. Except that some older programs
|
|
may need to use the cua.
|
|
|
|
What's the difference? The main difference between cua and ttyS has
|
|
to do with what happens in a C-program when an ordinary "open" command
|
|
tries to open the port. If a cua port has been set to check modem
|
|
control signals, the port can be opened even if the CD modem control
|
|
signal says not to. Astute programming (by adding additional lines to
|
|
the program) can force a ttyS port to behave this way also. But a cua
|
|
port can be more easily programmed to open for dialing out on a modem
|
|
even when the modem fails to raise CD (since no one has called into
|
|
it and there's no carrier). That's why cua was once used for dial-out
|
|
and ttyS used for dial-in.
|
|
|
|
Starting with Linux kernel 2.2, a warning message is put in the
|
|
kernel log when one uses cua. This is an omen that cua is defunct and
|
|
should be avoided if possible.
|
|
|
|
<sect>Interesting Programs You Should Know About
|
|
|
|
<sect1>What is setserial ? <label id="set_serial">
|
|
<!-- setserial.D begin (in MM TT SS)
|
|
<sect1>What is Setserial ? <label id="set_serial">
|
|
Change Log:
|
|
May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
|
|
Nov. 2000: auto_irq may work on the 2nd try
|
|
Dec. 2000: saving state of serial module
|
|
June 2001 OK to use setserial with Laptops
|
|
Nov. 2002 Debian's /var/lib/serial.conf
|
|
Nov. 2003 Major revision. Plug-and-play dominates
|
|
May 2004 Old Debian 1999 bug reported by me removed (fixed in 1999)
|
|
Feb.2005 Where config files reside
|
|
/var/lib/setserial/autoserial.conf
|
|
-->
|
|
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
|
|
are some minor differences, depending on which HOWTO it appears in.
|
|
|
|
<sect2>Setserial problems with linmodems, laptops
|
|
<p> The setserial program doesn't seem to work if the serial port is for
|
|
a linmodem such as ttySHCF0.
|
|
If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
|
|
read <ref id="laptops_" name="Laptops: PCMCIA">.
|
|
|
|
<sect2> Introduction
|
|
<p><tt/setserial/ is a program used for the user to communicate with
|
|
the serial device driver. You normally never need to use it, provided
|
|
that you only use the one or two serial ports that come as standard
|
|
equipment with a PC. Even in other cases, most extra serial ports
|
|
should be auto-detected by modern kernels. Except you'll need to use
|
|
setserial if you have an old ISA serial port set by jumpers on the
|
|
physical hardware or if your kernel (such as 2.2 or older) doesn't
|
|
both detect and set your add-on PCI serial ports.
|
|
|
|
<tt/setserial/ allows you (or a shell script) to talk to the serial
|
|
software. But there's also another program, tt/stty/, that also deals
|
|
with the serial port and is used for setting the port speed, etc.
|
|
|
|
<tt/setserial/ deals with the lower-level configuring of the serial
|
|
port, such as dealing with IRQs (such as 5), port addresses (such as
|
|
3f8), and the like. A major problem with it is that it can't
|
|
set or configure the serial port hardware: It can't set the IRQ or
|
|
port addresses into the hardware. Furthermore, when it seemingly
|
|
reports the configuration of the hardware, it's sometimes wrong since
|
|
it doesn't actually probe the hardware unless you specifically tell it
|
|
to. Even then, it doesn't do the modern type of bus probing and some
|
|
hardware may never be found by it. Still, what it shows is right most
|
|
all the time but if you're having trouble getting a serial port to
|
|
work, then there's a fair chance it's wrong.
|
|
|
|
In olden days, when the IRQ and port address was set by jumpers on the
|
|
serial card, one would use <tt/setserial/ to tell the driver how these
|
|
jumpers were set. Today, when plug-and-play methods detect how the
|
|
jumperless serial port is set, <tt/setserial/ is not really needed
|
|
anymore unless you're having problems or using old hardware.
|
|
Furthermore, if the configuration file used by <tt/setserial/ is
|
|
wrong, then there's trouble. In this case, if you use <tt/setserial/
|
|
to try to find out how the port is configured, it may just repeat the
|
|
incorrect information in the configuration file.
|
|
|
|
<tt/setserial/ can sometimes be of help to find a serial port. But
|
|
it's only of use if you know the port address and use the right
|
|
options. For modern ports, there's usually better ways to look for
|
|
them by plug-and-play methods.
|
|
|
|
Thus the name <tt/setserial/ is somewhat of a misnomer since it
|
|
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
|
|
them in the driver software. And the driver naively believes that
|
|
what <tt/setserial/ tells it, even if it conflicts with what the driver
|
|
has found by using plug-and-play methods. Too bad that it fails to
|
|
at least issue a warning message for such a conflict. Since the
|
|
device driver is considered to be part of the kernel, the word
|
|
"kernel" is often used in other documentation with no mention made of
|
|
any "serial driver".
|
|
|
|
Some distributions (and versions) set things up so that <tt/setserial/
|
|
is run at boot-time by an initialization shell script (in the
|
|
/etc directory tree). But the configuration file which this script
|
|
uses may be either in the /etc tree or the /var tree. In some cases,
|
|
if you want <tt/setserial/ to run at boot-time, you may have to take
|
|
some action. <tt/setserial/will not work without either serial
|
|
support built into the kernel or loaded as a module. The module may
|
|
get loaded automatically if you (or a script) attempt to use
|
|
<tt/setserial/.
|
|
|
|
While <tt/setserial/ can be made to probe the hardware I0 port
|
|
addresses to try to determine the UART type and IRQ, this has
|
|
severe limitations. See <ref id="probing_ss" name="Probing">. It
|
|
can't set the IRQ or the port address in the hardware of PnP or PCI
|
|
serial ports (but the plug-and-play features of the serial driver may
|
|
do this). It also can't directly read the PnP data stored in
|
|
configuration registers in the hardware. But since the device driver
|
|
can read these registers and setserial tells you what the device
|
|
driver thinks, it might be correct. Or it could be telling you what
|
|
<tt/setserial/ had previously (and perhaps erroneously) told the
|
|
driver. There's no way to know for sure without doing some other
|
|
checks.
|
|
|
|
The serial driver (for Linux Kernel 2.4+) looks for a few "standard"
|
|
legacy serial ports, for PnP ports on the ISA bus, and for all
|
|
supported port hardware on the PCI bus. If it finds your ports
|
|
correctly, then there's no need to use <tt/setserial/. The driver
|
|
doesn't probe for legacy IRQs and may get these wrong and it may miss
|
|
old ISA serial ports set with jumpers on the card.
|
|
|
|
Besides the man page for <tt/setserial/, check out info in
|
|
<tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>.
|
|
This should tell you how setserial is handled for your distribution of
|
|
Linux. While <tt/setserial/ behaves the same in all distributions,
|
|
the scripts for running it, how to configure such scripts (including
|
|
automatic configuration), and the names and locations of the script
|
|
files, etc., are all distribution-dependent.
|
|
|
|
<sect2>Serial module unload
|
|
<p>If a serial module gets unloaded, the changes previously made by
|
|
<tt/setserial/ will be forgotten by the driver. But while the driver
|
|
forgets it, a script provided by the distribution may save it in a
|
|
file somewhere so that it can the restored if the module is reloaded.
|
|
|
|
|
|
|
|
<sect2>Giving the <tt/setserial/ command
|
|
<p>Remember, that <tt/setserial/ can't set any I/O addresses or IRQs
|
|
in the hardware. That's done either by plug-and-play software (run by
|
|
the driver) or by jumpers for legacy serial ports. Even if you give
|
|
an I/O address or IRQ to the driver via <tt/setserial/ it will not set
|
|
such values and assumes that they have already been set. If you give
|
|
it wrong values, the serial port will not work right (if at all).
|
|
|
|
For legacy ports, if you know the I/O address but don't know the IRQ
|
|
you may command setserial to attempt to determine the IRQ.
|
|
|
|
You can see a list of possible commands by just typing <tt/setserial/
|
|
with no arguments. This fails to show you the one-letter options such
|
|
as -v for verbose which you should normally use when troubleshooting.
|
|
Note that setserial calls an IO address a "port". If you type:
|
|
<tscreen><verb>
|
|
setserial -g /dev/ttyS*
|
|
</verb></tscreen>
|
|
You'll see some info about how the device driver is configured for
|
|
your ports. In many cases you'll see some ports displayed with what
|
|
appears at first glance to be erroneous IRQs and addresses. But if
|
|
you also see: <tt>"UART: unknown"</tt> just ignore the entire line
|
|
since no serial port exists at that address.
|
|
|
|
If you add -a to the option -g you will see more info although few
|
|
people need to deal with (or understand) this additional info since
|
|
the default settings you see usually work fine. In normal cases the
|
|
hardware is set up the same way as "setserial" reports. But if you are
|
|
having problems there is a good chance that <tt/setserial/ has it wrong.
|
|
In fact, you can run "setserial" and assign a purely fictitious I/O
|
|
port 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 you've supplied to the driver. They will also be officially
|
|
registered with the kernel as displayed (at the top of the screen) by
|
|
the "scanport" command (Debian). Of course the serial
|
|
port driver will not work correctly (if at all) if you attempt to use
|
|
such a port. Thus, when giving parameters to <tt/setserial/, "anything
|
|
goes". Well almost. If you assign one port a base address that is
|
|
already assigned (such as 3e8) it may not accept it. But if you use
|
|
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
|
|
is within the range starting at base address 3e8. Thus the moral of
|
|
the story is to make sure your data is correct before assigning
|
|
resources with setserial.
|
|
|
|
<sect2>Configuration file
|
|
<p>While assignments made by setserial are lost when the PC is powered
|
|
off, a configuration file may restore them when the PC is started
|
|
up again. In newer versions, what you change by setserial might get
|
|
automatically saved to a configuration file. When <tt/setserial/ runs
|
|
it uses the info from the configuration file.
|
|
|
|
Where this configuration file resides depends on your distribution.
|
|
Look at the start-up scripts somewhere in the /etc/ tree (such as
|
|
/etc/init.d/ or /etc/rc.d/) and read the startup script for "serial"
|
|
or "setserial" or the like. It should show where the configuration
|
|
file(s) reside. In Debian there are 4 options for use of this
|
|
configuration file:
|
|
|
|
<enum>
|
|
<item>Don't use this file at all. At each boot, the serial driver
|
|
alone detects the ports and setserial doesn't ever run. ("kernel" option)
|
|
<item>Save what <tt/setserial/ reports when the system is first
|
|
shutdown and put it in the configuration file. After that, don't ever
|
|
make any changes to the configuration file, even if someone has made
|
|
changes by running the <tt/setserial/ command on the command line and
|
|
then shuts down the system. ("autosave-once" option)
|
|
<item>At every shutdown, save whatever <tt/setserial/ detects to the
|
|
configuration file. ("autosave" option)
|
|
<item>Manually edit the configuration file to set the configuration.
|
|
Don't ever do any automatic saves to it. ("manual" option)
|
|
</enum>
|
|
|
|
In olden days (perhaps before 2000), there wasn't any configuration
|
|
file and the configuration was manually set (hard coded) inside the
|
|
shell script that ran <tt/setserial/. See <ref id="old_sets_script"
|
|
name="Edit a script (prior to version 2.15)">.
|
|
|
|
<sect2> Probing <label id="probing_ss">
|
|
<p>You probe for a port with <tt/setserial/ only when you suspect that
|
|
it has been enabled (by PnP methods, the BIOS, jumpers, etc.).
|
|
Otherwise <tt/setserial/ probing will never find it since its address
|
|
doesn't exist. A problem is where the software looks for a port at
|
|
specified I/O addresses. Prior to probing with "setserial", one may
|
|
run the "scanport" (Debian) command to check all possible ports in one
|
|
scan. It makes crude guesses as to what is on some ports but doesn't
|
|
determine the IRQ. It's a fast first start. It may hang your PC but
|
|
so far it's worked fine for me. Note that non-Debian distributions
|
|
don't seem to supply "scanport". Is there another scan program?
|
|
|
|
With appropriate options, <tt/setserial/ can probe (at a given I/O
|
|
address) for a serial port but you must guess the I/O address. If you
|
|
ask it to probe for /dev/ttyS2 for example, it will only probe at the
|
|
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
|
|
is at a different address, then it will probe at that address, etc.
|
|
See <ref id="probing_ss" name="Probing">
|
|
|
|
The purpose of such probing is to see if there is a uart there, and if
|
|
so, what its IRQ is. Use <tt/setserial/ mainly as a last resort as
|
|
there are faster ways to attempt it such as wvdialconf to detect
|
|
modems, looking at very early boot-time messages, or using <tt>pnpdump
|
|
--dumpregs</tt>, or lspci -vv. But if you want to detect hardware
|
|
with <tt/setserial/ use for example :<newline> <tt>setserial
|
|
/dev/ttyS2 -v autoconfig</tt><newline>
|
|
If the resulting message shows a uart type such as 16550A, then you're
|
|
OK. If instead it shows "<tt/unknown/" for the uart type, then there
|
|
is supposedly no serial port at all at that I/O address. Some cheap
|
|
serial ports don't identify themselves correctly so if you see
|
|
"<tt/unknown/" you still might have a serial port there.
|
|
|
|
Besides auto-probing for a uart type, setserial can auto-probe for
|
|
IRQ's but this doesn't always work right either. In one case it first
|
|
gave the wrong irq but when the command was repeated it found the
|
|
correct irq. In versions of setserial >= 2.15, the results of your
|
|
last probe test could be automatically saved and put into a
|
|
distribution-specific configuration file such as
|
|
<tt>/etc/serial.conf</tt> or <tt>/etc/sysconfig/serial</tt> or
|
|
<tt>/var/lib/setserial/autoserial.conf</tt> for Debian. This will be
|
|
used next time you start Linux.
|
|
|
|
It may be that two serial ports both have the same IO address set in
|
|
the hardware. Of course this is not normally permitted for the ISA
|
|
bus but it sometimes happens anyway. Probing detects one serial port
|
|
when actually there are two. However if they have different IRQs,
|
|
then the probe for IRQs may show IRQ = 0. For me, it only did this if
|
|
I first used <tt/setserial/ to give the IRQ a fictitious value.
|
|
|
|
<sect2>Boot-time Configuration <label id="sets_boot_time">
|
|
<p>While <tt/setserial/ may run via an initialization script,
|
|
something akin to <tt/setserial/ also runs earlier when the serial
|
|
module is loaded (or when the kernel starts the built-in serial driver
|
|
if it was compiled into the kernel). Thus when you watch the start-up
|
|
messages on the screen it may look like it ran twice, and in fact it
|
|
has.
|
|
|
|
If the first message is for a legacy port, the IRQs shown may be wrong
|
|
since it didn't probe for IRQs. If there is a second report of serial
|
|
ports, it may the result of a script such as /etc/init.d/setserial.
|
|
It usually does no probing and thus could be wrong about how the
|
|
hardware is actually set. It only shows configuration data that got
|
|
saved in a configuration files. The old method, prior to setserial
|
|
2.15, was to manually write such data directly into the script.
|
|
|
|
When the kernel loads the serial module (or if the "module equivalent"
|
|
is built into the kernel) then all supported PnP ports are detected.
|
|
For legacy (non-PnP) ports, only <tt/ttyS{0-3}/ are auto-detected
|
|
and the driver is set to use only IRQs 4 and 3 (regardless of what
|
|
IRQs are actually set in the hardware). No probing is done for IRQs
|
|
but it's possible to do this manually. You see this as a boot-time
|
|
message just as if <tt/setserial/ had been run.
|
|
|
|
To correct possible errors in IRQs (or for other
|
|
reasons) there may be a script file somewhere that runs
|
|
<tt/setserial/. Unfortunately, if this file has some IRQs wrong, the
|
|
kernel will still have incorrect info about the IRQs. This file is
|
|
usually part of the initialization done at boot-time. Whether it
|
|
runs or not depends on how you (and/or your distribution) have set
|
|
things up. It may also depends on the runlevel.
|
|
|
|
Before modifying a configuration file, you can test out a "proposed"
|
|
<tt/setserial/ command by just typing it on the command line. In some
|
|
cases the results of this use of <tt/setserial/ will automatically get
|
|
saved somewhere such as /etc/serial.conf (or autoserial.conf or
|
|
serial) when you shutdown. So if it worked OK (and solved your
|
|
problem) then there's no need to modify any configuration file. See
|
|
<ref id="config_file" name="Configuration method using
|
|
/etc/serial.conf, etc.">.
|
|
|
|
<sect2> Edit a script (required prior to version 2.15)
|
|
<label id="old_sets_script">
|
|
<p> This is how it was done prior to <tt/setserial/ 2.15 (1999)
|
|
The objective was to modify (or create) a script file in the /etc
|
|
tree that runs setserial at boot-time. Most distributions provided
|
|
such a file (but it may not have initially resided in the /etc tree).
|
|
|
|
So prior to version 2.15 (1999) it was simpler. All you did was edit
|
|
a script. There was no /etc/serial.conf file (or the like) to
|
|
configure setserial. Thus you needed to find the file that runs
|
|
"setserial" at boot time and edit it. If it didn't exist, you needed
|
|
to create one (or place the commands in a file that ran early at
|
|
boot-time). If such a file was currently being used it's likely
|
|
was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
|
|
in /usr/doc/setserial/ but you need to move it to the /etc tree before
|
|
using it.
|
|
|
|
The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past.
|
|
The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>.
|
|
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's may
|
|
not have run early enough. It was reported that other processes may
|
|
try to open the serial port before rc.local ran resulting in serial
|
|
communication failure. Later on it most likely was found in
|
|
/etc/init.d/ but wasn't normally intended to be edited.
|
|
|
|
If such a file was supplied, it likely contained a number of
|
|
commented-out examples. By uncommenting some of these and/or
|
|
modifying them, you could set things up correctly. It was important
|
|
use a valid path for <tt/setserial/, and a valid
|
|
device name. You could do a test by executing this file manually
|
|
(just type its name as the super-user) to see if it works right.
|
|
Testing like this was a lot faster than doing repeated reboots to get
|
|
it right.
|
|
|
|
For versions >= 2.15 (provided your distribution implemented the
|
|
change, Redhat didn't at first) it may be more tricky to do since the
|
|
file that runs setserial on startup, /etc/init.d/setserial or the like
|
|
was not intended to be edited by the user. See <ref id="config_file"
|
|
name="Configuration method using /etc/serial.conf, etc.">.
|
|
|
|
An example line in such a script was:
|
|
<tscreen><verb>
|
|
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
|
|
</verb></tscreen>
|
|
|
|
or, if you wanted setserial to automatically determine the uart and the
|
|
IRQ for ttyS3 you would have used something like this:
|
|
|
|
<tscreen><verb>
|
|
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
|
|
</verb></tscreen>
|
|
|
|
This was done for every serial port you wanted to auto configure,
|
|
using a device name that really does exist on your machine. In some
|
|
cases it didn't work right due to the hardware.
|
|
|
|
<sect2> Configuration method using /etc/serial.conf, etc.
|
|
<label id="config_file">
|
|
<p> Prior to setserial version 2.15 (1999), the way to configure
|
|
setserial was to manually edit the shell-script that ran setserial at
|
|
boot-time. See <ref id="old_sets_script" name="Edit a script (before
|
|
version 2.15)">. This was simple, but the simple and clear method has
|
|
been changed to something that is unnecessarily complex. Today the
|
|
script and configuration file are two different files instead of one.
|
|
This shell-script is not edited but gets its data from a configuration
|
|
file such as <tt>/etc/serial.conf</tt> (or
|
|
<tt>/var/lib/setserial/autoserial.conf</tt>).
|
|
|
|
Furthermore you may not even need to edit serial.conf (or the like)
|
|
because using the "setserial" command on the command line may
|
|
automatically cause serial.conf to be edited appropriately. This was
|
|
done so that you may not need to edit any file in order to set up (or
|
|
change) what setserial does each time that Linux is booted.
|
|
|
|
What often happens is this: When you shut down your PC the script
|
|
that ran "setserial" at boot-time is run again, but this time it only
|
|
does what the part for the "stop" case says to do: It uses
|
|
"setserial" to find out what the current state of "setserial" is, and
|
|
it puts that info into the serial configuration file such as
|
|
<tt>serial.conf</tt>. Thus when you run "setserial" to change
|
|
the serial.conf file, it doesn't get changed immediately but only when
|
|
and if you shut down normally.
|
|
|
|
Now you can perhaps guess what problems might occur. Suppose you
|
|
don't shut down normally (someone turns the power off, etc.) and the
|
|
changes don't get saved. Suppose you experiment with "setserial" and
|
|
forget to run it a final time to restore the original state (or make a
|
|
mistake in restoring the original state). Then your "experimental"
|
|
settings are saved. And worst of all, unless you know which options
|
|
were set in the configuration file, you don't know what will happen.
|
|
One option in Debian (and likely other distributions) is known as
|
|
"AUTOSAVE-ONCE" which saves changes only for the first time you make
|
|
them with the setserial command.
|
|
|
|
If the option "###AUTOSAVE###" is set and you manually edit
|
|
serial.conf, then your editing is destroyed when you shut down because
|
|
it gets changed back to the state of setserial at shutdown. There is
|
|
a way to disable the changing of serial.conf at shutdown and that is
|
|
to remove "###AUTOSAVE###" or the like from first line of serial.conf.
|
|
In the Debian distribution, the removal of "###AUTOSAVE###" from the
|
|
first line was once automatically done after the first time you
|
|
shutdown just after installation. To retain this effect the
|
|
"AUTOSAVE-ONCE" option was created which only does a save when time
|
|
the system is shut down for the first time (just after you install or
|
|
update the setserial program).
|
|
|
|
The file most commonly used to run setserial at boot-time (in
|
|
conformance with the configuration file) is now /etc/init.d/setserial
|
|
(Debian) or /etc/init.d/serial (Redhat), or etc., but it should not
|
|
normally be edited. For 2.15, Redhat 6.0 just had a file
|
|
/usr/doc/setserial-2.15/rc.serial which you have to move to
|
|
/etc/init.d/ if you want setserial to run at boot-time.
|
|
|
|
To disable a port, use <tt/setserial/ to set it to "uart none". This
|
|
will not be saved. The format of /etc/serial.conf appears to be just
|
|
like that of the parameters placed after "setserial" on the command
|
|
line with one line for each port. If you don't use autosave, you may
|
|
edit /etc/serial.conf manually.
|
|
|
|
In order to force the current settings set by setserial to be saved to
|
|
the configuration file (serial.conf) without shutting down, do what
|
|
normally happens when you shutdown: Run the shell-script
|
|
<tt>/etc/init.d/{set}serial stop</tt>. The "stop" command will save
|
|
the current configuration but the serial ports still keep working OK.
|
|
|
|
In some cases you may wind up with both the old and new configuration
|
|
methods installed but hopefully only one of them runs at boot-time.
|
|
Debian labeled obsolete files with "...pre-2.15".
|
|
|
|
<sect2> IRQs
|
|
|
|
<p> By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and
|
|
ttyS3 share IRQ 3. But while sharing serial interrupts (using them in
|
|
running programs) is OK for the PCI bus, it's not permitted for the
|
|
ISA bus unless you: 1. have kernel 2.2 or better, and 2. you've
|
|
compiled in support for this, and 3. your serial hardware supports it.
|
|
See
|
|
|
|
|
|
<ref id="int_share-2.2" name="Interrupt sharing and Kernels 2.2+">
|
|
If you only have two serial ports, ttyS0 and ttyS1, you're still OK
|
|
since IRQ sharing conflicts don't exist for non-existent devices.
|
|
|
|
If you add a legacy internal modem (without plug-and-play) and retain
|
|
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
|
|
it in your serial port (or modem card) and then use setserial to
|
|
assign it to your device driver. If IRQ 5 is not being used for a
|
|
sound card, this could be used for a modem.
|
|
|
|
<sect2> Laptops: PCMCIA <label id="laptops_">
|
|
<p>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
|
|
configuration. For serial ports on the motherboard, setserial is used
|
|
just like it is for a desktop. But for PCMCIA cards (such as a modem)
|
|
it's a different story. The configuring of the PCMCIA system should
|
|
automatically run setserial so you shouldn't need to run it. If you
|
|
do run it (by a script file or by /etc/serial.conf) it might be
|
|
different and cause trouble. The autosave feature for serial.conf
|
|
shouldn't save anything for PCMCIA cards (but Debian did until
|
|
2.15-7). Of course, it's always OK to use setserial to find out how
|
|
the driver is configured for PCMCIA cards.
|
|
|
|
<!-- setserial.D end -->
|
|
|
|
|
|
<sect1> What is isapnp ?
|
|
<p> <tt/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.
|
|
|
|
<sect1> What is wvdialconf ? <label id="wvdial_">
|
|
<p> <tt/wvdialconf/ will try to find which serial port (ttyS?) has a
|
|
modem on it. It also creates a configuration program for the wvdial
|
|
program. <tt/wvdial/ is used for simplified dialing out using the PPP
|
|
protocol to an ISP. It can also look for modems which are not
|
|
currently in use. It will automatically devise a "suitable" init
|
|
string for the modem 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_config_file_name.
|
|
|
|
<sect>Trying Out Your Modem (Dialing Out) <label id="dialout">
|
|
<sect1> Are You Ready to Dial Out ?
|
|
<p> Once you've plugged in your modem and know which serial port it's
|
|
on you're ready to try using it. The protocol on the telephone line
|
|
will be PPP (Point-to-Point Protocol), but PPP often gets set up
|
|
without you needing to know much about it. If you already have an
|
|
account with an ISP to connect to the Internet, you could try using a
|
|
program like "wvdial" to connect to the Internet.
|
|
|
|
As an alternative to taking one big step using PPP to connect to the
|
|
Internet, you could do a two step process: First just test out your
|
|
modem without using PPP (using Minicom or Kermit). Then if your modem
|
|
works OK, use "wvdial" or another ppp dialer to connect to the Internet.
|
|
A different strategy is to first try a ppp dialer and then if that
|
|
doesn't work out, fallback to Minicom or Kermit to see if your modem
|
|
works OK. Knowing how to use either Minicom or Kermit is handy for
|
|
dialing out to other modems directly without going thru the Internet.
|
|
If you are going to use Minicom or Kermit you must find a phone number
|
|
to dial that will accept phone calls from a computer (without using
|
|
PPP). Perhaps a local library has such a phone number for its on-line
|
|
catalog.
|
|
|
|
Then make sure you are ready to phone. Do you know what serial port
|
|
(such as ttyS2) your modem is on? You should have found this out when
|
|
you io-irq configured your serial ports. Have you decided what speed
|
|
you are going to use for this port? See <ref id="speed_table"
|
|
name="Speed Table"> for a quick selection or <ref id="speed_"
|
|
name="What Speed Should I Use with My Modem"> for more details. If
|
|
you have no clue of what speed to set, try setting it a few times
|
|
faster than the advertised speed of your modem. Also remember that if
|
|
you see a menu where an option is "hardware flow control" and/or
|
|
"RTS/CTS" or the like, select it. Is a live telephone cable plugged
|
|
in to your modem? You may want to connect this cable to a real
|
|
telephone to make sure that it can produce a dial tone.
|
|
|
|
Now you need to select a communication (dialing) program to use to
|
|
dial out. Internet dialing programs (using PPP) include wvdial,
|
|
pppconfig (Debian), kppp (KDE), and for Gnome: gnome-ppp or "modem lights".
|
|
Non-internet dialing programs include: minicom, seyon (X Window), and
|
|
kermit. See section <ref id="comm_" name="Communications Programs">
|
|
about some communications programs. Three examples are presented
|
|
next: <ref id="wvdial_" name="Dialing Out with wvdial"> <ref
|
|
id="minicom_" name="Dialing Out with Minicom"> and <ref id="kermit_"
|
|
name="Dialing Out with Kermit">
|
|
|
|
<sect1> Dialing Out with wvdial <label id="wvdial_">
|
|
<p> Wvdial is a program with not only dials out, but starts PPP and
|
|
logs you in to an ISP where you get to the Internet. Wvdial may be
|
|
configured during the installation process or by using the program
|
|
"wvdialconf". See the man pages for both "wvdialconf" and "wvdial".
|
|
However, before using wvdial you must do two other tasks not covered
|
|
by the wvdial documentation:
|
|
<itemize>
|
|
<item>set up your network on your PC. The old HOWTO,
|
|
"ISP-Hookup-HOWTO" has some info on how to do this but fails to
|
|
mention programs such as wvdial which replaces "chatscripts".
|
|
<item>configure your browser
|
|
</itemize>
|
|
|
|
<sect1> Dialing Out with Minicom <label id="minicom_">
|
|
<p> Minicom comes with most Linux distributions. To configure it you
|
|
should be the root user. As root, type "minicom -s" to configure. This will
|
|
take you directly to the configuration (set-up) menus. This allows
|
|
you to use the configuration immediately. If you just type "minicom"
|
|
and then configure, you'll need to leave and restart minicom for the
|
|
configuration to take effect. Within minicom type ^A to see the
|
|
bottom status line. This shows to type ^A Z for help (you've already
|
|
typed the ^A so just type z).
|
|
|
|
Most of the options don't need to be set for just simply dialing out.
|
|
To configure you have to supply a few basic items: the name of the
|
|
serial port your modem is on such as /dev/ttyS2 and the speed such as
|
|
115200. These are set at the serial port menu. Go to it and set
|
|
them. Also (if possible) set hardware flow control (RTS/CTS). Then
|
|
save them. When typing in the speed, you should also see something
|
|
like "8N1" which you should leave alone. It means: 8-bit bytes, No
|
|
parity, 1 stop-bit appended to each byte. If you can't find the speed
|
|
you want, a lower speed will always work for a test. Exit (hit
|
|
return) when done and save the configuration as default (dfl) using
|
|
the menu. Unless you've used the -s option when you called minicom,
|
|
you'll need to exit minicom and start it again so it can now find the
|
|
serial port and initialize the modem.
|
|
|
|
Now you are ready to dial. But first at the main screen you get
|
|
after you first type "minicom" make sure there's a modem there by
|
|
typing AT and then hit the <enter> key. It should display OK.
|
|
If it doesn't, try typing ATQ0 V1 EI and see if you get OK. If you
|
|
still don't get OK, something is wrong and there is no point of trying
|
|
to dial. Why you might need to type: ATQ0 V1 E1 is because a modem
|
|
can be get into a state where is can't display OK and this should get
|
|
it out of that state.
|
|
|
|
If you got the "OK" go back to help and select the dialing directory.
|
|
You may edit it and type in a phone number, etc. into the directory
|
|
and then select "dial" to dial it. Alternatively, you may just dial
|
|
manually (by selecting "manual" and then type the number at the
|
|
keyboard). If it doesn't work, carefully note any error messages and
|
|
try to figure out what went wrong.
|
|
|
|
<sect1> Dialing Out with Kermit <label id="kermit_">
|
|
<p> You can find the latest version of <tt/kermit/ at <tt><htmlurl
|
|
url="http://www.columbia.edu/kermit/"
|
|
name="http://www.columbia.edu/kermit/"></tt>. For example, say your
|
|
modem was on <tt>ttyS4</tt>, and its speed was 115200 bps. You would
|
|
do the following:
|
|
<tscreen><verb>
|
|
linux# kermit
|
|
C-Kermit 6.0.192, 6 Sep 96, for Linux
|
|
Copyright (C) 1985, 1996,
|
|
Trustees of Columbia University in the City of New York.
|
|
Default file-transfer mode is BINARY
|
|
Type ? or HELP for help.
|
|
C-Kermit>set line /dev/ttyS4
|
|
C-Kermit>set carrier-watch off
|
|
C-Kermit>set speed 115200
|
|
/dev/ttyS4, 115200 bps
|
|
C-Kermit>c
|
|
Connecting to /dev/ttyS4, speed 115200.
|
|
The escape character is Ctrl-\ (ASCII 28, FS)
|
|
Type the escape character followed by C to get back,
|
|
or followed by ? to see other options.
|
|
ATE1Q0V1 ; you type this and then the Enter key
|
|
OK ; modem should respond with this
|
|
</verb></tscreen>
|
|
|
|
If your modem responds to <tt/AT/ commands, you can assume your modem
|
|
is working correctly on the Linux side. Now try calling another modem
|
|
by typing:
|
|
<tscreen><verb>
|
|
ATDT7654321
|
|
</verb></tscreen>
|
|
where 7654321 is a phone number. Use ATDP instead of ATDT if you have
|
|
a pulse line. If the call goes through, your modem is working.
|
|
<p>
|
|
To get back to the <tt/kermit/ prompt, hold down the Ctrl key, press
|
|
the backslash key, then let go of the Ctrl key, then press the C key:
|
|
<tscreen><verb>
|
|
Ctrl-\-C
|
|
(Back at linux)
|
|
C-Kermit>quit
|
|
linux#
|
|
</verb></tscreen>
|
|
|
|
This was just a test using the primitive "by-hand" dialing method.
|
|
The normal method is to let <tt/kermit/ do the dialing for you with
|
|
its built-in modem database and automatic dialing features, for example
|
|
using a US Robotics (USR) modem:
|
|
<tscreen><verb>
|
|
linux# kermit
|
|
C-Kermit 6.0.192, 6 Sep 1997, for Linux
|
|
Copyright (C) 1985, 1996,
|
|
Trustees of Columbia University in the City of New York.
|
|
Default file-transfer mode is BINARY
|
|
Type ? or HELP for help
|
|
C-Kermit>set modem type usr ; Select modem type
|
|
C-Kermit>set line /dev/ttyS4 ; Select communication device
|
|
C-Kermit>set speed 115200 ; Set the dialing speed
|
|
C-Kermit>dial 7654321 ; Dial
|
|
Number: 7654321
|
|
Device=/dev/ttyS4, modem=usr, speed=115200
|
|
Call completed.<BEEP>
|
|
Connecting to /dev/ttyS4, speed 115200
|
|
The escape character is Ctrl-\ (ASCII 28, FS).
|
|
Type the escape character followed by C to get back,
|
|
or followed by ? to see other options.
|
|
|
|
Welcome to ... (a welcome message, etc.)
|
|
|
|
login:
|
|
</verb></tscreen>
|
|
|
|
<sect> Dial-In <label id="dialin_">
|
|
<sect1> Dial-In Overview
|
|
<p> Dial-in is where you set up your PC so that others may dial in to
|
|
your PC (at your phone number) and use your PC. Unfortunately some
|
|
use the term "dial-in" when what they actually mean is just the
|
|
opposite: dial-out.
|
|
|
|
Dial-in works like this: Someone with a modem dials your telephone
|
|
number. Your modem answers the phone ring and connects. Once the
|
|
caller is connected, the <tt/getty/ program is notified and starts the
|
|
login process for the caller. After the caller has logged in, the
|
|
caller then may use your PC. It could be almost as if they were
|
|
sitting at your monitor-console.
|
|
|
|
The caller may use a script to automatically log in. This script will
|
|
be of the expect-send type. For example it expects "login:"
|
|
and then (after it detects "login:") will send the users login name.
|
|
It next expects the password and then sends the password, etc. Then
|
|
once the user has been automatically logged in, the /etc/passwd
|
|
(password file) might specify that a shell (such as bash) will be
|
|
started for the user. Or it might specify that PPP is to start so
|
|
that the user may be connected to the Internet. See the PPP-HOWTO for
|
|
more details. The program that you use at your PC to handle dialin is
|
|
called <tt/getty/ or <tt/mgetty/. See <ref id="getty_" name="Getty">
|
|
|
|
An advanced getty program such as mgetty can watch to see if PPP is
|
|
started by the PC on the other end. If so, the login prompt would be
|
|
skipped, a PPP connection would be made, and login would take place
|
|
automatically over the PPP connection.
|
|
|
|
<sect1> What Happens when Someone Dials In ?
|
|
<p> Here's a more detailed description of dialin. This all assumes
|
|
that you are using either mgetty or uugetty. Agetty is inferior and
|
|
doesn't work exactly the same (see <ref id="agetty_"
|
|
name="About agetty">)
|
|
|
|
For dialin to work, the modem must be listening for a ring and getty
|
|
must be running and ready to respond to the call. Your modem is
|
|
normally listening for incoming calls, but what it does when it gets a
|
|
ring depends on how it's configured. The modem can either
|
|
automatically answer the phone or not directly answer it. In the
|
|
latter case the modem sends a "RING" message to getty and then getty
|
|
tells the modem to answer the ring. In either case, it may be set up
|
|
to answer on say the 4th ring. This means that if the call is not for
|
|
the modem, one must walk/run to the phone and pick it up manually
|
|
before the 4th ring. Then an ordinary conversation can take place on
|
|
the telephone. If ons gets to the phone too late one will hear the
|
|
high pitched tones of the modem which has answered the call.
|
|
|
|
Once the modem answers the call it sends tones to the other modem
|
|
(and conversely). The two modems negotiate how they will communicate
|
|
and when this is completed your modem sends a "CONNECT" message (or
|
|
the like) to <tt/getty/. When <tt/getty/ gets this message, it sends
|
|
a login prompt out the serial port. Once a user name is given to this
|
|
prompt <tt/getty/ may just call on a program named <tt/login/ to
|
|
handle the login procedure from there on. While <tt/getty/ usually
|
|
starts running at boot-time it should wait until a connection is made
|
|
before sending out a "login" prompt.
|
|
|
|
Now for more details on the two methods of answering the call. The
|
|
first method is where the modem automatically answers the call. In
|
|
this case the number of times it will ring before answering is
|
|
controlled by the S0 register of the modem. If S0 is set to 3, the
|
|
modem will automatically answer on the 3rd ring. If S0 is set to 0
|
|
then the modem will only answer the call if getty sends it an "A" (=
|
|
Answer) AT command to the modem while the phone is ringing. (Actually
|
|
an "ATA" is sent since all modem commands are prefixed by "AT".) This
|
|
is the second method of answering, known as "manual" answering, since
|
|
the modem itself doesn't do it automatically (but getty does). You
|
|
might think it best to utilize the ability of the modem hardware to
|
|
automatically answer the call, but it's actually better if <tt/getty/
|
|
answers it "manually".
|
|
|
|
For the "manual" answer case, <tt/getty/ opens the port at boot-time
|
|
and listens. When the phone rings, a "RING" message is sent to the
|
|
listening <tt/getty/. Then if <tt/getty/ wants to answer this ring,
|
|
it sends the modem an "A" command. Note that getty may be set to
|
|
answer only after say 4 "RING" messages (the 4th ring) similar to the
|
|
automatic answer method. The modem then makes a connection and sends
|
|
a "CONNECT ..." message to <tt/getty/ which then sends a login prompt
|
|
to the caller. It's not all quite this simple as there are some
|
|
special tricks used to allow dial-out when waiting for a call. See
|
|
<ref id="dial_out_while_listening" name="Dialing Out while Waiting for
|
|
an Incoming Call">
|
|
|
|
The automatic answer case uses the CD (Carrier Detect aka DCD) wire
|
|
from the modem to the serial port to tell when a connection is made.
|
|
It works like this: At boot-time <tt/getty/ tries to open the serial
|
|
port but the attempt fails since the modem has negated CD (the modem
|
|
is idle). Then the <tt/getty/ program waits at the open statement in
|
|
the program until a CD signal is raised. When a CD signal arrives
|
|
(perhaps hours later) then the port is opened and <tt/getty/ sends the
|
|
login prompt. While <tt/getty/ is waiting (sleeping) at the open
|
|
statement, other processes can run so it doesn't degrade computer
|
|
performance. What actually wakes <tt/getty/ up is an interrupt which
|
|
is issued when the CD line from the modem changes its state to on.
|
|
|
|
You may wonder how getty is able to open the serial port in the
|
|
"manual"-answer case since CD may be negated. Well, there's a way to
|
|
write a program to force the port to open even if there is no CD
|
|
signal raised.
|
|
|
|
<sect1> 56k Doesn't Work for Dialin
|
|
<p>If you expect that people will be able to dial-in to you at 56k, it
|
|
can't be done unless you have all the following:
|
|
<enum>
|
|
<item> You have a digital connection to the telephone company such as a
|
|
trunkside-T1 or ISDN line
|
|
<item> You use special digital modems (see <ref id="digital_modem"
|
|
name="Digital Modems">)
|
|
<item> You have a "... concentrator", or the like to interface your
|
|
digital-modems to the digital lines of the telephone company.
|
|
</enum>
|
|
A "... concentrator" may be called a "modem concentrator"
|
|
or a "remote access concentrator" or it could be included in a "remote
|
|
access server" (RAS) which includes the digital modems, etc. This
|
|
type of setup is used by ISPs (Internet Service Providers).
|
|
|
|
<sect1> Getty <label id="getty_">
|
|
<sect2> Introduction to Getty
|
|
<p> A <tt/getty/ program (including agetty, mgetty, etc.) is what you
|
|
run for dialin. You don't need it for dialout. In addition to
|
|
presenting a login prompt, it also may help answer an incoming
|
|
telephone call. Originally getty was used for logging in to a
|
|
computer from a dumb terminal. A major use of it today is for logging
|
|
in to a Linux system at a console. There are several different getty
|
|
programs a few of which work OK with modems for dialin. The getty
|
|
program is usually started either at boot-time or when someone dials
|
|
in to your computer. It must be called from the /etc/inittab file.
|
|
In this file you may find some examples which you will likely need to
|
|
edit a bit.
|
|
|
|
There are four different getty programs to choose from that may be
|
|
used with modems for dial-in: <tt/mgetty/, <tt/uugetty/, <tt/getty_em/,
|
|
and <tt/agetty/. A brief overview is given in the following
|
|
subsections. <tt/agetty/ is the weakest of the four and it's mainly
|
|
for use with directly connected text-terminals. <tt/mgetty/ includes
|
|
support for fax and voice mail but <tt/uugetty/ doesn't. But
|
|
<tt/mgetty/ allegedly lacks a few of the features of <tt/uugetty/.
|
|
<tt/getty_em/ is a simplified version of <tt/uugetty/. Thus
|
|
<tt/mgetty/ is likely your best choice unless you are already familiar
|
|
with <tt/uugetty/ (or find it difficult to get <tt/mgetty/). The
|
|
syntax for these getty programs differs, so be sure to check that you
|
|
are using the correct syntax in <tt>/etc/inittab</tt> for whichever
|
|
getty you use.
|
|
|
|
In order to see what documentation exists about the various gettys on
|
|
your computer, use the "locate" command. Type: locate "*getty*"
|
|
(including the quotes may help). Note that many distributions just
|
|
call the program getty even though it may actually be agetty, uugetty,
|
|
etc. But if you read the man page (type: man getty), it might
|
|
disclose which getty it is. This should be the getty program with
|
|
path <tt>/sbin/getty.</tt>
|
|
|
|
<sect2> How getty respawns
|
|
<!-- getty_seq.D begin (in MM, TT)
|
|
This is the sequence of events that happens after getty starts up.
|
|
<sect2> How getty respawns
|
|
-->
|
|
<p>After you log in you will notice (by using "top", "ps -ax", or
|
|
"ptree") that the getty process is no longer running. What happened
|
|
to it? Why does getty restart again if your shell is killed? Here's
|
|
why.
|
|
|
|
After you type in your user name, getty takes it and calls the login
|
|
program telling it your user name. The getty process is replaced
|
|
by the login process. The login process asks for your password,
|
|
checks it and starts whatever process is specified in your password
|
|
file. This process is often the bash shell. If so, bash starts and
|
|
replaces the login process. Note that one process replaces another
|
|
and that the bash shell process originally started as the getty
|
|
process. The implications of this will be explained below.
|
|
|
|
Now in the /etc/inittab file, getty is supposed to respawn (restart) if
|
|
killed. It says so on the line that calls getty. But if the bash shell
|
|
(or the login process) is killed, getty respawns (restarts). Why?
|
|
Well, both the login process and bash are replacements for getty and
|
|
inherit the signal connections establish by their predecessors. In
|
|
fact if you observe the details you will notice that the replacement
|
|
process will have the same process ID as the original process. Thus
|
|
bash is sort of getty in disguise with the same process ID number. If
|
|
bash is killed it is just like getty was killed (even though getty
|
|
isn't running anymore). This results in getty respawning.
|
|
|
|
When one logs out, all the processes on that serial port are killed
|
|
including the bash shell. This may also happen (if enabled) if a
|
|
hangup signal is sent to the serial port by a drop of DCD voltage by
|
|
the modem. Either the logout or drop in DCD will result in getty
|
|
respawning. One may force getty to respawn by manually killing bash
|
|
(or login) either by hitting the k key, etc. while in "top" or with
|
|
the "kill" command. You will likely need to kill it with signal 9
|
|
(which can't be ignored).
|
|
|
|
|
|
<sect2>About mgetty <label id="mgetty_">
|
|
<p>
|
|
<tt/mgetty/ was written as a replacement for <tt/uugetty/ which was
|
|
in existence long before <tt/mgetty/. Both are for use with modems
|
|
but mgetty is best (unless you already are committed to <tt/uugetty/).
|
|
<tt/mgetty/ may be also used for directly connected terminals but
|
|
doesn't have many features for this purpose. In addition to allowing
|
|
dialup logins, <tt/mgetty/ also provides FAX support, auto PPP
|
|
detection, and caller-id support. It permits dialing out when mgetty
|
|
is waiting for an incoming phone call. There is a supplemental
|
|
program called <tt/vgetty/ which handles voicemail for some modems.
|
|
<tt/mgetty/ documentation is fair (except for voice mail), and is not
|
|
supplemented in this HOWTO. To automatically start PPP one must edit
|
|
/etc/mgetty/login.conf to use "AutoPPP" (has example). You can find
|
|
the latest information on <tt/mgetty/ at <htmlurl
|
|
url="http://www.leo.org/˜doering/mgetty/"
|
|
name="http://www.leo.org/˜doering/mgetty/"> and <url
|
|
url="http://alpha.greenie.net/mgetty/">
|
|
|
|
<sect2>About uugetty <label id="uugetty_">
|
|
<p>
|
|
<tt/getty_ps/ contains two programs: <tt/getty/ is used for console
|
|
and terminal devices, and <tt/uugetty/ for modems. Greg Hankins
|
|
(former author of Serial-HOWTO) used <tt/uugetty/ so his writings
|
|
about it are included here. See <ref id="uugetty_" name="Uugetty">.
|
|
|
|
<sect2> About getty_em <label id="getty_em_">
|
|
<p> This is a simplified version of ``uugetty''. It was written by
|
|
Vern Hoxie after he became fully confused with complex support files
|
|
needed for getty_ps and uugetty.
|
|
|
|
It is part of the collection of serial port utilities and information
|
|
by Vern Hoxie available via ftp from <url
|
|
url="scicom.alphacdc.com/pub/linux">. The name of the collection is
|
|
``serial_suite.tgz''.
|
|
|
|
<sect2>About agetty <label id="agetty_">
|
|
<p> This subsection is long since the author tried using agetty for
|
|
dialin. <tt/agetty/ is seemingly simple since there are no
|
|
initialization files. But when I tried it, it opened the serial port
|
|
even when there was no CD signal present. It then sent both a login
|
|
prompt and the /etc/issue file to the modem in the AT-command state
|
|
before a connection was made. The modem thinks all this an AT command
|
|
and if it does contain any "at" strings (by accident) it is likely to
|
|
adversely modify your modem profile. Echo wars can start where getty
|
|
and the modem send the same string back and forth over and over. You
|
|
may see a "respawning too rapidly" error message if this happens. To
|
|
prevent this you need to disable all echoing and result codes from the
|
|
modem (E0 and Q1). Also use the -i option with agetty to prevent any
|
|
/etc/issue file from being sent.
|
|
|
|
If you start getty on the modem port and a few seconds later find that
|
|
you have the login process running on that port instead of getty, it
|
|
means that a bogus user name has been sent to agetty from the modem.
|
|
To keep this from happening, I had to save my dial-in profile in the
|
|
modem so that it become effective at power-on. The other saved
|
|
profile is for dial-out. Then any dial-out programs which use the
|
|
modem must use a Z, Z0, or Z1 in their init string to initialize the
|
|
modem for dial-out (by loading the saved dial-out profile). If the
|
|
1-profile is for dial-in you use Z1 to load it, etc. If you want
|
|
to listen for dial-in later on, then the modem needs to be reset to
|
|
the dial-in profile. Not all dial-out programs can do this reset upon
|
|
exit from them.
|
|
|
|
Thus while agetty may work OK if you set up a dial-in profile
|
|
correctly in the modem hardware, it's probably best suited for virtual
|
|
consoles or terminals rather than modems. If agetty is running for
|
|
dialin, there's no easy way to dial out. When someone first dials in
|
|
to agetty, they should hit the return key to get the login prompt.
|
|
<tt/agetty/ in the Debian distribution is just named <tt/getty/.
|
|
|
|
<sect2> About mingetty, and fbgetty
|
|
<p><tt/mingetty/ is a small getty that will work only for monitors
|
|
(the usual console) so you can't use it with modems for dialin.
|
|
<tt>fbgetty</tt> is as above but supports framebuffers.
|
|
|
|
<sect1> Why "Manual" Answer is Best
|
|
<p> The difference between the two ways of answering is exhibited
|
|
when the computer happens to be down but the modem is still working.
|
|
For the manual case, the "RING" message is sent to getty but since the
|
|
computer is down, getty isn't there and the phone never gets answered.
|
|
There are no telephone charges when there is no answer. For the
|
|
automatic answer case, the modem (which is still on) answers the phone
|
|
but no login message is ever sent since the computer is down. The
|
|
phone bill runs up as the waiting continues. If the phone call is
|
|
toll-free, it doesn't make much difference, although it may be
|
|
frustrating waiting for a login prompt that never arrives.
|
|
<tt/mgetty/ uses manual answer. <tt/Uugetty/ can do this too by using a
|
|
configuration script.
|
|
|
|
<sect1> Dialing Out while Waiting for an Incoming Call <label
|
|
id="dial_out_while_listening">
|
|
<p>Here's what could go wrong with a simple-minded manual-answer
|
|
situation. Suppose another process dials out while getty is listening
|
|
for a "RING" message from its modem on the serial wire. Then incoming
|
|
bytes for the dial-out process flow from the modem to the serial port.
|
|
For example, your modem may send a "CONNECT" message to your serial
|
|
port when the dial-out process connects. If getty reads this there's
|
|
trouble since reads are destructive reads. Once getty reads it, then
|
|
the dial-out process that is expecting "CONNECT" (or something else)
|
|
can't read it. Thus the dial-out process is likely to fail.
|
|
|
|
There's a way to avoid this and here's how mgetty does it. When
|
|
mgetty is listing for an incoming call, it doesn't read anything from
|
|
the port until it thinks that the characters are for mgetty. Mgetty
|
|
monitors the port and if characters arrive, it doesn't read them right
|
|
away. Instead, it first checks to see if another process is using the
|
|
port. If so, mgetty backs off and closes the port (but the port
|
|
remains open for the other process). Thus, if another process dials
|
|
out, mgetty doesn't interfere with it. When the other process finally
|
|
closes the port, then mgetty resumes "listening". It's a special type
|
|
of "listening" that refrains from reading until mgetty believes that
|
|
what it will read is for mgetty (hopefully a "RING" message).
|
|
|
|
When mgetty checks to see if another process is using the port, it
|
|
actually checks for valid lockfiles on the port. If the other process
|
|
failed to use lockfiles, too bad for it. For more details see the
|
|
mgetty documentation: "How mgetty works". For programmers only:
|
|
"listening" is actually using the system calls "poll" or "select" to
|
|
monitor the port. They are likely also used to monitor the port when
|
|
a non-mgetty process is using the port.
|
|
|
|
Then there's the problem of modem configuration when using mgetty.
|
|
Mgetty first sets this configuration when it starts up and uses a
|
|
user-specified chat script to do it. So the modem is now configured
|
|
not to auto-answer but to send the RING string to mgetty when the
|
|
phone rings. Now suppose that while mgetty is waiting for an incoming
|
|
call, another program makes and outgoing call and reconfigures the
|
|
modem to something bad for mgetty. To prevent this, when mgetty
|
|
detects that some other program using the port has exited, mgetty just
|
|
exits itself. This results in mgetty starting up anew (respawns per
|
|
the /etc/inittab file) and then mgetty reconfigures the modem so that
|
|
it's all set up to listen once more for incoming calls.
|
|
|
|
With auto-answer (not normally used by mgetty), getty is waiting for
|
|
CD to be raised so that it can open the port. One may dial out, but
|
|
once a connection is made, the modem's CD is raised. If getty were
|
|
to then read the port it would eat the characters intended to be read
|
|
by the dial-out connection. While agetty will have this problem, it's
|
|
claimed that uugetty will check lockfiles before reading (similar to
|
|
mgetty).
|
|
|
|
<sect1> Ending a Dial-in Call <label id="end_dialin">
|
|
<p> There are two major ways to end a dial-in call. The caller may
|
|
either logout or just hang up. For the hangup case see <ref
|
|
id="caller_hangs_up" name="Caller hangs up">
|
|
|
|
<sect2> Caller logs out
|
|
<p> When the call is over, the normal way to end the connection is for
|
|
the remote user to log out. This should result in the dial-in PC
|
|
hanging up the phone line as will be explained shortly. Note that
|
|
this behavior is not what normally happens when one logs out from a PC
|
|
(when not using a modem). In this case, the user logs out and
|
|
immediately gets a login prompt as an invitation to log in again. But
|
|
a remote user that types "logout" gets hung up on, and must redial if
|
|
s/he wants to log in again. If there was no hang-up when the user
|
|
logged out, the connection would be maintained, and not give anyone
|
|
else the opportunity to login.
|
|
|
|
Logging out by the remote user of your dial-in PC will kill the shell
|
|
that the remote user was using on your dial-in PC. Now, since there is
|
|
nothing running on this port anymore, the port closes and sends a
|
|
hangup signal to the modem by negating DTR. This will only happen if
|
|
stty -a shows hupcl (default). hupcl = Hang UP on CLose => drop DTR
|
|
(the "hang up" signal) when the last program running on this port is
|
|
closed). But normally, when the shell is killed it's like getty was
|
|
killed and getty will respawn (since it's set this way in
|
|
/etc/inittab). This will almost immediately open the port again and
|
|
raise DTR. So DTR is said to wink (drop only for only a small
|
|
fraction of a second and then reassert itself). With modern fast
|
|
computers, this wink would be too short to be recognized by the modem
|
|
so the serial driver is supposed to make this wink longer (provided
|
|
stty has hupcl set, and provided ...). But there was a complaint in
|
|
2003 that it's not long enough.
|
|
|
|
The dial-in PC modem getting the hangup (negated DTR signal) will
|
|
then hang up the phone line (provided the modem has been configured to
|
|
do this --see below). The modem should then be ready to answer any
|
|
new incoming calls. For mgetty, if there is a chat-script to
|
|
initialize the modem and possibly reset the modem will happen also. If the modem didn't hang
|
|
up due to too short of a DTR wink, then a newly spawned getty might be
|
|
able to hang up. mgetty itself creates a long DTR wink when it starts
|
|
up to hang up the modem. It's claimed that making a respawned getty
|
|
clean up the mess (the modem still online) left by the previous call,
|
|
is not the right way to handle this.
|
|
|
|
When setting up mgetty, one may use a chat-script with the code
|
|
sequence +++ to the modem to put it into AT command mode if DTR didn't
|
|
work. The +++ must have both an initial and final minimal time delay.
|
|
Once in AT command mode, a hangup command (H0) may be sent to the
|
|
modem as well as other AT commands. One may have things set up to use
|
|
both this method and the DTR method and so that if one method should
|
|
fail, the other one will hopefully work. If the PC fails to
|
|
successfully signal the modem when a logout happens (or fails to use
|
|
the +++ escape when restarting getty), then the modem is apt to remain
|
|
in on-line mode and no more incoming calls can be received. It's
|
|
claimed that this might be a security risk.
|
|
|
|
<sect2> When DTR drops (is negated) <p>When DTR (the "hang-up" signal
|
|
when negated) is dropped (negated), what the modem does depends on the
|
|
value of the &D option in the modem's profile. If it's &D0
|
|
nothing at all happens (the modem ignores the negation of DTR).
|
|
Here's what happens when the computer drops DTR:
|
|
|
|
<tt>&D2:</tt> The modem will hang up and go into AT command mode
|
|
(off-line) to wait for the next call. Except that it will not
|
|
be able to automatically answer the phone until DTR is raised
|
|
again. But since mgetty automatically respawns (if so set in
|
|
/etc/inittab) then mgetty will immediately restart after a logout and
|
|
this will raise DTR. So what happens when someone logs out is that
|
|
DTR only is negated for a fraction of a second (winks) before it gets
|
|
raised again. During this wink, the DTR must be negated for
|
|
at least the time specified by register S25, otherwise the modem will
|
|
not hang up.
|
|
|
|
<tt>&D3:</tt> or S13 = 1. In this case the modem does a hard
|
|
reset when DTR drops: It hangs up and restores the saved profile as
|
|
specified by &Y. It should now be in the same state it was in
|
|
when first powered on. But mgetty may have a chat script which will
|
|
send the modem an init string and thus change the profile again.
|
|
Since these two changes in profile happen at about the same time,
|
|
could this be a problem (known as "race conditions").
|
|
|
|
The S25 limit may have no effect so even a very short DTR "wink" is
|
|
detected. Another brand of modem says the S25 limit is still valid.
|
|
Thus <tt>&D3</tt> is a stronger "reset" than <tt>&D2</tt>
|
|
which doesn't restore the saved profile and could require a longer
|
|
wink to work.
|
|
|
|
Under favorable conditions, either <tt>&D3</tt> or
|
|
<tt>&D2</tt> should work OK. It's reported that for a few modems,
|
|
only <tt>&D2</tt> works OK. Could this be related to a possible
|
|
race condition mentioned above if <tt>&D3</tt> is used?
|
|
|
|
<sect2> Caller hangs up <label id="caller_hangs_up">
|
|
<p> Instead of logging out the normal way, a caller may just hang up
|
|
(by closing the "terminal" program s/he's using, etc). This results
|
|
in a lost connection and of course a loss of carrier. Other problems
|
|
could also cause a loss of carrier. The modem hangs up and waits for
|
|
the next call. Except that there is no mgetty running yet to start
|
|
the login process.
|
|
|
|
Here's how getty gets started again: The loss of carrier should
|
|
negate the CD signal sent by the modem to the serial port (provided
|
|
<tt>&C1</tt> has been set). When the PC's serial port gets the
|
|
dropped CD signal it should kill the shell, provided clocal is negated
|
|
(-clocal) and then getty should respawn. mgetty raises clocal when
|
|
it starts. Does it later drop clocal?
|
|
|
|
This paragraph is about other things that happen but do nothing. Only
|
|
the curious need read it. When the shell is killed, a DTR wink is sent
|
|
to the modem but since the modem is not on-line anymore and has
|
|
already hung up due to lost carrier, the modem ignores the drop of
|
|
DTR. The loss of carrier also negates the DSR signal sent by the
|
|
modem to the serial port (provided &S1 or &S2 is set) but this
|
|
signal is ignored (by Linux). The "NO CARRIER" result code should be
|
|
generated by the modem but where does it go to ?
|
|
|
|
<sect1> Dial-in Modem Configuration <label id="dial-in_conf">
|
|
<p> The getty programs have a provision for sending an init string to
|
|
the modem to configure it. But you may need to edit it. Another
|
|
method is to save a suitable init string inside the modem (see
|
|
<ref id="init_str" name="Init Strings: Saving and Recalling"> for how
|
|
to save it in the modem).
|
|
|
|
The configuration for dial-in depends both on the getty you use and
|
|
perhaps on your modem. If you can't find suggested configurations in
|
|
other documentation here are some hints using Hayes AT commands:
|
|
|
|
<itemize>
|
|
<item><tt>&C1</tt> Make the CD line to the serial port track the actual
|
|
state of the carrier (CD raised only when there's carrier).
|
|
Getty_em requires &C0 (CD always raised)
|
|
<item><tt>&D3</tt> Do a hard reset of the modem when someone logs out
|
|
(or hangs up). For some modems it's reported that &D2 is
|
|
required since they can't tolerate a hard reset ??
|
|
<item><tt/E0/ Don't echo AT commands back to the serial port. This
|
|
is a must for agetty. Some suggest E1 (echo AT commands) for mgetty.
|
|
For dial-out you want E1 so you can see what was sent.
|
|
<item><tt>&K3</tt> Use hardware flow control
|
|
<item><tt/Q0/ Echo results words (such as CONNECT). Most gettys use
|
|
them. But it's reported an AT&T version of uugetty and agetty
|
|
require Q2 (no result words for dial-in).
|
|
<item><tt>S0=?</tt> mgetty suggests S0=0 (manual answer) but you give
|
|
the number of rings on the mgetty command line. If you set
|
|
S0=3 the modem will auto-answer on the 3rd ring, etc. Agetty uses
|
|
auto-answer. So does uugetty (usually).
|
|
<item><tt/V1/ Display results (such as CONNECT) in words (and not in code)
|
|
<item><tt/X4/ Check for dialtone and busy signal
|
|
</itemize>
|
|
|
|
<sect1> Callback
|
|
<p> Callback is where someone first dials in to your modem. Then, you
|
|
get a little info from the caller and then call it right back. Why
|
|
would you want to do this? One reason is to save on telephone bills
|
|
if you can call the caller cheaper than the caller can call you.
|
|
Another is to make sure that the caller really is who it claims to be.
|
|
If a caller calls you and claims to be calling from its usual phone
|
|
number, then one way to verify this is to actually place a new call to
|
|
that number.
|
|
|
|
There's a program for Linux called "callback" that works with mgetty.
|
|
It's at <url
|
|
url="ftp://ftp.rug.nl/contrib/frank/software/linux/callback/">
|
|
Step-by-step instructions on how someone installed it (and PPP) is at
|
|
<url
|
|
url="http://www.stokely.com/unix.serial.port.resources/callback.html">
|
|
|
|
<sect1> Distinctive Ring
|
|
<p>"Distinctive ring" is where you want the modem to answer phone calls
|
|
only for certain types of rings like long, short, long, short, etc.
|
|
To do this, you first need a modem that supports distinctive ring. The
|
|
Netcomm Roadster modem can be set with an AT command to do the
|
|
following, for example: It will send to mgetty: DROF=14 DRON=4 RING
|
|
DROF=4 DRON=2 RING ... meaning that there is a 1.4 seconds of initial
|
|
silence (DROF=14) followed by .4 seconds of ringing (DRON=4) etc.
|
|
RING is also reported after each ring. Note that the modem can't
|
|
be set to answer a certain type of ring, it only informs the program
|
|
listening on the serial port (such as mgetty) what the ring sequence
|
|
is. Then if the program likes the sequence, it sends an AT command to
|
|
the modem to answer the call. Unfortunately, mgetty doesn't recognize
|
|
such ring sequences but there's a workaround that may work.
|
|
|
|
Mgetty only waits for a "RING" and will ignore the DRON and DROF
|
|
(Distinctive Ring OFf) words. For the Netcomm Roadster modem, you can
|
|
set the delay between sending DRON= and RING. For example you could
|
|
set a delay of 2.0 seconds. However, if within this 2.0 second period
|
|
another actual ring occurs, the modem cancels the delayed RING message
|
|
and never sends it. So you might be able to set this delay so the
|
|
calls you don't want the modem to answer never send a RING message to
|
|
mgetty. But for the calls you want mgetty to answer, you get the
|
|
interval between rings to be long enough so that "RING" is sent
|
|
to mgetty and mgetty answers the call. This workaround is not always
|
|
feasible, especially if the telephone company doesn't give you much
|
|
choice of distinctive rings. Will the above work for other modems that
|
|
support distinctive ring?
|
|
|
|
For the above modem, the AT command: AT+VDR=1,24 sets the above delay for
|
|
2.4 seconds. You can put this in an "init-chat" parameter in
|
|
mgetty.config.
|
|
|
|
<sect1> Voice Mail <label id="voice_">
|
|
<p> Voice mail is like an answering machine run by a computer.
|
|
To do this you must have a modem that supports "voice" and supporting
|
|
software. Instead of storing the messages on tape, they are stored in
|
|
digital format on a hard-drive. When a person phones you, they hear a
|
|
"greeting" message and can then leave a message for you. More
|
|
advanced systems would have caller-selectable mail boxes and
|
|
caller-selectable messages to listen to. Free software is available in
|
|
Linux for simple answering, but doesn't seem to be available yet for
|
|
the more advanced stuff.
|
|
|
|
I know of two different voicemail packages for Linux. One is a very
|
|
minimal package (see <ref id="voice_sw" name="Voicemail Software">).
|
|
The other, more advanced, but currently poorly documented, is
|
|
<tt/vgetty/ which supports all ELSA modems and the ITU v.253 standard.
|
|
It's an optional addition to the well documented and widely
|
|
distributed <tt/mgetty/ program. In the Debian distribution, you
|
|
must get the mgetty-voice package in addition to the mgetty package
|
|
and mgetty-doc (documentation) package.
|
|
|
|
<sect1> Simple Manual Dial-In <label id="manual_dialin">
|
|
<p> This is really doing it manually! It doesn't even permit the
|
|
caller to login but the caller may "chat" with you, etc. It's a way
|
|
to answer a call without bothering to edit any configuration files for
|
|
dial-in or enabling getty. To do it you run a terminal program such
|
|
as minicom. Make sure it's connected to your modem by typing "AT
|
|
<enter>" and expect "OK". Then wait for the call. Then you
|
|
really answer the call manually by typing "ATA" when the phone is
|
|
ringing. This doesn't run getty and the caller can't login. But if
|
|
the caller is calling in with a terminal program they may type a
|
|
message to your screen (and conversely). You both may send files back
|
|
and forth by using the commands built into the terminal programs (such
|
|
as minicom). Another way to answer such a call would be to type say
|
|
"ATS0=3" just before the call comes in to enable the modem to
|
|
auto-answer on the third ring.
|
|
|
|
This is one way to crudely transfer files with someone on a MS Windows
|
|
PC who uses HyperTerminal or Terminal (for Windows 3.x or DOS). These
|
|
two MS programs are something like minicom. Using this simple manual
|
|
method (for Linux-to-Linux or MS-to-Linux) requires two people to be
|
|
present, one one each end of the phone line connection running a
|
|
terminal communications program. Be warned that if both people
|
|
type at the same time it's chaos. It's a "last resort" way to
|
|
transfer files between any two people that have PCs (either Linux or
|
|
MS Windows). It could also be used for testing your modem or as a
|
|
preliminary test before setting up dial-in.
|
|
|
|
<sect1> Complex GUI Dial-In, VNC
|
|
<p> At the opposite extreme to the simple (but labor intensive) manual
|
|
dial-in described above, is one that results in GUI graphical
|
|
interface to the Linux PC. This generally requires that a network
|
|
running TCP/IP protocol exist between the two computers. One way to
|
|
get such a "network" is to dial-out to a PC set for dial-in and then
|
|
run PPP on the phone line. PPP will use TCP/IP protocol encapsulated
|
|
inside the PPP packets. Both sides must run PPP and mgetty can be
|
|
configured to start PPP as soon as the caller does. The caller may
|
|
use a PPP-dialer program just like they were dialing an ISP. Programs
|
|
such as wvdial, eznet, or chat scripts should do it.
|
|
|
|
Instead of this tiny network over a phone connection a much larger
|
|
network (the entire world) is reached via an ISP. For their
|
|
lowest-rate service many of them use proxy servers that will not give
|
|
you access to the ports you need to use. Even if they don't use
|
|
proxy servers, the IP address they give you is only temporary for the
|
|
session, so you'll need to email this IP to whomever wants to reach
|
|
you. If you get a more expensive ISP service, then you can avoid
|
|
these problems.
|
|
|
|
One way to get a GUI interface from the remote PC is to run the GPLed
|
|
program: Virtual Network Computer (VNC) from AT&T. It has a
|
|
server part which you run on your Linux PC for dial-in and a viewer
|
|
(client) part used for dial-out. Neither of these actually does any
|
|
dialing or login but assumes that you have a network already set up.
|
|
The VNC server has an X-server built in and may use Linux's twm window
|
|
manager. See the article on VNC in Linux Magazine: <url
|
|
url="http://www.linux-mag.com/2000-11/desktop_03.html">. The AT&T
|
|
site for VNC is: <url url="http://www.uk.research.att.com/vnc/">.
|
|
|
|
With VNC one can also connect to remote Windows PCs, get the Windows
|
|
GUI on a Linux PC, and run Windows programs on the remote Windows PC.
|
|
Of course the Windows PC must be running VNC (as a server).
|
|
Obviously, a GUI connection over a modem will be slower than a
|
|
text-only connection especially if you run KDE or GNOME or want 16-bit
|
|
color.
|
|
|
|
<sect1> Interoperability with MS Windows
|
|
<p> Once you have dial-in set up, others may call in to you using
|
|
minicom (or the like) from Unix-like systems. From MS Windows one may
|
|
call you using "HyperTerminal (or just "Terminal" in Windows 3.1 or
|
|
DOS).
|
|
|
|
If in Windows one wants to use dial-up with a network protocol over
|
|
the phone line it's called "Dial-up Networking". But it probably will
|
|
not be able to communicate with Linux. For setting up such dial-in in
|
|
Windows one clicks on "server" while dial-out is the "client. Such
|
|
dial-in is often called "remote control" meaning that the caller can
|
|
use your PC, run programs on it, and thus control it remotely.
|
|
|
|
While it's easy to call in to a text-based Linux system from MS
|
|
Windows, it's not so easy the other way around (partly because
|
|
Windows is not text-based and would need to put the caller into DOS
|
|
where files wouldn't be protected like they are in Linux.
|
|
|
|
However Windows "Dial-up Networking" can establish a dial-in provided
|
|
the caller uses certain network protocols over the phone line: MS's
|
|
or Novel's (two protocols not liked by Linux). So if someone with
|
|
Windows enables their Dial-up networking server in Windows 98, you
|
|
can't just dial in directly to it from Linux. This type of dial-in
|
|
doesn't permit the caller to run most of the programs on the host like
|
|
Linux does. It's called "remote access" and one may transfer files,
|
|
use the hosts printer, access databases, etc. Is there some way to
|
|
interface to Dial-up Networking from Linux??
|
|
|
|
It is possible for two people to crudely chat and send files using
|
|
Minicom on the Linux end and HyperTerminal on the Windows end. It's
|
|
all done manually by two live persons, one on each end of the phone
|
|
connection. See <ref id="manual_dialin" name="Simple Manual
|
|
Dial-In">.
|
|
|
|
At the opposite extreme, one would like to run a dial-in so that the
|
|
person calling would get a GUI interface. For that a network protocol
|
|
is normally used. It's possible using PC Anywhere for Windows or VNC
|
|
for both Linux and Windows. But PC Anywhere doesn't seem to talk to
|
|
Linux ?? Other Window programs for "remote control" include Laplink,
|
|
Co-Session, and Microcom. Do any such programs support Linux besides
|
|
VNC ??
|
|
|
|
<sect> Uugetty for Dial-In (from the old Serial-HOWTO) <label id="uugetty_">
|
|
<p> Be aware that you could use mgetty as a (better?) alternative to
|
|
<tt/uugetty/. <tt/mgetty/ is newer and more popular than uugetty.
|
|
See <ref id="getty_" name="Getty"> for a brief comparison of these 2
|
|
gettys.
|
|
|
|
<sect1>Installing getty_ps
|
|
<p> Since uugetty is part of getty_ps you'll first have to install
|
|
getty_ps. If you don't have it, get the latest version from <tt><htmlurl
|
|
url="ftp://metalab.unc.edu:/pub/Linux/system/serial"
|
|
name="metalab.unc.edu:/pub/Linux/system/serial"></tt>. In particular,
|
|
if you want to use high speeds (57600 and 115200 bps), you must get
|
|
version 2.0.7j or later. You must also have libc 5.x or greater.
|
|
|
|
<p> By default, <tt/getty_ps/ will be configured to be Linux FSSTND
|
|
(File System Standard) compliant, which means
|
|
that the binaries will be in <tt>/sbin</tt>, and the config files
|
|
will be named <tt>/etc/conf.{uu}getty.ttyS</tt><em/N/. This is not
|
|
apparent from the documentation! It will also expect lock files to go
|
|
in <tt>/var/lock</tt>. Make sure you have the <tt>/var/lock</tt>
|
|
directory.
|
|
<p>
|
|
If you don't want FSSTND compliance, binaries will go
|
|
in <tt>/etc</tt>, config files will go in
|
|
<tt>/etc/default/{uu}getty.ttyS</tt><em/N/, and lock files will go in
|
|
<tt>/usr/spool/uucp</tt>. I recommend doing things this way if you
|
|
are using UUCP, because UUCP will have problems if you move
|
|
the lock files to where it isn't looking for them.
|
|
<p>
|
|
<tt/getty_ps/ can also use <tt/syslogd/ to log messages. See the man
|
|
pages for <tt/syslogd(1)/ and <tt/syslog.conf(5)/ for setting up
|
|
<tt/syslogd/, if you don't have it running already. Messages
|
|
are logged with priority LOG_AUTH, errors use LOG_ERR, and debugging
|
|
uses LOG_DEBUG. If you don't want to use <tt/syslogd/ you
|
|
can edit <tt/tune.h/ in the <tt/getty_ps/ source files to use a log
|
|
file for messages instead, namely <tt>/var/adm/getty.log</tt> by
|
|
default.
|
|
<p>
|
|
Decide on if you want FSSTND compliance and syslog capability.
|
|
You can also choose a combination of the two. Edit the <tt/Makefile/,
|
|
<tt/tune.h/ and <tt/config.h/ to reflect your decisions. Then
|
|
compile and install according to the instructions included with the
|
|
package.
|
|
|
|
<sect1>Setting up uugetty
|
|
<p>
|
|
With <tt/uugetty/ you may dial out with your modem while <tt/uugetty/
|
|
is watching the port for logins. <tt/uugetty/ does important lock
|
|
file checking. Update <tt>/etc/gettydefs</tt> to include an entry for
|
|
your modem. For help with the meaning of the entries that you put
|
|
into <tt>/etc/gettydefs</tt>, see the "serial_suite" collected by Vern
|
|
Hoxie. How to get it is in section See<ref id="getty_em_" name="About
|
|
getty_em">. When you are done editing <tt>/etc/gettydefs</tt>, you
|
|
can verify that the syntax is correct by doing:
|
|
|
|
<tscreen><verb>
|
|
linux# getty -c /etc/gettydefs
|
|
</verb></tscreen>
|
|
|
|
<sect2> Modern Modems
|
|
<p> If you have a 9600 bps or faster modem with data compression,
|
|
you can lock your serial port to one speed. For example:
|
|
<tscreen><verb>
|
|
# 115200 fixed speed
|
|
F115200# B115200 CS8 # B115200 SANE -ISTRIP HUPCL #@S @L @B login: #F115200
|
|
</verb></tscreen>
|
|
<p>
|
|
If you have your modem set up to do RTS/CTS hardware flow control, you
|
|
can add <tt/CRTSCTS/ to the entries:
|
|
<tscreen><verb>
|
|
# 115200 fixed speed with hardware flow control
|
|
F115200# B115200 CS8 CRTSCTS # B115200 SANE -ISTRIP HUPCL CRTSCTS #@S @L @B login: #F115200
|
|
</verb></tscreen>
|
|
|
|
<sect2> Old slow modems
|
|
<p> If you have a slow modem (under 9600 bps) Then, instead of one
|
|
line for a single speed, your need several lines to try a number of
|
|
speeds. Note that these lines are linked to each other by the last
|
|
"word" in the line such as #4800. Blank lines are needed between
|
|
each entry. Are the higher modem-to-serial_port speeds in this
|
|
example really needed for a slow modem ?? The uugetty documentation
|
|
shows them so I'm not yet deleting them.
|
|
|
|
<tscreen><verb>
|
|
# Modem entries
|
|
115200# B115200 CS8 # B115200 SANE -ISTRIP HUPCL #@S @L @B login: #57600
|
|
|
|
57600# B57600 CS8 # B57600 SANE -ISTRIP HUPCL #@S @L @B login: #38400
|
|
|
|
38400# B38400 CS8 # B38400 SANE -ISTRIP HUPCL #@S @L @B login: #19200
|
|
|
|
19200# B19200 CS8 # B19200 SANE -ISTRIP HUPCL #@S @L @B login: #9600
|
|
|
|
9600# B9600 CS8 # B9600 SANE -ISTRIP HUPCL #@S @L @B login: #4800
|
|
|
|
4800# B4800 CS8 # B4800 SANE -ISTRIP HUPCL #@S @L @B login: #2400
|
|
|
|
2400# B2400 CS8 # B2400 SANE -ISTRIP HUPCL #@S @L @B login: #1200
|
|
|
|
1200# B1200 CS8 # B1200 SANE -ISTRIP HUPCL #@S @L @B login: #115200
|
|
</verb></tscreen>
|
|
<p>
|
|
<sect2> Login Banner
|
|
<p> If you want, you can make <tt/uugetty/ print interesting things in
|
|
the login banner. In Greg's examples, he has the system name, the
|
|
serial line, and the current bps rate. You can add other things:
|
|
|
|
<tscreen><verb>
|
|
@B The current (evaluated at the time the @B is seen) bps rate.
|
|
@D The current date, in MM/DD/YY.
|
|
@L The serial line to which uugetty is attached.
|
|
@S The system name.
|
|
@T The current time, in HH:MM:SS (24-hour).
|
|
@U The number of currently signed-on users. This is a
|
|
count of the number of entries in the /etc/utmp file
|
|
that have a non-null ut_name field.
|
|
@V The value of VERSION, as given in the defaults file.
|
|
To display a single '@' character, use either '\@' or '@@'.
|
|
</verb></tscreen>
|
|
|
|
<sect1>Customizing uugetty
|
|
|
|
<p> There are lots of parameters you can tweak for each port you have.
|
|
These are implemented in separate config files for each port.
|
|
The file <tt>/etc/conf.uugetty</tt> will be used by <em/all/
|
|
instances of <tt/uugetty/, and <tt>/etc/conf.uugetty.ttyS</tt><em/N/
|
|
will only be used by that one port. Sample default config files can
|
|
be found with the <tt/getty_ps/ source files, which come with most
|
|
Linux distributions. Due to space concerns,
|
|
they are not listed here. Note that if you are using older versions
|
|
of <tt/uugetty/ (older than 2.0.7e), or aren't using FSSTND, then the
|
|
default file will be <tt>/etc/default/uugetty.ttyS</tt><em/N/. Greg's
|
|
<tt>/etc/conf.uugetty.ttyS3</tt> looked like this:
|
|
<tscreen><verb>
|
|
# sample uugetty configuration file for a Hayes compatible modem to allow
|
|
# incoming modem connections
|
|
#
|
|
# line to initialize
|
|
INITLINE=ttyS3
|
|
# timeout to disconnect if idle...
|
|
TIMEOUT=60
|
|
# modem initialization string...
|
|
# format: <expect> <send> ... (chat sequence)
|
|
INIT="" AT\r OK\r\n
|
|
WAITFOR=RING
|
|
CONNECT="" ATA\r CONNECT\s\A
|
|
# this line sets the time to delay before sending the login banner
|
|
DELAY=1
|
|
#DEBUG=010
|
|
</verb></tscreen>
|
|
<p>
|
|
Add the following line to your <tt>/etc/inittab</tt>, so that
|
|
<tt/uugetty/ is run on your serial port, substituting in the correct
|
|
information for your environment - run-levels (2345 or 345, etc.)
|
|
config file location, port, speed, and default terminal type:
|
|
|
|
<tscreen><verb>
|
|
S3:2345:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS3 ttyS3 F115200 vt100
|
|
</verb></tscreen>
|
|
Restart <tt/init/:
|
|
<tscreen><verb>
|
|
linux# init q
|
|
</verb></tscreen>
|
|
For the speed parameter in your <tt>/etc/inittab</tt>, you want to use
|
|
the highest bps rate that your modem supports.
|
|
<p>
|
|
Now Linux will be watching your serial port for connections.
|
|
Dial in from another machine and login to you Linux system.
|
|
|
|
<p> <tt/uugetty/ has a lot more options, see the man
|
|
page for <tt/uugetty)/ (often just called <tt/getty/) for a full
|
|
description. Among other things there is a scheduling feature, and a
|
|
ringback feature.
|
|
|
|
<sect>What Speed Should I Use with My Modem? <label id="speed_">
|
|
|
|
<p> By "speed" we really mean the "data flow rate" but almost everybody
|
|
incorrectly calls it speed. For all modern modems you have no choice
|
|
of the speed that the modem uses on the telephone line since it will
|
|
automatically choose the highest possible speed that is feasible under
|
|
the circumstances. If one modem is slower than the other, then the
|
|
faster modem will operate at the slower modem's speed. On a noisy
|
|
line, the speed will drop still lower.
|
|
|
|
While the above speeds are selected automatically by the modems you do
|
|
have a choice as to what speed will be used between your modem and
|
|
your computer (PC-to-modem speed). This is sometimes called "DTE
|
|
speed" where "DTE" stands for Data Terminal Equipment (Your computer
|
|
is a DTE.) You need to set this speed high enough so this part of the
|
|
signal path will not be a bottleneck. The setting for the DTE speed
|
|
is the maximum speed of this link. Most of the time it will likely
|
|
actually operate at lower speeds.
|
|
|
|
For an external modem, DTE speed is the speed (in bits/sec) of the
|
|
flow over the cable between you modem and PC. For an internal modem,
|
|
it's the same idea since the modem also emulates a serial port. It
|
|
may seem ridiculous having a speed limit on communication between a
|
|
computer and a modem card that is directly connected inside the
|
|
computer to a much higher speed bus. But it's usually that way since
|
|
the modem card probably includes a dedicated serial port which does
|
|
have speed limits (and settable speeds). However, some software
|
|
modems have no such speed limits.
|
|
|
|
<sect1> Speed and Data Compression
|
|
<p> What speed do you choose? If it were not for "data compression"
|
|
one might try to choose a DTE speed exactly the same as the modem
|
|
speed. Data compression takes the bytes sent to the modem from your
|
|
computer and encodes them into a fewer number of bytes. For example,
|
|
if the flow (speed) from the PC to the modem was 20,000 bytes/sec
|
|
(bps) and the compression ratio was 2 to 1, then only 10,000 bytes/sec
|
|
would flow over the telephone line. Thus for a 2:1 compression ratio
|
|
you would need to set the DTE speed to double the maximum modem speed
|
|
on the phone line. If the compression ratio were 3 to 1 you would
|
|
need to set it 3 times faster, etc.
|
|
|
|
<sect1> Where do I Set Speed ?
|
|
<p> This DTE (PC-to-modem) speed is normally set by a menu in your
|
|
communications program or by an option given to the getty command if
|
|
someone is dialing in. You can't set the DCE modem-to-modem speed
|
|
since this is set automatically by the modem to the highest feasible
|
|
speed after negotiation with the other modem. Well, actually you can
|
|
set the modem-to-modem speed with the S37 register but you shouldn't
|
|
do it. If the two modems on a connection were to be set this way to
|
|
different speeds, then they couldn't communicate with each other.
|
|
|
|
<sect1> Can't Set a High Enough Speed <label id="high_speed">
|
|
<!-- high_speed.D begin In Serial and Modem HOWTOs but some of the speed
|
|
section is unique to each HOWTO.
|
|
Feb. 2003,
|
|
-->
|
|
<sect2> Speeds over 115.2kbps
|
|
<p> The top speed of 115.2k has been standard since the mid 1990's.
|
|
But by the year 2000, most new serial ports supported higher speeds of
|
|
230.4k and 460.8k. Some also support 921.6k. Unfortunately Linux
|
|
seldom uses these speeds due to lack of drivers. Thus such ports
|
|
behave just like 115.2k ports unless the higher speeds are enabled by
|
|
special software. To get these speeds you need to compile the kernel
|
|
with special patches or use modules until support is built into the
|
|
kernel's serial driver.
|
|
|
|
Unfortunately serial port manufacturers never got together on a
|
|
standard way to support high speeds, so the serial driver needs to
|
|
support a variety of hardware. Once high speed is enabled, a standard
|
|
way to choose it is to set baud_base to the highest speed with
|
|
setserial (unless the serial driver does this for you). The software
|
|
will then use a divisor of 1 to set the highest speed. All this will
|
|
hopefully be supported by the Linux kernel sometime in 2003.
|
|
|
|
A driver for the w83627hf chip (used on many motherboards such as
|
|
the Tyan S2460) is at <url url="https://www.muru.com/linux/w83627hf/">
|
|
|
|
A non-standard way that some manufacturers have implemented high speed
|
|
is to use a very large number for the divisor to get the high speed.
|
|
This number isn't really a divisor at all since it doesn't divide
|
|
anything. It's just serves as a code number to tell the hardware what
|
|
speed to use. In such cases you need to compile the kernel with
|
|
special patches.
|
|
|
|
One patch to support this second type of high-speed hardware is called
|
|
shsmod (Super High Speed Mode). There are both Windows and Linux
|
|
versions of this patch. See <url
|
|
url="http://www.devdrv.com/shsmod/">. There is also a module for the
|
|
VIA VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it
|
|
may result in buffer overflow.
|
|
|
|
For internal modems, only a minority of them advertise that they
|
|
support speeds of over 115.2k for their built-in serial ports.
|
|
Does shsmod support these ??
|
|
|
|
<sect2> How speed is set in hardware: the divisor and baud_base <label
|
|
id="divisor_">
|
|
<p> Speed is set by having the serial port's clock change frequency.
|
|
But this change happens not by actually changing the frequency of the
|
|
oscillator driving the clock but by "dividing" the clock's frequency.
|
|
For example, to divide by two, just ignore every other clock tick.
|
|
This cuts the speed in half. Dividing by 3 makes the clock run at 1/3
|
|
frequency, etc. So to slow the clock down (meaning set speed), we
|
|
just send the clock a divisor. It's sent by the serial driver to a
|
|
register in the port. Thus speed is set by a divisor.
|
|
|
|
If the clock runs at a top speed of 115,000 bps (common), then here
|
|
are the divisors for various speeds (assuming a maximum speed of
|
|
115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24
|
|
(4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speed
|
|
in the hardware by sending the hardware only a "divisor" (a positive
|
|
integer). This "divisor" divides the "maximum speed" of the hardware
|
|
resulting in a slower speed (except a divisor of 1 obviously tells the
|
|
hardware to run at maximum speed).
|
|
|
|
There are exceptions to the above since for certain serial port
|
|
hardware, speeds above 115.2k are set by using a very high divisor.
|
|
Keep that exception in mind as you read the rest of this section.
|
|
Normally, if you specify a speed of 115.2k (in your communication
|
|
program or by stty) then the serial driver sets the port hardware to
|
|
divisor 1 which sets the highest speed.
|
|
|
|
Besides using a very high divisor to set high speed, the conventional
|
|
way to do it is as follows: If you happen to have hardware with a
|
|
maximum speed of say 230.4k (and the 230.4k speed has been enabled in
|
|
the hardware), then specifying 115.2k will result in divisor 1. For
|
|
some hardware this will actually give you 230.4k. This is double the
|
|
speed that you set. In fact, for any speed you set, the actual speed
|
|
will be double. If you had hardware that could run at 460.8k then the
|
|
actual speed would be quadruple what you set. All the above assumes
|
|
that you don't use "setserial" to modify things.
|
|
|
|
<sect2> Setting the divisor, speed accounting
|
|
<p> To correct this accounting (but not always fix the problem) you
|
|
may use "setserial" to change the baud_base to the actual maximal
|
|
speed of your port such as 230.4k. Then if you set the speed (by your
|
|
application or by stty) to 230.4k, a divisor of 1 will be used and
|
|
you'll get the same speed as you set.
|
|
|
|
If you have very old software which will not allow you to tell it such
|
|
a high speed (but your hardware has it enabled) then you might want to
|
|
look into using the "spd_cust" parameter. This allows you to tell the
|
|
application that the speed is 38,400 but the actual speed for this
|
|
case is determined by the value of "divisor" which has also been set
|
|
in setserial. I think it best to try to avoid using this kludge.
|
|
|
|
There are some brands of UARTs that uses a very high divisor to set
|
|
high speeds. There isn't any satisfactory way to use "setserial" (say
|
|
set "divisor 32770") to get such a speed since then setserial would
|
|
then think that the speed is very low and disable the FIFO in the
|
|
UART.
|
|
|
|
<sect2> Crystal frequency is higher than baud_base
|
|
<p> Note that the baud_base setting is usually much lower than the
|
|
frequency of the crystal oscillator since the crystal frequency of say
|
|
1.8432 MHz is divided by 16 in the hardware to get the actual top
|
|
speed of 115.2k. The reason the crystal frequency needs to be higher
|
|
is so that this high crystal speed can generate clock ticks to take a
|
|
number of samples of each bit to determine if it's a 1 or a 0.
|
|
|
|
Actually, the 1.8432 MHz "crystal frequency" may be obtained from a
|
|
18.432 MHz crystal oscillator by dividing by 10 before being fed to
|
|
the UART. Other schemes are also possible as long as the UART
|
|
performs properly.
|
|
|
|
<!-- high_speed.D end -->
|
|
|
|
|
|
<sect1> Speed Table <label id="speed_table">
|
|
<p> It's best to have at least a 16650 UART for a 56k modem but few
|
|
modems or serial ports provide it. Second best is a 16550 that has
|
|
been tweaked to give 230,400 bps (230.4 kbps). Most people still use
|
|
a 16550 that is only 115.2 kbps but it's claimed to only slow down
|
|
thruput by a few percent (on average). This is because a typical
|
|
compression ratio is 2 to 1 and for downloading compressed files
|
|
(packages) it's 1 to 1. There's no degradation for these cases. Here
|
|
are some suggested speeds to set your serial line if your modem speed
|
|
is:
|
|
|
|
<itemize>
|
|
<item> 56k (V.92): use 115.2 kbps or 230.4 kbps (best)
|
|
<item> 56k (V.90): use 115.2 kbps or 230.4 kbps (best)
|
|
<item> 33.6k (V.34bis): use 115.2 kbps
|
|
<item> 28.8k (V.34): use 115.2 kbps
|
|
<item> 14.4k (V.32bis): use 57600 bps
|
|
<item> 9.6k (V.32): use 38400 bps
|
|
<item> slower than a 9600 bps (V.32) modem: Set the speed to the
|
|
same speed as the modem (unless you have data compression).
|
|
</itemize>
|
|
|
|
All the above speeds may use V.42bis data compression and V.42 error
|
|
correction. If data compression is not used then the speed may be set
|
|
lower so long as it's above the modem speed.
|
|
|
|
<sect>Communications Programs And Utilities<label id="comm_">
|
|
|
|
<p> While PPP is used for Internet access you also need a dialer
|
|
program (or script) that will dial a phone number and then start PPP
|
|
once a connection is made. When the other side answers the phone,
|
|
then three things happen: a modem connection is established (CONNECT),
|
|
PPP is started at both ends, and you get logged in automatically. The
|
|
exact sequence of the last 2 events may vary. Dialer programs for ppp
|
|
include wvdial, chap scripts, kppp, RP3 (front end to wvdial and
|
|
ifup), gnome-ppp, and "modem lights" (Gnome). Linuxconf configures
|
|
some dialers.
|
|
|
|
There are also older dialer programs which can dial out (via a modem)
|
|
but don't connect to the Internet. Instead, you get connected to a
|
|
computer somewhere that puts a text image on your screen. This was
|
|
much used in the past to connect to Bulletin Boards. See <ref
|
|
id="bbs_" name="PCs and BBSs"> Today, it might be used to connect to
|
|
a remote computer that you may login to (including a PC at home).
|
|
Programs for this are: <tt/minicom/ (the most popular), <tt/Seyon/
|
|
(X-Windows only) and <tt/Kermit/. Some people have likely also used
|
|
these programs for dialing out with ppp for the Internet but it's not
|
|
what they were originally designed for.
|
|
|
|
<sect1> Minicom vs. Kermit
|
|
<p> Minicom is only a communications program while Kermit is both a
|
|
communications program and a file transfer protocol. But one may use
|
|
the Kermit protocol from within Minicom (provided one has Kermit
|
|
installed on one's PC). Minicom is menu based while Kermit is
|
|
command line based (interactive at the special Kermit prompt). While
|
|
the Kermit program is free software, the documentation is not all
|
|
free. There is no detailed manual supplied and it is suggested that
|
|
you purchase a book as the manual. However Kermit has interactive
|
|
online help which tells all but lacks tutorial explanations for the
|
|
beginner. Commands may be put in a script file so you don't have to
|
|
type them over again each time. Kermit (as a communications program)
|
|
is more powerful than Minicom.
|
|
|
|
Although all Minicom documentation is free, it's not as extensive as
|
|
Kermit's. In my opinion it's easier to set up Minicom, there is less
|
|
to learn, and you can still use kermit from within Minicom. But if
|
|
you want to write a script for automatically doing file transfers,
|
|
etc. Kermit is better.
|
|
|
|
g-kermit is a gpled kermit which has no dialout capabilities.
|
|
|
|
<sect1> List of Communication Software
|
|
<p> Here is a list of some communication software you can choose from,
|
|
If they didn't come with your distribution they should be available
|
|
via FTP. I would like comparative comments on the dialout programs.
|
|
Are the least popular ones obsolete?
|
|
|
|
<sect2> Least Popular Dialout
|
|
<p> <itemize>
|
|
<item><tt/ecu/ - a communications program
|
|
<item><tt/pcomm/ - <tt/procomm/-like communications program with zmodem
|
|
<item><tt/xc/ - xcomm communication package
|
|
</itemize>
|
|
|
|
<sect2> Most Popular Dialout
|
|
<p> <itemize>
|
|
<item> PPP dialers for getting on the internet: <tt/wvdial/, <tt/eznet/,
|
|
<tt/chat/, <tt/pon/ (uses chat),
|
|
<item><tt/minicom/ - <tt/telix/-like communications program. Can work
|
|
with scripts, zmodem, kermit
|
|
<item><url url="http://www.columbia.edu/kermit/" name="C-Kermit"> -
|
|
portable, scriptable, serial and TCP/IP communications including file
|
|
transfer, character-set translation, and zmodem support
|
|
<item><tt/seyon/ - X based communication program
|
|
</itemize>
|
|
|
|
<sect2> Fax <label id="fax_">
|
|
<p> By using a fax program, you may use most modems to send faxes.
|
|
In this case you dial out directly and not via ppp and an ISP. You
|
|
also pay any long-distance telephone charges. email is more
|
|
efficient.
|
|
|
|
<itemize>
|
|
<item> <tt/efax/ is a small fax program
|
|
<item> <tt/hylafax/ is a large fax program based on the client-server
|
|
model.
|
|
<item><tt/mgetty+fax/ handles fax stuff and login for dial-ins
|
|
<item>A fax protocol tutorial
|
|
<url url="http://www.iec.org/online/tutorials/vfoip/topic08.html">
|
|
</itemize>
|
|
|
|
<sect2> Voicemail Software <label id="voice_sw">
|
|
<p> <itemize>
|
|
<item> vgetty is an extension to mgetty that handles voicemail for
|
|
some modems. It should come with recent releases of mgetty.
|
|
<item> <url url="http://vocp.sourceforge.net/" name="VOCP">is a
|
|
"complete voice messaging" system for Linux.
|
|
|
|
</itemize>
|
|
|
|
<sect2> Dial-in (uses getty)
|
|
<p> <itemize>
|
|
<item><tt/mgetty+fax/ is for modems and is well documented (except for
|
|
voicemail as of early 1999). It also handles fax stuff and provides
|
|
an alternative to <tt/uugetty/. It's incorporating voicemail (using
|
|
vgetty) features. See <ref id="mgetty_" name="About mgetty">
|
|
|
|
<item> <tt/uugetty/ is also for modems. It comes as a part of the
|
|
<tt/ps_getty/ package. See <ref id="uugetty_" name="About
|
|
getty_ps"></itemize>
|
|
|
|
<sect2>Network Connection
|
|
<p>
|
|
<itemize>
|
|
<item><tt/ser2net/
|
|
<item><tt/sredird/
|
|
</itemize>
|
|
|
|
<sect2>Other
|
|
<p> <itemize>
|
|
<item><tt/callback/ is where you dial out to a remote modem and then
|
|
that modem hangs up and calls you back (to save on phone bills).
|
|
|
|
<item><tt/xringd/ listens for rings and detects inter-ring times etc.
|
|
|
|
<item><tt/SLiRP/ and <tt/term/ provide a PPP-like service that you can
|
|
run in user space on a remote computer with a shell account.
|
|
See <ref id="term+slurp" name="term and SLiRP"> for more details
|
|
|
|
<item><tt/ZyXEL/ is a control program for ZyXEL U-1496 modems. It
|
|
handles dialin, dialout, dial back security, FAXing, and voice
|
|
mailbox functions.
|
|
|
|
<item>SLIP and PPP software can be found at
|
|
<tt> <htmlurl
|
|
url="ftp://metalab.unc.edu/pub/Linux/system/network/serial/"
|
|
name="ftp://metalab.unc.edu/pub/Linux/system/network/serial/"></tt>.
|
|
|
|
<item>Other things can be found on
|
|
<tt><htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/serial"
|
|
name="ftp://metalab.unc.edu/pub/Linux/system/serial"></tt> and
|
|
<tt><htmlurl url="ftp://metalab.unc.edu/pub/Linux/apps/serialcomm"
|
|
name="ftp://metalab.unc.edu/pub/Linux/apps/serialcomm"></tt> or one of the
|
|
many mirrors. These are the directories where serial programs are kept.
|
|
</itemize>
|
|
|
|
<sect1> SLiRP and term <label id="term+slurp">
|
|
<p> <tt/SLiRP/ and <tt/term/ are programs which are of use if you only
|
|
have a dial-up shell account on a Unix-like machine and want to get
|
|
the equivalent of a PPP account (or the like) without being authorized
|
|
to have it (possibly because you don't want to pay extra for it, etc.).
|
|
<tt/SLiRP/ is more popular than <tt/term/ which is almost obsolete.
|
|
|
|
To use <tt/SLiRP/ you install it in your shell account on the remote
|
|
computer. Then you dial up the account and run SLiRP on the remote
|
|
and PPP on your local PC. You now have a PPP connection over which
|
|
you may run a web browser on your local PC such as Netscape, etc.
|
|
There may be some problems as SLiRP is not as good as a real PPP
|
|
account. Some accounts may provide SLiRP since it saves on IP
|
|
addresses (You have no IP address while using SLiRP).
|
|
|
|
<tt/term/ is something like SLiRP only you need to run <tt/term/ on
|
|
both the local and remote computer. There is no PPP on the phone line
|
|
since <tt/term/ uses its own protocol. To use <tt/term/ from your PC
|
|
you need to use a term-aware version of ftp to do ftp, etc. Thus it's
|
|
easier to use SLiRP since the ordinary version of ftp works fine with
|
|
SLiRP. There is an unmaintained Term HOWTO.
|
|
|
|
<sect1> MS Windows
|
|
<p> If you want someone who uses MS Windows to dial in to your Linux
|
|
PC then if they use:
|
|
<itemize>
|
|
<item> Windows 3.x: use <tt/Terminal/
|
|
<item> Windows 95/98/2000: use <tt/HyperTerminal/
|
|
</itemize>
|
|
|
|
Third party dial-out programs include HyperTerminal Private Edition.
|
|
|
|
<sect> Two Modems (Modem Doubling)
|
|
<sect1> Introduction
|
|
<p> By using two modems at the same time, the flow of data can be
|
|
doubled. It takes two modems and two phone lines. There are two
|
|
methods of doing this. One is "modem bonding" where software at both
|
|
ends of the modem-to-modem connection enables the paired modems to
|
|
work like a single channel.
|
|
|
|
The second method is called "modem teaming. Only one end of the
|
|
connection uses software to make 2 different connections to the
|
|
internet. Then when a file is to be downloaded, one modem gets the
|
|
first half of the file. The second modems simultaneously gets the
|
|
last half of the same file by pretending that it's resuming a download
|
|
that was interrupted in the middle of the file. Is there any modem
|
|
teaming support in Linux ??
|
|
|
|
<sect1> Modem Bonding
|
|
<p> There are two ways to do this in Linux: EQL and multilink. These
|
|
are provided as part of the Linux kernel (provided they've been
|
|
selected when the kernel was compiled). For multilink the kernel
|
|
must be at least v.2.4. Both ends of the connection must run them.
|
|
Few (if any) ISPs provide EQL but many provide Multilink.
|
|
|
|
The way it works is something like multiplexing only it's the other
|
|
way around. Thus it's called inverse-multiplexing. For the multilink
|
|
case, suppose you're sending some packets. The first packet goes out on
|
|
modem1 while the second packet is going out on modem2. Then the third
|
|
packet follows the first packet on modem1. The forth packet goes on
|
|
modem2, etc. To keep each modem busy, it may be necessary to send out
|
|
more packets on one modem than the other. Since EQL is not packet
|
|
based, it doesn't split up the flow on packet boundaries.
|
|
|
|
<sect2> EQL
|
|
<p>EQL is "serial line load balancing" which has been available for
|
|
Linux since at least 1995. An old (1995) howto on it is in the kernel
|
|
documentation (in the networking subdirectory). Unfortunately, ISPs
|
|
don't seem to provide EQL.
|
|
|
|
<sect2> Multilink
|
|
<p> Staring with kernel 2.4 in 2000, experimental support is provided
|
|
for multilink. It must be selected when compiling the kernel and it
|
|
only works with PPP.
|
|
|
|
<sect>ISDN "Modems"
|
|
<p> To use ISDN you must have a special ISDN telephone line supplied
|
|
by your telephone company at additional cost. An ISDN "modem" is
|
|
really a Terminal Adapter (TA). Like analog modems, there are
|
|
internal ones on cards and external ones that connect to serial ports.
|
|
|
|
<sect1>External ISDN "Modems"
|
|
<p>Configuring an external ISDN modem on a serial port is about the
|
|
same as configuring an analog modem. The main difference is in the
|
|
init string. Unfortunately, the init strings are different for
|
|
different models of ISDN modems. There is often one AT command for a
|
|
speed of 64k and another for 128k, etc. So you need to find out what
|
|
init string to use and tell it to say wvdial, etc.
|
|
|
|
<sect1>Internal ISDN "Modems"
|
|
<p>Support for some of these cards can be built into the 2.4 or 2.6
|
|
kernels or added as a module. The tty ports are ttyI2 for example.
|
|
The kernel documentation has an "isdn" subdirectory which describes
|
|
various drivers which support various isdn cards. A major website for
|
|
ISDN is <url url="http://www.isdn4linux.de">
|
|
|
|
For configuring, one might use the "isdn-config" GUI. A Debian
|
|
package "isdnutils" is available. There is SuSE ISDN Howto (not a LDP
|
|
Howto) which is translated from German <url
|
|
url="http://sol.parkland.cc.il.us/sdb/en/html/isdn.html"> There is an
|
|
isdn4linux package and a newsgroup: de.alt.comm.isdn4linux. Many of
|
|
the postings are in German.
|
|
|
|
<sect>Troubleshooting <label id="trouble_shoot">
|
|
|
|
<sect1> My Modem is Physically There but Can't be Found <label
|
|
id="cant_find_modem">
|
|
|
|
<p>The error message might also be something like "Modem
|
|
not responding". There are at least 4 possible reasons:
|
|
<enum>
|
|
<item> Your modem is a winmodem and no working driver has been
|
|
installed for it. Or the modem is defective or in "online data mode"
|
|
where it doesn't respond. See <ref id="winmodem_">
|
|
<item>Your modem is disabled since both the BIOS and Linux failed to
|
|
enable it. It has no IO address.
|
|
<item>Your modem is enabled and has an IO address but it has no ttyS
|
|
device number (like ttyS14) assigned to that address so the modem
|
|
can't be used.
|
|
<item>You modem does have a ttyS number assigned to it (like ttyS4)
|
|
but you are using the wrong ttyS number (like ttyS2 instead of
|
|
ttyS4). See <ref id="wrong_ttySx"> and/or <ref id="wvdial_"
|
|
name="wvdial"> and/or <ref id="minicom_test" name="minicom (test
|
|
modem)">
|
|
</enum>
|
|
|
|
<sect2>Case 1: Winmodem <label id="winmodem_">
|
|
<p>For a winmodem with no driver (or a defective modem) the serial
|
|
port that the modem is on can usually be found OK. But when the
|
|
wvdial program (or whatever) interrogates that port, it gets no
|
|
response since winmodems need a driver to do anything. So you see a
|
|
message saying that no modem was found. However, it's likely that the
|
|
modem card was detected at boot-time and it displays a message
|
|
implying that a modem was found. So you're told both that the modem
|
|
was found and that it wasn't found! What it all means is that no
|
|
working modem has been found, since a modem that doesn't work has been
|
|
found. Of course it could not be working for reasons other than being
|
|
a winmodem (or linmodem) with no driver. See <ref id="soft_modem"
|
|
name="Software-based Modems (winmodems, linmodems)">.
|
|
|
|
<sect2>Cases 2-3
|
|
<p>Cases 2. and 3. mean that no serial port device (such as
|
|
/dev/ttyS2) exists for the modem. If you suspect this, see <ref
|
|
id="cant_find_port" name="Serial Port Can't be Found">.
|
|
|
|
<sect2>Case 4: Wrong ttySx number <label id="wrong_ttySx">
|
|
<p>If you are lucky, the problem is case 4. Then you just need to find
|
|
which ttyS your modem is on.
|
|
|
|
<sect2> wvdial <label id="wvdial_">
|
|
<p>There's a program that looks for modems on commonly used serial
|
|
ports called "wvdialconf". Just type "wvdialconf
|
|
<a-new-file-name>". It will create the new file as a
|
|
configuration file but you don't need this file unless you are going
|
|
to use "wvdial" for dialing. See <ref id="wvdial_" name="What is
|
|
wvdialconf ?"> Unfortunately, if your modem is in "online data" mode,
|
|
wvdialconf will report "No modem detected". See <ref
|
|
id="minicom_test" name="minicom (test modem)">
|
|
|
|
<sect2> minicom (test modem) <label id="minicom_test">
|
|
<p>Another way try to find out if there's a modem on a certain port is
|
|
to start "minicom" on the port (after first setting up minicom for
|
|
that serial port. You will need to save the setup and then exit
|
|
minicom and start it again. Then type "AT" and you should see "OK".
|
|
If you don't, try typing ATQ0 V1 EI. If you still don't get OK (and
|
|
likely don't even see the AT you typed) then there is likely no modem
|
|
on the port. This may be due to either case 1. 2. or 3. above
|
|
|
|
If what you type is really getting thru to a modem, then the lack of
|
|
response could be due to the modem being in "online data" mode where
|
|
it can't accept any AT commands. You may have been using the modem
|
|
and then abruptly disconnected (such as killing the process with
|
|
signal 9). In that case your modem did not get reset to "command
|
|
mode" where it can interact to AT commands. "Minicom" may display
|
|
"You are already online. Hangup first." (For another meaning of this
|
|
minicom message see <ref id="already_online" name= "You are already
|
|
online! Hang up first.">) Well, you are sort of online but you are
|
|
may not be connected to anything over the phone line. Wvdial will
|
|
report "modem not responding" for the same situation.
|
|
|
|
To fix this as a last resort you could reboot the computer. Another
|
|
way to try to fix this is to send +++ to the modem to tell it to
|
|
escape back to "command mode" from "online data mode". On both sides
|
|
of the +++ sequence there must be about 1 second of delay (nothing
|
|
sent during "guard time"). This may not work if another process is
|
|
using the modem since the +++ sequence could wind up with other
|
|
characters inserted in between them or after the +++ (during the guard
|
|
time). Ironically, even if the modem line is idle, typing an
|
|
unexpected +++ is likely to set off an exchange of control packets
|
|
(that you never see) that will violate the required guard time so
|
|
that the +++ doesn't do what you wanted. +++ is usually in the string
|
|
that is named "hangup string" so if you command minicom (or the like)
|
|
to hangup it might work. Another way to do this is to just exit
|
|
minicom and then run minicom again.
|
|
|
|
Other problems which you might observe in minicom besides no response
|
|
to AT are:
|
|
<itemize>
|
|
<item> It takes many seconds to get an expected truncated response
|
|
(including only the cursor moving down one line). See <ref id="slow_"
|
|
name="Extremely Slow: Text appears on the screen slowly after long
|
|
delays">
|
|
<item> Some strange characters appear but they are not in response to
|
|
AT. This likely means that your modem is still connected to something
|
|
at the other end of the phone line which is sending some cryptic
|
|
packets or the like.
|
|
</itemize>
|
|
|
|
<sect1> "Modem is busy"
|
|
<p> What this means depends on what program sent it. The modem could
|
|
actually be in use (busy). Another cause reported for the SuSE
|
|
distribution is that there may be two serial drivers present instead
|
|
of one. One driver was built into the kernel and the second was a
|
|
module.
|
|
|
|
In kppp, this message is sent when an attempt to get/set the serial
|
|
port "stty" parameters fails. (It's similar to the "Input/output
|
|
error" one may get when trying to use "stty -F /dev/ttySx"). To get a
|
|
few of these stty parameters, the true address of the port must be
|
|
known to the driver. So the driver may have the wrong address. The
|
|
setserial" command will display what the driver thinks but it's likely
|
|
wrong in this case. So what the "modem busy" often means is that the
|
|
serial port (and thus the modem) can't be found.
|
|
|
|
If you have a pci modem, then use one of these commands: lspci -v, or
|
|
cat /proc/pci, or dmesg to find the correct address and irq of the
|
|
modem's serial port. Then check to see if "setserial" shows the same
|
|
thing. If not, you need to run a script at boot-time which contains a
|
|
setserial command that will tell the driver the correct address and
|
|
irq.
|
|
|
|
<sect1> "You are already online! Hang up first." (from minicom)
|
|
<label id="already_online">
|
|
<p> The modem has its CD signal on. Either you are actually online
|
|
(a remote modem is sending you a carrier) or your modem has been setup
|
|
to always send the CD signal. In minicom, type at&v to see if
|
|
&C or &C0 is set. If so, CD will be on even if you are
|
|
offline and you'll erroneously get this error message. The fix is to
|
|
set &C1 in the init string or save it in the modem.
|
|
|
|
<sect1> I can't get near 56k on my 56k modem
|
|
<p> There must be very low noise on the line for it to work at even
|
|
close to 56k. Some phone lines are so bad that the speeds obtainable
|
|
are much slower than 56k (like 28.8k or even slower). Sometimes
|
|
extension phones connected to the same line can cause problems. To
|
|
test this you might connect your modem directly at the point where the
|
|
telephone line enters the building with the feeds for everything else
|
|
on that line disconnected (if others can tolerate such a test).
|
|
|
|
<sect1> Uploading (downloading) files is broken/slow
|
|
<p> Flow control (both at your PC and/or modem-to-modem) may not be
|
|
enabled. For the uploading case: If you have set a high DTE speed
|
|
(like 115.2k) then flow from your modem to your PC may work OK but
|
|
uploading flow in the other direction will not all get thru due to the
|
|
telephone line bottleneck. This will result in many errors and the
|
|
resending of packets. It may thus take far too long to send a file.
|
|
In some cases, files don't make it thru at all.
|
|
|
|
For the downloading case: If you're downloading long uncompressed
|
|
files or web pages (and your modem uses data compression) or if you've
|
|
set a low DTE speed, then downloading may also be broken due to no
|
|
flow control.
|
|
|
|
<sect1>For Dial-in I Keep Getting "line NNN of inittab invalid"
|
|
<p>
|
|
Make sure you are using the correct syntax for your version of
|
|
<tt/init/. The different <tt/init/'s that are out there use different
|
|
syntax in the <tt>/etc/inittab</tt> file. Make sure you are using the
|
|
correct syntax for your version of <tt/getty/.
|
|
|
|
<sect1>I Keep Getting: ``Id "S4" respawning too fast: disabled for 5 minutes''
|
|
<p> Id "S4" is just an example. In this case look on the line which
|
|
starts with "S4" in <tt>/etc/inittab</tt> and calls getty. This line
|
|
causes the problem. Make sure the syntax for this line is correct and
|
|
that the device (ttyS4) exists and can be found. If the modem has
|
|
negated CD and getty opens the port, you'll get this error message
|
|
since negated CD will kill getty. Then getty will respawn only to be
|
|
killed again, etc. Thus it respawns over and over (too fast). It
|
|
seems that if the cable to the modem is disconnected or you have the
|
|
wrong serial port, it's just like CD is negated. All this can occur
|
|
when your modem is chatting with getty. Make sure your modem is
|
|
configured correctly. Look at AT commands <tt/E/ and <tt/Q/.
|
|
|
|
<p>
|
|
If you use uugetty, verify that your <tt>/etc/gettydefs</tt> syntax is
|
|
correct by doing the following:
|
|
<tscreen><verb>
|
|
linux# getty -c /etc/gettydefs
|
|
</verb></tscreen>
|
|
|
|
This can also happen when the <tt/uugetty/ initialization is failing.
|
|
See section <ref id="uu_nowork" name="uugetty Still Doesn't Work">.
|
|
|
|
<sect1>Dial-in: When remote user hangs up, getty doesn't respawn
|
|
<p> One possible cause is that your modem doesn't reset right when DTR
|
|
is dropped after someone hangs up. Most Hayes compatible modems do
|
|
this OK with <tt/&D3/. But for USR Courier, SupraFax, and some
|
|
other modems, you must set <tt/&D2/ (and <tt/S13=1/ in some
|
|
cases). Check your modem manual (if you have one). See <ref
|
|
id="end_dialin" name="Ending a Dial-in Call">
|
|
|
|
<sect1>NO DIALTONE
|
|
<p>It means exactly what it says. Someone else may be using another
|
|
telephone on the same line. You also get this error if there is no
|
|
phone line plugged into the modem, or if the phone line is somehow
|
|
broken. Try plugging a real telephone into the phone cord used by the
|
|
modem. Check it for a dialtone.
|
|
|
|
If for some reason your modem doesn't detect a dialtone, then you can
|
|
force it to dial anyway by putting X3 in the init string.
|
|
|
|
<sect1> NO CARRIER
|
|
<p>This means that the analog sine wave (the carrier) from the other
|
|
modem isn't present like it should be. If you were already connected,
|
|
this means that the connection has been lost. There may have been
|
|
noise on the line or a bad connection. The other modem may have hung
|
|
up on you for some reason: Perhaps the automatic login process
|
|
didn't work out OK. Perhaps PPP didn't get started OK. Perhaps a
|
|
time limit was exceeded.
|
|
|
|
If you get this error before you get connected, it means that the
|
|
carrier of the other modem wasn't detected by your modem. This may
|
|
happen if there is there is no properly working modem on the other
|
|
end. For example, an answering machine could have picked up your
|
|
call instead of a modem. NO CARRIER will also happen if the modems
|
|
fail to negotiate a protocol to use. This can happen if you have an
|
|
early V.90 modem that first tries to negotiate a high speed X2 or
|
|
K56flex protocol. These two protocols are obsolete and some ISP
|
|
servers will drop the connection (hang up) when this happens since
|
|
they have no understanding of such protocols and don't wait around
|
|
long enough for the calling modem to fallback to V.90.
|
|
|
|
If you force your modem to drop the connection by dropping the DTR
|
|
signal or sending your modem the hangup signal (ATH) you may get this
|
|
error message. But in this case you (or your software) wanted to drop
|
|
the connection so there should be no problem. In this case you are
|
|
only supposed to get NO CARRIER if data was lost. So for most cases
|
|
of dropping a connection by hangup (or by dropping DTR) you only get
|
|
an OK message. Your modem dialer program may not even display that to
|
|
you.
|
|
|
|
<sect1> uugetty Still Doesn't Work <label id="uu_nowork">
|
|
<p>
|
|
There is a <tt/DEBUG/ option that comes with <tt/getty_ps/. Edit your
|
|
config file
|
|
<tt>/etc/conf.{uu}getty.ttyS</tt><em/N/ and
|
|
add <tt/DEBUG=/<em/NNN/. Where <EM/NNN/ is one of the following
|
|
combination of numbers according to what you are trying to debug:
|
|
<tscreen><verb>
|
|
D_OPT 001 option settings
|
|
D_DEF 002 defaults file processing
|
|
D_UTMP 004 utmp/wtmp processing
|
|
D_INIT 010 line initialization (INIT)
|
|
D_GTAB 020 gettytab file processing
|
|
D_RUN 040 other runtime diagnostics
|
|
D_RB 100 ringback debugging
|
|
D_LOCK 200 uugetty lockfile processing
|
|
D_SCH 400 schedule processing
|
|
D_ALL 777 everything
|
|
</verb></tscreen>
|
|
Setting <tt/DEBUG=010/ is a good place to start.
|
|
<p>
|
|
If you are running <tt/syslogd/, debugging info
|
|
will appear in your log files. If you aren't running <tt/syslogd/
|
|
info will appear in <tt>/tmp/getty:ttyS</tt><em/N/ for debugging
|
|
<tt/getty/
|
|
and <tt>/tmp/uugetty:ttyS</tt><em/N/ for <tt/uugetty/, and in
|
|
<tt>/var/adm/getty.log</tt>. Look at the
|
|
debugging info and see what is going on. Most likely, you will need
|
|
to tune some of the parameters in your config
|
|
file, and reconfigure your modem.
|
|
<p>
|
|
You could also try <tt/mgetty/. Some people have better luck with
|
|
it.
|
|
|
|
<!-- <sect>Troubleshooting started above -->
|
|
<!-- troubleshooting.D begin (in Modem/Serial HOWTOs)
|
|
Change Log:
|
|
May '05<>Linux Creates an Interrupt Conflict (your PC has an ISA slot)
|
|
Feb. '05: Revised "Serial Port Can't be Found", /proc tree
|
|
error link
|
|
Feb. '04: Cannot open /dev/ttyS?
|
|
example n.g.
|
|
Dec. '03: Scanport can also detect an enabled PnP port
|
|
June '03: Wvdial: busy message due to lockfile permissions
|
|
Feb. '03: Interrupts may be shared on PCI Bus
|
|
Jan. '03: LSR safety check error
|
|
Dec. '02: IO error may mean IRQ conflict or IO address conflict.
|
|
July '02: typo: is doesn't => it doesn't, clarity re port not found
|
|
Dec. '00: /proc/tty/driver/serial shows info, I/O error+, pid 161 in
|
|
Nov. '00: which connector is ttyS1, etc. Input/output error, overrun
|
|
May '00: address conflict
|
|
Apr. '00: 2 ports on same address
|
|
-->
|
|
<sect1>(The following subsections are in both the Serial and Modem HOWTOs)
|
|
|
|
<sect1> Serial Port Can't be Found
|
|
<label id="cant_find_port">
|
|
<p>There are 3 possibilities:
|
|
<enum>
|
|
<item>Your port is disabled since both the BIOS and Linux failed to
|
|
enable it. It has no IO address.
|
|
<item>Your port is enabled and has an IO address but it has no ttyS
|
|
device number (like ttyS14) assigned to that address so the port
|
|
can't be used. As a last resort, you may need to use "setserial" to
|
|
assign a ttyS number to it.
|
|
<item>Your port does have a ttyS number assigned to it (like ttyS14)
|
|
but you don't know which physical connector it is (on the back of your
|
|
PC).
|
|
|
|
See the Serial_HOWTO: "Which Connector on the Back of
|
|
my PC is ttyS1, etc?" But if you want to find which ttyS port the
|
|
modem is on see <ref id="cant_find_modem" name="My Modem is Physically
|
|
There but Can't be Found">
|
|
</enum>
|
|
|
|
First check BIOS messages at boot-time (and possibly the BIOS menu for
|
|
the serial port). Then for the PCI bus type lspci -v. If this shows
|
|
something like "LPC Bridge" then your port is likely on the LPC bus
|
|
which is not well supported by Linux yet (but the BIOS might find it)
|
|
?? If it's an ISA bus PnP serial port, try "pnpdump --dumpregs"
|
|
and/or see Plug-and-Play-HOWTO. If the port happens to be enabled
|
|
then the following two paragraphs may help find the IO port:
|
|
|
|
<sect2> Scanning/probing legacy ports
|
|
<p>This is mainly for legacy non-PCI ports and ISA ports that are not
|
|
Plug-and-Play.
|
|
|
|
Using "scanport" (Debian only ??) will scan all enabled bus ports and
|
|
may discover an unknown port that could be a serial port (but it
|
|
doesn't probe the port). It could hang your PC. If you suspect that
|
|
your port may be at a certain address, you may try manually probing
|
|
with setserial, but it's a slow tedious task if you have several
|
|
addresses to probe. See <ref id="probing_ss" name="Probing">.
|
|
|
|
<sect1>Linux Creates an Interrupt Conflict (your PC has an ISA slot)
|
|
<p>If your PC has a BIOS that handles ISA (and likely PCI too) then
|
|
if you find a IRQ conflict, it might be due to a shortage of free
|
|
IRQs. The BIOS often maintains a list of reserved IRQs, reserved for
|
|
legacy ISA cards. If too many are reserved, the BIOS may not be able
|
|
to find a free IRQ and will erroneously assign an IRQ to the serial
|
|
port that creates a conflict. So check to see if all the reserved
|
|
IRQs are really needed and if not, unreserve an IRQ that the serial
|
|
port can use. For more details, see Plug-and-Play-HOWTO.
|
|
|
|
<sect1> Extremely Slow: Text appears on the screen slowly after long delays
|
|
<label id="slow_">
|
|
<p> It's likely mis-set/conflicting interrupts. Here are some of the
|
|
symptoms which will happen the first time you try to use a modem,
|
|
terminal, or serial printer. In some cases you type something but
|
|
nothing appears on the screen until many seconds later. Only the last
|
|
character typed may show up. It may be just an invisible
|
|
<return> character so all you notice is that the cursor jumps
|
|
down one line. In other cases where a lot of data should appear on
|
|
the screen, only a batch of about 16 characters appear. Then there is
|
|
a long wait of many seconds for the next batch of characters. You
|
|
might also get "input overrun" error messages (or find them in logs).
|
|
|
|
For more details on the symptoms and why this happens see
|
|
the Serial-HOWTO section: "Interrupt Problem Details".
|
|
|
|
If it involves Plug-and-Play devices, see also Plug-and-Play-HOWTO.
|
|
|
|
As a quick check to see if it really is an interrupt problem, set the
|
|
IRQ to 0 with "setserial". This will tell the driver to use
|
|
polling instead of interrupts. If this seems to fix the "slow"
|
|
problem then you had an interrupt problem. You should still try to
|
|
solve the problem since polling uses excessive computer resources.
|
|
|
|
Checking to find the interrupt conflict may not be easy since Linux
|
|
supposedly doesn't permit any interrupt conflicts and will send you a
|
|
<ref id="busy_err" name="/dev/ttyS?: Device or resource busy"> error
|
|
message if it thinks you are attempting to create a conflict. But a
|
|
real conflict can be created if "setserial" has told the kernel
|
|
incorrect info. The kernel has been lied to and thus doesn't think
|
|
there is any conflict. Thus using "setserial" will not reveal the
|
|
conflict (nor will looking at /proc/interrupts which bases its info on
|
|
"setserial"). You still need to know what "setserial" thinks so that
|
|
you can pinpoint where it's wrong and change it when you determine
|
|
what's really set in the hardware.
|
|
|
|
What you need to do is to check how the hardware is set by checking
|
|
jumpers or using PnP software to check how the hardware is actually
|
|
set. For PnP run either "pnpdump --dumpregs" (if ISA bus) or run
|
|
"lspci" (if PCI bus). Compare this to how Linux (e.g. "setserial")
|
|
thinks the hardware is set.
|
|
|
|
<sect1> Somewhat Slow: I expected it to be a few times faster
|
|
<p> An obvious reason is that the baud rate is set too slow. It's
|
|
claimed that this once happened by trying to set the baud rate to a
|
|
speed higher than the hardware can support (such as 230400).
|
|
|
|
Another reason may be that whatever is on the serial port (such as a
|
|
modem, terminal, printer) doesn't work as fast as you thought it did.
|
|
A 56k Modem seldom works at 56k and the Internet
|
|
often has congestion and bottlenecks that slow things down. If the
|
|
modem on the other end does not have a digital connection to the phone
|
|
line (and uses a special "digital modem" not sold in most computer
|
|
stores), then speeds above 33.6k are not possible.
|
|
|
|
Another possible reason is that you have an obsolete serial port: UART
|
|
8250, 16450 or early 16550 (or the serial driver thinks you do). See
|
|
"What are UARTS" in the Serial-HOWTO.
|
|
|
|
Use "setserial -g /dev/ttyS*".
|
|
If it shows anything less than a 16550A, this may be your problem.
|
|
If you think that "setserial" has it wrong check it out. See <ref
|
|
id="set_serial" name="What is Setserial"> for more info. If you
|
|
really do have an obsolete serial port, lying about it to setserial
|
|
will only make things worse.
|
|
|
|
<sect1>The Startup Screen Shows Wrong IRQs for the Serial Ports
|
|
<label id="irqs_shown_wrong">
|
|
<p> For non-PnP ports, Linux does not do any IRQ detection on startup.
|
|
When the serial module loads it only does serial device detection.
|
|
Thus, disregard what it says about the IRQ, because it's just assuming
|
|
the standard IRQs. This is done, because IRQ detection is unreliable,
|
|
and can be fooled. But if and when setserial runs from a start-up
|
|
script, it changes the IRQ's and displays the new (and hopefully
|
|
correct) state on on the startup screen. If the wrong IRQ is not
|
|
corrected by a later display on the screen, then you've got a problem.
|
|
|
|
So, even though I have my <tt/ttyS2/ set at IRQ 5, I still see
|
|
<tscreen><verb>
|
|
ttyS02 at 0x03e8 (irq = 4) is a 16550A
|
|
</verb></tscreen>
|
|
at first when Linux boots. (Older kernels may show "ttyS02" as
|
|
"tty02" which is the same as ttyS2). You may need to use
|
|
<tt/setserial/ to tell Linux the IRQ you are using.
|
|
|
|
<sect1> "Cannot open /dev/ttyS?: Device or resource busy
|
|
<p> See <ref id="busy_err" name="/dev/tty? Device or resource busy">
|
|
|
|
<sect1> "Cannot open /dev/ttyS?: Permission denied"
|
|
<p> Check the file permissions on this port with "ls -l /dev/ttyS?"_
|
|
If you own the ttyS? then you need read and write permissions: crw
|
|
with the c (Character device) in col. 1. It you don't own it then it
|
|
will work for you if it shows rw- in cols. 8 & 9 which means that
|
|
everyone has read and write permission on it. Use "chmod" to change
|
|
permissions. There are more complicated (and secure) ways to get
|
|
access like belonging to a "group" that has group permission. Some
|
|
programs change the permissions when they run but restore them when
|
|
the program exists normally. But if someone pulls the plug on your
|
|
PC it's an abnormal exit and correct permissions may not be restored.
|
|
|
|
<sect1> "Cannot open /dev/ttyS?"
|
|
<p>Unless stty is set for clocal, the CD pin may need to be asserted
|
|
in order to open a serial port. If the physical port is not connected
|
|
to anything, or if it's connected to something that is not powered on
|
|
(such an external modem) then there will be no voltage on CD
|
|
from that device. Thus the "cannot open" message. Either set clocal
|
|
or connect the serial port connector to something and power it on.
|
|
|
|
Even if a device is powered on and connected to a port, it may
|
|
sometimes prevent opening the port. An example of this is where the
|
|
device has negated CD and the CD pin on your PC is negated (negative
|
|
voltage).
|
|
|
|
<sect1> "Operation not supported by device" for ttyS?
|
|
<p> This means that an operation requested by setserial, stty, etc.
|
|
couldn't be done because the kernel doesn't support doing it.
|
|
Formerly this was often due to the "serial" module not being loaded.
|
|
But with the advent of PnP, it may likely mean that there is no modem
|
|
(or other serial device) at the address where the driver (and
|
|
setserial) thinks it is. If there is no modem there, commands (for
|
|
operations) sent to that address obviously don't get done. See <ref
|
|
id="io-irq_in_hdw" name="What is set in my serial port hardware?">
|
|
|
|
If the "serial" module wasn't loaded but "lsmod" shows you it's now
|
|
loaded it might be the case that it's loaded now but wasn't loaded
|
|
when you got the error message. In many cases the module will
|
|
automatically loaded when needed (if it can be found). To force
|
|
loading of the "serial" module it may be listed in the file:
|
|
/etc/modules.conf or /etc/modules. The actual module should reside
|
|
in: /lib/modules/.../misc/serial.o.
|
|
|
|
<sect1> "Cannot create lockfile. Sorry" <label id="lockfile_">
|
|
<p> Sometimes when it can't create a lockfile you get the erroneous
|
|
message: "... Device or resource busy" instead of the one above.
|
|
When a port is "opened" by a program a lockfile is created in
|
|
/var/lock/. Wrong permissions for the lock directory will not allow a
|
|
lockfile to be created there. Use "ls -ld /var/lock" to see if the
|
|
permissions are OK. Giving rwx permissions for the root owner and the
|
|
group should work, provided that the users that need to dialout belong
|
|
to that group. Others should have r-x permission. Even with this
|
|
scheme, there may be a security risk. Use "chmod" to change
|
|
permissions and "chgrp" to change groups. Of course, if there is no
|
|
"lock" directory no lockfile can be created there. For more info on
|
|
lockfiles see the Serial-HOWTO subsection: "What Are Lock
|
|
Files".
|
|
|
|
<sect1> "Device /dev/ttyS? is locked."
|
|
<p> This means that someone else (or some other process) is supposedly
|
|
using the serial port. There are various ways to try to find out what
|
|
process is "using" it. One way is to look at the contents of the
|
|
lockfile (/var/lock/LCK...). It should be the process id. If the
|
|
process id is say 100 type "ps 100" to find out what it is. Then if
|
|
the process is no longer needed, it may be gracefully killed by "kill
|
|
100". If it refuses to be killed use "kill -9 100" to force it to be
|
|
killed, but then the lockfile will not be removed and you'll need to
|
|
delete it manually. Of course if there is no such process as 100 then
|
|
you may just remove the lockfile but in most cases the lockfile should
|
|
have been automatically removed if it contained a stale process id
|
|
(such as 100).
|
|
|
|
<sect1> "/dev/tty? Device or resource busy" <label id="busy_err">
|
|
<p> This means that the device you are trying to access (or use) is
|
|
supposedly busy (in use) or that a resource it needs (such as an IRQ)
|
|
is supposedly being used by another device and can't be shared.
|
|
This message is easy to understand if it only means that the device is
|
|
busy (in use). But it sometimes means that a needed resource is already
|
|
in use (busy). What makes it even more confusing is that in some cases
|
|
neither the device nor the resources that it needs are actually
|
|
"busy".
|
|
|
|
In olden days, if a PC was shutdown by just turning off the power, a
|
|
bogus lockfile might remain and then later on one would get this bogus
|
|
message and not be able to use the serial port. Software today is
|
|
supposed to automatically remove such bogus lockfiles, but as of 2006
|
|
there is still a problem with the "wvdial" dialer program related to
|
|
lockfiles. If wvdial can't create a lockfile because it doesn't have
|
|
write permission in the /var/lock/ directory, you will see this
|
|
erroneous message. See <ref id="lockfile_" name= "Cannot create
|
|
lockfile. Sorry">
|
|
|
|
The following example is where interrupts can't be shared (at least
|
|
one of the interrupts is on the ISA bus). The ``resource busy'' part
|
|
often means (example for <tt/ttyS2/) ``You can't use <tt/ttyS2/ since
|
|
another device is using ttyS2's interrupt.'' The potential interrupt
|
|
conflict is inferred from what "setserial" thinks. A more accurate
|
|
error message would be ``Can't use <tt/ttyS2/ since the setserial data
|
|
(and kernel data) indicates that another device is using <tt/ttyS2/'s
|
|
interrupt''. If two devices use the same IRQ and you start up only
|
|
one of the devices, everything is OK because there is no conflict yet.
|
|
But when you next try to start the second device (without quitting the
|
|
first device) you get a "... busy" error message. This is because the
|
|
kernel only keeps track of what IRQs are actually in use and actual
|
|
conflicts don't happen unless the devices are in use (open). The
|
|
situation for I/O address (such as 0x3f8) conflict is similar.
|
|
|
|
This error is sometimes due to having two serial drivers: one a module
|
|
and the other compiled into the kernel. Both drivers try to grab the
|
|
same resources and one driver finds them "busy".
|
|
|
|
There are two possible cases when you see this message:
|
|
<enum>
|
|
<item> There may be a real resource conflict that is being avoided.
|
|
<item> Setserial has it wrong and the only reason <tt/ttyS2/ can't be
|
|
used is that setserial erroneously predicts a conflict.
|
|
</enum>
|
|
|
|
What you need to do is to find the interrupt setserial thinks
|
|
<tt/ttyS2/ is using. Look at /proc/tty/driver/serial. You should
|
|
also be able to find it with the "setserial" command for <tt/ttyS2/.
|
|
|
|
Bug in old versions: Prior to 2001 there was a bug which wouldn't let
|
|
you see it with "setserial". Trying to see it would give the same
|
|
"... busy" error message.
|
|
|
|
To try to resolve this problem reboot or: exit or gracefully kill all
|
|
likely conflicting processes. If you reboot: 1. Watch the boot-time
|
|
messages for the serial ports. 2. Hope that the file that runs
|
|
"setserial" at boot-time doesn't (by itself) create the same conflict
|
|
again.
|
|
|
|
If you think you know what IRQ say <tt/ttyS2/ is using then you may
|
|
look at /proc/interrupts to find what else (besides another serial
|
|
port) is currently using this IRQ. You might also want to double
|
|
check that any suspicious IRQs shown here (and by "setserial") are
|
|
correct (the same as set in the hardware). A way to test whether or
|
|
not it's a potential interrupt conflict is to set the IRQ to 0
|
|
(polling) using "setserial". Then if the busy message goes away, it
|
|
was likely a potential interrupt conflict. It's not a good idea to
|
|
leave it permanently set at 0 since it will put more load on the CPU.
|
|
|
|
<sect1>"Input/output error" from setserial, stty, pppd, etc.
|
|
<p> This means that communication with the serial port isn't working
|
|
right. It could mean that there isn't any serial port at the IO
|
|
address that setserial thinks your port is at. It could also be an
|
|
interrupt conflict (or an IO address conflict). It also may mean that
|
|
the serial port is in use (busy or opened) and thus the attempt to
|
|
get/set parameters by setserial or stty failed. It will also happen
|
|
if you make a typo in the serial port name such as typing "ttys"
|
|
instead of "ttyS".
|
|
|
|
<sect1>"LSR safety check engaged"
|
|
<p>LSR is the name of a hardware register. It usually means that
|
|
there is no serial port at the address where the driver thinks your
|
|
serial port is located. You need to find your serial port and
|
|
possibly configure it. See <ref id="locate_port" name="Locating the
|
|
Serial Port: IO address IRQs"> and/or <ref id="set_serial" name="What
|
|
is Setserial">
|
|
|
|
<sect1>Overrun errors on serial port
|
|
<p> This is an overrun of the hardware FIFO buffer and you can't
|
|
increase its size. Bug note (reported in 2002): Due to a bug in some
|
|
kernel 2.4 versions, the port number may be missing and you will only
|
|
see "ttyS" (no port number). But if devfs notation such as "tts/2" is
|
|
being used, there is no bug. See
|
|
"Higher Serial Thruput" in the Serial-HOWTO.
|
|
|
|
<sect1> Modem doesn't pick up incoming calls
|
|
<p> This paragraph is for the case where a modem is used for both
|
|
dial-in and dial-out. If the modem generates a DCD (=CD) signal, some
|
|
programs (but not mgetty) will think that the modem is busy.
|
|
This will cause a problem when you are trying to dial out with a modem
|
|
and the modem's DCD or DTR are not implemented correctly. The modem
|
|
should assert DCD only when there is an actual connection (ie someone
|
|
has dialed in), not when <tt/getty/ is watching the port. Check to
|
|
make sure that your modem is configured to only assert DCD when there
|
|
is a connection (&C1). DTR should be on (asserted) by the
|
|
communications program whenever something is using, or watching the
|
|
line, like <tt/getty/, <tt/kermit/, or some other comm program.
|
|
|
|
<sect1> Port gets characters only sporadically
|
|
<p> There could be some other program running on the port. Use "top"
|
|
(provided you've set it to display the port number) or type "ps
|
|
-alxw". Look at the results to see if the port is being used by
|
|
another program. Be on the lookout for the gpm mouse program which
|
|
often runs on a serial port.
|
|
|
|
<sect1> Troubleshooting Tools
|
|
<p> These are some of the programs you might want to use in
|
|
troubleshooting:
|
|
<itemize>
|
|
<item> "lsof /dev/ttyS*" will list serial ports which are open.
|
|
<item> "setserial" shows and sets the low-level hardware configuration
|
|
of a port (what the driver thinks it is). See <ref id="set_serial"
|
|
name="What is Setserial">
|
|
<item> "stty" shows and sets the configuration of a port (except for
|
|
that handled by "setserial").
|
|
See the Serial-HOWTO section: "Stty". <item> "modemstat" or "statserial" or "watch head
|
|
/proc/tty/driver/serial" will show the current state of various modem
|
|
signal lines (such as DTR, CTS, etc.). The one in /proc also shows
|
|
byte flow and errors.
|
|
<item> "irqtune" will give serial port interrupts higher
|
|
priority to improve performance.
|
|
<item> "hdparm" for hard-disk tuning may help some more.
|
|
<item> "lspci" shows the actual IRQs, etc. of hardware on the PCI bus.
|
|
<item> "pnpdump --dumpregs" shows the actual IRQs, etc. of hardware for
|
|
PnP devices on the ISA bus.
|
|
<item> Some "files" in the /proc tree (such as ioports, interrupts,
|
|
and tty/driver/serial).
|
|
</itemize>
|
|
|
|
<!-- troubleshooting.D end -->
|
|
|
|
|
|
<sect> Flash Upgrades
|
|
<p> Many modems can be upgraded by reprogramming their flash memories
|
|
with an upgrade program which you get from the Internet. By sending
|
|
this "program" from the PC via the serial port to the modem, the modem
|
|
will store this program in its non-volatile memory (it's still there
|
|
when the power is turned off). The instructions on installing it are
|
|
usually on how to do in under Windows so you'll need to figure out how
|
|
to do the equivalent under Linux (unless you want to install the
|
|
upgrade under Windows). Sending the program to the modem is often
|
|
called a download.
|
|
|
|
If the latest version of this HOWTO still contains this request (see
|
|
<ref id="new_vers" name="New Versions of this HOWTO">) please send me
|
|
your experiences with installing such upgrades that will be helpful to
|
|
others.
|
|
|
|
Here's the general idea of doing an upgrade. First, there may be a
|
|
command that you need to send your modem to tell it that what follows
|
|
is a flash ROM upgrade. In one case this was AT** You can do this by
|
|
starting a communications program (such as minicom) and type. First
|
|
type AT <enter> to see if your modem is there and answers "OK".
|
|
|
|
Next, you need to send an file (sometimes two files) directly to the modem.
|
|
Communication programs (such as minicom) often use zmodem or kermit to
|
|
send files to the modem (and beyond) but these put the file into
|
|
packets which append headers and you want the exact file sent to the
|
|
modem, not a modified one. But the kermit communications program has
|
|
a "transmit" command that will send the file directly (without using
|
|
the kermit packets) so this is one way to send a file directly.
|
|
Minicom didn't have this feature in 1998.
|
|
|
|
Another way to send the file(s) would be to escape from the
|
|
communications program to the shell (in minicom this is ^AJ) and then:
|
|
<tt>cat upgrade_file_name > /dev/ttyS4 </tt> (if your serial port is
|
|
ttyS4). Then go back to the communication program (type fg at the
|
|
command line prompt in minicom) to see what happened.
|
|
|
|
Here's an example session for a certain Rockwell modem (C-a is ^A):
|
|
<verb>
|
|
- Run minicom
|
|
- Type AT** : see "Download initiated ..."
|
|
- C-a J
|
|
- cat FLASH.S37 > /dev/modem
|
|
- fg : see "Download flash code ..."
|
|
- C-a J
|
|
- cat 283P1722.S37 > /dev/modem
|
|
- fg : see "Device successfully programmed"
|
|
</verb>
|
|
|
|
<sect>Other Sources of Information
|
|
<sect1> Misc
|
|
<p>
|
|
<itemize>
|
|
<item>man pages for: <tt/agetty(8)/, <tt/getty(1m)/, <tt/gettydefs(5)/,
|
|
<tt/init(1)/, <tt/isapnp(8)/, <tt/login(1)/, <tt/mgetty(8)/,
|
|
<tt/setserial(8)/
|
|
<item>Your modem manual (if it exists). Some modems come without manuals.
|
|
<item> <url url="ftp://scicom.alphacdc.com/pub/linux/" name="Serial
|
|
Suite"> by Vern Hoxie is a collection of blurbs about the care and
|
|
feeding of the Linux serial port plus some simple programs.
|
|
<item>The Linux serial mailing list. To subscribe, send email to
|
|
<tt><htmlurl url="mailto:majordomo@vger.rutgers.edu"
|
|
name="majordomo@vger.rutgers.edu"></tt>, with
|
|
``<tt/subscribe linux-serial/'' in the message body. If you
|
|
send ``<tt/help/'' in the message body, you get a help
|
|
message. The server also serves many other Linux lists. Send
|
|
the ``<tt/lists/'' command for a list of mailing lists.
|
|
</itemize>
|
|
|
|
<sect1> Books
|
|
<p> I've been unable to find a good up-to-date book on modems.
|
|
<itemize>
|
|
<item>The Complete Modem Reference by Gilbert Held, 1997.
|
|
Contains too much info about obsolete topics. More up-to-date info
|
|
may be found on the Internet.
|
|
<item>Modems For Dummies by Tina Rathbone, 1996. (Have never seen it.)
|
|
<item>The Modem Technical Guide by Douglas Anderson, 1996.
|
|
<item>Ultimate Modem Handbook by Cass R. Lewart, 1998.
|
|
<item> Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE
|
|
Computer Society Press, Los Alamitos, CA, 1996.
|
|
</itemize>
|
|
|
|
<sect1> HOWTOs
|
|
<p> <itemize>
|
|
<item>Cable-Modem mini-howto
|
|
<item> SuSE ISDN Howto (not a LDP Howto) <url
|
|
url="http://sol.parkland.cc.il.us/sdb/en/html/isdn.html"> or <url
|
|
url="http://brenner.chemietechnik.uni-dortmund.de/doc/sdb/en/html/isdn.html">
|
|
<item>Linux-Modem-Sharing mini-howto. Computers on a network share
|
|
a single modem for dial-out (like a shared printer).
|
|
<item>Modems-HOWTO: In French (Not used in creating this Modem-HOWTO)
|
|
<item>NET-3-4-HOWTO: all about networking, including SLIP, CSLIP, and PPP
|
|
<item>PPP-HOWTO: help with PPP including modem set-up
|
|
<item> Serial-HOWTO has info on Multiport Serial Cards used for
|
|
terminals, etc. Covers the serial port in more detail than in this
|
|
HOWTO.
|
|
<item>Serial-Programming-HOWTO: for some aspects of serial-port programming
|
|
<item>Text-Terminal-HOWTO: (including connecting up with modems)
|
|
<item>UUCP-HOWTO: for information on setting up UUCP
|
|
</itemize>
|
|
|
|
<sect1> Usenet newsgroups
|
|
<p> <itemize>
|
|
<item> comp.os.linux.answers; FAQs, How-To's, READMEs, etc. about Linux.
|
|
<item> comp.os.linux.hardware; Hardware compatibility with the
|
|
Linux operating system.
|
|
<item> comp.os.linux.setup; Linux installation and system administration.
|
|
<item> comp.dcom.modems; Modems for all OS's
|
|
</itemize>
|
|
|
|
<sect1>Old Modem Database on Internet <label id="modem_list">
|
|
<p>Rob Clark had a huge database of modems but it doesn't seem to have
|
|
been maintained since 2003. The website URLs have changed many times.
|
|
Right now (mid 2006), it seems that only these two mirrors work:
|
|
|
|
<url url="http://64.126.95.102:8080/gromitkc/winmodem.html#Database"
|
|
name="Modem List mirror1"><newline>
|
|
<url url="http://www.devidal.tv/~chris/winmodems/"
|
|
name="Modem List mirror2">
|
|
|
|
<sect1> Other Web Sites <label id="web_sites">
|
|
<p> <itemize>
|
|
<item> <url url="http://serial.sourceforge.net/" name="Linux Serial
|
|
Driver home page"> Includes info about support for PCI modems.
|
|
<item>Hayes AT modem commands
|
|
<url url="http://www-dcg.fnal.gov/Net/HYSTRM20.TXT"
|
|
name= "Technical Reference for Hayes (tm) Modem Users">
|
|
<!--
|
|
<url url="http://www.hayes.com/TechSupport/techref/"
|
|
name= "Technical Reference for Hayes (tm) Modem Users">
|
|
<item><url url="http://www.rss.rockwell.com/techinfo/"
|
|
name= "Rockwell-based modem commands">
|
|
-->
|
|
<item> <url
|
|
url="http://www.cisco.com/univercd/cc/td/doc/product/access/acs_mod/cis3600/analogfw/analogat.htm"
|
|
name="AT Command Set and Register Summary for Analog Modem Modules
|
|
(Cisco)"
|
|
<item><url url="http://www.zoltrix.com/support_html/modem/USEMODEM.HTM"
|
|
name="Controlling your Modem with AT Commands">
|
|
<item>Modem FAQs:<newline>
|
|
<url url="http://modemfaq.home.att.net/"
|
|
name="Navas 28800-56K Modem FAQ">
|
|
<item> <url url="http://www.net-boy.com" name="Curt's High Speed
|
|
Modem Page">
|
|
<item> Much info on 56k modems <url url="http://modemsite.com/56k/"
|
|
name= "56k Modem = v.Unreliable">
|
|
<item> <url url="http://www.56k.com/links/Modem_Manufacturers/"
|
|
name="Links to modem manufacturers">
|
|
<item> <url url="http://modems.rosenet.net/" name="More Links to modem
|
|
manufacturers">
|
|
<item> <url url=" http://search.fcc.gov/"> name="Search for
|
|
manufacturer by FCC ID">
|
|
</itemize>
|
|
|
|
<sect> Appendix A: How Analog Modems Work (technical) (unfinished)
|
|
<label id="how_modems_work">
|
|
<sect1> Modulation Details <label id="modulate_">
|
|
<sect2> Intro to Modulation
|
|
<p> This part describes the modulation methods used for conventional
|
|
analog modems. Two other types of modems, cable and ADSL, use the
|
|
same modulation methods but the situation is more complicated since
|
|
they divide their frequency spectrum into multiple channels, etc.
|
|
Cable modems have to share a cable used by many other people. This
|
|
HOWTO doesn't explain this added complexity of cable and ADSL modems.
|
|
|
|
Modulation is the conversion of a digital signal represented by binary
|
|
binary (0 or 1) into an analog signal something like a sine wave.
|
|
The modulated signal consists pure sine wave "carrier" signal which
|
|
is modified to convey information. A pure carrier sine wave,
|
|
unchanging in frequency and voltage, provides no flow of information
|
|
at all (except that a carrier is present). To make it convey
|
|
information we modify (or modulate) this carrier. There are 3 basic
|
|
types of modulation: frequency, amplitude, and phase. They will be
|
|
explained next.
|
|
|
|
<sect2> Frequency Modulation
|
|
<p> The simplest modulation method is frequency modulation. Frequency
|
|
is measured in cycles per second (of a sine wave). It's the count
|
|
of the number of times the sine wave shape repeats itself in a second.
|
|
This is the same as the number of times it reaches it peak value
|
|
during a second. The word "Hertz" (abbreviated Hz) is used to mean
|
|
"cycles per second".
|
|
|
|
A simple example of frequency modulation is where one frequency means
|
|
a binary 0 and another means a 1. For example, for some obsolete 300
|
|
baud modems 1070 Hz meant a binary 0 while 1270 Hz meant a binary 1.
|
|
This was called "frequency shift keying". Instead of just two
|
|
possible frequencies, more could be used to allow more information to
|
|
be transmitted. If we had 4 different frequencies (call them A, B, C,
|
|
and D) then each frequency could stand for a pair of bits. For
|
|
example, to send 00 one would use frequency A. To send 01, use
|
|
frequency B; for 10 use C; for 11 use D. In like manner, by using 8
|
|
different frequencies we could send 3 bits with each shift in
|
|
frequency. Each time we double the number of possible frequencies we
|
|
increase the number of bits it can represent by 1.
|
|
|
|
<sect2> Amplitude Modulation
|
|
<p> Once one understands frequency modulation example above including
|
|
the possibilities of representing a few bits by a single shift in
|
|
frequency, it's easier to understand both amplitude modulation and
|
|
phase modulation. For amplitude modulation, one just changes the height
|
|
(voltage) of the sine wave analogous to changing the frequency of the
|
|
sine wave. For a simple case there could only be 2 allowed amplitude
|
|
levels, one representing a 0-bit and another representing a 1-bit. As
|
|
explained for the case of frequency modulation, having more possible
|
|
amplitudes will result in more information being transmitted per
|
|
change in amplitude.
|
|
|
|
<sect2> Phase Modulation
|
|
<p> To change the phase of a sine wave at a certain instant of time,
|
|
we stop sending this old sine wave and immediately begin sending a new
|
|
sine wave of the same frequency and amplitude. If we started sending
|
|
the new sine wave at the same voltage level (and slope) as existed
|
|
when we stopped sending the old sine wave, there would be no change in
|
|
phase (and no detectable change at all). But suppose that we started
|
|
up the new sine wave at a different point on the sine wave curve.
|
|
Then there would likely be a sudden voltage jump at the point in time
|
|
where the old sine wave stopped and the new sine wave began. This is
|
|
a phase shift and it's measured in degrees (deg.) A 0 deg. (or a 360
|
|
deg.) phase shift means no change at all while a 180 deg. phase shift
|
|
just reverses the voltage (and slope) of the sine wave. Put another
|
|
way, a 180 deg. phase shift just skips over a half-period (180 deg.)
|
|
at the point of transition. Of course we could just skip over say 90
|
|
deg. or 135 deg. etc. As in the example for frequency modulation, the
|
|
more possible phase shifts, the more bits a single shift in phase can
|
|
represent.
|
|
|
|
<sect2> Combination Modulation <label id="QAM_">
|
|
<p> Instead of just selecting either frequency, amplitude, or phase
|
|
modulation, we may chose to combine modulation methods. Suppose that
|
|
we have 256 possible frequencies and thus can send a byte (8 bits) for
|
|
each shift in frequency (since 2 to the 8 power is 256). Suppose also
|
|
that we have another 256 different amplitudes so that each shift in
|
|
amplitude represents a byte. Also suppose there are 256 possible
|
|
phase shifts. Then a certain points in time we may make a shift in
|
|
all 3 things: frequency, amplitude and phase. This would send out 3
|
|
bytes for each such transition.
|
|
|
|
No modulation method in use today actually does this. It's not
|
|
practical due to the relatively long time it would take to detect all
|
|
3 types of changes. The main problem is that frequent shifts in phase
|
|
can make it appear that a shift in frequency has happened when it
|
|
actually didn't.
|
|
|
|
To avoid this difficulty one may simultaneous change only the phase
|
|
and amplitude (with no change in frequency). This is called
|
|
phase-amplitude modulation. It is also called quadrature amplitude
|
|
modulation (= QAM) since there were only 4 possible phases
|
|
(quadrature) in early versions of it. This method is used today for
|
|
the common modem speeds of 14.4k, 28.8k, and 33.6k. The only
|
|
significant case where this modulation method is not used today is for
|
|
56k modems. But even 56k modems exclusively use QAM (phase-amplitude
|
|
modulation) in the direction from your PC out the telephone line.
|
|
Sometimes even the other direction will also fall back to QAM when
|
|
line conditions are not good enough. Thus QAM (phase-amplitude
|
|
modulation) still remains the most widely used method on ordinary
|
|
telephone lines.
|
|
|
|
<sect1> 56k Modems (V.90, V.92) <label id="56k_modems">
|
|
<p> The "modulation" method used for speeds above 33.6k is entirely
|
|
different than the common phase-amplitude modulation used at 33.6k and
|
|
below. Since ordinary telephone calls are converted to digital
|
|
signals at the local offices of the telephone company, the fastest
|
|
speed that you can send digital data by an ordinary telephone call is
|
|
the same speed that the telephone company uses over its digital
|
|
portion of its network (for a phone call). What is this speed?
|
|
Well, it's close to 64kbps. It's sometimes 64k and sometimes less if
|
|
bits are "stolen" for signalling purposes. If the phone Co. knows
|
|
that the link is not for voice, bits may not get stolen. The case of
|
|
64k will be presented and then it will be explained why the actual
|
|
speed is lower (56k or less --often significantly less).
|
|
|
|
Thus 64k is the absolute top speed possible (not counting date
|
|
compression) for an ordinary telephone call using the digital portion
|
|
of the circuit that was designed to send digital encodings of the
|
|
human voice. In order to use 64k, the modems need to either have
|
|
direct access to the digital portion of the circuit or be able to
|
|
determine the exact digital signal that generated a received analog
|
|
signal (and conversely). This task is far too error prone if both
|
|
sides of a telephone call have only an analog interface to the
|
|
telephone company. But if one side has a digital interface, then it's
|
|
possible (in one direction for V.90 and in both directions for V.92).
|
|
Thus if your ISP has a digital interface to the phone company, the ISP
|
|
may send out a certain digital signal over the phone lines toward your
|
|
PC. The digital signal from the ISP gets converted to analog at the
|
|
local telephone office near your PC's location (perhaps near your
|
|
home). Then it's your modem's task to try to figure out exactly what
|
|
that digital signal was. If it could do this, then transmission at 64k
|
|
(the speed of the telephone company's digital signal) is possible in
|
|
this direction.
|
|
|
|
What method does the telephone company use to digitally encode analog
|
|
signals? It uses a method of sampling the amplitude of the analog
|
|
signal at a rate of 8000 samples per second. Each sample amplitude is
|
|
encoded as a 8-bit byte. (Note: 8 x 8000 = 64k) This is called
|
|
"Pulse Code Modulation" = PCM. These bytes are then sent digitally on
|
|
the telephone company's digital circuits where many calls share a
|
|
single circuit using a time-sharing scheme known as "time division
|
|
multiplexing". Then finally at a local telephone office near your
|
|
home, the digital signal is de-multiplexed resulting in the same
|
|
digital signal as was originally created by PCM. Then this signal is
|
|
converted back to analog and sent to your home. This analog to
|
|
digital conversion (and conversely) is done by telephone company
|
|
hardware called a "codec" (coder/decoder). Each PCM 8-bit byte
|
|
creates a certain amplitude of the analog signal. Your modem's task
|
|
is to determine just what that PCM 8-bit byte was, based on the analog
|
|
amplitude it detects.
|
|
|
|
This was originally called "modulus conversion". It's now often
|
|
called "PCM"-something (such as PCM modulation) since its just like
|
|
encoding/decoding PCM but with the added problem of sampling at the
|
|
precise time that the codec generated the analog voltage from the
|
|
digital PCM code.
|
|
|
|
In order to determine the digital codes the telephone Co. used to
|
|
create the analog signal, the modem must sample this analog signal
|
|
amplitude at exactly the same points in time the phone Co. did when
|
|
it created the analog signal. To do this an 8kHz clock timing signal
|
|
is generated with help from a residual 4kHz signal on the analog phone
|
|
line. The creation of amplitudes to go out to your home/office at 8k
|
|
amplitudes/sec sort of creates a 4kHz signal. Suppose every other
|
|
amplitude was of opposite polarity. Then there would be a 4kHz
|
|
sine-like wave created. Each amplitude is in a sense a 8-bit symbol
|
|
and when to sample amplitudes is known as "symbol timing". The
|
|
modem's task is to insure that it's 8kHz clock runs at precisely twice
|
|
the speed of the 4kHz signal (which could drift slightly off 4kHz) and
|
|
that the modem's clock is synchronized with that used by the telephone
|
|
company's codec. The actual electronics may use much higher frequency
|
|
clocks (dividing them down) and take more than a single sample. If
|
|
you know how this synchronization works, let me know (if this is a
|
|
recent Modem-HOWTO).
|
|
|
|
Now the encoding of amplitudes in PCM is not linear. At low
|
|
amplitudes an increment of 1 in the PCM byte value represents a much
|
|
smaller increment (delta) in analog signal amplitude than would be the
|
|
case if the amplitude being sampled were much higher. Thus for low
|
|
amplitudes it's difficult to distinguish between adjacent byte values.
|
|
To make it easier to do this (for 56k modems) certain PCM codes
|
|
representing very low amplitudes are not used. This gives a larger
|
|
delta between possible amplitudes and makes correct detection of them
|
|
by your modem easier. Thus half of the amplitude levels are not used
|
|
(in the downstream direction) by V.90 or V.92. This is tantamount to
|
|
each symbol (valid amplitude level) representing 7 bits instead of 8.
|
|
This is where 56k comes from: 7 bits/symbol x 8k symbols/sec = 56k
|
|
bps. Of course each amplitude symbol is actually generated by 8-bits
|
|
but only 128 bytes of the possible 256 bytes are actually used by the
|
|
ISP sender. There is a code table mapping these 128 8-bit bytes to
|
|
the 128 7-bit bytes. It's not just a simple mapping like ignoring the
|
|
last bit. Thus to send 7 normal data bytes (8-bits) will take 8 of
|
|
the above mentioned bytes.
|
|
|
|
But it's a little more complicated that this. If the line conditions
|
|
are not nearly perfect or if the direction is upstream (V.92 only),
|
|
then even fewer possible levels (symbols) are used resulting in speeds
|
|
under 56k. Also due to US government rules prohibiting high power
|
|
levels on phone lines, certain high amplitudes levels can't be used
|
|
resulting in only about 53.3k at best for "56k" modems in the
|
|
downstream direction.
|
|
|
|
Note that the digital part of the telephone network is bi-directional.
|
|
Two such circuits are used for a phone call, one in each direction.
|
|
For V.90, the 56k signal is only used in one of these directions: from
|
|
your ISP to your PC (called the "downstream" direction). For this
|
|
V.90, the other direction (upstream, from your home/office to the ISP)
|
|
uses the conventional phase-amplitude modulation scheme with a maximum
|
|
of 36.6kbps (and not 53.3kbps). For V.92, this upstream direction
|
|
also uses the PCM method and supports up to 48 kbps. The analog
|
|
portion of the circuit from your home/office to the nearest telephone
|
|
Co. office was never intended to be bi-directional since it's only a
|
|
single twisted pair. But due to sophisticated cancellation methods
|
|
it's able to convey data simultaneously in both directions as
|
|
explained in the next subsection. It's claimed that with V.92, it's
|
|
almost impossible to get maximum thruput in both directions
|
|
simultaneously due to the difficulties of bi-directional flow on a
|
|
single circuit.
|
|
|
|
<sect1> Full Duplex on One Circuit
|
|
<p> Modern modems are able to both send and receive signals
|
|
simultaneously. One could call this "bidirectional" or "full duplex".
|
|
This was once done by using one frequency for sending and another for
|
|
receiving. Today, the same frequency is used for both sending and
|
|
receiving. How this works is not easy to comprehend.
|
|
|
|
Most of the telephone system "main lines" are digital with two
|
|
channels in use when you make a telephone call. What you say goes over
|
|
one digital channel and what the other person says goes over the other
|
|
(reverse) digital channel. Unfortunately, the part of the telephone
|
|
system which goes to homes (and many offices) is not digital but only
|
|
a single analog channel. If both modems were directly connected to
|
|
the digital part of the phone system then bidirectional communication
|
|
(sending and receiving at the same time) would be no problem because
|
|
two channels would be available.
|
|
|
|
But the end portion of the signal path goes over just one circuit. How
|
|
can there be two-way communication on it simultaneously? It works
|
|
something like this. Suppose your modem is receiving a signal from
|
|
the other modem and is not transmitting. Then there's no problem.
|
|
But if your modem were to start transmitting (with the other received
|
|
signal still flowing into your modem) it would drown out the received
|
|
signal. If the transmitted signal was a "solid" voltage wave applied
|
|
to the end of the line then there is no way any received signal could
|
|
be present at that point.
|
|
|
|
But the transmitter has "internal impedance" and the transmitted
|
|
signal applied to the end of the line is not solid (or strong enough)
|
|
to completely eliminate the received signal coming from the other end.
|
|
Thus while the voltage at the end of the line is mostly the stronger
|
|
transmitted signal a small part of it is the desired received signal.
|
|
All that is needed is to filter out this stronger transmitted signal
|
|
and then what remains will be the signal from the other end which we
|
|
want. To do this, one only needs to get the pure transmitted signal
|
|
directly from the transmitter (before it's applied to the line)
|
|
amplify it a determined amount, and then subtract it from the total
|
|
signal present at the end of the line. Doing this in the receiver
|
|
circuits leaves a signal which mostly came from the other end of the
|
|
line.
|
|
|
|
<sect1> Echo Cancellation
|
|
<p> An analog signal traveling down a line in one direction may
|
|
encounter changes in the line that will cause part of the signal to
|
|
echo back in the opposite direction. Since the same circuit is used
|
|
for bi-directional flow of data, such echos will result in garbled
|
|
reception. One way to ameliorate this problem is to send training
|
|
signals once in a while to determine the echo characteristic of the
|
|
line. This will enable one to predict the echos that will be
|
|
generated by any given signal. Then this prediction method is used to
|
|
predict what echos the transmitted signal will cause. Then this
|
|
predicted echo signal is subtracted from the received signal. This
|
|
cancels out the echoes.
|
|
|
|
<sect> Appendix B: Analog Voice Infeasible Over Non-Voice Modem
|
|
<p>Sometimes people look for software that will allow them to transmit
|
|
ordinary analog voice over a modem that doesn't support voice. It
|
|
doesn't exist since it's just not very feasible to do this. Of
|
|
course, one can use VOIP to send digital voice over a modem. And when
|
|
one makes a call and the other side picks up the line, one might be
|
|
able to hear voice for a few seconds until negotiations for a
|
|
connection begin.
|
|
|
|
But once a modem is connected, sending analog voice over it just isn't
|
|
feasible. For phase-amplitude modulation, carrier frequencies of
|
|
fixed values are used which doesn't allow the continuously variable
|
|
frequencies required in analog voice. V.90 and V.92 might be feasible,
|
|
but if line conditions deteriorate, they fall back to phase-amplitude
|
|
modulation which won't work. Furthermore, V.90 uses phase-amplitude
|
|
in one direction. Also, both V.90 and V.92 don't permit all
|
|
amplitudes to be used, which limits the waveshapes which can be
|
|
created.
|
|
|
|
<sect>Appendix C: "baud" vs. "bps"
|
|
<sect1> A simple example
|
|
<p> ``baud'' and ``bps'' are perhaps one of the most misused terms in
|
|
the computing and telecommunications field. Many people use these
|
|
terms interchangeably, when in fact they are not! bps is simply the
|
|
number of bits transmitted per second. The baud rate is a measure of
|
|
how many times per second a signal changes (or could change). For a
|
|
typical serial port a 1-bit is -12 volts and a 0-bit is +12 v (volts).
|
|
If the bps is 38,400 a sequence of 010101... would also be 38,400 baud
|
|
since the voltage shifts back and forth from positive to negative to
|
|
positive, etc. and there are 38,400 shifts per second. For another
|
|
sequence say 111000111... there will be fewer shifts of voltage since
|
|
for three 1's in sequence the voltage just stays at -12 volts yet we
|
|
say that its still 38,400 baud since there is a possibility that the
|
|
number of changes per second will be that high.
|
|
|
|
Looked at another way, put an imaginary tic mark separating each bit
|
|
(even though the voltage may not change). 38,400 baud then means
|
|
38,400 tic marks per second. The tic marks at at the instants of
|
|
permitted change and are actually marked by a synchronized clock
|
|
signal generated in the hardware but not sent over the external cable.
|
|
|
|
Suppose that a "change" may have more than the two possible outcomes
|
|
of the previous example (of +- 12 v). Suppose it has 4 possible
|
|
outcomes, each represented by a unique voltage level. Each level may
|
|
represent a pair of bits (such as 01). For example, -12v could be 00,
|
|
-6v 01, +6v 10 and +12v 11. Here the bit rate is double the baud rate.
|
|
For example, 3000 changes per second will generate 2 bits for each
|
|
change resulting in 6000 bits per second (bps). In other words 3000
|
|
baud results in 6000 bps.
|
|
|
|
<sect1> Real examples
|
|
<p> The above example is overly simple. Real examples are more
|
|
complicated but based on the same idea. This explains how a modem
|
|
running at 2400 baud, can send 14400 bps (or higher). The modem
|
|
achieves a bps rate greater than baud rate by encoding many bits in
|
|
each signal change (or transition). Thus, when 2 or more bits are
|
|
encoded per baud, the bps rate exceeds the baud rate. If your
|
|
modem-to-modem connection is at 14400 bps, it's going to be sending 6
|
|
bits per signal transition (or symbol) at 2400 baud. A speed of 28800
|
|
bps is obtained by 3200 baud at 9 bits/baud. When people misuse the
|
|
word baud, they may mean the modem speed (such as 33.6k).
|
|
|
|
Common modem bps rates were formerly 50, 75, 110, 300, 1200,
|
|
2400, 9600. These were also the bps rates over the
|
|
serial_port-to-modem cables. Today the bps modem-to-modem (maximum)
|
|
rates are 14.4k, 28.8k, 33.6k, and 56k, but the common rates over the
|
|
serialPort-to-modem cables are not the same but are: 19.2k, 38.4k,
|
|
57.6k, 115.2k, 230.4k. The high speed of 230.4k is (as of late 2000)
|
|
unfortunately not provided by most new (and old) hardware. Using
|
|
modems with V.42bis compression (max 4:1 compression), rates up to
|
|
115.2k bps are possible for 33.6k modems. 203.2k (4 x 53.3k) is
|
|
possible for 56k modems.
|
|
|
|
Except for 56k modems, most modems run at 2400, 3000, or 3200
|
|
baud. Even the 56k modems use these bauds for transmission and
|
|
sometimes fall back to them for reception. Because of the bandwidth
|
|
limitations on voice-grade phone lines, baud rates greater than 2400
|
|
are harder to achieve, and only work under conditions of good phone
|
|
line quality.
|
|
|
|
How did this confusion between bps and baud start? Well, back when
|
|
antique low speed modems were high speed modems, the bps rate actually
|
|
did equal the baud rate. One bit would be encoded per phase change.
|
|
People would use bps and baud interchangeably, because they were the
|
|
same number. For example, a 300 bps modem also had a baud rate of
|
|
300. This all changed when faster modems came around, and the bit rate
|
|
exceeded the baud rate. ``baud'' is named after Emile Baudot, the
|
|
inventor of the asynchronous telegraph printer. One way this problem
|
|
gets resolved is to use the term "symbol rate" instead of "baud" and
|
|
thus avoid using the term "baud". However when talking about the
|
|
"speeds" between the modem and the serial port (DTE speed) baud and the
|
|
symbol rate are the same. And even "speed" is a misnomer since we
|
|
really mean flow rate.
|
|
|
|
<sect> Appendix D: Terminal Server Connection
|
|
<p> This section was adapted from Text-Terminal-HOWTO.
|
|
|
|
A terminal server is something like an intelligent switch that can
|
|
connect many modems (or terminals) to one or more computers. It's
|
|
not a mechanical switch so it may change the speeds and protocols of
|
|
the streams of data that go thru it. A number of companies make
|
|
terminal servers: Xyplex, Cisco, 3Com, Computone, Livingston, etc.
|
|
There are many different types and capabilities. Another HOWTO is
|
|
needed to compare and describe them (including the possibility of
|
|
creating your own terminal server with a Linux PC). Most are used for
|
|
modem connections rather than directly connected terminals.
|
|
|
|
One use for them is to connect many modems (or terminals) to a high
|
|
speed network which connects to host computers. Of course the
|
|
terminal server must have the computing power and software to run
|
|
network protocols so it is in some ways like a computer. The
|
|
terminal server may interact with the user and ask what computer to
|
|
connect to, etc. or it may connect without asking. One may sometimes
|
|
send jobs to a printer thru a terminal server.
|
|
|
|
A PC today has enough computing power to act like a terminal server
|
|
except that each serial port should have its own hardware interrupt.
|
|
PC's only have a few spare interrupts for this purpose and since they
|
|
are hard-wired you can't create more by software. A solution is to
|
|
use an advanced multiport serial card which has its own system of
|
|
interrupts (or on lower cost models, shares one of the PC's interrupts
|
|
between a number of ports). See Serial-HOWTO for more info. If such
|
|
a PC runs Linux with getty running on many serial ports it might be
|
|
thought of as a terminal server. It is in effect a terminal server if
|
|
it's linked to other PC's over a network and if its job is mainly to
|
|
pass thru data and handle the serial port interrupts every 14 (or so)
|
|
bytes. Software called "radius" is sometimes used.
|
|
|
|
Today real terminal servers serve more than just terminals. They also
|
|
serve PC's which emulate terminals, and are sometimes connected to a
|
|
bank of modems connected to phone lines. Some even include built-in
|
|
modems. If a terminal (or PC emulating one) is connected directly to
|
|
a modem, the modem at the other end of the line could be connected to
|
|
a terminal server. In some cases the terminal server by default
|
|
expects the callers to use PPP packets, something that real text
|
|
terminals don't generate.
|
|
|
|
<sect> Appendix E: Cable and DSL modems <label id="other_modems">
|
|
|
|
<sect1> Introduction
|
|
<p> This HOWTO only deals with the common type of analog modem used to
|
|
connect PC's to ordinary analog telephone lines. There are also
|
|
higher speed analog modems that use special types of lines: cable and
|
|
DSL modems. There is also the ISDN "modem" which uses digital signals.
|
|
While this HOWTO doesn't cover such modems, some links to documents
|
|
that do may be found at the start of this HOWTO. The next 3
|
|
sub-sections: DSL, Cable, and ISDN, briefly discuss such modems. For
|
|
both DSL and Cable modems, the basic QAM modulation method is similar
|
|
to ordinary analog analog modems. See <ref id="QAM_" name="Combination
|
|
Modulation">
|
|
|
|
<sect1>Digital Subscriber Line (DSL)
|
|
<p> DSL (often ADSL) uses the existing twisted pair line from your
|
|
home/office to the local telephone office. This can be used if your
|
|
telephone line can accept significantly higher speeds than an ordinary
|
|
modem would use. It replaces the analog-to-digital converter at the
|
|
local telephone office with one which can accept a much faster flow of
|
|
data (in a different format of course). The spectrum of the twisted
|
|
pair line is divided up into various channels. Each channel uses QAM
|
|
modulation like ordinary modems do. Data is sent over multiple
|
|
channels. The device which converts the digital signals from your
|
|
computer to the analog signal used to represent digital data on what
|
|
was once an ordinary telephone line, is a DSL modem. The DSL modem
|
|
is often external (takes up space on your desk) and connects to
|
|
your computer via either an ethernet port or a USB port.
|
|
|
|
<sect1> Cable Modems
|
|
<p> The coaxial cables that provide for cable television in homes have
|
|
additional bandwidth not used for television, mostly at frequencies
|
|
higher than used for cable TV. This extra bandwidth may be used for
|
|
connecting computers to ISP's. However, many computers need to share
|
|
the same cable. The spectrum of the free bandwidth is split up into
|
|
channels (frequency division multiplexing) and each channel is given
|
|
time slots to which individual computers are assigned (time division
|
|
multiplexing). The cable modem converts the digital date from your
|
|
computer (from a network card: NIC) to the required analog signal, and
|
|
only broadcasts within it's assigned time slots on it's assigned
|
|
channel.
|
|
|
|
|
|
<sect> Appendix F: Connecting 2 Modems Directly Back-to-Back (Leased Lines).
|
|
<p>While modems are designed to be connected to telephone lines which
|
|
have dial tones and voltages on the line, it's claimed that most
|
|
modems will communicate when just connected to each other back-to-back
|
|
via a telephone cord. To get this working, type ATD for one modem to
|
|
dial and ATA for the other modem to answer (or set it for auto
|
|
answer). Since there will be no dialtone, you may need to set ATX (or
|
|
whatever) to blind dial (force it to dial without a dialtone). If ATD
|
|
doesn't work because of no phone number, you could try ATD0 to send a
|
|
0.
|
|
|
|
If the above doesn't work, you could make a simple power supply to
|
|
emulate a telephone line. See <url
|
|
url="http://www.jagshouse.com/modem.html" name="Connecting two
|
|
computers using their modems, without a telephone line">.
|
|
|
|
A line without a source of voltage is sometimes called a "dry line"
|
|
and some modems exist which are designed to work on such lines (or
|
|
which can be configured to work on such lines). If you connect one of
|
|
these special modems to a line with voltage on it, it may destroy the
|
|
modem.
|
|
|
|
A leased line is one which is usually leased from the telephone
|
|
company. The end points of the line are under the control of the user
|
|
who may connect a modem at each end of the line. Leased lines may or
|
|
may not have a voltage supply on them. See the mini-howto:
|
|
Leased-Line which covers leased lines where there is neither voltage
|
|
nor dialtone on the line. One type of leased line used two pairs of
|
|
wires (one for each direction) using V.29 modulation at 9600 baud.
|
|
Some brands of leased line modems are incompatible with other brands.
|
|
|
|
<sect> Appendix G: Fax pixels (dots)
|
|
<p> Here's some info on the bloated bandwidth required for standard
|
|
fax including the dot density. You can of course send a fax via your
|
|
modem if you dial the real telephone number of the recipient.
|
|
|
|
<tscreen><verb>
|
|
A4 paper: 216mm (horizontal) * 297mm (vertical)
|
|
normal mode 8dots/mm * 3.85dots/mm
|
|
fine mode * 7.7dots/mm
|
|
extra fine mode *15.4dots/mm
|
|
</verb></tscreen>
|
|
|
|
Each dot is either white or black and thus 1 bit. One sheet of A4
|
|
paper using fine mode is (216*8) * (297*7.7) = about 4 million dots.
|
|
With a compression ratio of 8:1 it takes about 50 seconds at 9600bps
|
|
for transmission.
|
|
|
|
<sect> Appendix H: Stty Hanging Problem (prior to 2000)
|
|
<p>Here's a problem that existed prior to the year 2000 or thereabouts.
|
|
It's since been fixed. If -clocal is set and there is no CD signal,
|
|
then the "stty" command will hang and there is seemingly no way to set
|
|
clocal to stop the hanging (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 CD signal)
|
|
and then exit minicom with no reset so that the CD signal always
|
|
remains on. Then you may use stty again.
|
|
|
|
<sect> Appendix G: Antique Modems
|
|
<sect1> Introduction
|
|
<p> By "antique" I mean modems with speeds of under 56k speed
|
|
(although they don't really run this fast). This appendix compares
|
|
the antique modems with the modern ones. You should read it if you
|
|
are interested in modem history or are intending to actually use an
|
|
antique modem. Also, many modern modems and software still support
|
|
the old protocols and you might find that such old protocols have been
|
|
configured by mistake.
|
|
|
|
<sect1>Historical Modem Protocols
|
|
<p>
|
|
<itemize>
|
|
<item> Bell 103 300 bps; frequency shift keying = FSK (1962)
|
|
<item> V.21 300 bps; frequency shift keying (used a different
|
|
frequency than Bell 103) (1964)
|
|
<item> V.23 1200/75 bps and 600/75 bps asymmetric; 75 bps is the reverse
|
|
channel; frequency shift keying = FSK (1964)
|
|
<item> Bell 212A 1200 bps; quadrature differential phase shift keying
|
|
= QDPSK = DPSK (1963?)
|
|
<item> V.22 1200 bps; fallback to 600 bps ; QDPSK = DPSK (1980)
|
|
<item> V.22bis 2400 bps; QAM (1984)
|
|
<item> V.32 9600 bps; QAM (1984 but not widely used until years
|
|
later)
|
|
<item> V.32bis 14.4k bps; QAM (1991)
|
|
<item> V.34 28.8k bps; QAM (1994) AKA V.fast
|
|
<item> V.34bis 33.6k bps; QAM (1996)
|
|
<item> V.90 56k bps; Modulus Conversion downstream, QAM upstream (1998)
|
|
<item> V.92 56k bps; Modulus conversion in both directions (2000)
|
|
</itemize>
|
|
"bis" means a second version of the standard.<newline>
|
|
QAM= Quadrature Amplitude Modulation. The word "Quadrature" is short
|
|
for "quadrature differential phase shift keying" =QDPSK. "quadrature"
|
|
mean 4 (quad) implying there are 4 possible phases differences,
|
|
separated from each other by 90 degrees. Only the V.22 had 4
|
|
possible phases. After V.22, more possible phases were added so as to
|
|
convey more information, but the name "quadrature" was still retained.
|
|
It just means phase modulation.
|
|
|
|
The above table excludes historical standards for leased lines: Bell
|
|
201B,C (2400 bps) Bell 208A,B (4800 bps; 208B = V.27).
|
|
|
|
<sect1> Historical Overview
|
|
<sect2> Teletypes and dumb terminals
|
|
<p> Prior to 1960, 110 bps modems were used for teletype
|
|
machines (like an electric typewriter only much more noisy). What one
|
|
typed at a teletype (or had saved on punched paper tape) could be
|
|
printed on a remote teletype located far away. No computer was
|
|
involved.
|
|
|
|
In 1960 AT$amp;T came out with a 300 bps modem (for use on it's phone
|
|
system). Then in 1962 it started selling Bell 103 modems to the
|
|
public. Such slow and expensive modems were later mainly used for
|
|
transmitting data between mainframe computers or for connecting a dumb
|
|
terminal to a mainframe computer over phone lines. Many dumb
|
|
terminals didn't even have a screen display, but printed on paper what
|
|
you typed at the keyboard along with responses from the computer.
|
|
|
|
<sect2> PCs and BBSs <label id="bbs_">
|
|
<p>With the advent of the personal computer (PCs) in the early 1980s,
|
|
one could use a modem to dial into a remote mainframe computer. In
|
|
this case, the PC was used like a dumb terminal. But now files could
|
|
be transferred and one PC could connect to another via modems.
|
|
|
|
The 1980s saw the rise of the Bulletin Board System (BBS). A BBS was
|
|
just a computer with a modem listening for incoming calls. The public
|
|
could dial up a BBS with a modem and then download free software,
|
|
participate in discussions on various topics, play on-line games, etc.
|
|
Dialing in to a BBS was something like going to an Internet site.
|
|
Except that to go to another BBS site, you would need to dial another
|
|
number (and possible pay long distance telephone charges). Many BBSs
|
|
would have a monthly charge but some were run by volunteers and were
|
|
free. Many companies established BBSs for customers that contained
|
|
support information, catalogs, etc. In the early 1990s, BBSs were
|
|
booming. By the mid 1990s some even offered Internet connections.
|
|
For some history of BBSs see <url
|
|
url="http://sysopscorner.thebbs.org/bbshist.html" name="Sysops'
|
|
Corner: History of BBSing">
|
|
|
|
<sect2> The Internet
|
|
<p>Then came the advance of Internet in the mid 1990s which resulted
|
|
in the demise of the BBSs near the end of the 1990s. Some BBSs became
|
|
websites, but when BBSs were dying in droves, websites were quite
|
|
expensive so most BBSs just disappeared. The Internet contained far
|
|
more information than any one BBS could maintain so BBSs were no
|
|
longer competitive.
|
|
|
|
Modems permitted the public to connect to the Internet. In the 1990s,
|
|
Modems became fast, cheap and widely used. Then in the late 1990s,
|
|
faster non-analog "modems" appeared: ISDN, DSL, and cable. The
|
|
history of these isn't in this HOWTO.
|
|
|
|
<sect2> Speeds
|
|
<p>Before V.32 (9600 bps), modems typically had speeds of 300 to 2400
|
|
bps. Some super fast ones had much higher speeds (such as 19.2k bps)
|
|
and used non-standard protocols. To utilize these "fast" ones, both
|
|
modems for a connection needed to support the same proprietary protocol
|
|
which often meant that they must be the same brand.
|
|
|
|
Prior to the V.42 standard for error correction and the V.42bis (1990)
|
|
standard for data compression, the MNP standards were usually used for
|
|
both error correction and data compression. An X.PC error correction
|
|
standard was used on some commercial data networks. Compression and
|
|
error correction were available on some 2400 bps modems.
|
|
|
|
From 1960 to 1980 most modems only had a speed of 300 bps (which was
|
|
also 300 baud). This is only 0.3kbps. Modern modems are over 100
|
|
times faster. Some old-slow modems are still in use so they are not
|
|
really "antique" quite yet.
|
|
|
|
<sect1> Proprietary protocols, etc.
|
|
<p> These did not conform to the ITU V-series standards. They were
|
|
used in order to obtain higher speeds before more standardized higher
|
|
speeds became established. The modem at the other end needs to
|
|
support the same protocol for this to work. The dates shown below may
|
|
be only approximate.
|
|
|
|
<itemize>
|
|
<item> PEP (Packetized Ensemble Protocol 1985): 18k (at best).
|
|
<item> Turbo PEP: 23k 1994?
|
|
<item> Hayes Express 96: 9.6k (Hayes 1987)
|
|
<item> HST: 9.6k (US Robotics 1986)
|
|
<item> HST: 14.4k (US Robotics 1989)
|
|
<item> HST: 16.8k (US Robotics 1992)
|
|
<item> V.32 terbo): 19.2k (AT$amp;T 1993) (V.32ter was rejected as a standard)
|
|
<item> V.FastClass: 28.8k (Rockwell 1993) (V.FastClass is not an ITU standard)
|
|
<item> X2 :57.3k (US Robotics 1997)
|
|
<item> K56: Flex 57.3k (Rockwell 1997)
|
|
</itemize>
|
|
The PEP used as much bandwidth as feasible by splitting the spectrum
|
|
into as many as 512 sub-bands. It was supported by Ven-Tel's
|
|
Pathfinder and Telebit's Trailblazer.
|
|
|
|
<sect1> Autobauding <label id="autobaud_">
|
|
<p>This term has a few different meanings. In general it means either
|
|
the automatic adjustment of modem-to-modem speed or of
|
|
modem-to-serial_port speed.
|
|
|
|
<sect1> Modem-to-modem Speed
|
|
<p>Modern modems negotiate the modem-to-modem speed and protocol when
|
|
they first connect to each other and normally connect to each other at
|
|
the highest possible speed. If one side can't negotiate, the other
|
|
side should accept whatever speed and protocol that the fixed side has
|
|
available. Except that some modern modems may no longer support some
|
|
of the antique protocols. As a result of negotiations, one modem may
|
|
need to use a lower speed than its maximum in order to communicate
|
|
with the other modem. This is sometimes called "autobauding" or
|
|
"automode". It might also be called "fallback". A more intuitive use
|
|
of the word "fallback" is where both modems automatically lower their
|
|
speed due to a noisy line. While autobauding is normally the default,
|
|
setting a fixed modem-to-modem speed instead of autobauding is done
|
|
with either an AT command like or by a register like S37.
|
|
|
|
Early modems didn't have such autobauding or fallback. If you have
|
|
such a modem, it will likely work OK if the other modem you connect to
|
|
is a modern one that can adjust it's speed and protocol to yours. But
|
|
a problem arises if both modems which want to communicate with each
|
|
other are both antique and don't support automode. In this case
|
|
they need to be manually set to the same speed and protocol.
|
|
|
|
Even when this automode existed, there was sometimes a limited
|
|
choice of speed (like only 1200/300 bps). In olden days (rarely
|
|
today), a computer dial-in site might have one phone number a certain
|
|
speed (like say 2400) and another phone number for a different speed
|
|
(say 1200). It was often not quite this simple as there might be a
|
|
few different phone number for one speed, or one phone number might
|
|
support say only a couple of speeds (like 1200/300). Also one phone
|
|
number might support only a certain protocol such as the Bell 212A
|
|
modem. Once a site obtained modems that could support a wider variety
|
|
of speeds and protocols, then there was no need to have different
|
|
groups of phone lines.
|
|
|
|
<sect1> Modem-to-serial_port Speed
|
|
<sect2> Same speed required
|
|
<p> For old modems (mostly under 9600 bps) the modem-to-serial_port
|
|
speed had to be the same as the modem-to-modem speed. This was
|
|
because data flowed straight thru the modem without "speed buffering"
|
|
(storing bytes) inside the modem. This meant that both the modem's
|
|
serial port and the computer's serial port had to be set to this
|
|
speed. That is, both ends of the serial cable had to be set for this
|
|
speed.
|
|
|
|
One might erroneously reason that if the serial port speed was higher
|
|
than the modem-to-modem speed, all would work OK since then there
|
|
would be no bottleneck in the serial line. This works OK in the
|
|
direction from the modem to the PC since a higher speed line can have
|
|
a lower thruput speed due to greater time spacing between bytes. But
|
|
disaster strikes for the flow from the PC to the modem since it would
|
|
flow into the modem at a speed faster than the modem could transmit
|
|
the data. Data would be lost since there is no speed buffering.
|
|
|
|
<sect2> Equalizing speed
|
|
<p>If a modem had only one modem-to-modem speed (or was set by
|
|
software or physical switches to only operate at one speed), then this
|
|
wasn't a problem since one would just set the PCs serial port for this
|
|
speed. And the modem would set it's serial port for this speed.
|
|
Another way make the speeds equal is for the modem to detect the PC's
|
|
serial port speed and then set both it's serial speed and it's
|
|
modem-to-modem speed the same. This will be explained later.
|
|
|
|
But for modems that used more than one modem-to-modem speed there's a
|
|
problem. In that case it's not known in advance at what speed the
|
|
modem will connect to another modem. For example, if a fixed speed
|
|
modem dialed in to you modem and your modem supported the remote
|
|
modems fixed speed, then that's the speed it would connect at. If the
|
|
PC's serial port speed had been previously set to a different speed,
|
|
then this speed needs to be changed.
|
|
|
|
But setting the computer's serial port to the modem-to-modem speed was
|
|
a problem since the modem has no way to directly give commands to the
|
|
PCs serial port to change it's speed. Only system software can do
|
|
that. The modem finds out what speed to use based on negotiations
|
|
with the other modem and thus the change of this serial port speed
|
|
can't be done in advance. How does the modem communicate its
|
|
modem-to-modem speed to the system software?
|
|
|
|
<sect2> Use "CONNECT" message to set speed
|
|
<p>Here's one way to do it. Consider the case of a dial-in modem that
|
|
others dial into. A getty program will be used to send a login prompt
|
|
thru the modems to a user's terminal screen. Getty will also be the
|
|
system software that changes the speed of the serial port. The modem
|
|
will tell getty what modem-to-modem speed it's using by sending getty
|
|
a "CONNECT" message giving the modem-to-modem speed (such as "CONNECT
|
|
2400").
|
|
|
|
But there's one problem here. How does one insure that the "CONNECT"
|
|
message, which the modem sends to getty via the serial port, is sent
|
|
at the same speed as the PC's serial port which is expecting a
|
|
"CONNECT" message? Here's how it's done.
|
|
|
|
When the modem is first sent an init string, the modem detects the
|
|
speed of the computer's serial port and sets it's modem-to-serial_port
|
|
speed to this value. Now it can communicate with getty and the
|
|
"CONNECT" message can get thru.
|
|
|
|
To sense the speed the modem has examined the "AT" at the beginning of
|
|
the string. This is sometimes also called autobauding. For modern
|
|
modems, this same modem-to-serial port speed is always retained, even
|
|
after the modem connects to another modem and regardless of what the
|
|
modem-to-modem speed is. But for our old modem this initial serial speed
|
|
may need to be changed later to that of the modem-to-modem speed once
|
|
a connection is made.
|
|
|
|
For example, getty gets a CONNECT 2400 from the modem and switches the
|
|
PC's serial port speed to 2400. The modem also switches its serial
|
|
port speed to 2400. Now both ends of the modem serial cable are at
|
|
2400 and there is no speed mismatch. Then getty sends a login prompt
|
|
out over the phone line thru the modems. The 2400 bps is now both the
|
|
modem-to-modem speed and the modem-to-serial_port speed. Problem
|
|
solved. Mgetty can do this by configuring it for "autobauding" but
|
|
it's only of use for very old (and slow) modems.
|
|
|
|
For dialing out, the same method is used, but now the communication
|
|
software must handle it instead of getty.
|
|
|
|
<sect2> Setting modem-to-modem speeds by the serial speed
|
|
<p>Another way to switch modem-to-modem speed was by using a
|
|
modem feature where the modem would set its modem-to-modem speed to be
|
|
the same as the modem-to-serial port speed it detected. The Bn AT
|
|
commands would enable this and determine what protocol to use for each
|
|
speed. So with this enabled, setting the serial speed by the computer
|
|
would also set the modem-to-modem speed to be the same. This should
|
|
result in this modem being inflexible in any speed negotiations
|
|
between the modems.
|
|
|
|
<sect2> Manual bauding
|
|
<p>Another (but cruder) way to solve the serial speed problem when
|
|
dialing in to a site was to get the remote site to change it's
|
|
modem-to-modem speed to match your serial port speed. It works like
|
|
this: The person trying to login over a modem connection doesn't see
|
|
any login prompt because of a speed mismatch. So the person trying to
|
|
login hits a "break" key to send a break signal over the phone line
|
|
(via modem) to getty on the remote machine. A break signal will
|
|
always get through even if there is a speed mismatch in a serial line.
|
|
|
|
The remote getty gets this break signal and switches the remote's
|
|
serial port to the next speed as specified in its getty configuration
|
|
file. This new remote serial port speed causes the remote modem to
|
|
switch to the same modem-to-modem speed as previously configured by
|
|
the ATB command. Then the local modem would transmit the login prompt
|
|
over the local's serial line at this speed. If one doesn't see a
|
|
login prompt, then they hit the break key again and a new speed is
|
|
tried. This continues until the remote getty finally gets the speed
|
|
correct (equal to the serial speed set on the local PC) and a login
|
|
prompt finally displays. Note that PC keyboards have no "break" key
|
|
but dumb terminal keyboards did. Mgetty, agetty, and uugetty can do
|
|
this obsolete break method and it's called "manual bauding".
|
|
|
|
<sect2>Unsupported speeds
|
|
<p>In Linux, there's a problem if the speed is set to a speed not
|
|
supported by Linux's serial port (for example 7200 bps). You may dial
|
|
out and connect at 7200 bps (both modem-to-modem and
|
|
modem-to-serial_port speed) but you only see garbage since Linux
|
|
doesn't support 7200 on the serial port. Once you connect there is no
|
|
simple way to hang up because even the +++ escape sequence can't be
|
|
sent to the modem over a 7200 baud interface.
|
|
|
|
<sect2>Modern modems, speed buffering
|
|
<p>To dial out by the antique method using some modern modems set
|
|
&Q0 N0 and S37=5 (if you want 1200 bps). Some of the S17 settings
|
|
vary with the make of modem. S37=0 is the default that connects the
|
|
modern way at the highest speed supported.
|
|
|
|
Modern modems can use almost any serial port speed. It doesn't
|
|
depend at all on modem-to-modem speed. To do this, they employ speed
|
|
buffering and flow control. Speed buffering means that modems have
|
|
buffers so that there can be a difference between the modem-to-modem
|
|
speed and the modem-to-serial_port speed. If the flow entering the
|
|
modem is faster than the flow exiting it, the excess flow is simply
|
|
stored in a buffer in the modem. Then to prevent the buffer from
|
|
overflowing, the modem sends a flow control signal to stop the input
|
|
flow to it. This is true for either direction of flow. See
|
|
<ref id="flow_control" name="Flow Control"> for more details.
|
|
|
|
<sect1> Before AT Commands
|
|
<p> Hayes introduced the AT command set and other modem manufacturers
|
|
adopted it as a standard. Before the AT commands, many modems used
|
|
dip switches to configure the modem. Another command set is the CCITT
|
|
V.25bis command set. Some modems supported both CCITT and AT
|
|
commands. The CCITT V.25bis also specifies how Synchronous
|
|
modem-to-serial_port communication is to take place using either the
|
|
ASCII or 8-bit EBCDIC character sets.
|
|
|
|
<sect1> Acoustic-Coupling
|
|
<p> This is where one connects a modem to a telephone using audio tones
|
|
that one can hear. The modem contains a microphone and speaker which
|
|
"talks" directly into the telephone handset without using any wires.
|
|
It's "wireless" in a sense but uses sound waves instead of radio
|
|
waves. The modem speaker is placed in contact with the telephone
|
|
microphone (on the handset) so that the tones from the modem go into
|
|
the telephone. The modem microphone, picks up tones from the
|
|
telephone handset speaker. This scheme is called "acoustic coupling".
|
|
|
|
A major problem is that outside noises can interfere and cause
|
|
errors. The advantage is convenience: There are no cables to plug in.
|
|
Most modems that could do this were only 300 baud, but higher speeds
|
|
were used too. It's said that 9600 bps didn't work very well using
|
|
this scheme.
|
|
|
|
<sect1> Data Compression and Error Correction
|
|
<p> MNP 2, 3, or 4 were used for error correction. MNP 5 was
|
|
compression. Modern modems generally use V42 (error correction) and
|
|
V42bis (compression). Many modems support both MNP and V42.
|
|
|
|
<sect1>Historical Bibliography
|
|
<p>PC Today, Sept. 2004, v.2 #9, pp 110-111: "The Rise & Fall of
|
|
Dial-Up"
|
|
|
|
END OF Modem-HOWTO
|
|
</article>
|