/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:
/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:
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"
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
------------------------------------------------------------------------
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:
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
appropriate secret from /etc/ppp/pap-secrets.
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.
+arrangement from normal CHAP. There is a client-side (authenticatee)
+implementation of Microsoft's CHAP in ppp-2.3; see README.MSCHAP80.
+In ppp-2.4.2, server-side (authenticator) support was added as well as
+support for Microsoft CHAP v2; see README.MSCHAP81.
------------------------------------------------------------------------
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.
+
+
+------------------------------------------------------------------------
+
+Q: Since I installed ppp-2.3.6, dialin users to my server have been
+getting this message when they run pppd:
+
+peer authentication required but no suitable secret(s) found for
+authenticating any peer to us (ispserver)
+
+A: In 2.3.6, the default is to let an unauthenticated peer only use IP
+addresses to which the machine doesn't already have a route. So on a
+machine with a default route, everyone has to authenticate. If you
+really don't want that, you can put `noauth' in the /etc/ppp/options
+file. Note that there is then no check on who is using which IP
+address. IMHO, this is undesirably insecure, but I guess it may be
+tolerable as long as you don't use any .rhosts files or anything like
+that. I recommend that you require dialin users to authenticate, even
+if just with PAP using their login password (using the `login' option
+to pppd). If you do use `noauth', you should at least have a pppusers
+group and set the permissions on pppd to allow only user and group to
+execute it.
+
+------------------------------------------------------------------------
+
+Q: When running pppd as a dial-in server, I often get the message
+"LCP: timeout sending Config-Requests" from pppd. It seems to be
+random, but dial-out always works fine. What is wrong?
+
+A: Most modern modems auto-detects the speed of the serial line
+between the modem and the computer. This auto-detection occurs when
+the computer sends characters to the modem, when the modem is in
+command mode. It does not occur when the modem is in data mode.
+Thus, if you send commands to the modem at 2400 bps, and then change
+the serial port speed to 115200 bps, the modem will not detect this
+change until something is transmitted from the computer to the modem.
+When running pppd in dial-in mode (i.e. without a connect script),
+pppd sets the speed of the serial port, but does not transmit
+anything. If the modem was already running at the specified speed,
+everything is fine, but if not, you will just receive garbage from the
+modem. To cure this, use an init script such as the following:
+
+ pppd ttyS0 115200 modem crtscts init "chat '' AT OK"
+
+To reset the modem and enable auto-answer, use:
+
+ pppd ttyS0 115200 modem crtscts init "chat '' ATZ OK ATS0=1 OK"
projects / ppp.git / blobdiff