LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2003-03-10 14:22:55 +00:00
parent d723481f09
commit a26a935279
8 changed files with 863 additions and 635 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
View File

@ -1834,7 +1834,7 @@ and their solutions, availability and more. </Para>
Modem-HOWTO</ULink>,
<CiteTitle>Modem HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: September 2002</CiteTitle>.
<CiteTitle>Updated: March 2003</CiteTitle>.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC. </Para>
</ListItem>
@ -2524,7 +2524,7 @@ SCSI-Generic-HOWTO</ULink> for more current information.</emphasis> </Para>
Secure-Programs-HOWTO</ULink>,
<CiteTitle>Secure Programming for Linux and Unix HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: February 2003</CiteTitle>.
<CiteTitle>Updated: March 2003</CiteTitle>.
Provides a set of design and implementation guidelines for writing
secure programs for Linux and Unix systems. </Para>
</ListItem>
@ -2591,7 +2591,7 @@ Addresses Linux localization issues specific to Serbian users
Serial-HOWTO</ULink>,
<CiteTitle>Serial HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: March 2002</CiteTitle>.
<CiteTitle>Updated: February 2003</CiteTitle>.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port

4
LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
View File

@ -1011,7 +1011,7 @@ attached to this system with other systems over a TCP/IP network. </Para>
Modem-HOWTO</ULink>,
<CiteTitle>Modem HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: September 2002</CiteTitle>.
<CiteTitle>Updated: March 2003</CiteTitle>.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC. </Para>
</ListItem>
@ -1131,7 +1131,7 @@ SCSI-Generic-HOWTO</ULink> for more current information.</emphasis> </Para>
Serial-HOWTO</ULink>,
<CiteTitle>Serial HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: March 2002</CiteTitle>.
<CiteTitle>Updated: February 2003</CiteTitle>.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port

2
LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml
View File

@ -207,7 +207,7 @@ Configuring your modem and pppd to use a 2 wire twisted pair leased line. </Para
Modem-HOWTO</ULink>,
<CiteTitle>Modem HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: September 2002</CiteTitle>.
<CiteTitle>Updated: March 2003</CiteTitle>.
Help with selecting, connecting, configuring, trouble-shooting, and
understanding modems for a PC. </Para>
</ListItem>

2
LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml
View File

@ -489,7 +489,7 @@ operating systems with XML-RPC support. </Para>
Secure-Programs-HOWTO</ULink>,
<CiteTitle>Secure Programming for Linux and Unix HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: February 2003</CiteTitle>.
<CiteTitle>Updated: March 2003</CiteTitle>.
Provides a set of design and implementation guidelines for writing
secure programs for Linux and Unix systems. </Para>
</ListItem>

10
LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog
View File

@ -1,3 +1,13 @@
2002-02-18 David A. Wheeler <dwheeler@dwheeler.com>
* Clarified more about GUI applications.
* Updated my picture, now it actually looks more like me.
* Changed URL for libsafe.
* Renamed LCLint to splint.
* Mentioned dreamland.
2002-02-16 David A. Wheeler <dwheeler@dwheeler.com>
* Released version 3.007.
2002-02-02 David A. Wheeler <dwheeler@dwheeler.com>
* Noted Shamir and Tromir's paper on Factoring Large Numbers with
the TWIRL device (a draft paper at this time) - the paper basically

92
LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml
View File

@ -134,8 +134,8 @@ http://www.gocsi.com/press/20020407.html
<firstname>David</firstname> <othername role="mi">A.</othername><surname>Wheeler</surname>
</author>
<address><email>dwheeler@dwheeler.com</email></address>
<pubdate>v3.007, 16 February 2003</pubdate>
<edition>v3.007</edition>
<pubdate>v3.010, 3 March 2003</pubdate>
<edition>v3.010</edition>
<!-- FYI: The LDP claims they don't use the "edition" tag. -->
<copyright>
<year>1999</year>
@ -2261,9 +2261,9 @@ Information Assurance Glossary</ulink> defines hacker as
``A person who delights in having an intimate understanding of the
internal workings of computers and computer networks.
The term is misused in a negative context where `cracker' should be used.''
<ulink url="http://www.tuxedo.org/~esr/jargon">The
<ulink url="http://www.catb.org/~esr/jargon">The
Jargon File</ulink> has a
<ulink url="http://www.tuxedo.org/~esr/jargon/html/entry/hacker.html">
<ulink url="http://www.catb.org/~esr/jargon/html/entry/hacker.html">
long and complicate definition for hacker</ulink>, starting with
``A person who enjoys exploring the details of programmable systems
and how to stretch their capabilities,
@ -2285,7 +2285,7 @@ While this may cause a minor loss of typographical beauty, the traditional
American system causes extraneous characters to be placed inside the quotes.
These extraneous characters have
no effect on prose but can be disastrous in code or computer commands.
<!-- See http://www.tuxedo.org/~esr/jargon/html/Hacker-Writing-Style.html -->
<!-- See http://www.catb.org/~esr/jargon/html/Hacker-Writing-Style.html -->
<!-- I distinguish between the terms privilege and permission in this book;
a process (subject) may acquire privileges, while an object has permissions. -->
I use standard American (not British) spelling; I've yet to meet an
@ -3463,6 +3463,12 @@ and then call a program, these variables will have full effect.
Other Unix-like systems handle the situation differently but for the
same reason: a setuid/setgid program should not be unduly affected
by the environment variables set.
Note that graphical user interface toolkits generally do permit
user control over dynamically linked libraries, because
executables that directly invoke graphical user inteface toolkits
should never, ever, be setuid (or have other special privileges) at all.
For more about how to develop secure GUI applications, see
<xref linkend="minimize-privileged-modules">.
</para>
<para>
@ -7241,11 +7247,12 @@ that any buffer overflows are contained within the current stack frame.
Their initial performance analysis suggests that this
library's overhead is very small.
Libsafe papers and source code are available at
<ulink url="http://www.bell-labs.com/org/11356/libsafe.html">http://www.bell-labs.com/org/11356/libsafe.html</ulink>.
<ulink url="http://www.research.avayalabs.com/project/libsafe">
http://www.research.avayalabs.com/project/libsafe</ulink>.
<!-- <ulink url="http://www.bell-labs.com/org/11356/libsafe.html">http://www.bell-labs.com/org/11356/libsafe.html</ulink>.
-->
The Libsafe source code is available under the completely
open source LGPL license,
and there are indications that many Linux distributors are interested
in using it.
open source LGPL license.
</para>
<para>
@ -7847,9 +7854,10 @@ versions of the linux kernel.
</para>
<para>
One Linux-unique tool you can use to simplify minimizing granted privileges
One tool you can use to simplify minimizing granted privileges
is the ``compartment'' tool developed by SuSE.
This tool sets the filesystem root, uid, gid, and/or the
This tool, which only works on Linux,
sets the filesystem root, uid, gid, and/or the
capability set, then runs the given program.
This is particularly handy for running some other program without
modifying it.
@ -7886,8 +7894,12 @@ typical Linux distributions, but this may quickly change.
You can download the program via
<ulink
url="http://www.suse.de/~marc">http://www.suse.de/~marc</ulink>.
A similar tool is dreamland; you can that at
<ulink url="http://www.7ka.mipt.ru/~szh/dreamland">
http://www.7ka.mipt.ru/~szh/dreamland</ulink>.
</para>
<para>
Note that <emphasis remap="it">not</emphasis> all Unix-like systems,
implement POSIX capabilities, and PR_SET_KEEPCAPS is currently
@ -8048,24 +8060,45 @@ Another approach is to have separate commands in separate
executables; one command might be a complex
tool that can do a vast number of tasks for a privileged user (e.g., root),
while the other tool is setuid but is a small, simple tool that
only permits a small command subset.
only permits a small command subset (and does not trust its invoker).
The small, simple tool checks to see if the input meets various criteria for
acceptability, and then if it determines the input is acceptable, it
passes the data on to the complex tool.
Note that the small, simple tool must do a thorough job checking its inputs
and limiting what it will pass along to the complex tool, or this can
be a vulnerability.
The communication could be via shell invocation, or any IPC mechanism.
These approaches can even be layered several ways, for example,
a complex user tool could call a simple setuid
``wrapping'' program (that checks its inputs for secure values)
that then passes on information to another complex trusted tool.
This approach is especially helpful for GUI-based systems; have the GUI portion
run as a normal user, and then pass security-relevant
requests on to another program
that has the special privileges for actual execution.
</para>
<para>
This approach is the normal approach for developing GUI-based applications
which requre privilege, but must be run by unprivileged users.
The GUI portion is run as a normal unprivileged user process;
that process then passes security-relevant requests on to another process
that has the special privileges (and does not trust the first process, but
instead limits the requests to whatever the user is allowed to do).
Never develop a program that is
privileged (e.g., using setuid) and also directly invokes a graphical toolkit:
Graphical toolkits aren't designed to be used this way, and it would be
extremely difficult to audit graphical toolkits
in a way to make this possible.
Fundamentally, graphical toolkits must be large, and it's extremely
unwise to place so much faith in the perfection of that much code, so
there is no point in trying to make them do what should never be done.
Feel free to create a small setuid program that invokes two separate programs:
one without privileges (but with the graphical interface), and one with
privileges (and without an external interface).
Or, create a small setuid program that can be invoked by the unprivileged
GUI application.
But never combine the two into a single process.
For more about this, see the statement by
<ulink url="http://www.gtk.org/setuid.html">Owen Taylor about GTK
and setuid, discussing why GTK_MODULES is not a security hole</ulink>.
</para>
<para>
Some applications can be best developed by dividing the problem
@ -11793,7 +11826,7 @@ When MALLOC_CHECK_ is set, a special (less efficient) implementation
is used which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs).
Not all such errors can be proteced against, however, and memory leaks
Not all such errors can be protected against, however, and memory leaks
can result.
If MALLOC_CHECK_ is set to 0, any detected heap corruption
is silently ignored;
@ -14680,13 +14713,15 @@ ITS4 is available at
<ulink url="http://www.rstcorp.com/its4">http://www.rstcorp.com/its4</ulink>.
</para></listitem>
<listitem><para>
LCLint is a tool for statically checking C programs.
With minimal effort, LCLint can be used as a better lint.
Splint (formerly named LCLint) is a tool for statically checking C programs.
With minimal effort, splint can be used as a better lint.
If additional effort is invested adding annotations to programs,
LCLint can perform stronger checking than can be done by any standard lint.
splint can perform stronger checking than can be done by any standard lint.
For example, it can be used to statically detect likely buffer overflows.
The software is licensed under the GPL and is available from
<ulink url="http://lclint.cs.virginia.edu">http://lclint.cs.virginia.edu</ulink>.
The software is licensed under the GPL and is available at
<ulink url="http://www.splint.org">http://www.splint.org</ulink>.
<!-- <ulink url="http://lclint.cs.virginia.edu">http://lclint.cs.virginia.edu</ulink>.
-->
</para></listitem>
<listitem><para>
cqual is a type-based analysis tool for finding bugs in C programs. cqual
@ -14755,6 +14790,9 @@ detect certain memory management errors.
(public domain) and
<ulink url="http://odin.ac.hmc.edu/~neldredge/yamd/">YAMD</ulink> (GPL)
can detect memory allocation problems for C and C++.
You can even use the built-in capabilities of the
GNU C library's malloc library, which has the
MALLOC_CHECK_ environment variable (see its manual page for more information).
There are many others.
</para>
@ -15126,7 +15164,7 @@ Free Software Project Management HOWTO</ulink> and
<ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">
Software Release Practice HOWTO</ulink>;
you should also read
<ulink url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar">
<ulink url="http://www.catb.org/~esr/writings/cathedral-bazaar">
The Cathedral and the Bazaar</ulink>.
</para>
@ -16068,7 +16106,7 @@ Raymond, Eric.
1997.
<emphasis remap="it">The Cathedral and the Bazaar</emphasis>.
<ulink
url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar">http://www.tuxedo.org/~esr/writings/cathedral-bazaar</ulink>
url="http://www.catb.org/~esr/writings/cathedral-bazaar">http://www.catb.org/~esr/writings/cathedral-bazaar</ulink>
</para>
<para>
@ -16077,7 +16115,7 @@ Raymond, Eric.
April 1998.
<emphasis remap="it">Homesteading the Noosphere</emphasis>.
<ulink
url="http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html">http://www.tuxedo.org/~esr/writings/homesteading/homesteading.html</ulink>
url="http://www.catb.org/~esr/writings/homesteading/homesteading.html">http://www.catb.org/~esr/writings/homesteading/homesteading.html</ulink>
</para>
<para>
@ -17461,7 +17499,7 @@ per the license agreement included above.
<mediaobject>
<imageobject>
<imagedata fileref="dwheel1.jpg" format="jpg">
<imagedata fileref="dwheeler2003b.jpg" format="jpg">
</imageobject>
<caption>
<para>David A. Wheeler</para>

538
LDP/howto/linuxdoc/Modem-HOWTO.sgml
View File

@ -3,11 +3,12 @@
<title> Modem-HOWTO
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
<date> v0.25, September 2002
<date> v0.26, March 2003
<!--
Change log: + => added more info ++ => added new topic
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
@ -111,8 +112,8 @@ 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-2001 by David S. Lawyer <url url="mailto:dave@lafn.org">
<!-- license.H begin -->
<p> Copyright (c) 1998-2003 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
@ -123,7 +124,7 @@ provided that you:
<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@linuxdoc.org.
(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.
@ -141,9 +142,9 @@ 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) should be assumed to
be a trademark). Such trademarks belong to their respective owners.
<!-- copyright.H end -->
<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 -->
"Hayes" is a trademark of Microcomputer Products Inc. I use
@ -175,31 +176,27 @@ 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 come out every few months. The
modem situation is rapidly changing (and I'm still learning). 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.25, September 2002 with
<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.26, March 2003 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 v0.00 see the source file
(in linuxdoc format) at
<url
<p> For a full revision history going back to the first version see
the source file (in linuxdoc format) at <url
url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Modem-HOWTO.sgml.gz">.
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?<newline>
v0.24 June 2002: new callback link, "You are already online" error,
fixed several typos reported by Francesco Ronconi<newline>
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.
<sect1> What is a Modem ? <label id="what_is_modem">
<p> A modem is a device that lets one send digital signals over an
@ -215,10 +212,11 @@ may phone in to them and use their computer. This is called
There are four basic types of modems for a PC: external, USB, internal
and built-in. The external 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 modem plugs into a connector on the back of the PC known
as a "serial port". The USB modem plugs into the USB bus 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 part of the
Sometimes the USB type is called "USB external". The external serial
modem plugs into a connector on the back of the PC known as a "serial
port". The USB modem plugs into the USB bus 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 part of the
motherboard and is thus built into the computer. It's is just like an
internal modem except it can't be removed or replaced. As of 2001,
built-in modems are primarily for laptops. What is said in this HOWTO
@ -226,21 +224,30 @@ regarding internal modems will generally apply also to built-in
modems.
For a more detailed comparison see <ref id="int_vs_ext" name="External
vs. Internal">. When you get an internal, built-in, or USB modem,
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 another modem or a printer).
In Linux, the serial ports are named ttyS0, ttyS1, etc. (usually
corresponding respectively to COM1, COM2, etc. in Dos/Windows). For
the new devfs they are all in the /dev/ttys/ directory and named 0, 1,
etc. See <ref id="basics_" name="Modem & Serial Port Basics"> for
more details on modems and serial ports.
more details on modems and serial ports. With a USB modem, the driver
simulates a serial port at say /dev/usb/asm/0.
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">.
See <ref id="voice_" name="Voicemail Software">.
<sect1> Does My Computer Contain a Modem ?
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 ?).
<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
look like a jack on the wall of a house where a telephone plugs in.
@ -403,13 +410,13 @@ external modem and plug it in. But if you get the right internal
modem it may be just as easy.
<sect1> Is a Driver Needed ?
<p> Hardware modems (including all external modems) don't really need
any modem driver. But any software modem (winmodem, linmodem) must
have a modem driver (if it exists for Linux). The serial port the
modem resides on does need a driver and it's supplied either as a
Linux serial module or compiled into the kernel. Any serial driver
for a PCI Modem should install automatically since they are detected
by system software.
<p> Hardware modems (including all serial external modems) don't
really need any modem driver. But any software modem (winmodem,
linmodem) must have a modem driver (if it exists for Linux). The
serial port the modem resides on does need a driver and it's supplied
either as a Linux serial module or compiled into the kernel. Any
serial driver for a PCI Modem should install automatically since they
are detected by system software.
Software modems require software to run them and obviously do need a
driver. The drivers for MS Windows are *.exe programs which will not
@ -469,7 +476,7 @@ program and configure the modem itself.
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.
Some new PC don't have any ISA slots. Only some newer PCs will have
Some new PCs don't have any ISA slots. 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
@ -696,11 +703,14 @@ one of them.
<p>USB = Universal Serial Bus. Some USB modems work with Linux and
some don't. 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... document in
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.4.x in
Debian, perhaps /usr/doc/kernel... in some distributions). The ACM
serial port for the first (0th) such modem is (with devfs) is:
/dev/usb/acm/0. Otherwise it might be /dev/usb/ttyACM0.
"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.
<sect1> Which Internal Modems might not work with Linux <label id="m_to_avoid">
<p>
@ -901,6 +911,7 @@ 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.
-->
<!-- ifdef MODEM_ -->
<p> You don't have to understand the basics to use and install a
@ -940,7 +951,7 @@ name="Modulation Details">.
<sect1> What is a Serial Port ?
<sect2> Intro to Serial
<p> The serial port is an I/O (Input/Output) device.
<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.
@ -1051,7 +1062,7 @@ 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 what physical port
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
@ -1068,18 +1079,18 @@ their way to their destination inside your computer.
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 for a number of
bytes and then issues an interrupt.
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 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, 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.
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
@ -1088,13 +1099,13 @@ 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 (1 in old serial ports) 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_ -->
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.
For an external modem, there is no way (such as flow control) to stop
<!-- ifdef MODEM_ -->
For an external modem, there may be no way (such as flow control) to stop
the flow rapidly enough to prevent this. For an internal modem the
16-byte FIFO buffer is on the same card and a good modem will not
write to it if it's full. Thus a good internal modem will not overrun
@ -1104,11 +1115,11 @@ being overrun. This is one advantage of an internal modem over an
external. <!-- ifdef MODEM end -->
Interrupts are also issued when the serial port has just sent out all
16 of its bytes from its small transmit buffer out the external cable.
of its bytes from its small transmit 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.
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
@ -1201,8 +1212,9 @@ 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 is since the modem contains a dedicated serial
port within it.
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
@ -1224,7 +1236,7 @@ id="speed_" name="What Speed Should I Use">.
<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 to allow a jump in instantaneous flow rates.
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
@ -1259,18 +1271,19 @@ 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). The compression ratio is
3.43 (115.2/33.6) which is much higher than average. In this case the
modem is able to compress and the 115.2 bps PC-to-modem flow and send
the same data out on the phone line at 33.6bps. There's no need for
flow control here. But such a high compression ratio rarely happens
so that most of the time flow control is needed to slow down the flow
on the 115.2 bps PC-to-modem cable. The flow is stopped and started
so that the average flow is usually well under the "on" flow of 115.2
bps.
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 and
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 that 3.43. But
the compression ratio varies from second to second and is likely to
drops below 3.43. Thus, some of the time flow control is needed to
slow down the average flow on the 115.2 bps PC-to-modem cable. The
flow is stopped and started so that the average flow is usually lower
than the "on" flow of 115.2 bps.
In the above example the modem was an external modem. But the same
situation exists (as of late 2000) for most internal modems. There is
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.
@ -1280,23 +1293,25 @@ 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 involve 3 buffers: 1. in the modem
2. in the UART chip (called FIFOs) 3. in main memory managed by the
serial driver. Flow control protects certain buffers from
overflowing. The small UART FIFO buffers are not protected in this
way but rely instead on a fast response to the interrupts they issue.
FIFO stand for "First In, First Out" which is the way it handles
bytes. All the 3 buffers use the FIFO rule but only one of them also
uses it as a name. This is the essence of flow control but there are
still some more details.
serial driver. Flow control protects all buffers (except the FIFOs)
from overflowing.
Under Linux, the small UART FIFO buffers are not protected in this way
but rely instead 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 one of them
is named "FIFO". This is the essence of flow control but there
are still some more details.
<!-- ifdef MODEM_ -->
You don't often need flow control in the direction from the modem to a
PC. For complex example of a case where it's needed see "Complex Flow
Control Example" in the Serial-HOWTO. But if you don't have a high
enough speed set between the modem and the computer (serial port
speed) then you do need to slow down the flow coming into the modem
from the telephone line. To do this your modem must tell the other
modem to stop sending. See <ref id="M-M_flow_c" name="Modem-to-Modem
Flow Control">.
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 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 -->
@ -1304,11 +1319,24 @@ Flow Control">.
<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.
<!-- ifdef MODEM_ -->
Modern modems almost always use hardware flow control between the
modem and the serial port.
<!-- ifdef MODEM end -->
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 the signal.
For the case of a modem this "other" pin will be the modem's RTS pin
(same pin label as the PC). But for a printer or terminal, it will be
a CTS pin and requires "crossover" or "null modem" cable so as to
connect the CTS pin at one end with the RTS pin at the other end. 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 and the RTS pin a receive it. For a
non-modem, the roles of the RTS and CTS pins are interchanged.
Software flow control uses the main receive and transmit wires to send
the start and stop signals. It uses the ASCII control characters DC1
@ -1326,19 +1354,19 @@ 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 long files from my PC to
an ISP and a huge amount of retries and errors resulted (but
eventually Kermit could send a long file after many retries).
Receiving in the other direction (from my ISP to me) worked fine. The
problem turned out to be a modem with broken flow control. 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) was always higher than the
flow over the telephone line. But it was a problem in the other
direction where the PC could send at 115.2 kbps until it overran the
modem). The fix was to enable flow control by putting into the init
string an enable-flow-control command for the modem.
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) 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
@ -1350,48 +1378,53 @@ used.
<!-- ifdef MODEM end -->
<sect1> Data Flow Path; Buffers
<p> Much has been explained about this including flow control, a pair
of 16-byte FIFO buffers (in the UART), and a pair of larger buffers
inside a device connected to the serial port (such as a modem). But
there is still another pair of buffers. These are large buffers
(perhaps 4k) in main memory also known as serial port buffers. When
an application program sends bytes to the serial port
(and modem)they first get stashed in the transmit serial port buffer in main
memory. The pair consists of both this transmit buffer and 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.
<p>It's been mention 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
pair consists of both the transmit buffer and 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 4k-byte 16-byte 1k-byte tele-
BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
application 8k-byte 16-byte 1k-byte tele-
BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
program buffer buffer buffer line
</verb>
The serial device driver takes out say 16 bytes from this transmit buffer,
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
which also has a fair sized (say 1k) buffer. When the device driver
(on orders from flow control) 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 4k transmit buffer until it becomes
fill.
For the transmit case, the serial device driver takes out say 16 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) 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 MODEM continue to be sent out
until these buffers empty.
When it 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. It may
switch to running other processes while it's waiting at a flow control
stop. The above was a little oversimplified since there is another
alternative of having the application program itself do something else
while it is waiting to "write".
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 two 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.
<!-- ifdef MODEM_ -->
<sect1> Modem Commands
@ -1432,7 +1465,7 @@ id="modem_conf" name="Modem Configuration">
<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
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
@ -1500,6 +1533,7 @@ 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.
-->
<sect1> IO & IRQ Overview
@ -1614,7 +1648,7 @@ got them working anyway). The 2.4 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 it's IRQ, etc. So you don't need to use "setserial" for it.
<!--
<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
@ -1637,7 +1671,7 @@ 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.
@ -2174,11 +2208,12 @@ stty -F /dev/ttyS2 crtscts
</verb></tscreen>
If you want to see if flow control is enabled do the following: In
minicom (or the like) type AT&amp;V to see how the modem is configured
and look for &amp;K3 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).
minicom (or the like) type AT&amp;V (or ATI4 on 3Com modems) to see
how the modem is configured and look for &amp;K3 (or &amp;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).
<sect1> Speed Settings
<p> Besides flow control there is speed. See <ref id="speed_"
@ -2426,9 +2461,10 @@ these AT commands:
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&amp;v</tt> to
display the profile. To exit minicom without disturbing this profile,
use the q (quit) command for exiting without resetting.
restoring the saved modem profile. Then type <tt>at&amp;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
@ -2497,6 +2533,7 @@ interface and makes it easy to deal with a huge number of devices.
The device names have all changed as well. But there's an option to
continue using the old names. For a detailed description of it see:
<url url="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html">
Also see the kernel documentation tree: filesystems/devfs.
The name changes (if used) are: ttyS2 becomes tts/2 (Serial port),
tty3 becomes vc/3 (Virtual Console), ptyp1 becomes pty/m1 (PTY
@ -2513,10 +2550,10 @@ in the /dev directory.
There formerly was a "cua" name for each serial port and it behaved
just a little differently. For example, ttyS2 would correspond to
cua2. 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. Their drivers behave slightly different than for the
ttyS ones. name="cua Device Obsolete">."')
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.
Dos/Windows use the COM name while the <tt/setserial/ program uses
tty00, tty01, etc. Don't confuse these with dev/tty0, dev/tty1, etc.
@ -2590,6 +2627,7 @@ 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
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
are some minor differences, depending on which HOWTO it appears in.
@ -2724,14 +2762,15 @@ 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 the
configuration file <tt>/etc/serial.conf</tt> which will be used next
time you start Linux. At boot-time when the serial module loads (or
the like), a probe for UARTs is made automatically and reported on the
screen. But the IRQs shown may be wrong. The second report of the
same is the result of a script which usually does no probing and thus
provides no reliable information as to how the hardware is actually
set. It only shows configuration data someone wrote into the script
or data that got saved in /etc/serial.conf.
configuration file <tt>/etc/serial.conf</tt> or
<tt>/var/lib/serial.conf</tt> which will be used next time you start
Linux. At boot-time when the serial module loads (or the like), a
probe for UARTs is made automatically and reported on the screen. But
the IRQs shown may be wrong. The second report of the same is the
result of a script which usually does no probing and thus provides no
reliable information as to how the hardware is actually set. It only
shows configuration data someone wrote into the script or data that
got saved in /etc/serial.conf.
It may be that two serial ports both have the same IO address set in
the hardware. Of course this is not permitted but it sometimes
@ -3340,8 +3379,8 @@ 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 enable "AutoPPP" You can find the latest
information on <tt/mgetty/ at <htmlurl
/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/&tilde;doering/mgetty/"
name="http://www.leo.org/&tilde;doering/mgetty/"> and <url
url="http://alpha.greenie.net/mgetty/">
@ -3909,7 +3948,7 @@ 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 should
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
@ -3917,9 +3956,10 @@ 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 that way since the
modem card probably includes a dedicated serial port which does have
speed limits (and settable speeds).
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"
@ -3929,9 +3969,9 @@ 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 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 need to set it 3
times faster, etc.
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
@ -3946,6 +3986,7 @@ different speeds, then they couldn't communicate with each other.
<sect1> Can't Set a High Enough Speed <label id="high_speed">
<!-- high_speed.H begin In Serial and Modem HOWTOs but some of the speed
section is unique to each HOWTO.
Feb. 2003,
-->
<sect2> Speeds over 115.2k
<p> The top speed of 115.2k has been standard since the mid 1990's.
@ -3965,17 +4006,19 @@ 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 2002.
A non-standard way to do this is to use a very large number for the
divisor which isn't really a divisor at all. It's just a code number
to tell the serial driver what speed to use. In such cases you need
to compile the kernel with special patches.
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 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.
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.
@ -4341,11 +4384,14 @@ 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. Thus the message from
minicom "You are already online. Hangup 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.
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
@ -4375,8 +4421,8 @@ 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" really means is that the
serial port (and the modem) can't be found.
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, or cat
/proc/pci, or dmesg to find the correct address and irq of the
@ -4388,12 +4434,13 @@ the kernel to understand the lspci data correctly. You might notice
this in a boot-time message.
<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&amp;v to see if
&amp;C or &amp;C0 is set. If so, CD will be on even if you are
offline and you'll get this error message. The fix is to set &amp;C1
in the init string or save it in the modem.
offline and you'll erroneously get this error message. The fix is to
set &amp;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
@ -4541,6 +4588,9 @@ Nov. '00: which connector is ttyS1, etc. Input/output error, overrun
Dec. '00: /proc/tty/driver/serial shows info, I/O error+, pid 161 in
example n.g.
July '02: typo: is doesn't => it doesn't, clarity re port not found
Dec. '02: IO error may mean IRQ conflict or IO address conflict.
Jan. '03: LSR safety check error
Feb. '03: Interrupts may be shared on PCI Bus
-->
<sect1>(The following subsections are in both the Serial and Modem HOWTOs)
@ -4551,20 +4601,22 @@ often because it's disabled and has no address (PnP hasn't enabled it)
or that it is enabled but is not at the I/O address that setserial
thinks it's at. Thus it can't be found.
Check the BIOS menus and BIOS messages at boot-time. For the PCI bus
use lspci or scanpci. 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
it:
First check BIOS messages at boot-time (and possible the BIOS menu for
the serial port). For the PCI bus use lspci or scanpci. 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 it:
Using "scanport" (Debian only ??) will scan all ISA 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. You may try probing with
setserial. See <ref id="probing_ss" name="Probing">. If nothing
seems to get thru the port it may be accessible but have a bad
interrupt. See <ref id="slow_" name="Extremely Slow: Text appears on
the screen slowly after long delays">. Use <tt>setserial -g</tt> to
see what the serial driver thinks and check for IRQ and I0 address
For a non-PnP ISA legacy port, using "scanport" (Debian only ??) will
scan all 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.
You may try probing with setserial. See <ref id="probing_ss"
name="Probing">.
If nothing seems to get thru the port it may be accessible but have a
bad interrupt. See <ref id="slow_" name="Extremely Slow: Text appears
on the screen slowly after long delays">. Use <tt>setserial -g</tt>
to see what the serial driver thinks and check for IRQ and I0 address
conflicts. Even if you see no conflicts the driver may have incorrect
information (view it by "setserial") and conflicts may still exist.
@ -4717,25 +4769,27 @@ have been automatically removed if it contained a stale process id
<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 (the resource is "busy").
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 often means that a resource is in use. What
makes it even more confusing is that in some cases neither the device
nor the resources that it needs are actually "busy".
busy (in use). But it often 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".
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.
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
@ -4749,9 +4803,8 @@ There are two possible cases when you see this message:
</enum>
What you need to do is to find the interrupt setserial thinks
<tt/ttyS2/ is using. Look at /proc/tty/driver/serial (if you have
it). You should also be able to see it with the "setserial" command
for <tt/ttyS2/.
<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
@ -4773,15 +4826,21 @@ not it's a potential interrupt conflict is to set the IRQ to 0
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 or stty
<p> You may have typed "ttys" instead of "ttyS". You will see this
error message if you try to use the setserial command for any device
that is not a serial port. 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 could also mean that there isn't any
serial port at the IO address that setserial thinks your port is at.
<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> Overrun errors on serial port
<sect1>"LSR safety check engaged"
<p>LSR is the name of a hardware register. It's claimed that this
means there is no serial port at the specified address.
<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
@ -5505,7 +5564,7 @@ system). 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
instead.
what you typed at the keyboard along with responses from the computer.
<sect2> PCs and BBSs
<p>With the advent of the personal computer (PCs) in the early 1980s,
@ -5513,12 +5572,15 @@ the PC was used like a dumb terminal for connecting to mainframes.
But now files could be transferred and one PC could connect to
another.
The 1980s saw the rise of the Bulletin Board System (BBS). The public
The 1980s saw the rise of the Bulletin Board System (BBS). This was
just a computer with a modem listening for incoming calls. The public
could dial up a BBS with a modem and then downloadable free software,
participate in discussions on various topics, play on-line games, etc.
It was something like visiting a large Internet site. 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
Dialing in to a BBS was something like 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

844
LDP/howto/linuxdoc/Serial-HOWTO.sgml
View File

File diff suppressed because it is too large Load Diff