update for 2.3.6 release

1 files changed, 38 insertions, 31 deletions

diff --git a/FAQ b/FAQ
index a25f0d5..12a68f7 100644
--- 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:
+
+pppd call my-isp
 
-(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.)
+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