Date: Wed, 20 Nov 2019 06:16:00 +0000 (UTC) From: Mark Linimon <linimon@FreeBSD.org> 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 Message-ID: <201911200616.xAK6G0rP014205@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201911200616.xAK6G0rP014205>