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.
 
 /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,
 
 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:
 
 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
 /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:
 # 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
 
 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.)
 
 
 (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"
 
 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.
 
 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".
 
 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).
 
 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:
 
 
 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.
 
 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:
 
 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
 
 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.
 
 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.
        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.