X-Git-Url: http://git.ozlabs.org/?p=ppp.git;a=blobdiff_plain;f=FAQ;h=12a68f70b707c75f2d193d317439220780f3e499;hp=6996296b4d65be035a4dbc1b1786992b6a039e47;hb=6d89f8d2a2b827a1165e99ea683e6c859e98693e;hpb=98da136ec87f685b7dffb71afa775fa9d85016c9 diff --git a/FAQ b/FAQ index 6996296..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 @@ -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. ------------------------------------------------------------------------ @@ -482,6 +485,20 @@ message (since your pppd doesn't recognize the protocol number either.) +------------------------------------------------------------------------ + +Q: I get a message saying something like "ioctl(TIOCSETD): Operation +not permitted". How do I fix this? + +A: This is because pppd is not running as root. If you have not +installed pppd setuid-root, you will have to be root to run it. If +you have installed pppd setuid-root and you still get this message, it +is probably because your shell is using some other copy of pppd than +the installed one - for example, if you are in the pppd directory +where you've just built pppd and your $PATH has . before /usr/sbin (or +wherever pppd gets installed). + + ------------------------------------------------------------------------ Q: Has your package been ported to HP/UX or IRIX or AIX? @@ -493,3 +510,78 @@ AIX 4.x, but who is no longer able to maintain it. And apparently AIX IRIX includes a good PPP implementation in the standard distribution, as far as I know. + + +------------------------------------------------------------------------ + +Q: Under SunOS 4, when I try to modload the ppp modules, I get the +message "can't open /dev/vd: No such device". + +A: First check in /dev that there is an entry like this: + +crw-r--r-- 1 root 57, 0 Oct 2 1991 vd + +If not, make one (mknod /dev/vd c 57 0). If the problem still exists, +probably your kernel has been configured without the vd driver +included. The vd driver is needed for loadable module support. + +First, identify the config file that was used. When you boot your +machine, or if you run /etc/dmesg, you'll see a line that looks +something like this: + +SunOS Release 4.1.3_U1 (CAP_XBOX) #7: Thu Mar 21 15:31:56 EST 1996 + ^^^^^^^^ + this is the config file name + +The config file will be in the /sys/`arch -k`/conf directory (arch -k +should return sun4m for a SparcStation 10, sun3x for a Sun 3/80, +etc.). Look in there for a line saying "options VDDRV". If that line +isn't present (or is commented out), add it (or uncomment it). + +You then need to rebuild the kernel as described in the SunOS +manuals. Basically you need to run config and make like this: + + /usr/etc/config CAP_XBOX + cd ../CAP_XBOX + make + +(replacing the string CAP_XBOX by the name of the config file for your +kernel, of course). + +Then copy the new kernel to /: + + mv /vmunix /vmunix.working + 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.