svn commit: r53614 - head/en_US.ISO8859-1/books/faq
Mark Linimon <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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
- µsoft; 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 µsoft; 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 &
- 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> — 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>"</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 — 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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"