updated

LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml

@@ -1857,7 +1857,7 @@ and their solutions, availability and more. </Para>
 Modem-HOWTO</ULink>,
 <CiteTitle>Modem HOWTO</CiteTitle>
 </Para><Para>
-<CiteTitle>Updated: March 2003</CiteTitle>.
+<CiteTitle>Updated: May 2003</CiteTitle>.
 Help with selecting, connecting, configuring, trouble-shooting, and
 understanding modems for a PC. </Para>
 </ListItem>
@@ -2625,7 +2625,7 @@ Addresses Linux localization issues specific to Serbian users
 Serial-HOWTO</ULink>,
 <CiteTitle>Serial HOWTO</CiteTitle>
 </Para><Para>
-<CiteTitle>Updated: February 2003</CiteTitle>.
+<CiteTitle>Updated: May 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

LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml

@@ -1012,7 +1012,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: March 2003</CiteTitle>.
+<CiteTitle>Updated: May 2003</CiteTitle>.
 Help with selecting, connecting, configuring, trouble-shooting, and
 understanding modems for a PC. </Para>
 </ListItem>
@@ -1157,7 +1157,7 @@ SCSI-Generic-HOWTO</ULink> for more current information.</emphasis> </Para>
 Serial-HOWTO</ULink>,
 <CiteTitle>Serial HOWTO</CiteTitle>
 </Para><Para>
-<CiteTitle>Updated: February 2003</CiteTitle>.
+<CiteTitle>Updated: May 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

LDP/howto/docbook/HOWTO-INDEX/networkingSect.sgml

@@ -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: March 2003</CiteTitle>.
+<CiteTitle>Updated: May 2003</CiteTitle>.
 Help with selecting, connecting, configuring, trouble-shooting, and
 understanding modems for a PC. </Para>
 </ListItem>

LDP/howto/linuxdoc/Modem-HOWTO.sgml

@@ -3,10 +3,11 @@
 <title> Modem-HOWTO
 <author>David S.Lawyer
   <tt><url url="mailto:dave@lafn.org"></tt>
-<date> v0.26, March 2003 
+<date> v0.27, May 2003 
 
 <!--
 Change log:  + => added more info  ++ => added new topic
+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
@@ -180,7 +181,7 @@ send me any other info that you think belongs in this document.
 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
+only want to quickly compare the date of this the version v0.27, May 2003  with
 the date of the latest version go to: <url
 url="http://www.tldp.org/HOWTO/Modem-HOWTO.html">
 
@@ -188,15 +189,17 @@ url="http://www.tldp.org/HOWTO/Modem-HOWTO.html">
 <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">.
-
+<itemize>
-v0.26 March 2003: USB clarity improved, v.92 modem "on hold" supported?,
+<item>v0.27 May 2003: "Flow control" improved
-3Com AT codes
+<item>v0.26 March 2003: USB clarity improved, v.92 modem "on hold" supported?,
-v0.25 September 2002: Must restart minicom after configuring it unless
+ 3Com AT codes
-you used the -s option.  HCF is not an all-software modem as was
+<item>v0.25 September 2002: Must restart minicom after configuring it unless
-incorrectly claimed.  Better clarity for "Quick Install" and 56k
+ you used the -s option.  HCF is not an all-software modem as was
-modems.  Does my PC have a modem?<newline>
+ incorrectly claimed.  Better clarity for "Quick Install" and 56k
-v0.24 June 2002: new callback link, "You are already online" error, 
+ modems.  Does my PC have a modem?<newline>
+<item>v0.24 June 2002: new callback link, "You are already online" error, 
  fixed several typos reported by Francesco Ronconi<newline>
+</itemize>
 
 <sect1> What is a Modem ? <label id="what_is_modem">
 <p> A modem is a device that lets one send digital signals over an
@@ -911,7 +914,9 @@ 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.
+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
 -->
 <!-- ifdef MODEM_ -->
 <p> You don't have to understand the basics to use and install a
@@ -1105,21 +1110,21 @@ 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
+For an external modem, there may be no way (such as flow control) to
-the flow rapidly enough to prevent this.  For an internal modem the
+stop the flow rapidly enough to prevent such an overrun.  For an
-16-byte FIFO buffer is on the same card and a good modem will not
+internal modem, the 16-byte FIFO buffer is on the same card and a good
-write to it if it's full.  Thus a good internal modem will not overrun
+modem will not write to it if it's full.  Thus a good internal modem
-the 16-byte buffers but it may need to use <ref id="M-M_flow_c"
+will not overrun the 16-byte buffers but it may need to use <ref
-name="Modem-to-Modem Flow Control"> to prevent the modem itself from
+id="M-M_flow_c" name="Modem-to-Modem Flow Control"> to prevent the
-being overrun.  This is one advantage of an internal modem over an
+modem itself from being overrun.  This is one advantage of an internal
-external.  <!-- ifdef MODEM end -->
+modem 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 buffer out the external cable.
+of its bytes from its small transmit FIFO buffer out the external
-It then has space for 16 more outgoing bytes.  The interrupt is to
+cable.  It then has space for 16 more outgoing bytes.  The interrupt
-notify the CPU of that fact so that it may put more bytes in the small
+is to notify the CPU of that fact so that it may put more bytes in the
-transmit buffer to be transmitted.  Also, when a modem control line
+small transmit buffer to be transmitted.  Also, when a modem control
-changes state, an interrupt is issued.
+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
@@ -1257,7 +1262,7 @@ 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 the buffer, the level of bytes
+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
@@ -1266,77 +1271,79 @@ 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 would be true when the modem is sending a file
+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 and
+3.43 (115.2/33.6).   In this case the modem is able to compress the
-the 115.2 bps PC-to-modem flow and send the same data (in compressed
+115.2 bps PC-to-modem flow and send the same data (in compressed form)
-form) out the phone line at 33.6bps.  There's no need for flow control
+out the phone line at 33.6bps.  There's no need for flow control here
-here so long as the compression ratio remains higher that 3.43.  But
+so long as the compression ratio remains higher that 3.43.  But the
-the compression ratio varies from second to second and is likely to
+compression ratio varies from second to second and if it should drop
-drops below 3.43.  Thus, some of the time flow control is needed to
+below 3.43, flow control will be needed 
-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
+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
+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 involve 3 buffers: 1. in the modem
+computer.  Each direction of flow involves 3 buffers: 1. in the modem
-2. in the UART chip (called FIFOs) 3. in main memory managed by the
+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 in this way
+Under Linux, the small UART FIFO buffers are not protected by flow
-but rely instead on a fast response to the interrupts they issue.
+control but instead rely on a fast response to the interrupts they
-Some UART chips can be set to do hardware flow control to protect
+issue.  Some UART chips can be set to do hardware flow control to
-their FIFOs but Linux (as of early 2003) doesn't seem to support it.
+protect their FIFOs but Linux (as of early 2003) doesn't seem to
-FIFO stand for "First In, First Out" which is the way it handles bytes
+support it.  FIFO stand for "First In, First Out" which is the way it
-in a queue.  All the 3 buffers use the FIFO rule but only one of them
+handles bytes in a queue.  All the 3 buffers use the FIFO rule but
-is named "FIFO".   This is the essence of flow control but there
+only the one in the UART is named "FIFO".   This is the essence of flow
-are still some more details.
+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 complex example
+control in the direction from the modem to a PC.  For a complex
-of a case where it's needed see "Complex Flow Control Example" in the
+example of a case where it's needed see "Complex Flow Control Example"
-Serial-HOWTO.  To slow down this incoming flow, your modem must tell
+in the Serial-HOWTO.  To slow down this incoming flow, your modem must
-the other modem to stop sending.  See <ref id="M-M_flow_c"
+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
+<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").
+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.  
+to receive the signal.
 
-For the case of a modem this "other" pin will be the modem's RTS pin
+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
+But for a printer, another PC, or a non-modem device, it's usually a
-a CTS pin and requires "crossover" or "null modem" cable so as to
+CTS pin so a "crossover" or "null modem" cable is required.  This
-connect the CTS pin at one end with the RTS pin at the other end.  For
+cable connects the CTS pin at one end with the RTS pin at the other
-a modem, a straight-thru cable is used.  For the opposite direction of
+end (two wires since each end of the cable has a CTS pin).  For a
-flow a similar scheme is used.  For a modem, the CTS pin is used to
+modem, a straight-thru cable is used.
-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.
+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 wires to send
 the start and stop signals.  It uses the ASCII control characters DC1
@@ -1354,7 +1361,7 @@ 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
+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.
@@ -1370,12 +1377,10 @@ 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.  Practically speaking, it only exists when you
+between two modems.  It works as long as error correction is enabled.
-have error correction enabled.  Actually, even without error
+Actually, even without error correction it's possible to enable
-correction it's possible to enable software flow control between
+software flow control between modems but it may interfere with sending
-modems but it may interfere with sending binary data so it's not often
+binary data so it's not often used.  <!-- ifdef MODEM end -->
-used.
-<!-- ifdef MODEM end -->
 
 <sect1> Data Flow Path; Buffers
 <p>It's been mention that there are 3 buffers for each direction of
@@ -1384,10 +1389,10 @@ 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
+other member of the pair consists of a receive buffer for the
-the opposite direction of byte-flow.  Here's an example diagram for
+opposite direction of byte-flow.  Here's an example diagram for the
-the case of browsing the Internet with a browser.  Transmit data flow
+case of browsing the Internet with a browser.  Transmit data flow is
-is left to right while receive flow is right to left.  There is a
+left to right while receive flow is right to left.  There is a
 separate buffer for each direction of flow.
 
 <verb>
@@ -1420,11 +1425,13 @@ 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
+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.
+transmit buffer, it could possibly perform other tasks.  Third, the
+serial driver (located between the memory buffer and the FIFO) has
+it's own buffer (in main memory) used to process characters.
 
 <!-- ifdef MODEM_ -->
 <sect1> Modem Commands
@@ -2633,7 +2640,9 @@ Nov. 2002 Debian's /var/lib/serial.conf
 are some minor differences, depending on which HOWTO it appears in.
 
 <sect2> Introduction
-<p> If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
+<p> The setserial program doesn't seem to work with serial ports used
+with linmodems such as ttySHCF0.
+If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
 read <ref id="laptops_" name="Laptops: PCMCIA">.  <tt/setserial/ is a
 program which allows you to tell the device driver software the I/O
 address of the serial port, which interrupt (IRQ) is set in the port's
@@ -3311,7 +3320,7 @@ 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/ has
-support for fax and voice mail but <tt/Uugetty/ doesn't.  <tt/mgetty/
+support for fax and voice mail but <tt/uugetty/ doesn't.  <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
@@ -3327,10 +3336,10 @@ 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> Getty "exits" after login (and can respawn)
+<sect2> How getty respawns
-<!-- getty_seq.H begin (in MM, TT)
+<!-- getty_seq.D begin (in MM, TT)
 This is the sequence of events that happens after getty starts up.
-<sect2> Getty "exits" after login (and can respawn).
+<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
@@ -3346,7 +3355,7 @@ 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
+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
@@ -3374,14 +3383,14 @@ 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.  In
 addition to allowing dialup logins, <tt/mgetty/ also provides FAX
-support and auto PPP detection.  It permits dialing out when mgetty is
+support, auto PPP detection, and caller-id support.  It permits
-waiting for an incoming phone call.  There is a supplemental program
+dialing out when mgetty is waiting for an incoming phone call.  There
-called <tt/vgetty/ which handles voicemail for some modems.
+is a supplemental program called <tt/vgetty/ which handles voicemail
-<tt/mgetty/ documentation is fair (except for voice mail), and is not
+for some modems.  <tt/mgetty/ documentation is fair (except for voice
-supplemented in this HOWTO.  To automatically start PPP one must edit
+mail), and is not supplemented in this HOWTO.  To automatically start
-/etc/mgetty/login.conf to use "AutoPPP" (has example).  You can find
+PPP one must edit /etc/mgetty/login.conf to use "AutoPPP" (has
-the latest information on <tt/mgetty/ at <htmlurl
+example).  You can find the latest information on <tt/mgetty/ at
-url="http://www.leo.org/&tilde;doering/mgetty/"
+<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/">
 
@@ -3629,7 +3638,7 @@ url="http://www.stokely.com/unix.serial.port.resources/callback.html">
 <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 disk.  When a person phones you, they hear a
+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
@@ -3643,29 +3652,23 @@ The other, more advanced, but currently poorly documented, is
 widely distributed <tt/mgetty/  program.  It supports ZyXEL-like voice
 modem commands.  In the Debian distribution, you must get the
 mgetty-voice package in addition to the mgetty package and mgetty-doc
-package.  Obsolete documentation has been removed from mgetty but
+package.
-replacement documentation is lacking (except if you use the -h (help)
-option when running certain programs, etc.).  But one sees postings
-about using it on the mgetty newsgroup.  See <ref id="mgetty_"
-name="About mgetty">.  It seems that <tt/vgetty/ is currently not very
-stable but it's successfully being used and development of it
-continues.  If this is the latest version of this HOWTO can someone
-who is familiar with vgetty please let me know its current status.
 
 <sect1> Simple Manual Dial-In <label id="manual_dialin">
-<p> This is really doing it manually!  There's a way to answer a call
+<p> This is really doing it manually!  It doesn't even permit the
-without bothering to edit any configuration files for dial-in or
+caller to login but the caller may "chat" with you, etc.  It's a way
-enabling getty but the caller can't login.  To do this you run a
+to answer a call without bothering to edit any configuration files for
-terminal program such as minicom.  Make sure it's connected to your
+dial-in or enabling getty.  To do it you run a terminal program such
-modem by typing "AT &lt;enter&gt;" and expect "OK".  Then wait for the
+as minicom.  Make sure it's connected to your modem by typing "AT
-call.  Then you really answer the call manually by typing "ATA" when
+&lt;enter&gt;" and expect "OK".  Then wait for the call.  Then you
-the phone is ringing.  This doesn't run getty and the caller can't
+really answer the call manually by typing "ATA" when the phone is
-login.  But if the caller is calling in with a terminal program they
+ringing.  This doesn't run getty and the caller can't login.  But if
-may type a message to your screen (and conversely).  You both may send
+the caller is calling in with a terminal program they may type a
-files back and forth by using the commands built into the terminal
+message to your screen (and conversely).  You both may send files back
-programs (such as minicoms).  Another way to answer such a call would be
+and forth by using the commands built into the terminal programs (such
-to type say "ATS0=3" just before the call comes in to enable the modem
+as minicom).  Another way to answer such a call would be to type say
-to auto-answer on the third ring.
+"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
@@ -3680,15 +3683,15 @@ 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 is one that results in GUI graphical interface to the Linux
+dial-in described above, is one that results in GUI graphical
-PC.  This generally requires that a network running TCP/IP protocol exist
+interface to the Linux PC.  This generally requires that a network
-between the two computers.  One way to get such a "network" is to
+running TCP/IP protocol exist between the two computers.  One way to
-dial-out to a PC set for dial-in and then run PPP on the phone line.
+get such a "network" is to dial-out to a PC set for dial-in and then
-PPP will use TCP/IP protocol encapsulated inside the PPP packets.
+run PPP on the phone line.  PPP will use TCP/IP protocol encapsulated
-Both sides must run PPP and mgetty can be configured to start PPP as
+inside the PPP packets.  Both sides must run PPP and mgetty can be
-soon as the caller does.  The caller may use a PPP-dialer program just
+configured to start PPP as soon as the caller does.  The caller may
-like they were dialing an ISP.  Programs such as wvdial, eznet, or
+use a PPP-dialer program just like they were dialing an ISP.  Programs
-chat scripts should do it.
+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

LDP/howto/linuxdoc/Serial-HOWTO.sgml

@@ -4,9 +4,11 @@
 <author>David S.Lawyer
   <tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
   original by Greg Hankins
-<date> v2.17 February 2003 
+<date> v2.18, May 2003 
 
 <!--  Change log:
+v2.18 May 2003: EIA-485 features not supported by Linux, Flow control
+"typos" fixed
 v2.17 Feb. 2003 url signum->cendio, Mac port names, clarity when
 stopping data flow when printing, ide2 address conflict
 v2.16 March 2002 fixed a few broken links.
@@ -46,41 +48,42 @@ v1.0: 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
 v1.0: June 1993: was called Serial FAQ, by Greg Hankins
 -->
 <abstract>
-  This document describes serial port features other than those which
+  This document describes the UART serial port features other than
-  should be covered by Modem-HOWTO, PPP-HOWTO,
+  those which should be covered by Modem-HOWTO, PPP-HOWTO,
-  Serial-Programming-HOWTO, or Text-Terminal-HOWTO.  It does not cover
+  Serial-Programming-HOWTO, or Text-Terminal-HOWTO.  It lists info on
-  the Universal Serial Bus (see the kernel documentation for USB).
+  multiport serial cards.  It contains technical info about the serial
-  It lists info on multiport serial cards.  It contains technical info
+  port itself in more detail than found in the above HOWTOs and should
-  about the serial port itself in more detail than found in the above
+  be best for troubleshooting when the problem is the serial port
-  HOWTOs and should be best for troubleshooting when the problem is
+  itself.  If you are dealing with a Modem, PPP (used for Internet
-  the serial port itself.  If you are dealing with a Modem, PPP (used
+  access on a phone line), or a Text-Terminal, those HOWTOs should be
-  for Internet access on a phone line), or a Text-Terminal, those
+  consulted first.  </abstract>
-  HOWTOs should be consulted first.  </abstract>
 
 <toc>
 <sect>Introduction
 
 <p> This HOWTO covers basic info on the Serial Port and multiport
-serial cards.  Information specific to modems and text-terminals has
+serial cards.  It's the original serial port which uses a UART chip
-been moved to Modem-HOWTO and Text-Terminal-HOWTO.  Info on getty (the
+and is sometimes called a "UART serial port" to differentiate it from
-program that runs the login process or the like) has been also moved
+the newer Universal Serial Bus, Information specific to modems and
-to these HOWTOs since mgetty and uugetty are best for modems while
+text-terminals is found in Modem-HOWTO and Text-Terminal-HOWTO.
-agetty is best for text-terminals.  If you are dealing with a modem,
+Info on getty (the program that runs the login process or the like)
-text terminal, or printer, then you may not need to consult this
+has been also moved to these HOWTOs since mgetty and uugetty are best
-HOWTO.  But if you are using the serial port for some other device,
+for modems while agetty is best for text-terminals.  If you are
-using a multiport serial card, trouble-shooting the serial port
+dealing with a modem, text terminal, or printer, then you may not need
-itself, or want to understand more technical details of the serial
+to consult this HOWTO.  But if you are using the serial port for some
-port, then you may want to use this HOWTO as well as some of the other
+other device, using a multiport serial card, trouble-shooting the
-HOWTOs.  (See <ref id="related_howtos" name="Related HOWTO's">)  This
+serial port itself, or want to understand more technical details of
-HOWTO lists info on various multiport serial cards since they may be
+the serial port, then you may want to use this HOWTO as well as some
-used for either modems or text-terminals.  This HOWTO addresses Linux
+of the other HOWTOs.  (See <ref id="related_howtos" name="Related
-running on PCs (ISA or PCI buses), although it might be valid for
+HOWTO's">)  This HOWTO lists info on various multiport serial cards
-other architectures.
+since they may be used for either modems or text-terminals.  This
+HOWTO addresses Linux running on PCs (ISA or PCI buses), although it
+might be valid for other architectures.
 
 <sect1> Copyright, Disclaimer, & Credits
 <sect2>Copyright
 <p>
-Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2001 by David S.
+Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2003 by David S.
 Lawyer <url url="mailto:dave@lafn.org">
 <!-- license.D begin -->
 
@@ -134,7 +137,7 @@ sites see: <url url="http://www.tldp.org/mirrors.html">.
 Various formats are available.  If you only want to quickly check the
 date of the latest version look at <url
 url="http://www.tldp.org/HOWTO/Serial-HOWTO.html"> and compare
-it to this version: v2.17 February 2003 .
+it to this version: v2.18 May 2003 .
 
 <sect1>New in Recent Versions
 <p> For a full revision history going back to the time I started
@@ -142,10 +145,13 @@ maintaining this HOWTO, see the source file (in linuxdoc format) at
 <url
 url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz">.
 
-v2.18 January 2003: url signum->cendio,
+<itemize>
-v2.17 June 2002: Mac port names, clarity when stopping data flow when 
+<item>v2.18 May 2003: EIA-485 features not supported by Linux, Flow control
-printing, ide2 address conflict<newline>
+"typos" fixed
+<item>v2.17 Feb 2003: url signum->cendio, Mac port names, clarity when
+stopping data flow when printing, ide2 address conflict<newline>
 v2.16 March 2002 fixed a few broken links<newline>
+</itemize>
 
 <sect1> Related HOWTO's re the Serial Port <label id="related_howtos">
 <p> Modems, Text-Terminals, some printers, and other peripherals often
@@ -159,9 +165,9 @@ explained above.
 <item><tt>LPRng-HOWTO</tt> (not a LDP HOWTO, may come with software)
  has info for serial printing for "Next Generation" lpr
 <item><tt>Serial-Programming-HOWTO</tt> helps you write
- C programs (or parts of them) that read and write to the serial port
+ C programs that read and write to the serial port
- and/or check/set its state.  A new version has been written by Vern
+ and/or check/set its state.  A version written by Vern
- Hoxie but not submitted.  A copy is at <ref id="vern_" name="Internet">.
+ Hoxie but not submitted is at <ref id="vern_" name="Internet">.
 <item><tt>Text-Terminal-HOWTO</tt> is about how they work, how to install
  configure, and repair them.  It includes a section on "Make a
  Terminal the Console" which is useful for using a remote terminal to
@@ -361,7 +367,9 @@ 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.
+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
 -->
 
 
@@ -523,15 +531,15 @@ 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.
 
-There is no <ref id="flow_control" name="Flow Control"> to prevent
+There is no
-this.
+<ref id="flow_control" name="Flow Control"> to prevent this.
 
 Interrupts are also issued when the serial port has just sent out all
-of its bytes from its small transmit buffer out the external cable.
+of its bytes from its small transmit FIFO buffer out the external
-It then has space for 16 more outgoing bytes.  The interrupt is to
+cable.  It then has space for 16 more outgoing bytes.  The interrupt
-notify the CPU of that fact so that it may put more bytes in the small
+is to notify the CPU of that fact so that it may put more bytes in the
-transmit buffer to be transmitted.  Also, when a modem control line
+small transmit buffer to be transmitted.  Also, when a modem control
-changes state, an interrupt is issued.
+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
@@ -596,7 +604,7 @@ 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 the buffer, the level of bytes
+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
@@ -605,78 +613,79 @@ 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 would be true when the modem is sending a file
+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 and
+3.43 (115.2/33.6).   In this case the modem is able to compress the
-the 115.2 bps PC-to-modem flow and send the same data (in compressed
+115.2 bps PC-to-modem flow and send the same data (in compressed form)
-form) out the phone line at 33.6bps.  There's no need for flow control
+out the phone line at 33.6bps.  There's no need for flow control here
-here so long as the compression ratio remains higher that 3.43.  But
+so long as the compression ratio remains higher that 3.43.  But the
-the compression ratio varies from second to second and is likely to
+compression ratio varies from second to second and if it should drop
-drops below 3.43.  Thus, some of the time flow control is needed to
+below 3.43, flow control will be needed 
-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
+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
+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 involve 3 buffers: 1. in the modem
+computer.  Each direction of flow involves 3 buffers: 1. in the modem
-2. in the UART chip (called FIFOs) 3. in main memory managed by the
+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 in this way
+Under Linux, the small UART FIFO buffers are not protected by flow
-but rely instead on a fast response to the interrupts they issue.
+control but instead rely on a fast response to the interrupts they
-Some UART chips can be set to do hardware flow control to protect
+issue.  Some UART chips can be set to do hardware flow control to
-their FIFOs but Linux (as of early 2003) doesn't seem to support it.
+protect their FIFOs but Linux (as of early 2003) doesn't seem to
-FIFO stand for "First In, First Out" which is the way it handles bytes
+support it.  FIFO stand for "First In, First Out" which is the way it
-in a queue.  All the 3 buffers use the FIFO rule but only one of them
+handles bytes in a queue.  All the 3 buffers use the FIFO rule but
-is named "FIFO".   This is the essence of flow control but there
+only the one in the UART is named "FIFO".   This is the essence of flow
-are still some more details.
+control but there are still some more details.
 
 
 
 <!-- ifdef SERIAL_ -->
 <sect2> Symptoms of No Flow Control
 <p> Understanding flow-control theory can be of practical use.  The
-symptom of no flow control is chunks of data missing from files sent
+symptom of no flow control is that chunks of data missing from files
-without the benefit of flow control.  This is because when overflow
+sent without the benefit of flow control.  When overflow happens,
-happens, it's usually more than just a few bytes that overflow and are
+often hundreds or even thousands of bytes get lost, and all in
-lost.  Often hundreds or even thousands of bytes get lost, and all in
 contiguous chunks.
 <!-- ifdef SERIAL_ end -->
 
 <sect2> Hardware vs. Software Flow Control
-<p> If feasible it's best to use "hardware" flow control that uses two
+<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").
+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
+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
+But for a printer, another PC, or a non-modem device, it's usually a
-a CTS pin and requires "crossover" or "null modem" cable so as to
+CTS pin so a "crossover" or "null modem" cable is required.  This
-connect the CTS pin at one end with the RTS pin at the other end.  For
+cable connects the CTS pin at one end with the RTS pin at the other
-a modem, a straight-thru cable is used.  For the opposite direction of
+end (two wires since each end of the cable has a CTS pin).  For a
-flow a similar scheme is used.  For a modem, the CTS pin is used to
+modem, a straight-thru cable is used.
-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.
+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 wires to send
 the start and stop signals.  It uses the ASCII control characters DC1
@@ -696,10 +705,10 @@ 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
+other member of the pair consists of a receive buffer for the
-the opposite direction of byte-flow.  Here's an example diagram for
+opposite direction of byte-flow.  Here's an example diagram for the
-the case of browsing the Internet with a browser.  Transmit data flow
+case of browsing the Internet with a browser.  Transmit data flow is
-is left to right while receive flow is right to left.  There is a
+left to right while receive flow is right to left.  There is a
 separate buffer for each direction of flow.
 
 <verb>
@@ -732,11 +741,13 @@ 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
+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.
+transmit buffer, it could possibly perform other tasks.  Third, the
+serial driver (located between the memory buffer and the FIFO) has
+it's own buffer (in main memory) used to process characters.
 
 
 
@@ -2257,7 +2268,8 @@ Nov. 2002 Debian's /var/lib/serial.conf
 are some minor differences, depending on which HOWTO it appears in.
 
 <sect2> Introduction
-<p> If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
+<p> 
+If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
 read <ref id="laptops_" name="Laptops: PCMCIA">.  <tt/setserial/ is a
 program which allows you to tell the device driver software the I/O
 address of the serial port, which interrupt (IRQ) is set in the port's
@@ -3092,6 +3104,7 @@ available via FTP, if they didn't come with your distribution.
 <item><tt>gkermit</tt> Tiny GPLed kermit run only from the command line.
  Can't connect to another computer
 <item><tt/minicom/ - telix-like communications program
+<item><tt/pppd/ - establishes a ppp connection on the serial line
 <item><tt/seyon/ - X based communication program
 <item><tt/xc/ - xcomm communication package
 
@@ -3112,9 +3125,10 @@ available via FTP, if they didn't come with your distribution.
  mailbox functions.
 
 
-<item>SLIP and PPP software can be found at
+<item>SLIP and PPP software (if not in your Linux distribution) can be
- <tt> <htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/network/serial"
+found at <tt> <htmlurl
- name="ftp://metalab.unc.edu/pub/Linux/system/network/serial"></tt>.
+url="ftp://metalab.unc.edu/pub/Linux/system/network/serial"
+name="ftp://metalab.unc.edu/pub/Linux/system/network/serial"></tt>.
 </itemize>
 
 <sect1>kermit and zmodem
@@ -4300,17 +4314,28 @@ computers for Linux.
 <p> This is like EIA-422 (balanced = differential).  It is
 half-duplex.  It's not just point-to-point but is like ethernet or the
 USB since all devices (nodes) on it share the same "bus".  It may be
-used for a multidrop LAN (up to 32 nodes or more).  Since many nodes
+used for a multidrop LAN (up to 32 nodes or more).  Unfortunately,
-share the same twisted pair, there's a need to use the electrical
+Linux currently doesn't support this and you can only use it under
-tri-state mode.  Besides the 0 and 1 binary states there is also an
+Linux only for point-to-point where it behaves like EIA-232.  So read
-open circuit state to permit other nodes to use the twisted pair line.
+further only if you are curious about how its features would work if
-Instead of a transmitter keeping a 1-state voltage on the line during
+only Linux supported them. 
-line idle, the line is open circuited and all nodes just listen
+
-(receive mode).
+Since many nodes share the same twisted pair, there's a need to use
+the electrical tri-state mode.  Thus, besides the 0 and 1 binary
+states, there is also an open circuit state to permit other nodes to
+use the twisted pair line.  Instead of a transmitter keeping a 1-state
+voltage on the line during line idle, the line is open circuited and
+all nodes just listen (receive mode).
 
 The most common architecture is master/slave.  The master polls the
 slaves to see if they have anything to send.  A slave can only
-transmit just after it's been polled.
+transmit just after it's been polled.  But EIA-485 is just an
+electrical specification and doesn't specify any protocol for the
+master/slave interaction.  In fact, it doesn't even specify that there
+must be a master and slaves.  So various protocols have been used.
+Based on a discussion of 485 on the linux-serial mailing list in March
+2003, it seems likely that none of these master/slave protocols are
+currently supported by Linux.
 
 There is an alternative implementation where two pair of wires are used
 for sending data.  One pair is only for the Master to send to the Slaves.