Say a few words about ppp.

1 files changed, 266 insertions, 27 deletions

diff --git a/FAQ/FAQ.sgml b/FAQ/FAQ.sgml
index 8d2009303f..de347ab5e6 100644
--- a/FAQ/FAQ.sgml
+++ b/FAQ/FAQ.sgml
@@ -1,12 +1,12 @@
 <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
-<!-- $Id: FAQ.sgml,v 1.72 1997-09-10 11:50:51 pds Exp $ -->
+<!-- $Id: FAQ.sgml,v 1.73 1997-09-21 12:35:36 brian Exp $ -->
 
   <article>
 
 <title>Frequently Asked Questions for FreeBSD 2.X
 <author>Maintainer: Peter da Silva <tt><htmlurl url='mailto:peter@taronga.com'
   name='&lt;peter@taronga.com&gt;'></tt>
-<date>$Date: 1997-09-10 11:50:51 $</date>
+<date>$Date: 1997-09-21 12:35:36 $</date>
 
 <abstract>
 This is the FAQ for FreeBSD systems version 2.X  All entries are
@@ -3160,43 +3160,282 @@ vnconfig -ce /dev/vn0c /usr/swap0 swap
 	<heading>Does FreeBSD support SLIP and PPP?</heading>
 
         <p>
-          Yes.  See the man pages for <tt/slattach(8)/ and/or <tt/pppd(8)/
-          if you're using FreeBSD to connect to another site.  If you're
-          using FreeBSD as a server for other machines, look at the man
-          page for <tt/sliplogin(8)/.
+          Yes.  See the man pages for <tt/slattach(8)/, <tt/sliplogin(8)/,
+          <tt/pppd(8)/ and <tt/ppp(8)/.  <tt/pppd/ and <tt/ppp/ provide
+          support for both incoming and outgoing connections.
+          <tt/Sliplogin/ deals exclusively with incoming connections and
+          <tt/slattach/ deals exclusively with outgoing connections.
 
-          You can also have a look at the SLIP/PPP/Use PPP sections of the
-          handbook in <tt>/usr/share/doc/handbook</tt> or use the following
-          links:
+          These programs are described in the following sections of the
+          <url url="../handbook/handbook.html" name="handbook">:
 
-          <url url="../handbook/slips.html"
+          <p><url url="../handbook/slips.html"
             name="Handbook entry on SLIP (server side)">
-          <url url="../handbook/slipc.html"
+          <p><url url="../handbook/slipc.html"
             name="Handbook entry on SLIP (client side)">
-          <url url="../handbook/ppp.html"
+          <p><url url="../handbook/ppp.html"
             name="Handbook entry on PPP (kernel version)">
-          <url url="../handbook/userppp.html"
+          <p><url url="../handbook/userppp.html"
             name="Handbook entry on PPP (user-mode version)">
 
-	  All these of course require that you can create a subnet for
-	  your new network interfaces.
-	  If you can't get the IP address assigned, try the <tt/slirp/
-	  package.
+          <p>
+            If you only have access to the Internet through a "shell
+            account", you may want to have a look at the <tt/slirp/
+            package.  It can provide you with (limited) access to services
+            such as ftp and http direct from your local machine.
 
       <sect1>
-        <heading>I can connect with IJPPP but it doesn't work right!</heading>
+	<heading>Does FreeBSD support NAT or Masquerading</heading>
 
-        <p>
-        A possible cause for this is IJPPPs' use of predictor1
-        compression.  One way of determining if you have this problem
-        is to look at your log and if you have protocol errors then this is
-        most likely it.
-        These can be shut off with:
+          <p>
+            If you have a subnet (one or more local machines), but have
+            been allocated only a single IP number from your Internet
+            provider, you may want to look at the <tt/natd(8)/ program.
+            <tt/Natd/ allows you to connect an entire subnet to the internet
+            using only a single IP number.
+
+          <p>
+            The <tt/ppp(8)/ program has similar functionality built in via
+            the <tt/-alias/ switch.
+
+      <sect1>
+        <heading>I can't make <tt/ppp/ work.  What am I doing wrong ?</heading>
+
+          <p>
+            You should first read the <tt/ppp(8)/ manual page and
+            the <url url="../handbook/userppp.html"
+            name="ppp section of the handbook">.  Enable logging
+            with the command
+<verb>
+  set log Phase Chat Connect Carrier lcp ipcp ccp command
+</verb>
+            This command may be typed at the <tt/ppp/ command prompt or
+            it may be entered in the <tt>/etc/ppp/ppp.conf</tt>
+            configuration file (the start of the <bf>default</bf> section
+            is the best place to put it).  Make sure that
+            <tt>/etc/syslog.conf</tt> contains the lines
+<verb>
+  !ppp
+  *.*              /var/log/ppp.log
+</verb>
+            and that the file <tt>/var/log/ppp.log</tt> exists.  You can
+            now find out a lot about what's going on from the log file.
+            Don't worry if it doesn't all make sense.  If you need to
+            get help from someone, it may make sense to them.
+
+          <sect2>
+            <heading>Ppp won't dial in -auto mode</heading>
+
+            <p>
+              First, check that you've got a default route.  By
+              running <tt/netstat -rn/, you should see two entries
+              like this:
+<verb>
+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
+</verb>
+              This is assuming that you've used the addresses from the
+              handbook, the man page or from the ppp.conf.sample file.
+              If you haven't got a default route, it may be because you're
+              running an old version of <tt/ppp/ that doesn't understand the
+              word <tt/HISADDR/ in the ppp.conf file.  If your version of
+              <tt/ppp/ is from before FreeBSD 2.2.5, change the
+<verb>
+  add 0 0 HISADDR
+</verb>
+              line to one saying
+<verb>
+  add 0 0 10.0.0.2
+</verb>
+              Another reason for the default route line being missing is that
+              you have mistakenly set up a default router in your
+              <tt>/etc/rc.conf</tt> file (this file was called
+              <tt>/etc/sysconfig</tt> prior to release 2.2.2), and you have
+              omitted the line saying
+<verb>
+  delete ALL
+</verb>
+              from <tt>ppp.conf</tt>.  If this is the case, go back to the
+              <url url="../handbook/userppp:final.html"
+              name="Final system configuration"> section of the handbook.
+
+          <sect2>
+            <heading>What does "No route to host" mean</heading>
+
+            <p>
+              This error is usually due to a missing
+<verb>
+MYADDR:
+  delete ALL
+  add 0 0 HISADDR
+</verb>
+              section in your <tt>/etc/ppp/ppp.linkup</tt> file.  This is
+              only necessary if you have a dynamic IP address or don't
+              know the address of your gateway.  If you're using
+              interactive mode, you can type the following after entering
+              <tt/packet mode/ (packet mode is indicated by the capitalized
+              <bf/PPP/ in the prompt):
+<verb>
+  delete ALL
+  add 0 0 HISADDR
+</verb>
+              Refer to the <url url="../handbook/userppp:dynamicIP.html"
+              name="PPP and Dynamic IP addresses"> section of the handbook
+              for further details.
+
+          <sect2>
+            <heading>My connection drops after about 3 minutes</heading>
+
+            <p>
+              The default ppp timeout is 3 minutes.  This can be adjusted
+              with the line
+<verb>
+  set timeout NNN
+</verb>
+              where NNN is the number of seconds of inactivity before the
+              connection is closed.  If NNN is zero, the connection is
+              never closed due to a timeout.
+              It is possible to put this command in the <tt>ppp.conf</tt>
+              file, 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 <tt/ppp/s server socket using
+              <tt/telnet(1)/ or <tt/pppctl(8)/.  Refer to the <tt/ppp(8)/
+              man page for further details.
+
+          <sect2>
+            <heading>My connection drops under heavy load</heading>
+
+            <p>
+              If you have Link Quality Reporting (LQR) configured, it is
+              possible that too many LQR packets are lost between your
+              machine and the peer.  Ppp deduces that the line must therefore
+              be bad, and disconnects.  Prior to FreeBSD version 2.2.5,
+              LQR was enabled by default.  It is now disabled by default.
+              LQR can be disabled with the line
+<verb>
+  disable lqr
+</verb>
+
+          <sect2>
+            <heading>Nothing happens after the Login OK! message</heading>
+
+            <p>
+              Prior to FreeBSD version 2.2.5, once the link was established,
+              <tt/ppp/ would wait for the peer to initiate the Line Control
+              Protocol (LCP).  Many ISPs will not initiate negotiations and
+              expect the client to do so.  To force <tt/ppp/ to initiate
+              the LCP, use the following line:
+<verb>
+  set openmode active
+</verb>
+              <bf/Note/: It does no harm if both sides initiate negotiation,
+              so openmode is now active by default.
+
+          <sect2>
+            <heading>Ppp locks up shortly after connecting</heading>
+
+            <p>
+              Prior to version 2.2.5 of FreeBSD, it was possible that your
+              link was disabled shortly after connection due to <tt/ppp/
+              mis-handling Predictor1 compression negotiation.  This would
+              only happen if both sides tried to negotiate different
+              Compression Control Protocols (CCP).  This problem is now
+              corrected, but if you're still running an old version of
+              <tt/ppp/, the problem can be circumvented with the line
 <verb>
-deny pred1
-disable pred1
+  disable pred1
 </verb>
-        Use these two before you dial out and it should work.
+
+          <sect2>
+            <heading>Ppp locks up when I shell out to test it</heading>
+
+            <p>
+              When you execute the <tt/shell/ or <tt/!/ command, <tt/ppp/
+              executes a shell (or if you've passed any arguements, <tt/ppp/
+              will execute those arguements).  Ppp will wait for the command
+              to complete before continuing.  If you attempt to use the
+              ppp link while running the command, the link will appear to have
+              frozen.  This is because <tt/ppp/ is waiting for the command
+              to complete.
+
+            <p>
+              If you wish to execute commands like this, use the
+              <tt/!bg/ command instead.  This will execute the given command
+              in the background, and ppp can continue to service the link.
+
+          <sect2>
+            <heading>Ppp over a null-modem cable never exits</heading>
+
+            <p>
+              There is no way for <tt/ppp/ 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 line
+<verb>
+  enable lqr
+</verb>
+              LQR is accepted by default if negotiated by the peer.
+
+          <sect2>
+            <heading>Why does ppp dial for no reason in -auto mode</heading>
+
+            <p>
+              If <tt/ppp/ is dialing unexpectedly, you must determine the
+              cause, and set up Dial filters (dfilters) to prevent such
+              dialing.
+
+            <p>
+              To determine the cause, use the following line:
+<verb>
+  set log +tcp/ip
+</verb>
+              This will log all traffic through the connection.  The next
+              time the line comes up unexpectedly, you will see the reason
+              logged with a convenient timestamp next to it.
+
+            <p>
+              You can now disable dialing under these circumstances.  Usually,
+              this sort of problem arrises due to DNS lookups.  To prevent
+              DNS lookups from establishing a connection (this will <bf/not/
+              prevent <tt/ppp/ from passing the packets through an established
+              connection), use the following:
+<verb>
+  set dfilter 1 deny udp src eq 53
+  set dfilter 2 deny udp dst eq 53
+  set dfilter 3 permit 0/0 0/0
+</verb>
+
+          <sect2>
+            <heading>What do these CCP errors mean</heading>
+
+            <p>
+              I keep seeing the following errors in my log file:
+<verb>
+  CCP: CcpSendConfigReq
+  CCP: Received Terminate Ack (1) state = Req-Sent (6)
+</verb>
+              This is because ppp is trying to negotiate Predictor1
+              compression, and the peer does not want to negotiate any
+              compression at all.  The messages are harmless, but if you
+              wish to remove them, you can disable Predictor1 compression
+              locally too:
+<verb>
+  disable pred1
+</verb>
+
+          <sect2>
+            <heading>None of this helps - I'm desperate !</heading>
+
+            <p>
+              If all else fails, send as much information as you can,
+              including your config files, how you're starting <tt/ppp/,
+              the relevent parts of your log file and the output of the
+              <tt/netstat -rn/ command (before and after connecting)  to the
+              <url url="mailto:freebsd-questions@FreeBSD.org"
+              name="freebsd-questions@FreeBSD.org"> mailing list, and someone
+              should point you in the right direction.
 
       <sect1>
         <heading>I can't create a <tt>/dev/ed0</tt> device!</heading>