1 This is a list of Frequently Asked Questions about using ppp-2.x and
5 ------------------------------------------------------------------------
7 Q: Can you give me an example of how I might set up my machine to dial
10 A: Here's an example for dialling out to an ISP via a modem on
11 /dev/tty02. The modem uses hardware (CTS/RTS) flow control, and the
12 serial port is run at 38400 baud. The ISP assigns our IP address.
14 The ppp connection is initiated by running the following script,
15 called (say) dial-isp, and placed somewhere in your path:
19 pppd tty02 crtscts 38400 connect 'chat -v -f /etc/ppp/chat-isp' \
22 (Don't forget to make the script executable with `chmod +x dial-isp'.)
23 On some systems, you will need to change /usr/sbin to /usr/local/bin
24 or /usr/local/etc (wherever the pppd and chat binaries have been
27 When you run this, pppd will use the chat program to dial the ISP and
28 invoke its ppp service. Chat will read the file specified with -f,
29 namely /etc/ppp/chat-isp, to find a list of strings to expect to
30 receive, and strings to send. This file would contain something like
38 ABORT "Username/Password Incorrect"
45 "Switching to PPP-ppp-Switching to PPP"
47 You will need to change the details here. The first string on each
48 line is a string to expect to receive; the second is the string to
49 send. You can add or delete lines according to the dialog required to
50 access your ISP's system. This example is for a modem with a standard
51 AT command set, dialling out to an Annex terminal server. The \q
52 toggles "quiet" mode; when quiet mode is on, the strings to be sent
53 are replaced by ?????? in the log. You may need to go through the
54 dialog manually using kermit or tip first to determine what should go
57 To terminate the link, run the following script, called (say)
63 if [ -f $piddir/$unit.pid ]; then
64 kill -1 `cat $piddir/$unit.pid`
67 On some systems (SunOS, Solaris, Ultrix), you will need to change
71 ------------------------------------------------------------------------
73 Q: Can you give me an example of how I could set up my office machine
74 so I can dial in to it from home?
76 A: Let's assume that the office machine is called "office" and is on a
77 local ethernet subnet. Call the home machine "home" and give it an IP
78 address on the same subnet as "office". We'll require both machines
79 to authenticate themselves to each other.
81 Set up the files on "office" as follows:
83 /etc/ppp/options contains:
85 auth # require the peer to authenticate itself
86 usehostname # only use our hostname for looking up peer's secret
87 # other options can go here if desired
89 /etc/ppp/chap-secrets contains:
91 home office "beware the frub-jub" home
92 office home "bird, my son!%&*" -
94 Set up a modem on a serial port so that users can dial in to the
95 modem and get a login prompt.
97 On "home", set up the files as follows:
99 /etc/ppp/options contains the same as on "office".
101 /etc/ppp/chap-secrets contains:
103 home office "beware the frub-jub" -
104 office home "bird, my son!%&*" office
106 Create a script called /etc/ppp/dial-office containing the following,
107 and make it executable:
111 pppd tty02 crtscts 38400 connect 'chat -v -f /etc/ppp/chat-office' \
114 (You may need to change some of the details here.)
116 Create the /etc/ppp/chat-office file containing the following:
123 ABORT "ogin incorrect"
129 "$" "\q^U/usr/sbin/pppd proxyarp"
132 You will need to change the details. Note that the "$" in the
133 second-last line is expecting the shell prompt after a successful
134 login - you may need to change it to "%" or something else.
137 ------------------------------------------------------------------------
139 Q: When I try to establish a connection, the modem successfully dials
140 the remote system, but then hangs up a few seconds later. How do I
141 find out what's going wrong?
143 A: There are a number of possible problems here. The first thing to
144 do is to ensure that pppd's messages are visible. Pppd uses the
145 syslog facility to log messages which help to identify specific
146 problems. Messages from pppd have facility "daemon" and levels
147 ranging from "debug" to "error".
149 Usually it is useful to see messages of level "notice" or higher on
150 the console. To see these, find the line in /etc/syslog.conf which
151 has /dev/console on the right-hand side, and add "daemon.notice" in
152 the list on the left. The line will end up looking something like
155 *.err;kern.debug;auth.notice;mail.crit;daemon.notice /dev/console
157 Note that the whitespace is tabs, *not* spaces.
159 If you are having problems, it may be useful to see messages of level
160 "info" as well, in which case you would change "daemon.notice" to
163 In addition, it is useful to collect pppd's debugging output in a
164 file - the debug option to pppd causes it to log the contents of all
165 control packets sent and received in human-readable form. To do this,
166 add a line like this to /etc/syslog.conf:
168 daemon,local2.debug /etc/ppp/log
170 and create an empty /etc/ppp/log file.
172 When you change syslog.conf, you will need to send a HUP signal to
173 syslogd to causes it to re-read syslog.conf. You can do this with a
174 command like this (as root):
176 kill -HUP `cat /etc/syslogd.pid`
178 (On some systems, you need to use /var/run/syslog.pid instead of
181 After setting up syslog like this, you can use the -v flag to chat and
182 the `debug' option to pppd to get more information. Try initiating
183 the connection again; when it fails, inspect /etc/ppp/log to see what
184 happened and where the connection failed.
187 ------------------------------------------------------------------------
189 Q: When I try to establish a connection, I get an error message saying
190 "Serial link is not 8-bit clean". Why?
192 A: The most common cause is that your connection script hasn't
193 successfully dialled out to the remote system and invoked ppp service
194 there. Instead, pppd is talking to something (a shell or login
195 process on the remote machine, or maybe just the modem) which is only
196 outputting 7-bit characters.
198 This can also arise with a modem which uses an AT command set if the
199 dial command is issued before pppd is invoked, rather than within a
200 connect script started by pppd. If the serial port is set to 7
201 bits/character plus parity when the last AT command is issued, the
202 modem serial port will be set to the same setting.
204 Note that pppd *always* sets the local serial port to 8 bits per
205 character, with no parity and 1 stop bit. So you shouldn't need to
206 issue an stty command before invoking pppd.
209 ------------------------------------------------------------------------
211 Q: When I try to establish a connection, I get an error message saying
212 "Serial line is looped back". Why?
214 A: Probably your connection script hasn't successfully dialled out to
215 the remote system and invoked ppp service there. Instead, pppd is
216 talking to something which is just echoing back the characters it
217 receives. The -v option to chat can help you find out what's going
218 on. It can be useful to include "~" as the last expect string to
219 chat, so chat won't return until it's seen the start of the first PPP
220 frame from the remote system.
222 Another possibility is that your phone connection has dropped for some
223 obscure reason and the modem is echoing the characters it receives
227 ------------------------------------------------------------------------
229 Q: I installed pppd successfully, but when I try to run it, I get a
230 message saying something like "peer authentication required but no
231 authentication files accessible".
233 A: When pppd is installed on a machine which already has a connection
234 to the Internet (or to be more precise, one which has a default route
235 in its routing table), it is set up to require all peers to
236 authenticate themselves. The reason for this is that if you don't
237 require authentication, you have a security hole, because the peer can
238 basically choose any IP address it wants, even the IP address of some
239 trusted host (for example, a host mentioned in some .rhosts file).
241 On machines which don't have a default route, the default ppp
242 installation does not require the peer to authenticate itself. The
243 reason is that such machines would mostly be using pppd to dial out to
244 an ISP which will refuse to authenticate itself. (Yes, it's still a
245 security hole, which will hopefully be fixed in the next version.)
247 There are 3 ways around the problem:
249 1. If possible, arrange for the peer to authenticate itself, and
250 create the necessary secrets files (/etc/ppp/pap-secrets and/or
251 /etc/ppp/chap-secrets).
253 2. If the peer refuses to authenticate itself, and will always be
254 using the same IP address, or one of a small set of IP addresses, you
255 can create an entry in the /etc/ppp/pap-secrets file like this:
257 "" * "" his-ip.his-domain his-other-ip.other-domain
259 (that is, using the empty string for the client name and password
260 fields). Of couse, you replace the 4th and following fields in the
261 example above with the IP address(es) that the peer may use. You can
262 use either hostnames or numeric IP addresses.
264 3. You can remove the `auth' option from the /etc/ppp/options file.
265 Pppd will then not ask the peer to authenticate itself. If you do
266 this, I *strongly* recommend that you remove the set-uid bit from the
267 permissions on the pppd executable, with a command like this:
269 chmod u-s /usr/local/etc/pppd
271 Then, an intruder could only use pppd maliciously if they had already
272 become root, in which case they couldn't do any more damage using pppd
273 than they could anyway.
276 ------------------------------------------------------------------------
278 Q: What do I need to put in the secrets files?
281 - secrets (i.e. passwords) to use for authenticating this host to
282 other hosts (i.e., for proving our identity to others);
283 - secrets which other hosts can use for authenticating themselves
284 to us (i.e., so that they can prove their identity to us); and
285 - information about which IP addresses other hosts may use, once
286 they have authenticated themselves.
288 There are two authentication files: /etc/ppp/pap-secrets, which
289 contains secrets for use with PAP (the Password Authentication
290 Protocol), and /etc/ppp/chap-secrets, which contains secrets for use
291 with CHAP (the Challenge Handshake Authentication Protocol). Both
292 files have the same simple format, which is as follows:
294 - The file contains a series of entries, each of which contains a
295 secret for authenticating one machine to another.
297 - Each entry is contained on a single logical line. A logical line
298 may be continued across several lines by placing a backslash (\) at
299 the end of each line except the last.
301 - Each entry has 3 or more fields, separated by whitespace (spaces
302 and/or tabs). These fields are, in order:
303 * The name of the machine that is authenticating itself
305 * The name of the machine that is authenticating the client
307 * The secret to be used for authenticating that client to that
308 server. If this field begins with the at-sign `@', the rest
309 of the field is taken as the name of a file containing the
311 * The 4th and any following fields list the IP address(es)
312 that the client may use.
314 - The file may contain comments, which begin with a `#' and continue
315 to the end of the line.
317 - Double quotes `"' should be used around a field if it contains
318 characters with special significance, such as space, tab, `#', etc.
320 - The backslash `\' may be used before characters with special
321 significance (space, tab, `#', `\', etc.) to remove that significance.
323 Some important points to note:
325 * A machine can be *both* a "client" and a "server" for the purposes
326 of authentication - this happens when both peers require the other to
327 authenticate itself. So A would authenticate itself to B, and B would
328 also authenticate itself to A (possibly using a different
329 authentication protocol).
331 * If both the "client" and the "server" are running ppp-2.x, they need
332 to have a similar entry in the appropriate secrets file; the first two
333 fields are *not* swapped on the client, compared to the server. So
334 the client might have an entry like this:
336 ay bee "our little secret" -
338 and the corresponding entry on the server could look like this:
340 ay bee "our little secret" 123.45.67.89
343 ------------------------------------------------------------------------
345 Q: Explain about PAP and CHAP?
347 PAP stands for the Password Authentication Protocol. With this
348 protocol, the "client" (the machine that needs to authenticate itself)
349 sends its name and a password, in clear text, to the "server". The
350 server returns a message indicating whether the name and password are
353 CHAP stands for the Challenge Handshake Authentication Protocol. It
354 is designed to address some of the deficiencies and vulnerabilities of
355 PAP. Like PAP, it is based on the client and server having a shared
356 secret, but the secret is never passed in clear text over the link.
357 Instead, the server sends a "challenge" - an arbitrary string of
358 bytes, and the client must prove it knows the shared secret by
359 generating a hash value from the challenge combined with the shared
360 secret, and sending the hash value back to the server. The server
361 also generates the hash value and compares it with the value received
364 At a practical level, CHAP can be slightly easier to configure than
365 PAP because the server sends its name with the challenge. Thus, when
366 finding the appropriate secret in the secrets file, the client knows
367 the server's name. In contrast, with PAP, the client has to find its
368 password (i.e. the shared secret) before it has received anything from
369 the server. Thus, it may be necessary to use the `remotename' option
370 to pppd when using PAP authentication so that it can select the
371 appropriate secret from /etc/ppp/pap-secrets.
373 Microsoft also has a variant of CHAP which they apparently think is
374 more secure than standard CHAP because they don't store secrets in
375 clear text on the server. However, a bogus client only needs to know
376 the encrypted secret to gain access, so the only extra security is
377 that the bogus client would need to run something other than Windows.
378 There is a client-side implementation of Microsoft's CHAP in ppp-2.3;
382 ------------------------------------------------------------------------
384 Q: When the modem hangs up, without the remote system having
385 terminated the connection properly, pppd does not notice the hangup,
386 but just keeps running. How do I get pppd to notice the hangup and
389 A: Pppd detects modem hangup by looking for an end-of-file indication
390 from the serial driver, which should be generated when the CD (carrier
391 detect) signal on the serial port is deasserted. For this to work:
393 - The modem has to be set to assert CD when the connection is made and
394 deassert it when the phone line hangs up. Usually the AT&C1 modem
395 command sets this mode.
397 - The cable from the modem to the serial port must connect the CD
400 - Some serial drivers have a "software carrier detect" mode, which
401 must be *disabled*. The method of doing this varies between systems.
402 Under SunOS, use the ttysoftcar command. Under NetBSD, edit /etc/ttys
403 to remove the "softcar" flag from the line for the serial port, and
407 ------------------------------------------------------------------------
409 Q: Why should I use PPP compression (BSD-Compress or Deflate) when my
410 modem already does V.42 compression? Won't it slow the CPU down a
413 A: Using PPP compression is preferable, especially when using modems
414 over phone lines, for the following reasons:
416 - The V.42 compression in the modem isn't very strong - it's an LZW
417 technique (same as BSD-Compress) with a 10, 11 or 12 bit code size.
418 With BSD-Compress you can use a code size of up to 15 bits and get
419 much better compression, or you can use Deflate and get even better
422 - I have found that enabling V.42 compression in my 14.4k modem
423 increases the round-trip time for a character to be sent, echoed and
424 returned by around 40ms, from 160ms to 200ms (with error correction
425 enabled). This is enough to make it feel less responsive on rlogin or
426 telnet sessions. Using PPP compression adds less than 5ms (small
427 enough that I couldn't measure it reliably). I admit my modem is a
428 cheapie and other modems may well perform better.
430 - While compression and decompression do require some CPU time, they
431 reduce the amount of time spent in the serial driver to transmit a
432 given amount of data. Many machines require an interrupt for each
433 character sent or received, and the interrupt handler can take a
434 significant amount of CPU time. So the increase in CPU load isn't as
435 great as you might think. My measurements indicate that a system with
436 a 33MHz 486 CPU should be able to do Deflate compression for serial
437 link speeds of up to 100kb/s or more. It depends somewhat on the type
438 of data, of course; for example, when compressing a string of nulls
439 with Deflate, it's hard to get a high output data rate from the
440 compressor, simply because it compresses strings of nulls so well that
441 it has to eat a very large amount of input data to get each byte of