Put in a have_route_to cobbled up from stuff sent by Sowmini.
[ppp.git] / FAQ
diff --git a/FAQ b/FAQ
index ef6dd73b29f19d440895b7c29a58053b4f2fda77..12a68f70b707c75f2d193d317439220780f3e499 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -11,22 +11,24 @@ A: Here's an example for dialling out to an ISP via a modem on
 /dev/tty02.  The modem uses hardware (CTS/RTS) flow control, and the
 serial port is run at 38400 baud.  The ISP assigns our IP address.
 
-The ppp connection is initiated by running the following script,
-called (say) dial-isp, and placed somewhere in your path:
+To configure pppd for this connection, create a file under
+/etc/ppp/peers called (say) my-isp containing the following:
 
-#!/bin/sh
-PATH=/usr/sbin:$PATH
-pppd tty02 crtscts 38400 connect 'chat -v -f /etc/ppp/chat-isp' \
-  defaultroute
+tty02 crtscts 38400
+connect 'chat -v -f /etc/ppp/chat/my-isp'
+defaultroute
+
+The ppp connection is then initiated using the following command:
 
-(Don't forget to make the script executable with `chmod +x dial-isp'.)
-On some systems, you will need to change /usr/sbin to /usr/local/bin
-or /usr/local/etc (wherever the pppd and chat binaries have been
-installed.)
+pppd call my-isp
+
+Of course, if the directory containing pppd is not in your path, you
+will need to give the full pathname for pppd, for example,
+/usr/sbin/pppd.
 
 When you run this, pppd will use the chat program to dial the ISP and
 invoke its ppp service.  Chat will read the file specified with -f,
-namely /etc/ppp/chat-isp, to find a list of strings to expect to
+namely /etc/ppp/chat/my-isp, to find a list of strings to expect to
 receive, and strings to send.  This file would contain something like
 this:
 
@@ -83,7 +85,7 @@ Set up the files on "office" as follows:
 /etc/ppp/options contains:
 
 auth           # require the peer to authenticate itself
-usehostname    # only use our hostname for looking up peer's secret
+lock
 # other options can go here if desired
 
 /etc/ppp/chap-secrets contains:
@@ -103,17 +105,15 @@ On "home", set up the files as follows:
 home   office  "beware the frub-jub"   -
 office home    "bird, my son!%&*"      office
 
-Create a script called /etc/ppp/dial-office containing the following,
-and make it executable:
+Create a file called /etc/ppp/peers/office containing the following:
 
-#!/bin/sh
-PATH=/usr/sbin:$PATH
-pppd tty02 crtscts 38400 connect 'chat -v -f /etc/ppp/chat-office' \
-  defaultroute
+tty02 crtscts 38400
+connect 'chat -v -f /etc/ppp/chat/office'
+defaultroute
 
 (You may need to change some of the details here.)
 
-Create the /etc/ppp/chat-office file containing the following:
+Create the /etc/ppp/chat/office file containing the following:
 
 ABORT "NO CARRIER"
 ABORT "NO DIALTONE"
@@ -133,6 +133,9 @@ You will need to change the details.  Note that the "$" in the
 second-last line is expecting the shell prompt after a successful
 login - you may need to change it to "%" or something else.
 
+You then initiate the connection (from home) with the command:
+
+pppd call office
 
 ------------------------------------------------------------------------
 
@@ -230,19 +233,23 @@ Q: I installed pppd successfully, but when I try to run it, I get a
 message saying something like "peer authentication required but no
 authentication files accessible".
 
-A: When pppd is installed on a machine which already has a connection
-to the Internet (or to be more precise, one which has a default route
-in its routing table), it is set up to require all peers to
-authenticate themselves.  The reason for this is that if you don't
-require authentication, you have a security hole, because the peer can
+A: When pppd is used on a machine which already has a connection to
+the Internet (or to be more precise, one which has a default route in
+its routing table), it will require all peers to authenticate
+themselves.  The reason for this is that if you don't require
+authentication, you have a security hole, because the peer can
 basically choose any IP address it wants, even the IP address of some
 trusted host (for example, a host mentioned in some .rhosts file).
 
-On machines which don't have a default route, the default ppp
-installation does not require the peer to authenticate itself.  The
-reason is that such machines would mostly be using pppd to dial out to
-an ISP which will refuse to authenticate itself.  (Yes, it's still a
-security hole, which will hopefully be fixed in the next version.)
+On machines which don't have a default route, pppd does not require
+the peer to authenticate itself.  The reason is that such machines
+would mostly be using pppd to dial out to an ISP which will refuse to
+authenticate itself.  In that case the peer can use any IP address as
+long as the system does not already have a route to that address.
+For example, if you have a local ethernet network, the peer can't use
+an address on that network.  (In fact it could if it authenticated
+itself and it was permitted to use that address by the pap-secrets or
+chap-secrets file.)
 
 There are 3 ways around the problem:
 
@@ -261,12 +268,12 @@ fields).  Of couse, you replace the 4th and following fields in the
 example above with the IP address(es) that the peer may use.  You can
 use either hostnames or numeric IP addresses.
 
-3. You can remove the `auth' option from the /etc/ppp/options file.
+3. You can add the `noauth' option to the /etc/ppp/options file.
 Pppd will then not ask the peer to authenticate itself.  If you do
 this, I *strongly* recommend that you remove the set-uid bit from the
 permissions on the pppd executable, with a command like this:
 
-       chmod u-s /usr/local/etc/pppd
+       chmod u-s /usr/sbin/pppd
 
 Then, an intruder could only use pppd maliciously if they had already
 become root, in which case they couldn't do any more damage using pppd
@@ -370,13 +377,9 @@ the server.  Thus, it may be necessary to use the `remotename' option
 to pppd when using PAP authentication so that it can select the
 appropriate secret from /etc/ppp/pap-secrets.
 
-Microsoft also has a variant of CHAP which they apparently think is
-more secure than standard CHAP because they don't store secrets in
-clear text on the server.  However, a bogus client only needs to know
-the encrypted secret to gain access, so the only extra security is
-that the bogus client would need to run something other than Windows.
-There is a client-side implementation of Microsoft's CHAP in ppp-2.3;
-see README.MSCHAP80.
+Microsoft also has a variant of CHAP which uses a different hashing
+arrangement from normal CHAP.  There is a client-side implementation
+of Microsoft's CHAP in ppp-2.3; see README.MSCHAP80.
 
 
 ------------------------------------------------------------------------
@@ -551,3 +554,34 @@ Then copy the new kernel to /:
        cp vmunix /
 
 and reboot.  Modload should then work.
+
+
+------------------------------------------------------------------------
+
+Q: I'm running Linux (or NetBSD or FreeBSD), and my system comes with
+PPP already.  Should I consider installing this package?  Why?
+
+A: The PPP that is already installed in your system is (or is derived
+from) some version of this PPP package.  You can find out what version
+of this package is already installed with the command "pppd --help".
+If this is older than the latest version, you may wish to install the
+latest version so that you can take advantage of the new features or
+bug fixes.
+
+
+------------------------------------------------------------------------
+
+Q: I'm running pppd in demand mode, and I find that pppd often dials
+out unnecessarily when I try to make a connection within my local
+machine or with a machine on my local LAN.  What can I do about this?
+
+A: Very often the cause of this is that a program is trying to contact
+a nameserver to resolve a hostname, and the nameserver (specified in
+/etc/resolv.conf, usually) is on the far side of the ppp link.  You
+can try executing a command such as `ping myhost' (where myhost is the
+name of the local machine, or some other machine on a local LAN), to
+see whether that starts the ppp link.  If it does, check the setup of
+your /etc/hosts file to make sure you have the local machine and any
+hosts on your local LAN listed, and /etc/resolv.conf and/or
+/etc/nsswitch.conf files to make sure you resolve hostnames from
+/etc/hosts if possible before trying to contact a nameserver.