Initial import from FreeBSD RELENG_4:
[dragonfly.git] / usr.sbin / pppd / pppd.8
1.\" manual page [] for pppd 2.3
2.\" $FreeBSD: src/usr.sbin/pppd/pppd.8,v 2003/03/11 22:31:30 trhodes Exp $
3.\" SH section heading
4.\" SS subsection heading
5.\" LP paragraph
6.\" IP indented paragraph
7.\" TP hanging label
10pppd \- Point to Point Protocol daemon
12.B pppd
14.I tty_name
15] [
16.I speed
17] [
18.I options
22The Point-to-Point Protocol (PPP) provides a method for transmitting
23datagrams over serial point-to-point links. PPP
24is composed of three parts: a method for encapsulating datagrams over
25serial links, an extensible Link Control Protocol (LCP), and
26a family of Network Control Protocols (NCP) for establishing
27and configuring different network-layer protocols.
29The encapsulation scheme is provided by driver code in the kernel.
30Pppd provides the basic LCP, authentication support, and an NCP for
31establishing and configuring the Internet Protocol (IP) (called the IP
32Control Protocol, IPCP).
35.I <tty_name>
36Communicate over the named device. The string "/dev/" is prepended if
37necessary. If no device name is given, or if the name of the terminal
38connected to the standard input is given, pppd
39will use that terminal, and will not fork to put itself in the
40background. This option is privileged if the \fInoauth\fR option is
43.I <speed>
44Set the baud rate to <speed> (a decimal number). On systems such as
454.4BSD and NetBSD, any speed can be specified, providing that it is
46supported by the serial device driver. Other systems
47(e.g. SunOS, Linux) allow only a limited set of speeds.
49.B active-filter \fIfilter-expression
50Specifies a packet filter to be applied to data packets to determine
51which packets are to be regarded as link activity, and therefore reset
52the idle timer, or cause the link to be brought up in demand-dialling
53mode. This option is useful in conjunction with the
54\fBidle\fR option if there are packets being sent or received
55regularly over the link (for example, routing information packets)
56which would otherwise prevent the link from ever appearing to be idle.
57The \fIfilter-expression\fR syntax is as described for tcpdump(1),
58except that qualifiers which are inappropriate for a PPP link, such as
59\fBether\fR and \fBarp\fR, are not permitted. Generally the filter
60expression should be enclosed in single-quotes to prevent whitespace
61in the expression from being interpreted by the shell.
62This option
63only available
64if both the kernel and pppd were compiled with PPP_FILTER defined.
66.B asyncmap \fI<map>
67Set the async character map to <map>. This map describes which
68control characters cannot be successfully received over the serial
69line. Pppd will ask the peer to send these characters as a 2-byte
70escape sequence. The argument is a 32 bit hex number with each bit
71representing a character to escape. Bit 0 (00000001) represents the
72character 0x00; bit 31 (80000000) represents the character 0x1f or ^_.
73If multiple \fIasyncmap\fR options are given, the values are ORed
74together. If no \fIasyncmap\fR option is given, no async character
75map will be negotiated for the receive direction; the peer should then
76escape \fIall\fR control characters. To escape transmitted
77characters, use the \fIescape\fR option.
79.B auth
80Require the peer to authenticate itself before allowing network
81packets to be sent or received.
83.B call \fIname
84Read options from the file /etc/ppp/peers/\fIname\fR. This file may
85contain privileged options, such as \fInoauth\fR, even if pppd
86is not being run by root. The \fIname\fR string may not begin with /
87or include .. as a pathname component. The format of the options file
88is described below.
90.B connect \fIscript
91Use the executable or shell command specified by \fIscript\fR to set
92up the serial line. This script would typically use the chat(8)
93program to dial the modem and start the remote ppp session. This
94option is privileged if the \fInoauth\fR option is used.
96.B connect-max-attempts \fI<n>
97Attempt dial-out connection to remote system no more than specified number
98of times (default = 1). If the connection is not made, pppd will exit.
99Requires that \fBpersist\fR has been specified.
101.B crtscts
102Use hardware flow control (i.e. RTS/CTS) to control the flow of data
103on the serial port. If neither the \fIcrtscts\fR nor the
104\fInocrtscts\fR option is given, the hardware flow control setting
105for the serial port is left unchanged.
107.B defaultroute
108Add a default route to the system routing tables, using the peer as
109the gateway, when IPCP negotiation is successfully completed.
110This entry is removed when the PPP connection is broken. This option
111is privileged if the \fInodefaultroute\fR option has been specified.
113.B disconnect \fIscript
114Run the executable or shell command specified by \fIscript\fR after
115pppd has terminated the link. This script could, for example, issue
116commands to the modem to cause it to hang up if hardware modem control
117signals were not available. The disconnect script is not run if the
118modem has already hung up. This option is privileged if the
119\fInoauth\fR option is used.
121.B escape \fIxx,yy,...
122Specifies that certain characters should be escaped on transmission
123(regardless of whether the peer requests them to be escaped with its
124async control character map). The characters to be escaped are
125specified as a list of hex numbers separated by commas. Note that
126almost any character can be specified for the \fIescape\fR option,
127unlike the \fIasyncmap\fR option which only allows control characters
128to be specified. The characters which may not be escaped are those
129with hex values 0x20 - 0x3f or 0x5e.
131.B file \fIname
132Read options from file \fIname\fR (the format is described below).
133The file must be readable by the user who has invoked pppd.
135.B lock
136Specifies that pppd should create a UUCP-style lock file for the
137serial device to ensure exclusive access to the device.
139.B mru \fIn
140Set the MRU [Maximum Receive Unit] value to \fIn\fR.
142will ask the peer to send packets of no more than \fIn\fR bytes. The
143minimum MRU value is 128. The default MRU value is 1500. A value of
144296 is recommended for slow links (40 bytes for TCP/IP header + 256
145bytes of data).
147.B mtu \fIn
148Set the MTU [Maximum Transmit Unit] value to \fIn\fR. Unless the
149peer requests a smaller value via MRU negotiation, pppd will
150request that the kernel networking code send data packets of no more
151than \fIn\fR bytes through the PPP network interface.
153.B passive
154Enables the "passive" option in the LCP. With this option, pppd will
155attempt to initiate a connection; if no reply is received from the
156peer, pppd will then just wait passively for a valid LCP packet from
157the peer, instead of exiting, as it would without this option.
160.I <local_IP_address>\fB:\fI<remote_IP_address>
161Set the local and/or remote interface IP addresses. Either one may be
162omitted. The IP addresses can be specified with a host name or in
163decimal dot notation (e.g. The default local
164address is the (first) IP address of the system (unless the
166option is given). The remote address will be obtained from the peer
167if not specified in any option. Thus, in simple cases, this option is
168not required. If a local and/or remote IP address is specified with
169this option, pppd
170will not accept a different value from the peer in the IPCP
171negotiation, unless the \fIipcp-accept-local\fR and/or
172\fIipcp-accept-remote\fR options are given, respectively.
174.B bsdcomp \fInr,nt
175Request that the peer compress packets that it sends, using the
176BSD-Compress scheme, with a maximum code size of \fInr\fR bits, and
177agree to compress packets sent to the peer with a maximum code size of
178\fInt\fR bits. If \fInt\fR is not specified, it defaults to the value
179given for \fInr\fR. Values in the range 9 to 15 may be used for
180\fInr\fR and \fInt\fR; larger values give better compression but
181consume more kernel memory for compression dictionaries.
182Alternatively, a value of 0 for \fInr\fR or \fInt\fR disables
183compression in the corresponding direction. Use \fInobsdcomp\fR or
184\fIbsdcomp 0\fR to disable BSD-Compress compression entirely.
186.B chap-interval \fIn
187If this option is given, pppd will rechallenge the peer every \fIn\fR
190.B chap-max-challenge \fIn
191Set the maximum number of CHAP challenge transmissions to \fIn\fR
192(default 10).
194.B chap-restart \fIn
195Set the CHAP restart interval (retransmission timeout for challenges)
196to \fIn\fR seconds (default 3).
198.B debug
199Enables connection debugging facilities.
200If this option is given, pppd will log the contents of all
201control packets sent or received in a readable form. The packets are
202logged through syslog with facility \fIdaemon\fR and level
203\fIdebug\fR. This information can be directed to a file by setting up
204/etc/syslog.conf appropriately (see syslog.conf(5)).
206.B default-asyncmap
207Disable asyncmap negotiation, forcing all control characters to be
208escaped for both the transmit and the receive direction.
210.B default-mru
211Disable MRU [Maximum Receive Unit] negotiation. With this option,
212pppd will use the default MRU value of 1500 bytes for both the
213transmit and receive direction.
215.B deflate \fInr,nt
216Request that the peer compress packets that it sends, using the
217Deflate scheme, with a maximum window size of \fI2**nr\fR bytes, and
218agree to compress packets sent to the peer with a maximum window size
219of \fI2**nt\fR bytes. If \fInt\fR is not specified, it defaults to
220the value given for \fInr\fR. Values in the range 8 to 15 may be used
221for \fInr\fR and \fInt\fR; larger values give better compression but
222consume more kernel memory for compression dictionaries.
223Alternatively, a value of 0 for \fInr\fR or \fInt\fR disables
224compression in the corresponding direction. Use \fInodeflate\fR or
225\fIdeflate 0\fR to disable Deflate compression entirely. (Note: pppd
226requests Deflate compression in preference to BSD-Compress if the peer
227can do either.)
229.B demand
230Initiate the link only on demand, i.e. when data traffic is present.
231With this option, the remote IP address must be specified by the user
232on the command line or in an options file. Pppd will initially
233configure the interface and enable it for IP traffic without
234connecting to the peer. When traffic is available, pppd will
235connect to the peer and perform negotiation, authentication, etc.
236When this is completed, pppd will commence passing data packets
237(i.e., IP packets) across the link.
239The \fIdemand\fR option implies the \fIpersist\fR option. If this
240behaviour is not desired, use the \fInopersist\fR option after the
241\fIdemand\fR option. The \fIidle\fR and \fIholdoff\fR
242options are also useful in conjuction with the \fIdemand\fR option.
244.B domain \fId
245Append the domain name \fId\fR to the local host name for authentication
246purposes. For example, if gethostname() returns the name porsche, but
247the fully qualified domain name is porsche.Quotron.COM, you could
248specify \fIdomain Quotron.COM\fR. Pppd would then use the name
249\fIporsche.Quotron.COM\fR for looking up secrets in the secrets file,
250and as the default name to send to the peer when authenticating itself
251to the peer. This option is privileged.
253.B holdoff \fIn
254Specifies how many seconds to wait before re-initiating the link after
255it terminates. This option only has any effect if the \fIpersist\fR
256or \fIdemand\fR option is used. The holdoff period is not applied if
257the link was terminated because it was idle.
259.B idle \fIn
260Specifies that pppd should disconnect if the link is idle for \fIn\fR
261seconds. The link is idle when no data packets (i.e. IP packets) are
262being sent or received. Note: it is not advisable to use this option
263with the \fIpersist\fR option without the \fIdemand\fR option.
264If the \fBactive-filter\fR
265option is given, data packets which are rejected by the specified
266activity filter also count as the link being idle.
268.B ipcp-accept-local
269With this option, pppd will accept the peer's idea of our local IP
270address, even if the local IP address was specified in an option.
272.B ipcp-accept-remote
273With this option, pppd will accept the peer's idea of its (remote) IP
274address, even if the remote IP address was specified in an option.
276.B ipcp-max-configure \fIn
277Set the maximum number of IPCP configure-request transmissions to
278\fIn\fR (default 10).
280.B ipcp-max-failure \fIn
281Set the maximum number of IPCP configure-NAKs returned before starting
282to send configure-Rejects instead to \fIn\fR (default 10).
284.B ipcp-max-terminate \fIn
285Set the maximum number of IPCP terminate-request transmissions to
286\fIn\fR (default 3).
288.B ipcp-restart \fIn
289Set the IPCP restart interval (retransmission timeout) to \fIn\fR
290seconds (default 3).
292.B ipparam \fIstring
293Provides an extra parameter to the ip-up and ip-down scripts. If this
294option is given, the \fIstring\fR supplied is given as the 6th
295parameter to those scripts.
297.B ipx
298Enable the IPXCP and IPX protocols. This option is presently only
299supported under Linux, and only if your kernel has been configured to
300include IPX support.
302.B ipx-network \fIn
303Set the IPX network number in the IPXCP configure request frame to
304\fIn\fR, a hexadecimal number (without a leading 0x). There is no
305valid default. If this option is not specified, the network number is
306obtained from the peer. If the peer does not have the network number,
307the IPX protocol will not be started.
309.B ipx-node \fIn\fB:\fIm
310Set the IPX node numbers.
311The two node numbers are separated from each
312other with a colon character.
313The first number \fIn\fR is the local
314node number.
315The second number \fIm\fR is the peer's node number.
317node number is a hexadecimal number, at most 10 digits long.
318The node
319numbers on the ipx-network must be unique.
320There is no valid
322If this option is not specified then the node numbers are
323obtained from the peer.
325.B ipx-router-name \fI<string>
326Set the name of the router.
327This is a string and is sent to the peer
328as information data.
330.B ipx-routing \fIn
331Set the routing protocol to be received by this option.
332More than one
333instance of \fIipx-routing\fR may be specified.
334The '\fInone\fR'
335option (0) may be specified as the only instance of ipx-routing.
337values may be \fI0\fR for \fINONE\fR, \fI2\fR for \fIRIP/SAP\fR, and
338\fI4\fR for \fINLSP\fR.
340.B ipxcp-accept-local
341Accept the peer's NAK for the node number specified in the ipx-node
343If a node number was specified, and non-zero, the default is
344to insist that the value be used.
345If you include this option then you
346will permit the peer to override the entry of the node number.
348.B ipxcp-accept-network
349Accept the peer's NAK for the network number specified in the
350ipx-network option.
351If a network number was specified, and non-zero, the
352default is to insist that the value be used.
353If you include this
354option then you will permit the peer to override the entry of the node
357.B ipxcp-accept-remote
358Use the peer's network number specified in the configure request
360If a node number was specified for the peer and this option was
361not specified, the peer will be forced to use the value which you have
364.B ipxcp-max-configure \fIn
365Set the maximum number of IPXCP configure request frames which the
366system will send to \fIn\fR.
367The default is 10.
369.B ipxcp-max-failure \fIn
370Set the maximum number of IPXCP NAK frames which the local system will
371send before it rejects the options.
372The default value is 3.
374.B ipxcp-max-terminate \fIn
375Set the maximum nuber of IPXCP terminate request frames before the
376local system considers that the peer is not listening to them.
378default value is 3.
380.B kdebug \fIn
381Enable debugging code in the kernel-level PPP driver. The argument
382\fIn\fR is a number which is the sum of the following values: 1 to
383enable general debug messages, 2 to request that the contents of
384received packets be printed, and 4 to request that the contents of
385transmitted packets be printed. On most systems, messages printed by
386the kernel are logged by syslog(1) to a file as directed in the
387/etc/syslog.conf configuration file.
389.B lcp-echo-failure \fIn
390If this option is given, pppd will presume the peer to be dead
391if \fIn\fR LCP echo-requests are sent without receiving a valid LCP
392echo-reply. If this happens, pppd will terminate the
393connection. Use of this option requires a non-zero value for the
394\fIlcp-echo-interval\fR parameter. This option can be used to enable
395pppd to terminate after the physical connection has been broken
396(e.g., the modem has hung up) in situations where no hardware modem
397control lines are available.
399.B lcp-echo-interval \fIn
400If this option is given, pppd will send an LCP echo-request frame to
401the peer every \fIn\fR seconds. Normally the peer should respond to
402the echo-request by sending an echo-reply. This option can be used
403with the \fIlcp-echo-failure\fR option to detect that the peer is no
404longer connected.
406.B lcp-max-configure \fIn
407Set the maximum number of LCP configure-request transmissions to
408\fIn\fR (default 10).
410.B lcp-max-failure \fIn
411Set the maximum number of LCP configure-NAKs returned before starting
412to send configure-Rejects instead to \fIn\fR (default 10).
414.B lcp-max-terminate \fIn
415Set the maximum number of LCP terminate-request transmissions to
416\fIn\fR (default 3).
418.B lcp-restart \fIn
419Set the LCP restart interval (retransmission timeout) to \fIn\fR
420seconds (default 3).
422.B local
423Don't use the modem control lines. With this option, pppd will ignore
424the state of the CD (Carrier Detect) signal from the modem and will
425not change the state of the DTR (Data Terminal Ready) signal.
427.B login
428Use the system password database for authenticating the peer using
429PAP, and record the user in the system wtmp file. Note that the peer
430must have an entry in the /etc/ppp/pap-secrets file as well as the
431system password database to be allowed access.
433.B maxconnect \fIn
434Terminate the connection when it has been available for network
435traffic for \fIn\fR seconds (i.e. \fIn\fR seconds after the first
436network control protocol comes up).
438.B modem
439Use the modem control lines. This option is the default. With this
440option, pppd will wait for the CD (Carrier Detect) signal from the
441modem to be asserted when opening the serial device (unless a connect
442script is specified), and it will drop the DTR (Data Terminal Ready)
443signal briefly when the connection is terminated and before executing
444the connect script. On Ultrix, this option implies hardware flow
445control, as for the \fIcrtscts\fR option.
447.B ms-dns \fI<addr>
448If pppd is acting as a server for Microsoft Windows clients, this
449option allows pppd to supply one or two DNS (Domain Name Server)
450addresses to the clients. The first instance of this option specifies
451the primary DNS address; the second instance (if given) specifies the
452secondary DNS address. (This option was present in some older
453versions of pppd under the name \fBdns-addr\fR.)
455.B ms-wins \fI<addr>
456If pppd is acting as a server for Microsoft Windows or "Samba"
457clients, this option allows pppd to supply one or two WINS (Windows
458Internet Name Services) server addresses to the clients. The first
459instance of this option specifies the primary WINS address; the second
460instance (if given) specifies the secondary WINS address.
462.B name \fIname
463Set the name of the local system for authentication purposes to
464\fIname\fR. This is a privileged option. With this option, pppd will
465use lines in the secrets files which have \fIname\fR as the second
466field when looking for a secret to use in authenticating the peer. In
467addition, unless overridden with the \fIuser\fR option, \fIname\fR
468will be used as the name to send to the peer when authenticating the
469local system to the peer. (Note that pppd does not append the domain
470name to \fIname\fR.)
472.B netmask \fIn
473Set the interface netmask to \fIn\fR, a 32 bit netmask in "decimal dot"
474notation (e.g. If this option is given, the value
475specified is ORed with the default netmask. The default netmask is
476chosen based on the negotiated remote IP address; it is the
477appropriate network mask for the class of the remote IP address, ORed
478with the netmasks for any non point-to-point network interfaces in the
479system which are on the same network.
481.B noaccomp
482Disable Address/Control compression in both directions (send and
485.B noauth
486Do not require the peer to authenticate itself. This option is
487privileged if the \fIauth\fR option is specified in /etc/ppp/options.
489.B nobsdcomp
490Disables BSD-Compress compression; \fBpppd\fR will not request or
491agree to compress packets using the BSD-Compress scheme.
493.B noccp
494Disable CCP (Compression Control Protocol) negotiation. This option
495should only be required if the peer is buggy and gets confused by
496requests from pppd for CCP negotiation.
498.B nocrtscts
499Disable hardware flow control (i.e. RTS/CTS) on the serial port. If
500neither the \fIcrtscts\fR nor the \fInocrtscts\fR option is given,
501the hardware flow control setting for the serial port is left
504.B nodefaultroute
505Disable the \fIdefaultroute\fR option. The system administrator who
506wishes to prevent users from creating default routes with pppd
507can do so by placing this option in the /etc/ppp/options file.
509.B nodeflate
510Disables Deflate compression; pppd will not request or agree to
511compress packets using the Deflate scheme.
513.B nodetach
514Don't detach from the controlling terminal. Without this option, if a
515serial device other than the terminal on the standard input is
516specified, pppd will fork to become a background process.
518.B noip
519Disable IPCP negotiation and IP communication. This option should
520only be required if the peer is buggy and gets confused by requests
521from pppd for IPCP negotiation.
523.B noipdefault
524Disables the default behaviour when no local IP address is specified,
525which is to determine (if possible) the local IP address from the
526hostname. With this option, the peer will have to supply the local IP
527address during IPCP negotiation (unless it specified explicitly on the
528command line or in an options file).
530.B noipx
531Disable the IPXCP and IPX protocols. This option should only be
532required if the peer is buggy and gets confused by requests from pppd
533for IPXCP negotiation.
535.B nomagic
536Disable magic number negotiation. With this option, pppd cannot
537detect a looped-back line. This option should only be needed if the
538peer is buggy.
540.B nopcomp
541Disable protocol field compression negotiation in both the receive and
542the transmit direction.
544.B nopersist
545Exit once a connection has been made and terminated. This is the
546default unless the \fIpersist\fR or \fIdemand\fR option has been
549.B nopredictor1
550Do not accept or agree to Predictor-1 compression.
552.B noproxyarp
553Disable the \fIproxyarp\fR option. The system administrator who
554wishes to prevent users from creating proxy ARP entries with pppd can
555do so by placing this option in the /etc/ppp/options file.
557.B novj
558Disable Van Jacobson style TCP/IP header compression in both the
559transmit and the receive direction.
561.B novjccomp
562Disable the connection-ID compression option in Van Jacobson style
563TCP/IP header compression. With this option, pppd will not omit the
564connection-ID byte from Van Jacobson compressed TCP/IP headers, nor
565ask the peer to do so.
567.B papcrypt
568Indicates that all secrets in the /etc/ppp/pap-secrets file which are
569used for checking the identity of the peer are encrypted, and thus
570pppd should not accept a password which, before encryption, is
571identical to the secret from the /etc/ppp/pap-secrets file.
573.B pap-max-authreq \fIn
574Set the maximum number of PAP authenticate-request transmissions to
575\fIn\fR (default 10).
577.B pap-restart \fIn
578Set the PAP restart interval (retransmission timeout) to \fIn\fR
579seconds (default 3).
581.B pap-timeout \fIn
582Set the maximum time that pppd will wait for the peer to authenticate
583itself with PAP to \fIn\fR seconds (0 means no limit).
585.B pass-filter \fIfilter-expression
586Specifies a packet filter to applied to data packets being sent or
587received to determine which packets should be allowed to pass.
588Packets which are rejected by the filter are silently discarded. This
589option can be used to prevent specific network daemons (such as
590routed) using up link bandwidth, or to provide a basic firewall
592The \fIfilter-expression\fR syntax is as described for tcpdump(1),
593except that qualifiers which are inappropriate for a PPP link, such as
594\fBether\fR and \fBarp\fR, are not permitted. Generally the filter
595expression should be enclosed in single-quotes to prevent whitespace
596in the expression from being interpreted by the shell. Note that it
597is possible to apply different constraints to incoming and outgoing
598packets using the \fBinbound\fR and \fBoutbound\fR qualifiers.
600option is currently only available under NetBSD, and then only if both
601the kernel and pppd were compiled with PPP_FILTER defined.
603.B persist
604Do not exit after a connection is terminated; instead try to reopen
605the connection.
607.B predictor1
608Request that the peer compress frames that it sends using Predictor-1
609compression, and agree to compress transmitted frames with Predictor-1
610if requested. This option has no effect unless the kernel driver
611supports Predictor-1 compression.
613.B proxyarp
614Add an entry to this system's ARP [Address Resolution Protocol] table
615with the IP address of the peer and the Ethernet address of this
616system. This will have the effect of making the peer appear to other
617systems to be on the local ethernet.
619.B remotename \fIname
620Set the assumed name of the remote system for authentication purposes
621to \fIname\fR.
623.B refuse-chap
624With this option, pppd will not agree to authenticate itself to the
625peer using CHAP.
627.B refuse-pap
628With this option, pppd will not agree to authenticate itself to the
629peer using PAP.
631.B require-chap
632Require the peer to authenticate itself using CHAP [Challenge
633Handshake Authentication Protocol] authentication.
635.B require-pap
636Require the peer to authenticate itself using PAP [Password
637Authentication Protocol] authentication.
639.B silent
640With this option, pppd will not transmit LCP packets to initiate a
641connection until a valid LCP packet is received from the peer (as for
642the `passive' option with ancient versions of pppd).
644.B usehostname
645Enforce the use of the hostname (with domain name appended, if given)
646as the name of the local system for authentication purposes (overrides
647the \fIname\fR option).
649.B user \fIname
650Sets the name used for authenticating the local system to the peer to
653.B vj-max-slots \fIn
654Sets the number of connection slots to be used by the Van Jacobson
655TCP/IP header compression and decompression code to \fIn\fR, which
656must be between 2 and 16 (inclusive).
658.B welcome \fIscript
659Run the executable or shell command specified by \fIscript\fR before
660initiating PPP negotiation, after the connect script (if any) has
661completed. This option is privileged if the \fInoauth\fR option is
664.B xonxoff
665Use software flow control (i.e. XON/XOFF) to control the flow of data on
666the serial port.
668Options can be taken from files as well as the command line. Pppd
669reads options from the files /etc/ppp/options, ~/.ppprc and
670/etc/ppp/options.\fIttyname\fR (in that order) before processing the
671options on the command line. (In fact, the command-line options are
672scanned to find the terminal name before the options.\fIttyname\fR
673file is read.) In forming the name of the options.\fIttyname\fR file,
674the initial /dev/ is removed from the terminal name, and any remaining
675/ characters are replaced with dots.
677An options file is parsed into a series of words, delimited by
678whitespace. Whitespace can be included in a word by enclosing the
679word in double-quotes ("). A backslash (\\) quotes the following character.
680A hash (#) starts a comment, which continues until the end of the
681line. There is no restriction on using the \fIfile\fR or \fIcall\fR
682options within an options file.
684.I pppd
685provides system administrators with sufficient access control that PPP
686access to a server machine can be provided to legitimate users without
687fear of compromising the security of the server or the network it's
688on. In part this is provided by the /etc/ppp/options file, where the
689administrator can place options to restrict the ways in which pppd can
690be used, and in part by the PAP and CHAP secrets files, where the
691administrator can restrict the set of IP addresses which individual
692users may use.
694The normal way that pppd should be set up is to have the \fIauth\fR
695option in the /etc/ppp/options file. (This may become the default in
696later releases.) If users wish to use pppd to dial out to a peer
697which will refuse to authenticate itself (such as an internet service
698provider), the system administrator should create an options file
699under /etc/ppp/peers containing the \fInoauth\fR option, the name of
700the serial port to use, and the \fIconnect\fR option (if required),
701plus any other appropriate options. In this way, pppd can be set up
702to allow non-privileged users to make unauthenticated connections only
703to trusted peers.
705As indicated above, some security-sensitive options are privileged,
706which means that they may not be used by an ordinary non-privileged
707user running a setuid-root pppd, either on the command line, in the
708user's ~/.ppprc file, or in an options file read using the \fIfile\fR
709option. Privileged options may be used in /etc/ppp/options file or in
710an options file read using the \fIcall\fR option. If pppd is being
711run by the root user, privileged options can be used without
714Authentication is the process whereby one peer convinces the other of
715its identity. This involves the first peer sending its name to the
716other, together with some kind of secret information which could only
717come from the genuine authorized user of that name. In such an
718exchange, we will call the first peer the "client" and the other the
719"server". The client has a name by which it identifies itself to the
720server, and the server also has a name by which it identifies itself
721to the client. Generally the genuine client shares some secret (or
722password) with the server, and authenticates itself by proving that it
723knows that secret. Very often, the names used for authentication
724correspond to the internet hostnames of the peers, but this is not
727At present, pppd supports two authentication protocols: the Password
728Authentication Protocol (PAP) and the Challenge Handshake
729Authentication Protocol (CHAP). PAP involves the client sending its
730name and a cleartext password to the server to authenticate itself.
731In contrast, the server initiates the CHAP authentication exchange by
732sending a challenge to the client (the challenge packet includes the
733server's name). The client must respond with a response which
734includes its name plus a hash value derived from the shared secret and
735the challenge, in order to prove that it knows the secret.
737The PPP protocol, being symmetrical, allows both peers to require the
738other to authenticate itself. In that case, two separate and
739independent authentication exchanges will occur. The two exchanges
740could use different authentication protocols, and in principle,
741different names could be used in the two exchanges.
743The default behaviour of pppd is to agree to authenticate if
744requested, and to not require authentication from the peer. However,
745pppd will not agree to authenticate itself with a particular protocol
746if it has no secrets which could be used to do so.
748Pppd stores secrets for use in authentication in secrets
749files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP).
750Both secrets files have the same format. The secrets files can
751contain secrets for pppd to use in authenticating itself to other
752systems, as well as secrets for pppd to use when authenticating other
753systems to itself.
755Each line in a secrets file contains one secret. A given secret is
756specific to a particular combination of client and server - it can
757only be used by that client to authenticate itself to that server.
758Thus each line in a secrets file has at least 3 fields: the name of
759the client, the name of the server, and the secret. These fields may
760be followed by a list of the IP addresses that the specified client
761may use when connecting to the specified server.
763A secrets file is parsed into words as for an options file, so the
764client name, server name and secrets fields must each be one word,
765with any embedded spaces or other special characters quoted or
766escaped. Any following words on the same line are taken to be a list
767of acceptable IP addresses for that client, or an
768override for "local:remote" addresses (the same format used on the
769command line or in the options file) when on a line that contains a
770specific client name (not a wildcard nor empty).
771If there are only 3 words
772on the line, or if the first word is "-", then all IP addresses are
773disallowed. To allow any address, use "*".
774A word starting with "!" indicates that the
775specified address is \fInot\fR acceptable. An address may be followed
776by "/" and a number \fIn\fR, to indicate a whole subnet, i.e. all
777addresses which have the same value in the most significant \fIn\fR
778bits. Note that case is significant in the client and server names
779and in the secret.
781If the secret starts with an `@', what follows is assumed to be the
782name of a file from which to read the secret. A "*" as the client or
783server name matches any name. When selecting a secret, pppd takes the
784best match, i.e. the match with the fewest wildcards.
786Thus a secrets file contains both secrets for use in authenticating
787other hosts, plus secrets which we use for authenticating ourselves to
788others. When pppd is authenticating the peer (checking the peer's
789identity), it chooses a secret with the peer's name in the first
790field and the name of the local system in the second field. The
791name of the local system defaults to the hostname, with the domain
792name appended if the \fIdomain\fR option is used. This default can be
793overridden with the \fIname\fR option, except when the
794\fIusehostname\fR option is used.
796When pppd is choosing a secret to use in authenticating itself to the
797peer, it first determines what name it is going to use to identify
798itself to the peer. This name can be specified by the user with the
799\fIuser\fR option. If this option is not used, the name defaults to
800the name of the local system, determined as described in the previous
801paragraph. Then pppd looks for a secret with this name in the first
802field and the peer's name in the second field. Pppd will know the
803name of the peer if CHAP authentication is being used, because the
804peer will have sent it in the challenge packet. However, if PAP is being
805used, pppd will have to determine the peer's name from the options
806specified by the user. The user can specify the peer's name directly
807with the \fIremotename\fR option. Otherwise, if the remote IP address
808was specified by a name (rather than in numeric form), that name will
809be used as the peer's name. Failing that, pppd will use the null
810string as the peer's name.
812When authenticating the peer with PAP, the supplied password is first
813compared with the secret from the secrets file. If the password
814doesn't match the secret, the password is encrypted using crypt() and
815checked against the secret again. Thus secrets for authenticating the
816peer can be stored in encrypted form if desired. If the
817\fIpapcrypt\fR option is given, the first (unencrypted) comparison is
818omitted, for better security.
820Furthermore, if the \fIlogin\fR option was specified, the username and
821password are also checked against the system password database. Thus,
822the system administrator can set up the pap-secrets file to allow PPP
823access only to certain users, and to restrict the set of IP addresses
824that each user can use. Typically, when using the \fIlogin\fR option,
825the secret in /etc/ppp/pap-secrets would be "", which will match any
826password supplied by the peer. This avoids the need to have the same
827secret in two places.
829Additional checks are performed when the \fBlogin\fR option is used.
830If the file /etc/ppp/ppp.deny exists, and the user is listed in it,
831the authentication fails. If the file /etc/ppp/ppp.shells exists and
832the user's normal login shell is not listed, the authentication fails.
834Authentication must be satisfactorily completed before IPCP (or any
835other Network Control Protocol) can be started. If the peer is
836required to authenticate itself, and fails to do so, pppd will
837terminated the link (by closing LCP). If IPCP negotiates an
838unacceptable IP address for the remote host, IPCP will be closed. IP
839packets can only be sent or received when IPCP is open.
841In some cases it is desirable to allow some hosts which can't
842authenticate themselves to connect and use one of a restricted set of
843IP addresses, even when the local host generally requires
844authentication. If the peer refuses to authenticate itself when
845requested, pppd takes that as equivalent to authenticating with PAP
846using the empty string for the username and password. Thus, by adding
847a line to the pap-secrets file which specifies the empty string for
848the client and password, it is possible to allow restricted access to
849hosts which refuse to authenticate themselves.
852When IPCP negotiation is completed successfully, pppd will inform the
853kernel of the local and remote IP addresses for the ppp interface.
854This is sufficient to create a host route to the remote end of the
855link, which will enable the peers to exchange IP packets.
856Communication with other machines generally requires further
857modification to routing tables and/or ARP (Address Resolution
858Protocol) tables. In most cases the \fIdefaultroute\fR and/or
859\fIproxyarp\fR options are sufficient for this, but in some cases
860further intervention is required. The /etc/ppp/ip-up script can be
861used for this.
863Sometimes it is desirable to add a default route through the remote
864host, as in the case of a machine whose only connection to the
865Internet is through the ppp interface. The \fIdefaultroute\fR option
866causes pppd to create such a default route when IPCP comes up, and
867delete it when the link is terminated.
869In some cases it is desirable to use proxy ARP, for example on a
870server machine connected to a LAN, in order to allow other hosts to
871communicate with the remote host. The \fIproxyarp\fR option causes
872pppd to look for a network interface on the same subnet as the remote
873host (an interface supporting broadcast and ARP, which is up and not a
874point-to-point or loopback interface). If found, pppd creates a
875permanent, published ARP entry with the IP address of the remote host
876and the hardware address of the network interface found.
878When the \fIdemand\fR option is used, the interface IP addresses have
879already been set at the point when IPCP comes up. If pppd has not
880been able to negotiate the same addresses that it used to configure
881the interface (for example when the peer is an ISP that uses dynamic
882IP address assignment), pppd has to change the interface IP addresses
883to the negotiated addresses. This may disrupt existing connections,
884and the use of demand dialling with peers that do dynamic IP address
885assignment is not recommended.
888The following examples assume that the /etc/ppp/options file contains
889the \fIauth\fR option (as in the default /etc/ppp/options file in the
890ppp distribution).
892Probably the most common use of pppd is to dial out to an ISP. This
893can be done with a command such as
895pppd call isp
897where the /etc/ppp/peers/isp file is set up by the system
898administrator to contain something like this:
900ttyS0 19200 crtscts
902connect '/usr/sbin/chat -v -f /etc/ppp/chat-isp'
906In this example, we are using chat to dial the ISP's modem and go
907through any logon sequence required. The /etc/ppp/chat-isp file
908contains the script used by chat; it could for example contain
909something like this:
921ABORT "Username/Password Incorrect"
923"" "at"
925OK "at&d0&c1"
927OK "atdt2468135"
929"name:" "^Umyuserid"
931"word:" "\\qmypassword"
933"ispts" "\\q^Uppp"
937See the chat(8) man page for details of chat scripts.
939Pppd can also be used to provide a dial-in ppp service for users. If
940the users already have login accounts, the simplest way to set up the
941ppp service is to let the users log in to their accounts and run pppd
942(installed setuid-root) with a command such as
944pppd proxyarp
946To allow a user to use the PPP facilities, you need to allocate an IP
947address for that user's machine and create an entry in
948/etc/ppp/pap-secrets or /etc/ppp/chap-secrets (depending on which
949authentication method the PPP implementation on the user's machine
950supports), so that the user's
951machine can authenticate itself. For example, if Joe has a machine
952called "joespc" which is to be allowed to dial in to the machine
953called "server" and use the IP address, you would add an
954entry like this to /etc/ppp/pap-secrets or /etc/ppp/chap-secrets:
956joespc server "joe's secret"
958Alternatively, you can create a username called (for example) "ppp",
959whose login shell is pppd and whose home directory is /etc/ppp.
960Options to be used when pppd is run this way can be put in
963If your serial connection is any more complicated than a piece of
964wire, you may need to arrange for some control characters to be
965escaped. In particular, it is often useful to escape XON (^Q) and
966XOFF (^S), using \fIasyncmap a0000\fR. If the path includes a telnet,
967you probably should escape ^] as well (\fIasyncmap 200a0000\fR). If
968the path includes an rlogin, you will need to use the \fIescape ff\fR
969option on the end which is running the rlogin client, since many
970rlogin implementations are not transparent; they will remove the
971sequence [0xff, 0xff, 0x73, 0x73, followed by any 8 bytes] from the
975Messages are sent to the syslog daemon using facility LOG_DAEMON.
976(This can be overriden by recompiling pppd with the macro
977LOG_PPP defined as the desired facility.) In order to see the error
978and debug messages, you will need to edit your /etc/syslog.conf file
979to direct the messages to the desired output device or file.
981The \fIdebug\fR option causes the contents of all control packets sent
982or received to be logged, that is, all LCP, PAP, CHAP or IPCP packets.
983This can be useful if the PPP negotiation does not succeed or if
984authentication fails.
985If debugging is enabled at compile time, the \fIdebug\fR option also
986causes other debugging messages to be logged.
988Debugging can also be enabled or disabled by sending a SIGUSR1 signal
989to the pppd process. This signal acts as a toggle.
991Pppd invokes scripts at various stages in its processing which can be
992used to perform site-specific ancillary processing. These scripts are
993usually shell scripts, but could be executable code files instead.
994Pppd does not wait for the scripts to finish. The scripts are
995executed as root (with the real and effective user-id set to 0), so
996that they can do things such as update routing tables or run
997privileged daemons. Be careful that the contents of these scripts do
998not compromise your system's security. Pppd runs the scripts with
999standard input, output and error redirected to /dev/null, and with an
1000environment that is empty except for some environment variables that
1001give information about the link. The environment variables that pppd
1002sets are:
1005The name of the serial tty device being used.
1008The name of the network interface being used.
1011The IP address for the local end of the link. This is only set when
1012IPCP has come up.
1015The IP address for the remote end of the link. This is only set when
1016IPCP has come up.
1019The authenticated name of the peer. This is only set if the peer
1020authenticates itself.
1022.B SPEED
1023The baud rate of the tty device.
1025.B UID
1026The real user-id of the user who invoked pppd.
1028Pppd invokes the following scripts, if they exist. It is not an error
1029if they don't exist.
1031.B /etc/ppp/auth-up
1032A program or script which is executed after the remote system
1033successfully authenticates itself. It is executed with the parameters
1035\fIinterface-name peer-name user-name tty-device speed\fR
1037Note that this script is not executed if the peer doesn't authenticate
1038itself, for example when the \fInoauth\fR option is used.
1040.B /etc/ppp/auth-down
1041A program or script which is executed when the link goes down, if
1042/etc/ppp/auth-up was previously executed. It is executed in the same
1043manner with the same parameters as /etc/ppp/auth-up.
1045.B /etc/ppp/ip-up
1046A program or script which is executed when the link is available for
1047sending and receiving IP packets (that is, IPCP has come up). It is
1048executed with the parameters
1050\fIinterface-name tty-device speed local-IP-address
1051remote-IP-address ipparam\fR
1053.B /etc/ppp/ip-down
1054A program or script which is executed when the link is no longer
1055available for sending and receiving IP packets. This script can be
1056used for undoing the effects of the /etc/ppp/ip-up script. It is
1057invoked in the same manner and with the same parameters as the ip-up
1060.B /etc/ppp/ipx-up
1061A program or script which is executed when the link is available for
1062sending and receiving IPX packets (that is, IPXCP has come up). It is
1063executed with the parameters
1065\fIinterface-name tty-device speed network-number local-IPX-node-address
1066remote-IPX-node-address local-IPX-routing-protocol remote-IPX-routing-protocol
1067local-IPX-router-name remote-IPX-router-name ipparam pppd-pid\fR
1069The local-IPX-routing-protocol and remote-IPX-routing-protocol field
1070may be one of the following:
1072NONE to indicate that there is no routing protocol
1074RIP to indicate that RIP/SAP should be used
1076NLSP to indicate that Novell NLSP should be used
1078RIP NLSP to indicate that both RIP/SAP and NLSP should be used
1080.B /etc/ppp/ipx-down
1081A program or script which is executed when the link is no longer
1082available for sending and receiving IPX packets. This script can be
1083used for undoing the effects of the /etc/ppp/ipx-up script. It is
1084invoked in the same manner and with the same parameters as the ipx-up
1088.B /var/run/ppp\fIn\ \fR(BSD or Linux), \fB/etc/ppp/ppp\fIn\ \fR(others)
1089Process-ID for pppd process on ppp interface unit \fIn\fR.
1091.B /etc/ppp/pap-secrets
1092Usernames, passwords and IP addresses for PAP authentication. This
1093file should be owned by root and not readable or writable by any other
1094user. Pppd will log a warning if this is not the case.
1096.B /etc/ppp/chap-secrets
1097Names, secrets and IP addresses for CHAP authentication. As for
1098/etc/ppp/pap-secrets, this file should be owned by root and not
1099readable or writable by any other user. Pppd will log a warning if
1100this is not the case.
1102.B /etc/ppp/options
1103System default options for pppd, read before user default options or
1104command-line options.
1106.B ~/.ppprc
1107User default options, read before /etc/ppp/options.\fIttyname\fR.
1109.B /etc/ppp/options.\fIttyname
1110System default options for the serial port being used, read after
1111~/.ppprc. In forming the \fIttyname\fR part of this
1112filename, an initial /dev/ is stripped from the port name (if
1113present), and any slashes in the remaining part are converted to
1116.B /etc/ppp/peers
1117A directory containing options files which may contain privileged
1118options, even if pppd was invoked by a user other than root. The
1119system administrator can create options files in this directory to
1120permit non-privileged users to dial out without requiring the peer to
1121authenticate, but only to certain trusted peers.
1123.B /etc/ppp/ppp.deny
1124Lists users who may not use the system password PAP authentication.
1126.B /etc/ppp/ppp.shells
1127Lists user shells which are approved for system password PAP authentication
1130.B /usr/share/examples/pppd/
1131Sample pppd configuration files.
1133.IR chat(8),
1134.IR ppp(8)
1136.B RFC1144
1137Jacobson, V.
1138\fICompressing TCP/IP headers for low-speed serial links.\fR
1139February 1990.
1141.B RFC1321
1142Rivest, R.
1143.I The MD5 Message-Digest Algorithm.
1144April 1992.
1146.B RFC1332
1147McGregor, G.
1148.I PPP Internet Protocol Control Protocol (IPCP).
1149May 1992.
1151.B RFC1334
1152Lloyd, B.; Simpson, W.A.
1153.I PPP authentication protocols.
1154October 1992.
1156.B RFC1661
1157Simpson, W.A.
1158.I The Point\-to\-Point Protocol (PPP).
1159July 1994.
1161.B RFC1662
1162Simpson, W.A.
1163.I PPP in HDLC-like Framing.
1164July 1994.
1166The following signals have the specified effect when sent to pppd.
1169These signals cause pppd to terminate the link (by closing LCP),
1170restore the serial device settings, and exit.
1173This signal causes pppd to terminate the link, restore the serial
1174device settings, and close the serial device. If the \fIpersist\fR or
1175\fIdemand\fR option has been specified, pppd will try to reopen the
1176serial device and start another connection (after the holdoff period).
1177Otherwise pppd will exit. If this signal is received during the
1178holdoff period, it causes pppd to end the holdoff period immediately.
1180.B SIGUSR1
1181This signal toggles the state of the \fIdebug\fR option.
1183.B SIGUSR2
1184This signal causes pppd to renegotiate compression. This can be
1185useful to re-enable compression after it has been disabled as a result
1186of a fatal decompression error. (Fatal decompression errors generally
1187indicate a bug in one or other implementation.)
1190Paul Mackerras (, based on earlier work by
1191Drew Perkins,
1192Brad Clements,
1193Karl Fox,
1194Greg Christy,
1196Brad Parker.