From owner-svn-doc-head@freebsd.org  Wed Nov 20 06:16:00 2019
Return-Path: <owner-svn-doc-head@freebsd.org>
Delivered-To: svn-doc-head@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id A3DD31A9E54;
 Wed, 20 Nov 2019 06:16:00 +0000 (UTC)
 (envelope-from linimon@FreeBSD.org)
Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org
 [IPv6:2610:1c1:1:606c::19:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (4096 bits) client-digest SHA256)
 (Client CN "mxrelay.nyi.freebsd.org",
 Issuer "Let's Encrypt Authority X3" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 47Hsrc4YQZz4Nqj;
 Wed, 20 Nov 2019 06:16:00 +0000 (UTC)
 (envelope-from linimon@FreeBSD.org)
Received: from repo.freebsd.org (repo.freebsd.org
 [IPv6:2610:1c1:1:6068::e6a:0])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7F4431E84D;
 Wed, 20 Nov 2019 06:16:00 +0000 (UTC)
 (envelope-from linimon@FreeBSD.org)
Received: from repo.freebsd.org ([127.0.1.37])
 by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id xAK6G07t014206;
 Wed, 20 Nov 2019 06:16:00 GMT (envelope-from linimon@FreeBSD.org)
Received: (from linimon@localhost)
 by repo.freebsd.org (8.15.2/8.15.2/Submit) id xAK6G0rP014205;
 Wed, 20 Nov 2019 06:16:00 GMT (envelope-from linimon@FreeBSD.org)
Message-Id: <201911200616.xAK6G0rP014205@repo.freebsd.org>
X-Authentication-Warning: repo.freebsd.org: linimon set sender to
 linimon@FreeBSD.org using -f
From: Mark Linimon <linimon@FreeBSD.org>
Date: Wed, 20 Nov 2019 06:16:00 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
 svn-doc-head@freebsd.org
Subject: svn commit: r53614 - head/en_US.ISO8859-1/books/faq
X-SVN-Group: doc-head
X-SVN-Commit-Author: linimon
X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/faq
X-SVN-Commit-Revision: 53614
X-SVN-Commit-Repository: doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SVN commit messages for the doc tree for head
 <svn-doc-head.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-doc-head>,
 <mailto:svn-doc-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-doc-head/>
List-Post: <mailto:svn-doc-head@freebsd.org>
List-Help: <mailto:svn-doc-head-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-doc-head>,
 <mailto:svn-doc-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 06:16:00 -0000

Author: linimon
Date: Wed Nov 20 06:16:00 2019
New Revision: 53614
URL: https://svnweb.freebsd.org/changeset/doc/53614

Log:
  Complete the operation of removing ppp(8) information by removing the
  previously-commented-out text.

Modified:
  head/en_US.ISO8859-1/books/faq/book.xml

Modified: head/en_US.ISO8859-1/books/faq/book.xml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.xml	Wed Nov 20 06:13:34 2019	(r53613)
+++ head/en_US.ISO8859-1/books/faq/book.xml	Wed Nov 20 06:16:00 2019	(r53614)
@@ -4782,55 +4782,7 @@ Key F15        A        A        Menu Workplace Nop</p
 	</answer>
       </qandaentry>
 
-<!-- XXX MCL ANTIQUATED
       <qandaentry>
-	<question xml:id="win95-connection">
-	  <para>Can I connect my &windows; box to the Internet via
-	    &os;?</para>
-	</question>
-
-	<answer>
-	  <para>Typically, people who ask this question have two PCs
-	    at home, one with &os; and one with some version of
-	    &windows; the idea is to use the &os; box to connect to
-	    the Internet and then be able to access the Internet from
-	    the &windows; box through the &os; box.  This is really
-	    just a special case of the previous question and works
-	    perfectly well.</para>
-
-	  <para>Dialup users must use <option>-nat</option>
-	    and set <literal>gateway_enable</literal> to
-	    <emphasis>YES</emphasis> in
-	    <filename>/etc/rc.conf</filename>.  For more information,
-	    refer to &man.ppp.8; or the <link
-	      xlink:href="&url.books.handbook;/userppp.html">Handbook
-	      entry on user PPP</link>.</para>
-
-	  <para>If the connection to the Internet is over Ethernet,
-	    use &man.natd.8;.  A tutorial can be found in the <link
-	      xlink:href="&url.books.handbook;/firewalls-ipfw.html#network-natd">natd</link>
-	    section of the Handbook.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="slip-ppp-support">
-	  <para>Does &os; support PPP?</para>
-	</question>
-
-	<answer>
-	  <para>Yes.  &man.ppp.8; provides support for both incoming
-	    and outgoing connections.</para>
-
-	  <para>For more information on how to use this, refer to
-	    the <link
-	      xlink:href="&url.books.handbook;/ppp-and-slip.html">Handbook
-	      chapter on PPP</link>.</para>
-	</answer>
-      </qandaentry>
-XXX MCL ANTIQUATED -->
-
-      <qandaentry>
 	<question xml:id="natd">
 	  <para>Does &os; support NAT or Masquerading?</para>
 	</question>
@@ -5396,767 +5348,13 @@ nodevice gre</screen></para>
     </qandaset>
   </chapter>
 
-<!-- XXX MCL ANTIQUATED
-  <chapter xml:id="ppp">
-    <title>PPP</title>
-
-    <qandaset>
-      <qandaentry>
-	<question xml:id="userppp">
-	  <para>I cannot make &man.ppp.8; work.  What am I doing
-	    wrong?</para>
-	</question>
-
-	<answer>
-	  <para>First, read &man.ppp.8; and
-	    the <link
-	      xlink:href="&url.books.handbook;/ppp-and-slip.html#userppp">PPP
-	      section of the Handbook</link>.  To assist in
-	    troubleshooting, enable logging with the
-	    following command:</para>
-
-	  <programlisting>set log Phase Chat Connect Carrier lcp ipcp ccp command</programlisting>
-
-	  <para>This command may be typed at the &man.ppp.8; command
-	    prompt or it may be entered at the start of the
-	    <literal>default</literal> section
-	    in <filename>/etc/ppp/ppp.conf</filename>.  Make sure that
-	    <filename>/etc/syslog.conf</filename> contains the lines
-	    below and the file <filename>/var/log/ppp.log</filename>
-	    exists:</para>
-
-	  <programlisting>!ppp
-*.*        /var/log/ppp.log</programlisting>
-
-	  <para>A lot about what is going can be learned from the log
-	    file.  Do not worry if it does not all make sense as
-	    it may make sense to someone else.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-hangs">
-	  <para>Why does &man.ppp.8; hang when I run it?</para>
-	</question>
-
-	<answer>
-	  <para>This is usually because the hostname will not
-	    resolve.  The best way to fix this is to make sure that
-	    <filename>/etc/hosts</filename> is read first by the
-	    by ensuring that the <literal>hosts</literal> line is
-	    listed first in <filename>/etc/host.conf</filename>.
-	    Then, put an entry in <filename>/etc/hosts</filename> for
-	    the local machine.  If there is no local network, change
-	    the <systemitem>localhost</systemitem> line:</para>
-
-	  <programlisting>127.0.0.1        foo.example.com foo localhost</programlisting>
-
-	  <para>Otherwise, add another entry for the host.
-	    Consult the relevant manual pages for more details.</para>
-
-	  <para>When finished, verify that this command is successful:
-	    <command>ping -c1 `hostname`</command>.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-nodial-auto">
-	  <para>Why will &man.ppp.8; not dial in
-	    <literal>-auto</literal> mode?</para>
-	</question>
-
-	<answer>
-	  <para>First, check that a default route exists.  This
-	    command should display two entries:</para>
-
-	  <programlisting>Destination        Gateway            Flags     Refs     Use     Netif Expire
-default            10.0.0.2           UGSc        0        0      tun0
-10.0.0.2           10.0.0.1           UH          0        0      tun0</programlisting>
-
-	  <para>If
-	    a default route is not listed, make sure that the
-	    <literal>HISADDR</literal> line has been added to
-	    <filename>/etc/ppp/ppp.conf</filename>.</para>
-
-	  <para>Another reason for the default route line being
-	    missing is that a default
-	    route has been added to <filename>/etc/rc.conf</filename>
-	    and this line is missing
-	    from <filename>/etc/ppp/ppp.conf</filename>:</para>
-
-	  <programlisting>delete ALL</programlisting>
-
-	  <para>If this is the case, go back to the <link
-	      xlink:href="&url.books.handbook;/userppp.html#userppp-final">Final
-	      System Configuration</link> section of the
-	    Handbook.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="no-route-to-host">
-	  <para>What does <errorname>No route to host</errorname>
-	    mean?</para>
-	</question>
-
-	<answer>
-	  <para>This error is usually because the following section
-	    is missing in
-	    <filename>/etc/ppp/ppp.linkup</filename>:</para>
-
-	  <programlisting>MYADDR:
-  delete ALL
-  add 0 0 HISADDR</programlisting>
-
-	  <para>This is only necessary for a dynamic IP address or
-	    when the address of the default gateway is unknown.  When
-	    using interactive mode, the following can be typed in
-	    after entering packet mode.  Packet mode
-	    is indicated by the capitalized <acronym>PPP</acronym> in
-	    the prompt:</para>
-
-	  <programlisting>delete ALL
-add 0 0 HISADDR</programlisting>
-
-	  <para>Refer to the <link
-	      xlink:href="&url.books.handbook;/userppp.html#userppp-dynamicip">PPP
-	      and Dynamic IP addresses</link> section of the Handbook
-	    for further details.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="connection-threeminutedrop">
-	  <para>Why does my connection drop after about 3
-	    minutes?</para>
-	</question>
-
-	<answer>
-	  <para>The default PPP timeout is 3 minutes.  This can be
-	    adjusted with the following line:</para>
-
-	  <programlisting>set timeout <replaceable>NNN</replaceable></programlisting>
-
-	  <para>where <replaceable>NNN</replaceable> is the number of
-	    seconds of inactivity before the connection is closed.  If
-	    <replaceable>NNN</replaceable> is zero, the connection is
-	    never closed due to a timeout.  It is possible to put this
-	    command in <filename>ppp.conf</filename>, or to type it at
-	    the prompt in interactive mode.  It is also possible to
-	    adjust it on the fly while the line is active by
-	    connecting to <application>ppp</application>'s server
-	    socket using &man.telnet.1; or &man.pppctl.8;.  Refer to
-	    the &man.ppp.8; man page for further details.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-drop-heavy-load">
-	  <para>Why does my connection drop under heavy load?</para>
-	</question>
-
-	<answer>
-	  <para>If Link Quality Reporting (<acronym>LQR</acronym>) is
-	    configured, it is possible that too many
-	    <acronym>LQR</acronym> packets are lost between the &os;
-	    system and the peer.  &man.ppp.8; deduces that the line
-	    must therefore be bad, and disconnects.
-	    <acronym>LQR</acronym> is disabled by default and can be
-	    enabled with the following line:</para>
-
-	  <programlisting>enable lqr</programlisting>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-drop-random">
-	  <para>Why does my connection drop after a random amount of
-	    time?</para>
-	</question>
-
-	<answer>
-	  <para>Sometimes, on a noisy phone line or even on a line
-	    with call waiting enabled, the modem may hang up because
-	    it incorrectly thinks that it lost carrier.</para>
-
-	  <para>There is a setting on most modems for determining how
-	    tolerant it should be to temporary losses of carrier.
-	    Refer to the modem manual for details.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-hangs-random">
-	  <para>Why does my connection hang after a random amount of
-	    time?</para>
-	</question>
-
-	<answer>
-	  <para>Many people experience hung connections with no
-	    apparent explanation.  The first thing to establish is
-	    which side of the link is hung.</para>
-
-	  <para>When using an external modem, try
-	    using &man.ping.8; to see if the <acronym>TD</acronym>
-	    light is flashing when data is transmitted.  If it flashes
-	    but the <acronym>RD</acronym> light does not, the
-	    problem is with the remote end.  If <acronym>TD</acronym>
-	    does not flash, the problem is local.  With an internal
-	    modem, use the <literal>set
-	      server</literal> command in
-	    <filename>ppp.conf</filename>.  When the hang occurs,
-	    connect to &man.ppp.8; using &man.pppctl.8;.  If the
-	    network connection suddenly revives due to the activity on
-	    the diagnostic socket, or if it will not
-	    connect but the <literal>set socket</literal>
-	    command succeeded at startup time, the problem is local.
-	    If it can connect but things are still hung, enable local
-	    logging with <literal>set log local async</literal>
-	    and use &man.ping.8; from another window or terminal to
-	    make use of the link.  The async logging will show the
-	    data being transmitted and received on the link.  If data
-	    is going out and not coming back, the problem is
-	    remote.</para>
-
-	  <para>Having established whether the problem is local or
-	    remote, there are now two possibilities:</para>
-
-	  <itemizedlist>
-	    <listitem>
-	      <para>If the problem is remote, read on entry <xref
-		  linkend="ppp-remote-not-responding"/>.</para>
-	    </listitem>
-
-	    <listitem>
-	      <para>If the problem is local, read on entry <xref
-		  linkend="ppp-hung"/>.</para>
-	    </listitem>
-	  </itemizedlist>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-remote-not-responding">
-	  <para>The remote end is not responding.  What can I
-	    do?</para>
-	</question>
-
-	<answer>
-	  <para>There is very little that can be done about this.
-	    Many ISPs will refuse to help users not running a
-	    &microsoft; OS.  Add <literal>enable lqr</literal> to
-	    <filename>/etc/ppp/ppp.conf</filename>, allowing
-	    &man.ppp.8; to detect the remote failure and hang up.
-	    This detection is relatively slow and therefore not that
-	    useful.</para>
-
-	  <para>First, try disabling all local compression by adding
-	    the following to the configuration:</para>
-
-	  <programlisting>disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
-deny pred1 deflate deflate24 protocomp acfcomp shortseq vj</programlisting>
-
-	  <para>Then reconnect to ensure that this makes no
-	    difference.  If things improve or if the problem is solved
-	    completely, determine which setting makes the difference
-	    through trial and error.  This is good information for
-	    the ISP, although it may make
-	    it apparent that it is not a &microsoft; system.</para>
-
-	  <para>Before contacting the ISP, enable async logging
-	    locally and wait until the connection hangs again.  This
-	    may use up quite a bit of disk space.  The last data read
-	    from the port may be of interest.  It is usually ASCII
-	    data, and may even describe the problem (<errorname>Memory
-	      fault</errorname>, <errorname>Core
-	      dumped</errorname>).</para>
-
-	  <para>If the ISP is helpful, they should be able to enable
-	    logging on their end, then when the next link drop occurs,
-	    they may be able to tell why their side is having a
-	    problem.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-hung">
-	  <para>&man.ppp.8; has hung.  What can I do?</para>
-	</question>
-
-	<answer>
-	  <para>In this case, rebuild &man.ppp.8; with
-	    debugging information, and then use &man.gdb.1; to grab a
-	    stack trace from the <application>ppp</application>
-	    process that is stuck.  To rebuild the
-	    <application>ppp</application> utility with debugging
-	    information, type:</para>
-
-	  <screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/ppp</userinput>
-&prompt.root; <userinput>env DEBUG_FLAGS='-g' make clean</userinput>
-&prompt.root; <userinput>env DEBUG_FLAGS='-g' make install</userinput></screen>
-
-	  <para>Then, restart <application>ppp</application>
-	    and wait until it hangs again.  When the debug build of
-	    <application>ppp</application> hangs, start
-	    <application>gdb</application> on the stuck process by
-	    typing:</para>
-
-	  <screen>&prompt.root; <userinput>gdb ppp `pgrep ppp`</userinput></screen>
-
-	  <para>At the <application>gdb</application> prompt,
-	    use the <command>bt</command> or <command>where</command>
-	    commands to get a stack trace.  Save the output of the
-	    <application>gdb</application> session, and
-	    <quote>detach</quote> from the running process by typing
-	    <command>quit</command>.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-same-magic">
-	  <para>I keep seeing errors about magic being the same.  What
-	    does it mean?</para>
-	</question>
-
-	<answer>
-	  <para>Occasionally, just after connecting, there may be
-	    messages in the log that say <errorname>Magic is
-	      same</errorname>.  Sometimes, these messages are
-	    harmless, and sometimes one side or the other exits.  Most
-	    PPP implementations cannot survive this problem, and even
-	    if the link seems to come up, there will be repeated
-	    configure requests and configure acknowledgments in the
-	    log file until &man.ppp.8; eventually gives up and closes
-	    the connection.</para>
-
-	  <para>This normally happens on server machines with slow
-	    disks that are spawning a &man.getty.8; on the port, and
-	    executing &man.ppp.8; from a login script or program after
-	    login.  There were reports of it happening consistently
-	    when using slirp.  The reason is that in the time taken
-	    between &man.getty.8; exiting and &man.ppp.8; starting,
-	    the client-side &man.ppp.8; starts sending Line Control
-	    Protocol (LCP) packets.  Because ECHO is still switched on
-	    for the port on the server, the client &man.ppp.8; sees
-	    these packets <quote>reflect</quote> back.</para>
-
-	  <para>One part of the LCP negotiation is to establish a
-	    magic number for each side of the link so that
-	    <quote>reflections</quote> can be detected.  The protocol
-	    says that when the peer tries to negotiate the same magic
-	    number, a NAK should be sent and a new magic number should
-	    be chosen.  During the period that the server port has
-	    ECHO turned on, the client &man.ppp.8; sends LCP packets,
-	    sees the same magic in the reflected packet and NAKs it.
-	    It also sees the NAK reflect (which also means &man.ppp.8;
-	    must change its magic).  This produces a potentially
-	    enormous number of magic number changes, all of which are
-	    happily piling into the server's tty buffer.  As soon as
-	    &man.ppp.8; starts on the server, it is flooded with magic
-	    number changes and almost immediately decides it has tried
-	    enough to negotiate LCP and gives up.  Meanwhile, the
-	    client, who no longer sees the reflections, becomes happy
-	    just in time to see a hangup from the server.</para>
-
-	  <para>This can be avoided by allowing the peer to start
-	    negotiating with the following line in
-	    <filename>ppp.conf</filename>:</para>
-
-	  <programlisting>set openmode passive</programlisting>
-
-	  <para>This tells &man.ppp.8; to wait for the server to
-	    initiate LCP negotiations.  Some servers however may never
-	    initiate negotiations.  In this case, try
-	    something like:</para>
-
-	  <programlisting>set openmode active 3</programlisting>
-
-	  <para>This tells &man.ppp.8; to be passive for 3 seconds,
-	    and then to start sending LCP requests.  If the peer
-	    starts sending requests during this period, &man.ppp.8;
-	    will immediately respond rather than waiting for the full
-	    3 second period.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-lcp-constant">
-	  <para>LCP negotiations continue until the connection is
-	    closed.  What is wrong?</para>
-	</question>
-
-	<answer>
-	  <para>There is currently an implementation mis-feature in
-	    &man.ppp.8; where it does not associate LCP, CCP &amp;
-	    IPCP responses with their original requests.  As a result,
-	    if one PPP implementation is more than 6 seconds slower
-	    than the other side, the other side will send two
-	    additional LCP configuration requests.  This is
-	    fatal.</para>
-
-	  <para>Consider two implementations,
-	    <systemitem>A</systemitem> and <systemitem>B</systemitem>.
-	    <systemitem>A</systemitem> starts sending LCP requests
-	    immediately after connecting and
-	    <systemitem>B</systemitem> takes 7 seconds to start.  When
-	    <systemitem>B</systemitem> starts,
-	    <systemitem>A</systemitem> has sent 3 LCP REQs.  We are
-	    assuming the line has ECHO switched off, otherwise we
-	    would see magic number problems as described in the
-	    previous section.  <systemitem>B</systemitem> sends a REQ,
-	    then an ACK to the first of <systemitem>A</systemitem>'s
-	    REQs.  This results in <systemitem>A</systemitem> entering
-	    the <acronym>OPENED</acronym> state and sending and ACK
-	    (the first) back to <systemitem>B</systemitem>.  In the
-	    meantime, <systemitem>B</systemitem> sends back two more
-	    ACKs in response to the two additional REQs sent by
-	    <systemitem>A</systemitem> before
-	    <systemitem>B</systemitem> started up.
-	    <systemitem>B</systemitem> then receives the first ACK
-	    from <systemitem>A</systemitem> and enters the
-	    <acronym>OPENED</acronym> state.
-	    <systemitem>A</systemitem> receives the second ACK from
-	    <systemitem>B</systemitem> and goes back to the
-	    <acronym>REQ-SENT</acronym> state, sending another (forth)
-	    REQ as per the RFC.  It then receives the third ACK and
-	    enters the <acronym>OPENED</acronym> state.  In the
-	    meantime, <systemitem>B</systemitem> receives the forth
-	    REQ from <systemitem>A</systemitem>, resulting in it
-	    reverting to the <acronym>ACK-SENT</acronym> state and
-	    sending another (second) REQ and (forth) ACK as per the
-	    RFC.  <systemitem>A</systemitem> gets the REQ, goes into
-	    <acronym>REQ-SENT</acronym> and sends another REQ.  It
-	    immediately receives the following ACK and enters
-	    <acronym>OPENED</acronym>.</para>
-
-	  <para>This goes on until one side figures out that they are
-	    getting nowhere and gives up.</para>
-
-	  <para>The best way to avoid this is to configure one side to
-	    be <literal>passive</literal> &mdash; that is, make one
-	    side wait for the other to start negotiating.  This can be
-	    done with the following command:</para>
-
-	  <programlisting>set openmode passive</programlisting>
-
-	  <para>Care should be taken with this option.  This command
-	    can also be used to limit the amount of time that
-	    &man.ppp.8; waits for the peer to begin
-	    negotiations:</para>
-
-	  <programlisting>set stopped <replaceable>N</replaceable></programlisting>
-
-	  <para>Alternatively, the following command (where
-	    <replaceable>N</replaceable> is the number of seconds to
-	    wait before starting negotiations) can be used:</para>
-
-	  <programlisting>set openmode active <replaceable>N</replaceable></programlisting>
-
-	  <para>Check the manual page for details.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-shell-test-lockup">
-	  <para>Why does &man.ppp.8; lock up when I shell out to test
-	    it?</para>
-	</question>
-
-	<answer>
-	  <para>When using <command>shell</command> or
-	    <command>!</command>, &man.ppp.8; executes a shell
-	    or the passed arguments.  The
-	    <application>ppp</application> program will wait for the
-	    command to complete before continuing.  Any attempt to
-	    use the PPP link while running the command will appear as
-	    a frozen link.  This is because &man.ppp.8; is
-	    waiting for the command to complete.</para>
-
-	  <para>To execute commands like this, use
-	    <command>!bg</command> instead.  This will execute the
-	    given command in the background, and &man.ppp.8; can
-	    continue to service the link.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-null-modem">
-	  <para>Why does &man.ppp.8; over a null-modem cable never
-	    exit?</para>
-	</question>
-
-	<answer>
-	  <para>There is no way for &man.ppp.8; to automatically
-	    determine that a direct connection has been dropped.  This
-	    is due to the lines that are used in a null-modem serial
-	    cable.  When using this sort of connection, LQR should
-	    always be enabled with the following line:</para>
-
-	  <programlisting>enable lqr</programlisting>
-
-	  <para>LQR is accepted by default if negotiated by the
-	    peer.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-auto-noreasondial">
-	  <para>Why does &man.ppp.8; dial for no reason in
-	    <option>-auto</option> mode?</para>
-	</question>
-
-	<answer>
-	  <para>If &man.ppp.8; is dialing unexpectedly,
-	    determine the cause, and set up dial filters to
-	    prevent such dialing.</para>
-
-	  <para>To determine the cause, use the following line:</para>
-
-	  <programlisting>set log +tcp/ip</programlisting>
-
-	  <para>This will log all traffic through the connection.  The
-	    next time the line comes up unexpectedly, the
-	    reason will be logged with a convenient timestamp next to
-	    it.</para>
-
-	  <para>Next, disable dialing under these circumstances.
-	    Usually, this sort of problem arises due to DNS lookups.
-	    To prevent DNS lookups from establishing a connection
-	    (this will <emphasis>not</emphasis> prevent &man.ppp.8;
-	    from passing the packets through an established
-	    connection), use the following:</para>
-
-	  <programlisting>set dfilter 1 deny udp src eq 53
-set dfilter 2 deny udp dst eq 53
-set dfilter 3 permit 0/0 0/0</programlisting>
-
-	  <para>This is not always suitable, as it will effectively
-	    break demand-dial capabilities.  Most programs
-	    will need a DNS lookup before doing any other network
-	    related things.</para>
-
-	  <para>In the DNS case, try to determine what is actually
-	    trying to resolve a host name.  A lot of the time,
-	    <application>Sendmail</application> is the culprit.  Make
-	    sure to configure <application>Sendmail</application> not
-	    to do any DNS lookups in its configuration file.  See the
-	    section on <link
-	      xlink:href="&url.books.handbook;/smtp-dialup.html">using
-	      email with a dialup connection</link> in the &os;
-	    Handbook for details.  You may
-	    also want to add the following line to
-	    <filename>.mc</filename>:</para>
-
-	  <programlisting>define(`confDELIVERY_MODE', `d')dnl</programlisting>
-
-	  <para>This will make <application>Sendmail</application>
-	    queue everything until the queue is run, usually,
-	    every 30 minutes, or until a <command>sendmail
-	      -q</command> is done, perhaps from
-	    <filename>/etc/ppp/ppp.linkup</filename>.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ccp-errors">
-	  <para>What do these CCP errors mean?</para>
-	</question>
-
-	<answer>
-	  <para>I keep seeing the following errors in my log
-	    file:</para>
-
-	  <programlisting>CCP: CcpSendConfigReq
-CCP: Received Terminate Ack (1) state = Req-Sent (6)</programlisting>
-
-	  <para>This is because &man.ppp.8; is trying to negotiate
-	    Predictor1 compression, but the peer does not want to
-	    negotiate any compression at all.  The messages are
-	    harmless, but can be silenced by disabling the
-	    compression:</para>
-
-	  <programlisting>disable pred1</programlisting>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-connectionspeed">
-	  <para>Why does &man.ppp.8; not log my connection
-	    speed?</para>
-	</question>
-
-	<answer>
-	  <para>To log all lines of the modem
-	    conversation, enable the
-	    following:</para>
-
-	  <programlisting>set log +connect</programlisting>
-
-	  <para>This will make &man.ppp.8; log everything up until the
-	    last requested <quote>expect</quote> string.</para>
-
-	  <para>To see the connect speed when using
-	    PAP or CHAP,
-	    make sure to configure &man.ppp.8; to
-	    expect the whole CONNECT line, using something
-	    like this:</para>
-
-	  <programlisting>set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \
-  \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"</programlisting>
-
-	  <para>This gets the CONNECT, sends nothing, then expects a
-	    line-feed, forcing &man.ppp.8; to read the whole CONNECT
-	    response.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="ppp-ignores-backslash">
-	  <para>Why does &man.ppp.8; ignore the <literal>\</literal>
-	    character in my chat script?</para>
-	</question>
-
-	<answer>
-	  <para>The <application>ppp</application> utility parses each
-	    line in its configuration files so that it can interpret
-	    strings such as <literal>set phone "123 456 789"</literal>
-	    correctly and realize that the number is actually only
-	    one argument.  To specify a
-	    <literal>&quot;</literal> character, escape it
-	    using a backslash (<literal>\</literal>).</para>
-
-	  <para>When the chat interpreter parses each argument, it
-	    re-interprets the argument to find any special escape
-	    sequences such as <literal>\P</literal> or
-	    <literal>\T</literal>.  As a result
-	    of this double-parsing, remember to use the
-	    correct number of escapes.</para>
-
-	  <para>To actually send a <literal>\</literal>
-	    character, do something
-	    like:</para>
-
-	  <programlisting>set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"</programlisting>
-
-	  <para>It will result in the following sequence:</para>
-
-	  <programlisting>ATZ
-OK
-AT\X
-OK</programlisting>
-
-	  <para>Or:</para>
-
-	  <programlisting>set phone 1234567
-set dial "\"\" ATZ OK ATDT\\T"</programlisting>
-
-	  <para>It will result in the following sequence:</para>
-
-	  <programlisting>ATZ
-OK
-ATDT1234567</programlisting>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="fcs-errors">
-	  <para>What are FCS errors?</para>
-	</question>
-
-	<answer>
-	  <para>FCS stands for Frame Check Sequence.  Each PPP packet
-	    has a checksum attached to ensure that the data being
-	    received is the data being sent.  If the FCS of an
-	    incoming packet is incorrect, the packet is dropped and
-	    the HDLC FCS count is increased.  The HDLC error values
-	    can be displayed using the <literal>show hdlc</literal>
-	    command.</para>
-
-	  <para>If the link is bad or if the serial driver is dropping
-	    packets, it will produce the occasional FCS error.
-	    This is not usually worth worrying about although it does
-	    slow down the compression protocols substantially.</para>
-
-	  <para>If the link freezes as soon as it connects and
-	    produces a large number of FCS errors, make sure the modem
-	    is not using software flow control (XON/XOFF).  If the
-	    link must use software flow control, use
-	    <literal>set accmap 0x000a0000</literal> to
-	    tell &man.ppp.8; to escape the <literal>^Q</literal> and
-	    <literal>^S</literal> characters.</para>
-
-	  <para>Another reason for too many FCS errors may be
-	    that the remote end has stopped talking
-	    <acronym>PPP</acronym>.  In this case, enable
-	    <literal>async</literal> logging to
-	    determine if the incoming data is actually a login or
-	    shell prompt.  If it is a shell prompt at the remote
-	    end, it is possible to terminate &man.ppp.8; without
-	    dropping the line by using <command>close lcp</command>
-	    followed by <command>term</command>) to reconnect to
-	    the shell on the remote machine.</para>
-
-	  <para>If nothing in the log file indicates why the link
-	    was terminated, ask the remote
-	    administrator or ISP why the session was
-	    terminated.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
-	<question xml:id="desperation">
-	  <para>None of this helps &mdash; I am desperate!  What can I
-	    do?</para>
-	</question>
-
-	<answer>
-	  <para>If all else fails, send the details of the error, the
-	    configuration files, how &man.ppp.8; is being started, the
-	    relevant parts of the log file, and the
-	    output of <command>netstat -rn</command>, before and after
-	    connecting, to the &a.questions;.</para>
-	</answer>
-      </qandaentry>
-    </qandaset>
-  </chapter>
-XXX MCL ANTIQUATED -->
-
   <chapter xml:id="serial">
     <title>Serial Communications</title>
 
     <para>This section answers common questions about serial
-      communications with &os;.
-<!-- XXX MCL ANTIQUATED
- PPP is covered in the <link
-	linkend="networking">Networking</link> section.
-XXX MCL ANTIQUATED -->
-      </para>
+      communications with &os;.</para>
 
     <qandaset>
-<!-- XXX MCL ANTIQUATED
-      <qandaentry>
-	<question xml:id="multiport-serial-support">
-	  <para>Which multi-port serial cards are supported by
-	    &os;?</para>
-	</question>
-
-	<answer>
-	  <para>There is a list of these in the <link
-	      xlink:href="&url.books.handbook;/serial.html">Serial
-	      Communications</link> chapter of the Handbook.</para>
-
-	  <para>Most multi-port PCI cards that are based on 16550 or
-	    clones are supported with no extra effort.</para>
-
-	  <para>Some unnamed clone cards have also been known to work,
-	    especially those that claim to be AST compatible.</para>
-
-	  <para>Check &man.uart.4; and &man.sio.4; to get more
-	    information on configuring such cards.</para>
-	</answer>
-      </qandaentry>
-
-XXX MCL ANTIQUATED -->
       <qandaentry>
 	<question xml:id="serial-console-prompt">
 	  <para>How do I get the boot: prompt to show on the serial