/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:
/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
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"