2472 lines
94 KiB
HTML
2472 lines
94 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of PPPD</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>PPPD</H1>
|
|
Section: Maintenance Commands (8)<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
pppd - Point-to-Point Protocol Daemon
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
<B>pppd</B>
|
|
|
|
[
|
|
<I>options</I>
|
|
|
|
]
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<P>
|
|
|
|
PPP is the protocol used for establishing internet links over dial-up
|
|
modems, DSL connections, and many other types of point-to-point
|
|
links. The <I>pppd</I> daemon works together with the kernel PPP
|
|
driver to establish and maintain a PPP link with another system
|
|
(called the <I>peer</I>) and to negotiate Internet Protocol (IP)
|
|
addresses for each end of the link. Pppd can also authenticate the
|
|
peer and/or supply authentication information to the peer. PPP can be
|
|
used with other network protocols besides IP, but such use is becoming
|
|
increasingly rare.
|
|
<A NAME="lbAE"> </A>
|
|
<H2>FREQUENTLY USED OPTIONS</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="1"><I>ttyname</I>
|
|
|
|
<DD>
|
|
Use the serial port called <I>ttyname</I> to communicate with the
|
|
peer. If <I>ttyname</I> does not begin with a slash (/),
|
|
the string "/dev/" is prepended to <I>ttyname</I> to form the
|
|
name of the device to open. If no device name is given, or if the
|
|
name of the terminal
|
|
connected to the standard input is given, pppd will use that terminal,
|
|
and will not fork to put itself in the background. A value for this
|
|
option from a privileged source cannot be overridden by a
|
|
non-privileged user.
|
|
<DT id="2"><I>speed</I>
|
|
|
|
<DD>
|
|
An option that is a decimal number is taken as the desired baud rate
|
|
for the serial device. On systems such as
|
|
4.4BSD and NetBSD, any speed can be specified. Other systems
|
|
(e.g. Linux, SunOS) only support the commonly-used baud rates.
|
|
<DT id="3"><B>asyncmap </B><I>map</I>
|
|
|
|
<DD>
|
|
This option sets the Async-Control-Character-Map (ACCM) for this end
|
|
of the link. The ACCM is a set of 32 bits, one for each of the
|
|
ASCII control characters with values from 0 to 31, where a 1 bit
|
|
indicates that the corresponding control character should not be used
|
|
in PPP packets sent to this system. The map is encoded as a
|
|
hexadecimal number (without a leading 0x) where the least significant
|
|
bit (00000001) represents character 0 and the most significant bit
|
|
(80000000) represents character 31.
|
|
Pppd will ask the peer to send these characters as a 2-byte
|
|
escape sequence.
|
|
If multiple <I>asyncmap</I> options are given, the values are ORed
|
|
together. If no <I>asyncmap</I> option is given, the default is zero,
|
|
so pppd will ask the peer not to escape any control characters.
|
|
To escape transmitted characters, use the <I>escape</I> option.
|
|
<DT id="4"><B>auth</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself before allowing network
|
|
packets to be sent or received. This option is the default if the
|
|
system has a default route. If neither this option nor the
|
|
<I>noauth</I> option is specified, pppd will only allow the peer to use
|
|
IP addresses to which the system does not already have a route.
|
|
<DT id="5"><B>call </B><I>name</I>
|
|
|
|
<DD>
|
|
Read additional options from the file /etc/ppp/peers/<I>name</I>. This
|
|
file may contain privileged options, such as <I>noauth</I>, even if pppd
|
|
is not being run by root. The <I>name</I> string may not begin with /
|
|
or include .. as a pathname component. The format of the options file
|
|
is described below.
|
|
<DT id="6"><B>connect </B><I>script</I>
|
|
|
|
<DD>
|
|
Usually there is something which needs to be done to prepare the link
|
|
before the PPP protocol can be started; for instance, with a dial-up
|
|
modem, commands need to be sent to the modem to dial the appropriate
|
|
phone number. This option specifies an command for pppd to execute
|
|
(by passing it to a shell) before attempting to start PPP negotiation.
|
|
The chat (8) program is often useful here, as it provides a way to
|
|
send arbitrary strings to a modem and respond to received characters.
|
|
A value
|
|
for this option from a privileged source cannot be overridden by a
|
|
non-privileged user.
|
|
<DT id="7"><B>crtscts</B>
|
|
|
|
<DD>
|
|
Specifies that pppd should set the serial port to use hardware flow
|
|
control using the RTS and CTS signals in the RS-232 interface.
|
|
If neither the <I>crtscts</I>, the
|
|
<I>nocrtscts</I>, the <I>cdtrcts</I> nor the <I>nocdtrcts</I> option
|
|
is given, the hardware flow control setting for the serial port is
|
|
left unchanged.
|
|
Some serial ports (such as Macintosh serial ports) lack a true
|
|
RTS output. Such serial ports use this mode to implement
|
|
unidirectional flow control. The serial port will
|
|
suspend transmission when requested by the modem (via CTS)
|
|
but will be unable to request the modem to stop sending to the
|
|
computer. This mode retains the ability to use DTR as
|
|
a modem control line.
|
|
<DT id="8"><B>defaultroute</B>
|
|
|
|
<DD>
|
|
Add a default route to the system routing tables, using the peer as
|
|
the gateway, when IPCP negotiation is successfully completed.
|
|
This entry is removed when the PPP connection is broken. This option
|
|
is privileged if the <I>nodefaultroute</I> option has been specified.
|
|
<DT id="9"><B>replacedefaultroute</B>
|
|
|
|
<DD>
|
|
This option is a flag to the defaultroute option. If defaultroute is
|
|
set and this flag is also set, pppd replaces an existing default route
|
|
with the new default route.
|
|
<DT id="10"><B>disconnect </B><I>script</I>
|
|
|
|
<DD>
|
|
Execute the command specified by <I>script</I>, by passing it to a
|
|
shell, after
|
|
pppd has terminated the link. This command could, for example, issue
|
|
commands to the modem to cause it to hang up if hardware modem control
|
|
signals were not available. The disconnect script is not run if the
|
|
modem has already hung up. A value for this option from a privileged
|
|
source cannot be overridden by a non-privileged user.
|
|
<DT id="11"><B>escape </B><I>xx,yy,...</I>
|
|
|
|
<DD>
|
|
Specifies that certain characters should be escaped on transmission
|
|
(regardless of whether the peer requests them to be escaped with its
|
|
async control character map). The characters to be escaped are
|
|
specified as a list of hex numbers separated by commas. Note that
|
|
almost any character can be specified for the <I>escape</I> option,
|
|
unlike the <I>asyncmap</I> option which only allows control characters
|
|
to be specified. The characters which may not be escaped are those
|
|
with hex values 0x20 - 0x3f or 0x5e.
|
|
<DT id="12"><B>file </B><I>name</I>
|
|
|
|
<DD>
|
|
Read options from file <I>name</I> (the format is described below).
|
|
The file must be readable by the user who has invoked pppd.
|
|
<DT id="13"><B>init </B><I>script</I>
|
|
|
|
<DD>
|
|
Execute the command specified by <I>script</I>, by passing it to a shell, to
|
|
initialize the serial line. This script would typically use the
|
|
<A HREF="/cgi-bin/man/man2html?8+chat">chat</A>(8) program to configure the modem to enable auto answer. A value
|
|
for this option from a privileged source cannot be overridden by a
|
|
non-privileged user.
|
|
<DT id="14"><B>lock</B>
|
|
|
|
<DD>
|
|
Specifies that pppd should create a UUCP-style lock file for the
|
|
serial device to ensure exclusive access to the device. By default,
|
|
pppd will not create a lock file.
|
|
<DT id="15"><B>mru </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the MRU [Maximum Receive Unit] value to <I>n</I>. Pppd
|
|
will ask the peer to send packets of no more than <I>n</I> bytes.
|
|
The value of <I>n</I> must be between 128 and 16384; the default is 1500.
|
|
A value of
|
|
296 works well on very slow links (40 bytes for TCP/IP header + 256
|
|
bytes of data).
|
|
Note that for the IPv6 protocol, the MRU must be at least 1280.
|
|
<DT id="16"><B>mtu </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the MTU [Maximum Transmit Unit] value to <I>n</I>. Unless the
|
|
peer requests a smaller value via MRU negotiation, pppd will
|
|
request that the kernel networking code send data packets of no more
|
|
than <I>n</I> bytes through the PPP network interface. Note that for
|
|
the IPv6 protocol, the MTU must be at least 1280.
|
|
<DT id="17"><B>passive</B>
|
|
|
|
<DD>
|
|
Enables the "passive" option in the LCP. With this option, pppd will
|
|
attempt to initiate a connection; if no reply is received from the
|
|
peer, pppd will then just wait passively for a valid LCP packet from
|
|
the peer, instead of exiting, as it would without this option.
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="18"><I><local_IP_address></I><B>:</B><I><remote_IP_address></I>
|
|
|
|
<DD>
|
|
Set the local and/or remote interface IP addresses. Either one may be
|
|
omitted. The IP addresses can be specified with a host name or in
|
|
decimal dot notation (e.g. 150.234.56.78). The default local
|
|
address is the (first) IP address of the system (unless the
|
|
<I>noipdefault</I>
|
|
option is given). The remote address will be obtained from the peer
|
|
if not specified in any option. Thus, in simple cases, this option is
|
|
not required. If a local and/or remote IP address is specified with
|
|
this option, pppd
|
|
will not accept a different value from the peer in the IPCP
|
|
negotiation, unless the <I>ipcp-accept-local</I> and/or
|
|
<I>ipcp-accept-remote</I> options are given, respectively.
|
|
<DT id="19"><B>+ipv6</B>
|
|
|
|
<DD>
|
|
Enable the IPv6CP and IPv6 protocols.
|
|
<DT id="20"><B>ipv6 </B><I><local_interface_identifier></I>,<I><remote_interface_identifier></I>
|
|
|
|
<DD>
|
|
Set the local and/or remote 64-bit interface identifier. Either one may be
|
|
omitted. The identifier must be specified in standard ASCII notation of
|
|
IPv6 addresses (e.g. ::dead:beef). If the
|
|
<I>ipv6cp-use-ipaddr</I>
|
|
option is given, the local identifier is the local IPv4 address (see above).
|
|
On systems which supports a unique persistent id, such as EUI-48 derived
|
|
from the Ethernet MAC address, <I>ipv6cp-use-persistent</I> option can be
|
|
used to replace the <I>ipv6 <local>,<remote></I> option. Otherwise the
|
|
identifier is randomized.
|
|
<DT id="21"><B>active-filter </B><I>filter-expression</I>
|
|
|
|
<DD>
|
|
Specifies a packet filter to be applied to data packets to determine
|
|
which packets are to be regarded as link activity, and therefore reset
|
|
the idle timer, or cause the link to be brought up in demand-dialling
|
|
mode. This option is useful in conjunction with the
|
|
<B>idle</B> option if there are packets being sent or received
|
|
regularly over the link (for example, routing information packets)
|
|
which would otherwise prevent the link from ever appearing to be idle.
|
|
The <I>filter-expression</I> syntax is as described for <A HREF="/cgi-bin/man/man2html?1+tcpdump">tcpdump</A>(1),
|
|
except that qualifiers which are inappropriate for a PPP link, such as
|
|
<B>ether</B> and <B>arp</B>, are not permitted. Generally the filter
|
|
expression should be enclosed in single-quotes to prevent whitespace
|
|
in the expression from being interpreted by the shell. This option
|
|
is currently only available under Linux, and requires that the kernel
|
|
was configured to include PPP filtering support (CONFIG_PPP_FILTER).
|
|
Note that it
|
|
is possible to apply different constraints to incoming and outgoing
|
|
packets using the <B>inbound</B> and <B>outbound</B> qualifiers.
|
|
<DT id="22"><B>allow-ip </B><I>address(es)</I>
|
|
|
|
<DD>
|
|
Allow peers to use the given IP address or subnet without
|
|
authenticating themselves. The parameter is parsed as for each
|
|
element of the list of allowed IP addresses in the secrets files (see
|
|
the AUTHENTICATION section below).
|
|
<DT id="23"><B>allow-number </B><I>number</I>
|
|
|
|
<DD>
|
|
Allow peers to connect from the given telephone number. A trailing
|
|
`*' character will match all numbers beginning with the leading part.
|
|
<DT id="24"><B>bsdcomp </B><I>nr,nt</I>
|
|
|
|
<DD>
|
|
Request that the peer compress packets that it sends, using the
|
|
BSD-Compress scheme, with a maximum code size of <I>nr</I> bits, and
|
|
agree to compress packets sent to the peer with a maximum code size of
|
|
<I>nt</I> bits. If <I>nt</I> is not specified, it defaults to the value
|
|
given for <I>nr</I>. Values in the range 9 to 15 may be used for
|
|
<I>nr</I> and <I>nt</I>; larger values give better compression but
|
|
consume more kernel memory for compression dictionaries.
|
|
Alternatively, a value of 0 for <I>nr</I> or <I>nt</I> disables
|
|
compression in the corresponding direction. Use <I>nobsdcomp</I> or
|
|
<I>bsdcomp 0</I> to disable BSD-Compress compression entirely.
|
|
<DT id="25"><B>ca </B><I>ca-file</I>
|
|
|
|
<DD>
|
|
(EAP-TLS) Use the file <I>ca-file</I> as the X.509 Certificate Authority
|
|
(CA) file (in PEM format), needed for setting up an EAP-TLS connection.
|
|
This option is used on the client-side in conjunction with the <B>cert</B>
|
|
and <B>key</B> options.
|
|
<DT id="26"><B>cdtrcts</B>
|
|
|
|
<DD>
|
|
Use a non-standard hardware flow control (i.e. DTR/CTS) to control
|
|
the flow of data on the serial port. If neither the <I>crtscts</I>,
|
|
the <I>nocrtscts</I>, the <I>cdtrcts</I> nor the <I>nocdtrcts</I>
|
|
option is given, the hardware flow control setting for the serial
|
|
port is left unchanged.
|
|
Some serial ports (such as Macintosh serial ports) lack a true
|
|
RTS output. Such serial ports use this mode to implement true
|
|
bi-directional flow control. The sacrifice is that this flow
|
|
control mode does not permit using DTR as a modem control line.
|
|
<DT id="27"><B>cert </B><I>certfile</I>
|
|
|
|
<DD>
|
|
(EAP-TLS) Use the file <I>certfile</I> as the X.509 certificate (in PEM
|
|
format), needed for setting up an EAP-TLS connection. This option is
|
|
used on the client-side in conjunction with the <B>ca</B> and
|
|
<B>key</B> options.
|
|
<DT id="28"><B>chap-interval </B><I>n</I>
|
|
|
|
<DD>
|
|
If this option is given, pppd will rechallenge the peer every <I>n</I>
|
|
seconds.
|
|
<DT id="29"><B>chap-max-challenge </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of CHAP challenge transmissions to <I>n</I>
|
|
(default 10).
|
|
<DT id="30"><B>chap-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the CHAP restart interval (retransmission timeout for challenges)
|
|
to <I>n</I> seconds (default 3).
|
|
<DT id="31"><B>child-timeout </B><I>n</I>
|
|
|
|
<DD>
|
|
When exiting, wait for up to <I>n</I> seconds for any child processes
|
|
(such as the command specified with the <B>pty</B> command) to exit
|
|
before exiting. At the end of the timeout, pppd will send a SIGTERM
|
|
signal to any remaining child processes and exit. A value of 0 means
|
|
no timeout, that is, pppd will wait until all child processes have
|
|
exited.
|
|
<DT id="32"><B>connect-delay </B><I>n</I>
|
|
|
|
<DD>
|
|
Wait for up to <I>n</I> milliseconds after the connect script finishes for
|
|
a valid PPP packet from the peer. At the end of this time, or when a
|
|
valid PPP packet is received from the peer, pppd will commence
|
|
negotiation by sending its first LCP packet. The default value is
|
|
1000 (1 second). This wait period only applies if the <B>connect</B>
|
|
or <B>pty</B> option is used.
|
|
<DT id="33"><B>crl </B><I>filename</I>
|
|
|
|
<DD>
|
|
(EAP-TLS) Use the file <I>filename</I> as the Certificate Revocation List
|
|
to check for the validity of the peer's certificate. This option is not
|
|
mandatory for setting up an EAP-TLS connection. Also see the <B>crl-dir</B>
|
|
option.
|
|
<DT id="34"><B>crl-dir </B><I>directory</I>
|
|
|
|
<DD>
|
|
(EAP-TLS) Use the directory <I>directory</I> to scan for CRL files in
|
|
has format ($hash.r0) to check for the validity of the peer's certificate.
|
|
This option is not mandatory for setting up an EAP-TLS connection.
|
|
Also see the <B>crl</B> option.
|
|
<DT id="35"><B>debug</B>
|
|
|
|
<DD>
|
|
Enables connection debugging facilities.
|
|
If this option is given, pppd will log the contents of all
|
|
control packets sent or received in a readable form. The packets are
|
|
logged through syslog with facility <I>daemon</I> and level
|
|
<I>debug</I>. This information can be directed to a file by setting up
|
|
/etc/syslog.conf appropriately (see <A HREF="/cgi-bin/man/man2html?5+syslog.conf">syslog.conf</A>(5)).
|
|
<DT id="36"><B>default-asyncmap</B>
|
|
|
|
<DD>
|
|
Disable asyncmap negotiation, forcing all control characters to be
|
|
escaped for both the transmit and the receive direction.
|
|
<DT id="37"><B>default-mru</B>
|
|
|
|
<DD>
|
|
Disable MRU [Maximum Receive Unit] negotiation. With this option,
|
|
pppd will use the default MRU value of 1500 bytes for both the
|
|
transmit and receive direction.
|
|
<DT id="38"><B>deflate </B><I>nr,nt</I>
|
|
|
|
<DD>
|
|
Request that the peer compress packets that it sends, using the
|
|
Deflate scheme, with a maximum window size of <I>2**nr</I> bytes, and
|
|
agree to compress packets sent to the peer with a maximum window size
|
|
of <I>2**nt</I> bytes. If <I>nt</I> is not specified, it defaults to
|
|
the value given for <I>nr</I>. Values in the range 9 to 15 may be used
|
|
for <I>nr</I> and <I>nt</I>; larger values give better compression but
|
|
consume more kernel memory for compression dictionaries.
|
|
Alternatively, a value of 0 for <I>nr</I> or <I>nt</I> disables
|
|
compression in the corresponding direction. Use <I>nodeflate</I> or
|
|
<I>deflate 0</I> to disable Deflate compression entirely. (Note: pppd
|
|
requests Deflate compression in preference to BSD-Compress if the peer
|
|
can do either.)
|
|
<DT id="39"><B>demand</B>
|
|
|
|
<DD>
|
|
Initiate the link only on demand, i.e. when data traffic is present.
|
|
With this option, the remote IP address may be specified by the user
|
|
on the command line or in an options file, or if not, pppd will use
|
|
an arbitrary address in the 10.x.x.x range. Pppd will initially
|
|
configure the interface and enable it for IP traffic without
|
|
connecting to the peer. When traffic is available, pppd will
|
|
connect to the peer and perform negotiation, authentication, etc.
|
|
When this is completed, pppd will commence passing data packets
|
|
(i.e., IP packets) across the link.
|
|
<P>
|
|
The <I>demand</I> option implies the <I>persist</I> option. If this
|
|
behaviour is not desired, use the <I>nopersist</I> option after the
|
|
<I>demand</I> option. The <I>idle</I> and <I>holdoff</I>
|
|
options are also useful in conjunction with the <I>demand</I> option.
|
|
<DT id="40"><B>domain </B><I>d</I>
|
|
|
|
<DD>
|
|
Append the domain name <I>d</I> to the local host name for authentication
|
|
purposes. For example, if gethostname() returns the name porsche, but
|
|
the fully qualified domain name is porsche.Quotron.COM, you could
|
|
specify <I>domain Quotron.COM</I>. Pppd would then use the name
|
|
<I>porsche.Quotron.COM</I> for looking up secrets in the secrets file,
|
|
and as the default name to send to the peer when authenticating itself
|
|
to the peer. This option is privileged.
|
|
<DT id="41"><B>dryrun</B>
|
|
|
|
<DD>
|
|
With the <B>dryrun</B> option, pppd will print out all the option
|
|
values which have been set and then exit, after parsing the command
|
|
line and options files and checking the option values, but before
|
|
initiating the link. The option values are logged at level info, and
|
|
also printed to standard output unless the device on standard output
|
|
is the device that pppd would be using to communicate with the peer.
|
|
<DT id="42"><B>dump</B>
|
|
|
|
<DD>
|
|
With the <B>dump</B> option, pppd will print out all the option values
|
|
which have been set. This option is like the <B>dryrun</B> option
|
|
except that pppd proceeds as normal rather than exiting.
|
|
<DT id="43"><B>enable-session</B>
|
|
|
|
<DD>
|
|
Enables session accounting via PAM or wtwp/wtmpx, as appropriate.
|
|
When PAM is enabled, the PAM "account" and "session" module stacks
|
|
determine behavior, and are enabled for all PPP authentication
|
|
protocols. When PAM is disabled, wtmp/wtmpx entries are recorded
|
|
regardless of whether the peer name identifies a valid user on the
|
|
local system, making peers visible in the <A HREF="/cgi-bin/man/man2html?1+last">last</A>(1) log. This feature
|
|
is automatically enabled when the pppd <B>login</B> option is used.
|
|
Session accounting is disabled by default.
|
|
<DT id="44"><B>endpoint </B><I><epdisc></I>
|
|
|
|
<DD>
|
|
Sets the endpoint discriminator sent by the local machine to the peer
|
|
during multilink negotiation to <I><epdisc></I>. The default is to use
|
|
the MAC address of the first ethernet interface on the system, if any,
|
|
otherwise the IPv4 address corresponding to the hostname, if any,
|
|
provided it is not in the multicast or locally-assigned IP address
|
|
ranges, or the localhost address. The endpoint discriminator can be
|
|
the string <B>null</B> or of the form <I>type</I>:<I>value</I>, where
|
|
type is a decimal number or one of the strings <B>local</B>, <B>IP</B>,
|
|
<B>MAC</B>, <B>magic</B>, or <B>phone</B>. The value is an IP address in
|
|
dotted-decimal notation for the <B>IP</B> type, or a string of bytes in
|
|
hexadecimal, separated by periods or colons for the other types. For
|
|
the MAC type, the value may also be the name of an ethernet or similar
|
|
network interface. This option is currently only available under
|
|
Linux.
|
|
<DT id="45"><B>eap-interval </B><I>n</I>
|
|
|
|
<DD>
|
|
If this option is given and pppd authenticates the peer with EAP
|
|
(i.e., is the server), pppd will restart EAP authentication every
|
|
<I>n</I> seconds. For EAP SRP-SHA1, see also the <B>srp-interval</B>
|
|
option, which enables lightweight rechallenge.
|
|
<DT id="46"><B>eap-max-rreq </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of EAP Requests to which pppd will respond (as
|
|
a client) without hearing EAP Success or Failure. (Default is 20.)
|
|
<DT id="47"><B>eap-max-sreq </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of EAP Requests that pppd will issue (as a
|
|
server) while attempting authentication. (Default is 10.)
|
|
<DT id="48"><B>eap-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the retransmit timeout for EAP Requests when acting as a server
|
|
(authenticator). (Default is 3 seconds.)
|
|
<DT id="49"><B>eap-timeout </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum time to wait for the peer to send an EAP Request when
|
|
acting as a client (authenticatee). (Default is 20 seconds.)
|
|
<DT id="50"><B>hide-password</B>
|
|
|
|
<DD>
|
|
When logging the contents of PAP packets, this option causes pppd to
|
|
exclude the password string from the log. This is the default.
|
|
<DT id="51"><B>holdoff </B><I>n</I>
|
|
|
|
<DD>
|
|
Specifies how many seconds to wait before re-initiating the link after
|
|
it terminates. This option only has any effect if the <I>persist</I>
|
|
or <I>demand</I> option is used. The holdoff period is not applied if
|
|
the link was terminated because it was idle.
|
|
<DT id="52"><B>idle </B><I>n</I>
|
|
|
|
<DD>
|
|
Specifies that pppd should disconnect if the link is idle for <I>n</I>
|
|
seconds. The link is idle when no data packets (i.e. IP packets) are
|
|
being sent or received. Note: it is not advisable to use this option
|
|
with the <I>persist</I> option without the <I>demand</I> option.
|
|
If the <B>active-filter</B>
|
|
option is given, data packets which are rejected by the specified
|
|
activity filter also count as the link being idle.
|
|
<DT id="53"><B>ipcp-accept-local</B>
|
|
|
|
<DD>
|
|
With this option, pppd will accept the peer's idea of our local IP
|
|
address, even if the local IP address was specified in an option.
|
|
<DT id="54"><B>ipcp-accept-remote</B>
|
|
|
|
<DD>
|
|
With this option, pppd will accept the peer's idea of its (remote) IP
|
|
address, even if the remote IP address was specified in an option.
|
|
<DT id="55"><B>ipcp-max-configure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPCP configure-request transmissions to
|
|
<I>n</I> (default 10).
|
|
<DT id="56"><B>ipcp-max-failure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPCP configure-NAKs returned before starting
|
|
to send configure-Rejects instead to <I>n</I> (default 10).
|
|
<DT id="57"><B>ipcp-max-terminate </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPCP terminate-request transmissions to
|
|
<I>n</I> (default 3).
|
|
<DT id="58"><B>ipcp-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the IPCP restart interval (retransmission timeout) to <I>n</I>
|
|
seconds (default 3).
|
|
<DT id="59"><B>ipparam </B><I>string</I>
|
|
|
|
<DD>
|
|
Provides an extra parameter to the ip-up, ip-pre-up and ip-down
|
|
scripts. If this
|
|
option is given, the <I>string</I> supplied is given as the 6th
|
|
parameter to those scripts.
|
|
<DT id="60"><B>ipv6cp-accept-local</B>
|
|
|
|
<DD>
|
|
With this option, pppd will accept the peer's idea of our local IPv6
|
|
interface identifier, even if the local IPv6 interface identifier
|
|
was specified in an option.
|
|
<DT id="61"><B>ipv6cp-accept-remote</B>
|
|
|
|
<DD>
|
|
With this option, pppd will accept the peer's idea of its (remote)
|
|
IPv6 interface identifier, even if the remote IPv6 interface
|
|
identifier was specified in an option.
|
|
<DT id="62"><B>ipv6cp-max-configure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPv6CP configure-request transmissions to
|
|
<I>n</I> (default 10).
|
|
<DT id="63"><B>ipv6cp-max-failure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPv6CP configure-NAKs returned before starting
|
|
to send configure-Rejects instead to <I>n</I> (default 10).
|
|
<DT id="64"><B>ipv6cp-max-terminate </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPv6CP terminate-request transmissions to
|
|
<I>n</I> (default 3).
|
|
<DT id="65"><B>ipv6cp-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the IPv6CP restart interval (retransmission timeout) to <I>n</I>
|
|
seconds (default 3).
|
|
<DT id="66"><B>ipx</B>
|
|
|
|
<DD>
|
|
Enable the IPXCP and IPX protocols. This option is presently only
|
|
supported under Linux, and only if your kernel has been configured to
|
|
include IPX support.
|
|
<DT id="67"><B>ipx-network </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the IPX network number in the IPXCP configure request frame to
|
|
<I>n</I>, a hexadecimal number (without a leading 0x). There is no
|
|
valid default. If this option is not specified, the network number is
|
|
obtained from the peer. If the peer does not have the network number,
|
|
the IPX protocol will not be started.
|
|
<DT id="68"><B>ipx-node </B><I>n</I><B>:</B><I>m</I>
|
|
|
|
<DD>
|
|
Set the IPX node numbers. The two node numbers are separated from each
|
|
other with a colon character. The first number <I>n</I> is the local
|
|
node number. The second number <I>m</I> is the peer's node number. Each
|
|
node number is a hexadecimal number, at most 10 digits long. The node
|
|
numbers on the ipx-network must be unique. There is no valid
|
|
default. If this option is not specified then the node numbers are
|
|
obtained from the peer.
|
|
<DT id="69"><B>ipx-router-name </B><I><string></I>
|
|
|
|
<DD>
|
|
Set the name of the router. This is a string and is sent to the peer
|
|
as information data.
|
|
<DT id="70"><B>ipx-routing </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the routing protocol to be received by this option. More than one
|
|
instance of <I>ipx-routing</I> may be specified. The '<I>none</I>'
|
|
option (0) may be specified as the only instance of ipx-routing. The
|
|
values may be <I>0</I> for <I>NONE</I>, <I>2</I> for <I>RIP/SAP</I>, and
|
|
<I>4</I> for <I>NLSP</I>.
|
|
<DT id="71"><B>ipxcp-accept-local</B>
|
|
|
|
<DD>
|
|
Accept the peer's NAK for the node number specified in the ipx-node
|
|
option. If a node number was specified, and non-zero, the default is
|
|
to insist that the value be used. If you include this option then you
|
|
will permit the peer to override the entry of the node number.
|
|
<DT id="72"><B>ipxcp-accept-network</B>
|
|
|
|
<DD>
|
|
Accept the peer's NAK for the network number specified in the
|
|
ipx-network option. If a network number was specified, and non-zero, the
|
|
default is to insist that the value be used. If you include this
|
|
option then you will permit the peer to override the entry of the node
|
|
number.
|
|
<DT id="73"><B>ipxcp-accept-remote</B>
|
|
|
|
<DD>
|
|
Use the peer's network number specified in the configure request
|
|
frame. If a node number was specified for the peer and this option was
|
|
not specified, the peer will be forced to use the value which you have
|
|
specified.
|
|
<DT id="74"><B>ipxcp-max-configure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPXCP configure request frames which the
|
|
system will send to <I>n</I>. The default is 10.
|
|
<DT id="75"><B>ipxcp-max-failure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPXCP NAK frames which the local system will
|
|
send before it rejects the options. The default value is 3.
|
|
<DT id="76"><B>ipxcp-max-terminate </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of IPXCP terminate request frames before the
|
|
local system considers that the peer is not listening to them. The
|
|
default value is 3.
|
|
<DT id="77"><B>kdebug </B><I>n</I>
|
|
|
|
<DD>
|
|
Enable debugging code in the kernel-level PPP driver. The argument
|
|
values depend on the specific kernel driver, but in general a value of
|
|
1 will enable general kernel debug messages. (Note that these
|
|
messages are usually only useful for debugging the kernel driver
|
|
itself.) For the Linux 2.2.x kernel driver, the value is a sum of
|
|
bits: 1 to
|
|
enable general debug messages, 2 to request that the contents of
|
|
received packets be printed, and 4 to request that the contents of
|
|
transmitted packets be printed. On most systems, messages printed by
|
|
the kernel are logged by <A HREF="/cgi-bin/man/man2html?1+syslog">syslog</A>(1) to a file as directed in the
|
|
/etc/syslog.conf configuration file.
|
|
<DT id="78"><B>key </B><I>keyfile</I>
|
|
|
|
<DD>
|
|
(EAP-TLS) Use the file <I>keyfile</I> as the private key file (in PEM
|
|
format), needed for setting up an EAP-TLS connection. This option is
|
|
used on the client-side in conjunction with the <B>ca</B> and
|
|
<B>cert</B> options.
|
|
<DT id="79"><B>ktune</B>
|
|
|
|
<DD>
|
|
Enables pppd to alter kernel settings as appropriate. Under Linux,
|
|
pppd will enable IP forwarding (i.e. set /proc/sys/net/ipv4/ip_forward
|
|
to 1) if the <I>proxyarp</I> option is used, and will enable the
|
|
dynamic IP address option (i.e. set /proc/sys/net/ipv4/ip_dynaddr to
|
|
1) in demand mode if the local address changes.
|
|
<DT id="80"><B>lcp-echo-adaptive</B>
|
|
|
|
<DD>
|
|
If this option is used with the <I>lcp-echo-failure</I> option then
|
|
pppd will send LCP echo-request frames only if no traffic was received
|
|
from the peer since the last echo-request was sent.
|
|
<DT id="81"><B>lcp-echo-failure </B><I>n</I>
|
|
|
|
<DD>
|
|
If this option is given, pppd will presume the peer to be dead
|
|
if <I>n</I> LCP echo-requests are sent without receiving a valid LCP
|
|
echo-reply. If this happens, pppd will terminate the
|
|
connection. Use of this option requires a non-zero value for the
|
|
<I>lcp-echo-interval</I> parameter. This option can be used to enable
|
|
pppd to terminate after the physical connection has been broken
|
|
(e.g., the modem has hung up) in situations where no hardware modem
|
|
control lines are available.
|
|
<DT id="82"><B>lcp-echo-interval </B><I>n</I>
|
|
|
|
<DD>
|
|
If this option is given, pppd will send an LCP echo-request frame to
|
|
the peer every <I>n</I> seconds. Normally the peer should respond to
|
|
the echo-request by sending an echo-reply. This option can be used
|
|
with the <I>lcp-echo-failure</I> option to detect that the peer is no
|
|
longer connected.
|
|
<DT id="83"><B>lcp-max-configure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of LCP configure-request transmissions to
|
|
<I>n</I> (default 10).
|
|
<DT id="84"><B>lcp-max-failure </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of LCP configure-NAKs returned before starting
|
|
to send configure-Rejects instead to <I>n</I> (default 10).
|
|
<DT id="85"><B>lcp-max-terminate </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of LCP terminate-request transmissions to
|
|
<I>n</I> (default 3).
|
|
<DT id="86"><B>lcp-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the LCP restart interval (retransmission timeout) to <I>n</I>
|
|
seconds (default 3).
|
|
<DT id="87"><B>linkname </B><I>name</I>
|
|
|
|
<DD>
|
|
Sets the logical name of the link to <I>name</I>. Pppd will create a
|
|
file named <B>ppp-</B><I>name</I><B>.pid</B> in /var/run (or /etc/ppp on some
|
|
systems) containing its process ID. This can be useful in determining
|
|
which instance of pppd is responsible for the link to a given peer
|
|
system. This is a privileged option.
|
|
<DT id="88"><B>local</B>
|
|
|
|
<DD>
|
|
Don't use the modem control lines. With this option, pppd will ignore
|
|
the state of the CD (Carrier Detect) signal from the modem and will
|
|
not change the state of the DTR (Data Terminal Ready) signal. This is
|
|
the opposite of the <B>modem</B> option.
|
|
<DT id="89"><B>logfd </B><I>n</I>
|
|
|
|
<DD>
|
|
Send log messages to file descriptor <I>n</I>. Pppd will send log
|
|
messages to at most one file or file descriptor (as well as sending
|
|
the log messages to syslog), so this option and the <B>logfile</B>
|
|
option are mutually exclusive. The default is for pppd to send log
|
|
messages to stdout (file descriptor 1), unless the serial port is
|
|
already open on stdout.
|
|
<DT id="90"><B>logfile </B><I>filename</I>
|
|
|
|
<DD>
|
|
Append log messages to the file <I>filename</I> (as well as sending the
|
|
log messages to syslog). The file is opened with the privileges of
|
|
the user who invoked pppd, in append mode.
|
|
<DT id="91"><B>login</B>
|
|
|
|
<DD>
|
|
Use the system password database for authenticating the peer using
|
|
PAP, and record the user in the system wtmp file. Note that the peer
|
|
must have an entry in the /etc/ppp/pap-secrets file as well as the
|
|
system password database to be allowed access. See also the
|
|
<B>enable-session</B> option.
|
|
<DT id="92"><B>master_detach</B>
|
|
|
|
<DD>
|
|
If multilink is enabled and this pppd process is the multilink bundle
|
|
master, and the link controlled by this pppd process terminates, this
|
|
pppd process continues to run in order to maintain the bundle. If the
|
|
<B>master_detach</B> option has been given, pppd will detach from its
|
|
controlling terminal in this situation, even if the <B>nodetach</B>
|
|
option has been given.
|
|
<DT id="93"><B>maxconnect </B><I>n</I>
|
|
|
|
<DD>
|
|
Terminate the connection when it has been available for network
|
|
traffic for <I>n</I> seconds (i.e. <I>n</I> seconds after the first
|
|
network control protocol comes up).
|
|
<DT id="94"><B>maxfail </B><I>n</I>
|
|
|
|
<DD>
|
|
Terminate after <I>n</I> consecutive failed connection attempts. A
|
|
value of 0 means no limit. The default value is 10.
|
|
<DT id="95"><B>modem</B>
|
|
|
|
<DD>
|
|
Use the modem control lines. This option is the default. With this
|
|
option, pppd will wait for the CD (Carrier Detect) signal from the
|
|
modem to be asserted when opening the serial device (unless a connect
|
|
script is specified), and it will drop the DTR (Data Terminal Ready)
|
|
signal briefly when the connection is terminated and before executing
|
|
the connect script. On Ultrix, this option implies hardware flow
|
|
control, as for the <I>crtscts</I> option. This is the opposite of the
|
|
<B>local</B> option.
|
|
<DT id="96"><B>mp</B>
|
|
|
|
<DD>
|
|
Enables the use of PPP multilink; this is an alias for the `multilink'
|
|
option. This option is currently only available under Linux.
|
|
<DT id="97"><B>mppe-stateful</B>
|
|
|
|
<DD>
|
|
Allow MPPE to use stateful mode. Stateless mode is still attempted first.
|
|
The default is to disallow stateful mode.
|
|
<DT id="98"><B>mpshortseq</B>
|
|
|
|
<DD>
|
|
Enables the use of short (12-bit) sequence numbers in multilink
|
|
headers, as opposed to 24-bit sequence numbers. This option is only
|
|
available under Linux, and only has any effect if multilink is
|
|
enabled (see the multilink option).
|
|
<DT id="99"><B>mrru </B><I>n</I>
|
|
|
|
<DD>
|
|
Sets the Maximum Reconstructed Receive Unit to <I>n</I>. The MRRU is
|
|
the maximum size for a received packet on a multilink bundle, and is
|
|
analogous to the MRU for the individual links. This option is
|
|
currently only available under Linux, and only has any effect if
|
|
multilink is enabled (see the multilink option).
|
|
<DT id="100"><B>ms-dns </B><I><addr></I>
|
|
|
|
<DD>
|
|
If pppd is acting as a server for Microsoft Windows clients, this
|
|
option allows pppd to supply one or two DNS (Domain Name Server)
|
|
addresses to the clients. The first instance of this option specifies
|
|
the primary DNS address; the second instance (if given) specifies the
|
|
secondary DNS address. (This option was present in some older
|
|
versions of pppd under the name <B>dns-addr</B>.)
|
|
<DT id="101"><B>ms-wins </B><I><addr></I>
|
|
|
|
<DD>
|
|
If pppd is acting as a server for Microsoft Windows or "Samba"
|
|
clients, this option allows pppd to supply one or two WINS (Windows
|
|
Internet Name Services) server addresses to the clients. The first
|
|
instance of this option specifies the primary WINS address; the second
|
|
instance (if given) specifies the secondary WINS address.
|
|
<DT id="102"><B>multilink</B>
|
|
|
|
<DD>
|
|
Enables the use of the PPP multilink protocol. If the peer also
|
|
supports multilink, then this link can become part of a bundle between
|
|
the local system and the peer. If there is an existing bundle to the
|
|
peer, pppd will join this link to that bundle, otherwise pppd will
|
|
create a new bundle. See the MULTILINK section below. This option is
|
|
currently only available under Linux.
|
|
<DT id="103"><B>name </B><I>name</I>
|
|
|
|
<DD>
|
|
Set the name of the local system for authentication purposes to
|
|
<I>name</I>. This is a privileged option. With this option, pppd will
|
|
use lines in the secrets files which have <I>name</I> as the second
|
|
field when looking for a secret to use in authenticating the peer. In
|
|
addition, unless overridden with the <I>user</I> option, <I>name</I>
|
|
will be used as the name to send to the peer when authenticating the
|
|
local system to the peer. (Note that pppd does not append the domain
|
|
name to <I>name</I>.)
|
|
<DT id="104"><B>noaccomp</B>
|
|
|
|
<DD>
|
|
Disable Address/Control compression in both directions (send and
|
|
receive).
|
|
<DT id="105"><B>need-peer-eap</B>
|
|
|
|
<DD>
|
|
(EAP-TLS) Require the peer to verify our authentication credentials.
|
|
<DT id="106"><B>noauth</B>
|
|
|
|
<DD>
|
|
Do not require the peer to authenticate itself. This option is
|
|
privileged.
|
|
<DT id="107"><B>nobsdcomp</B>
|
|
|
|
<DD>
|
|
Disables BSD-Compress compression; <B>pppd</B> will not request or
|
|
agree to compress packets using the BSD-Compress scheme.
|
|
<DT id="108"><B>noccp</B>
|
|
|
|
<DD>
|
|
Disable CCP (Compression Control Protocol) negotiation. This option
|
|
should only be required if the peer is buggy and gets confused by
|
|
requests from pppd for CCP negotiation.
|
|
<DT id="109"><B>nocrtscts</B>
|
|
|
|
<DD>
|
|
Disable hardware flow control (i.e. RTS/CTS) on the serial port.
|
|
If neither the <I>crtscts</I> nor the <I>nocrtscts</I> nor the
|
|
<I>cdtrcts</I> nor the <I>nocdtrcts</I> option is given, the hardware
|
|
flow control setting for the serial port is left unchanged.
|
|
<DT id="110"><B>nocdtrcts</B>
|
|
|
|
<DD>
|
|
This option is a synonym for <I>nocrtscts</I>. Either of these options will
|
|
disable both forms of hardware flow control.
|
|
<DT id="111"><B>nodefaultroute</B>
|
|
|
|
<DD>
|
|
Disable the <I>defaultroute</I> option. The system administrator who
|
|
wishes to prevent users from adding a default route with pppd
|
|
can do so by placing this option in the /etc/ppp/options file.
|
|
<DT id="112"><B>noreplacedefaultroute</B>
|
|
|
|
<DD>
|
|
Disable the <I>replacedefaultroute</I> option. The system administrator who
|
|
wishes to prevent users from replacing a default route with pppd
|
|
can do so by placing this option in the /etc/ppp/options file.
|
|
<DT id="113"><B>nodeflate</B>
|
|
|
|
<DD>
|
|
Disables Deflate compression; pppd will not request or agree to
|
|
compress packets using the Deflate scheme.
|
|
<DT id="114"><B>nodetach</B>
|
|
|
|
<DD>
|
|
Don't detach from the controlling terminal. Without this option, if a
|
|
serial device other than the terminal on the standard input is
|
|
specified, pppd will fork to become a background process.
|
|
<DT id="115"><B>noendpoint</B>
|
|
|
|
<DD>
|
|
Disables pppd from sending an endpoint discriminator to the peer or
|
|
accepting one from the peer (see the MULTILINK section below). This
|
|
option should only be required if the peer is buggy.
|
|
<DT id="116"><B>noip</B>
|
|
|
|
<DD>
|
|
Disable IPCP negotiation and IP communication. This option should
|
|
only be required if the peer is buggy and gets confused by requests
|
|
from pppd for IPCP negotiation.
|
|
<DT id="117"><B>noipv6</B>
|
|
|
|
<DD>
|
|
Disable IPv6CP negotiation and IPv6 communication. This option should
|
|
only be required if the peer is buggy and gets confused by requests
|
|
from pppd for IPv6CP negotiation.
|
|
<DT id="118"><B>noipdefault</B>
|
|
|
|
<DD>
|
|
Disables the default behaviour when no local IP address is specified,
|
|
which is to determine (if possible) the local IP address from the
|
|
hostname. With this option, the peer will have to supply the local IP
|
|
address during IPCP negotiation (unless it specified explicitly on the
|
|
command line or in an options file).
|
|
<DT id="119"><B>noipx</B>
|
|
|
|
<DD>
|
|
Disable the IPXCP and IPX protocols. This option should only be
|
|
required if the peer is buggy and gets confused by requests from pppd
|
|
for IPXCP negotiation.
|
|
<DT id="120"><B>noktune</B>
|
|
|
|
<DD>
|
|
Opposite of the <I>ktune</I> option; disables pppd from changing system
|
|
settings.
|
|
<DT id="121"><B>nolock</B>
|
|
|
|
<DD>
|
|
Opposite of the <I>lock</I> option; specifies that pppd should not
|
|
create a UUCP-style lock file for the serial device. This option is
|
|
privileged.
|
|
<DT id="122"><B>nolog</B>
|
|
|
|
<DD>
|
|
Do not send log messages to a file or file descriptor. This option
|
|
cancels the <B>logfd</B> and <B>logfile</B> options.
|
|
<DT id="123"><B>nomagic</B>
|
|
|
|
<DD>
|
|
Disable magic number negotiation. With this option, pppd cannot
|
|
detect a looped-back line. This option should only be needed if the
|
|
peer is buggy.
|
|
<DT id="124"><B>nomp</B>
|
|
|
|
<DD>
|
|
Disables the use of PPP multilink. This option is currently only
|
|
available under Linux.
|
|
<DT id="125"><B>nomppe</B>
|
|
|
|
<DD>
|
|
Disables MPPE (Microsoft Point to Point Encryption). This is the default.
|
|
<DT id="126"><B>nomppe-40</B>
|
|
|
|
<DD>
|
|
Disable 40-bit encryption with MPPE.
|
|
<DT id="127"><B>nomppe-128</B>
|
|
|
|
<DD>
|
|
Disable 128-bit encryption with MPPE.
|
|
<DT id="128"><B>nomppe-stateful</B>
|
|
|
|
<DD>
|
|
Disable MPPE stateful mode. This is the default.
|
|
<DT id="129"><B>nompshortseq</B>
|
|
|
|
<DD>
|
|
Disables the use of short (12-bit) sequence numbers in the PPP
|
|
multilink protocol, forcing the use of 24-bit sequence numbers. This
|
|
option is currently only available under Linux, and only has any
|
|
effect if multilink is enabled.
|
|
<DT id="130"><B>nomultilink</B>
|
|
|
|
<DD>
|
|
Disables the use of PPP multilink. This option is currently only
|
|
available under Linux.
|
|
<DT id="131"><B>nopcomp</B>
|
|
|
|
<DD>
|
|
Disable protocol field compression negotiation in both the receive and
|
|
the transmit direction.
|
|
<DT id="132"><B>nopersist</B>
|
|
|
|
<DD>
|
|
Exit once a connection has been made and terminated. This is the
|
|
default unless the <I>persist</I> or <I>demand</I> option has been
|
|
specified.
|
|
<DT id="133"><B>nopredictor1</B>
|
|
|
|
<DD>
|
|
Do not accept or agree to Predictor-1 compression.
|
|
<DT id="134"><B>noproxyarp</B>
|
|
|
|
<DD>
|
|
Disable the <I>proxyarp</I> option. The system administrator who
|
|
wishes to prevent users from creating proxy ARP entries with pppd can
|
|
do so by placing this option in the /etc/ppp/options file.
|
|
<DT id="135"><B>noremoteip</B>
|
|
|
|
<DD>
|
|
Allow pppd to operate without having an IP address for the peer. This
|
|
option is only available under Linux. Normally, pppd will request the
|
|
peer's IP address, and if the peer does not supply it, pppd will use
|
|
an arbitrary address in the 10.x.x.x subnet.
|
|
With this option, if the peer does
|
|
not supply its IP address, pppd will not ask the peer for it, and will
|
|
not set the destination address of the ppp interface. In this
|
|
situation, the ppp interface can be used for routing by creating
|
|
device routes, but the peer itself cannot be addressed directly for IP
|
|
traffic.
|
|
<DT id="136"><B>notty</B>
|
|
|
|
<DD>
|
|
Normally, pppd requires a terminal device. With this option, pppd
|
|
will allocate itself a pseudo-tty master/slave pair and use the slave
|
|
as its terminal device. Pppd will create a child process to act as a
|
|
`character shunt' to transfer characters between the pseudo-tty master
|
|
and its standard input and output. Thus pppd will transmit characters
|
|
on its standard output and receive characters on its standard input
|
|
even if they are not terminal devices. This option increases the
|
|
latency and CPU overhead of transferring data over the ppp interface
|
|
as all of the characters sent and received must flow through the
|
|
character shunt process. An explicit device name may not be given if
|
|
this option is used.
|
|
<DT id="137"><B>novj</B>
|
|
|
|
<DD>
|
|
Disable Van Jacobson style TCP/IP header compression in both the
|
|
transmit and the receive direction.
|
|
<DT id="138"><B>novjccomp</B>
|
|
|
|
<DD>
|
|
Disable the connection-ID compression option in Van Jacobson style
|
|
TCP/IP header compression. With this option, pppd will not omit the
|
|
connection-ID byte from Van Jacobson compressed TCP/IP headers, nor
|
|
ask the peer to do so.
|
|
<DT id="139"><B>papcrypt</B>
|
|
|
|
<DD>
|
|
Indicates that all secrets in the /etc/ppp/pap-secrets file which are
|
|
used for checking the identity of the peer are encrypted, and thus
|
|
pppd should not accept a password which, before encryption, is
|
|
identical to the secret from the /etc/ppp/pap-secrets file.
|
|
<DT id="140"><B>pap-max-authreq </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum number of PAP authenticate-request transmissions to
|
|
<I>n</I> (default 10).
|
|
<DT id="141"><B>pap-restart </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the PAP restart interval (retransmission timeout) to <I>n</I>
|
|
seconds (default 3).
|
|
<DT id="142"><B>pap-timeout </B><I>n</I>
|
|
|
|
<DD>
|
|
Set the maximum time that pppd will wait for the peer to authenticate
|
|
itself with PAP to <I>n</I> seconds (0 means no limit).
|
|
<DT id="143"><B>pass-filter </B><I>filter-expression</I>
|
|
|
|
<DD>
|
|
Specifies a packet filter to applied to data packets being sent or
|
|
received to determine which packets should be allowed to pass.
|
|
Packets which are rejected by the filter are silently discarded. This
|
|
option can be used to prevent specific network daemons (such as
|
|
routed) using up link bandwidth, or to provide a very basic firewall
|
|
capability.
|
|
The <I>filter-expression</I> syntax is as described for <A HREF="/cgi-bin/man/man2html?1+tcpdump">tcpdump</A>(1),
|
|
except that qualifiers which are inappropriate for a PPP link, such as
|
|
<B>ether</B> and <B>arp</B>, are not permitted. Generally the filter
|
|
expression should be enclosed in single-quotes to prevent whitespace
|
|
in the expression from being interpreted by the shell. Note that it
|
|
is possible to apply different constraints to incoming and outgoing
|
|
packets using the <B>inbound</B> and <B>outbound</B> qualifiers. This
|
|
option is currently only available under Linux, and requires that the
|
|
kernel was configured to include PPP filtering support (CONFIG_PPP_FILTER).
|
|
<DT id="144"><B>password </B><I>password-string</I>
|
|
|
|
<DD>
|
|
Specifies the password to use for authenticating to the peer. Use
|
|
of this option is discouraged, as the password is likely to be visible
|
|
to other users on the system (for example, by using <A HREF="/cgi-bin/man/man2html?1+ps">ps</A>(1)).
|
|
<DT id="145"><B>persist</B>
|
|
|
|
<DD>
|
|
Do not exit after a connection is terminated; instead try to reopen
|
|
the connection. The <B>maxfail</B> option still has an effect on
|
|
persistent connections.
|
|
<DT id="146"><B>plugin </B><I>filename</I>
|
|
|
|
<DD>
|
|
Load the shared library object file <I>filename</I> as a plugin. This
|
|
is a privileged option. If <I>filename</I> does not contain a slash
|
|
(/), pppd will look in the <B>/usr/lib/pppd/</B><I>version</I> directory
|
|
for the plugin, where
|
|
<I>version</I> is the version number of pppd (for example, 2.4.2).
|
|
<DT id="147"><B>predictor1</B>
|
|
|
|
<DD>
|
|
Request that the peer compress frames that it sends using Predictor-1
|
|
compression, and agree to compress transmitted frames with Predictor-1
|
|
if requested. This option has no effect unless the kernel driver
|
|
supports Predictor-1 compression.
|
|
<DT id="148"><B>privgroup </B><I>group-name</I>
|
|
|
|
<DD>
|
|
Allows members of group <I>group-name</I> to use privileged options.
|
|
This is a privileged option. Use of this option requires care as
|
|
there is no guarantee that members of <I>group-name</I> cannot use pppd
|
|
to become root themselves. Consider it equivalent to putting the
|
|
members of <I>group-name</I> in the kmem or disk group.
|
|
<DT id="149"><B>proxyarp</B>
|
|
|
|
<DD>
|
|
Add an entry to this system's ARP [Address Resolution Protocol] table
|
|
with the IP address of the peer and the Ethernet address of this
|
|
system. This will have the effect of making the peer appear to other
|
|
systems to be on the local ethernet.
|
|
<DT id="150"><B>pty </B><I>script</I>
|
|
|
|
<DD>
|
|
Specifies that the command <I>script</I> is to be used to communicate
|
|
rather than a specific terminal device. Pppd will allocate itself a
|
|
pseudo-tty master/slave pair and use the slave as its terminal
|
|
device. The <I>script</I> will be run in a child process with the
|
|
pseudo-tty master as its standard input and output. An explicit
|
|
device name may not be given if this option is used. (Note: if the
|
|
<I>record</I> option is used in conjunction with the <I>pty</I> option,
|
|
the child process will have pipes on its standard input and output.)
|
|
<DT id="151"><B>receive-all</B>
|
|
|
|
<DD>
|
|
With this option, pppd will accept all control characters from the
|
|
peer, including those marked in the receive asyncmap. Without this
|
|
option, pppd will discard those characters as specified in RFC1662.
|
|
This option should only be needed if the peer is buggy.
|
|
<DT id="152"><B>record </B><I>filename</I>
|
|
|
|
<DD>
|
|
Specifies that pppd should record all characters sent and received to
|
|
a file named <I>filename</I>. This file is opened in append mode,
|
|
using the user's user-ID and permissions. This option is implemented
|
|
using a pseudo-tty and a process to transfer characters between the
|
|
pseudo-tty and the real serial device, so it will increase the latency
|
|
and CPU overhead of transferring data over the ppp interface. The
|
|
characters are stored in a tagged format with timestamps, which can be
|
|
displayed in readable form using the <A HREF="/cgi-bin/man/man2html?8+pppdump">pppdump</A>(8) program.
|
|
<DT id="153"><B>remotename </B><I>name</I>
|
|
|
|
<DD>
|
|
Set the assumed name of the remote system for authentication purposes
|
|
to <I>name</I>.
|
|
<DT id="154"><B>remotenumber </B><I>number</I>
|
|
|
|
<DD>
|
|
Set the assumed telephone number of the remote system for authentication
|
|
purposes to <I>number</I>.
|
|
<DT id="155"><B>refuse-chap</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not agree to authenticate itself to the
|
|
peer using CHAP.
|
|
<DT id="156"><B>refuse-mschap</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not agree to authenticate itself to the
|
|
peer using MS-CHAP.
|
|
<DT id="157"><B>refuse-mschap-v2</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not agree to authenticate itself to the
|
|
peer using MS-CHAPv2.
|
|
<DT id="158"><B>refuse-eap</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not agree to authenticate itself to the
|
|
peer using EAP.
|
|
<DT id="159"><B>refuse-pap</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not agree to authenticate itself to the
|
|
peer using PAP.
|
|
<DT id="160"><B>require-chap</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself using CHAP [Challenge
|
|
Handshake Authentication Protocol] authentication.
|
|
<DT id="161"><B>require-mppe</B>
|
|
|
|
<DD>
|
|
Require the use of MPPE (Microsoft Point to Point Encryption). This
|
|
option disables all other compression types. This option enables
|
|
both 40-bit and 128-bit encryption. In order for MPPE to successfully
|
|
come up, you must have authenticated with either MS-CHAP or MS-CHAPv2.
|
|
This option is presently only supported under Linux, and only if your
|
|
kernel has been configured to include MPPE support.
|
|
<DT id="162"><B>require-mppe-40</B>
|
|
|
|
<DD>
|
|
Require the use of MPPE, with 40-bit encryption.
|
|
<DT id="163"><B>require-mppe-128</B>
|
|
|
|
<DD>
|
|
Require the use of MPPE, with 128-bit encryption.
|
|
<DT id="164"><B>require-mschap</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself using MS-CHAP [Microsoft Challenge
|
|
Handshake Authentication Protocol] authentication.
|
|
<DT id="165"><B>require-mschap-v2</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself using MS-CHAPv2 [Microsoft Challenge
|
|
Handshake Authentication Protocol, Version 2] authentication.
|
|
<DT id="166"><B>require-eap</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself using EAP [Extensible
|
|
Authentication Protocol] authentication.
|
|
<DT id="167"><B>require-pap</B>
|
|
|
|
<DD>
|
|
Require the peer to authenticate itself using PAP [Password
|
|
Authentication Protocol] authentication.
|
|
<DT id="168"><B>set </B><I>name</I>=<I>value</I>
|
|
|
|
<DD>
|
|
Set an environment variable for scripts that are invoked by pppd.
|
|
When set by a privileged source, the variable specified by <I>name</I>
|
|
cannot be changed by options contained in an unprivileged source. See
|
|
also the <I>unset</I> option and the environment described in
|
|
<I>SCRIPTS</I>.
|
|
<DT id="169"><B>show-password</B>
|
|
|
|
<DD>
|
|
When logging the contents of PAP packets, this option causes pppd to
|
|
show the password string in the log message.
|
|
<DT id="170"><B>silent</B>
|
|
|
|
<DD>
|
|
With this option, pppd will not transmit LCP packets to initiate a
|
|
connection until a valid LCP packet is received from the peer (as for
|
|
the `passive' option with ancient versions of pppd).
|
|
<DT id="171"><B>srp-interval </B><I>n</I>
|
|
|
|
<DD>
|
|
If this parameter is given and pppd uses EAP SRP-SHA1 to authenticate
|
|
the peer (i.e., is the server), then pppd will use the optional
|
|
lightweight SRP rechallenge mechanism at intervals of <I>n</I>
|
|
seconds. This option is faster than <B>eap-interval</B>
|
|
reauthentication because it uses a hash-based mechanism and does not
|
|
derive a new session key.
|
|
<DT id="172"><B>srp-pn-secret </B><I>string</I>
|
|
|
|
<DD>
|
|
Set the long-term pseudonym-generating secret for the server. This
|
|
value is optional and if set, needs to be known at the server
|
|
(authenticator) side only, and should be different for each server (or
|
|
poll of identical servers). It is used along with the current date to
|
|
generate a key to encrypt and decrypt the client's identity contained
|
|
in the pseudonym.
|
|
<DT id="173"><B>srp-use-pseudonym</B>
|
|
|
|
<DD>
|
|
When operating as an EAP SRP-SHA1 client, attempt to use the pseudonym
|
|
stored in ~/.ppp_pseudonym first as the identity, and save in this
|
|
file any pseudonym offered by the peer during authentication.
|
|
<DT id="174"><B>sync</B>
|
|
|
|
<DD>
|
|
Use synchronous HDLC serial encoding instead of asynchronous.
|
|
The device used by pppd with this option must have sync support.
|
|
Currently supports Microgate SyncLink adapters
|
|
under Linux and FreeBSD 2.2.8 and later.
|
|
<DT id="175"><B>unit </B><I>num</I>
|
|
|
|
<DD>
|
|
Sets the ppp unit number (for a ppp0 or ppp1 etc interface name) for outbound
|
|
connections. If the unit is already in use a dynamically allocated number will
|
|
be used.
|
|
<DT id="176"><B>ifname </B><I>string</I>
|
|
|
|
<DD>
|
|
Set the ppp interface name for outbound connections. If the interface name is
|
|
already in use, or if the name cannot be used for any other reason, pppd will
|
|
terminate.
|
|
<DT id="177"><B>unset </B><I>name</I>
|
|
|
|
<DD>
|
|
Remove a variable from the environment variable for scripts that are
|
|
invoked by pppd. When specified by a privileged source, the variable
|
|
<I>name</I> cannot be set by options contained in an unprivileged
|
|
source. See also the <I>set</I> option and the environment described
|
|
in <I>SCRIPTS</I>.
|
|
<DT id="178"><B>updetach</B>
|
|
|
|
<DD>
|
|
With this option, pppd will detach from its controlling terminal once
|
|
it has successfully established the ppp connection (to the point where
|
|
the first network control protocol, usually the IP control protocol,
|
|
has come up).
|
|
<DT id="179"><B>usehostname</B>
|
|
|
|
<DD>
|
|
Enforce the use of the hostname (with domain name appended, if given)
|
|
as the name of the local system for authentication purposes (overrides
|
|
the <I>name</I> option). This option is not normally needed since the
|
|
<I>name</I> option is privileged.
|
|
<DT id="180"><B>usepeerdns</B>
|
|
|
|
<DD>
|
|
Ask the peer for up to 2 DNS server addresses. The addresses supplied
|
|
by the peer (if any) are passed to the /etc/ppp/ip-up script in the
|
|
environment variables DNS1 and DNS2, and the environment variable
|
|
USEPEERDNS will be set to 1. In addition, pppd will create an
|
|
/etc/ppp/resolv.conf file containing one or two nameserver lines with
|
|
the address(es) supplied by the peer.
|
|
<DT id="181"><B>user </B><I>name</I>
|
|
|
|
<DD>
|
|
Sets the name used for authenticating the local system to the peer to
|
|
<I>name</I>.
|
|
<DT id="182"><B>vj-max-slots </B><I>n</I>
|
|
|
|
<DD>
|
|
Sets the number of connection slots to be used by the Van Jacobson
|
|
TCP/IP header compression and decompression code to <I>n</I>, which
|
|
must be between 2 and 16 (inclusive).
|
|
<DT id="183"><B>welcome </B><I>script</I>
|
|
|
|
<DD>
|
|
Run the executable or shell command specified by <I>script</I> before
|
|
initiating PPP negotiation, after the connect script (if any) has
|
|
completed. A value for this option from a privileged source cannot be
|
|
overridden by a non-privileged user.
|
|
<DT id="184"><B>xonxoff</B>
|
|
|
|
<DD>
|
|
Use software flow control (i.e. XON/XOFF) to control the flow of data on
|
|
the serial port.
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H2>OPTIONS FILES</H2>
|
|
|
|
Options can be taken from files as well as the command line. Pppd
|
|
reads options from the files /etc/ppp/options, ~/.ppprc and
|
|
/etc/ppp/options.<I>ttyname</I> (in that order) before processing the
|
|
options on the command line. (In fact, the command-line options are
|
|
scanned to find the terminal name before the options.<I>ttyname</I>
|
|
file is read.) In forming the name of the options.<I>ttyname</I> file,
|
|
the initial /dev/ is removed from the terminal name, and any remaining
|
|
/ characters are replaced with dots.
|
|
<P>
|
|
|
|
An options file is parsed into a series of words, delimited by
|
|
whitespace. Whitespace can be included in a word by enclosing the
|
|
word in double-quotes ("). A backslash (\) quotes the following character.
|
|
A hash (#) starts a comment, which continues until the end of the
|
|
line. There is no restriction on using the <I>file</I> or <I>call</I>
|
|
options within an options file.
|
|
<A NAME="lbAH"> </A>
|
|
<H2>SECURITY</H2>
|
|
|
|
<I>pppd</I>
|
|
|
|
provides system administrators with sufficient access control that PPP
|
|
access to a server machine can be provided to legitimate users without
|
|
fear of compromising the security of the server or the network it's
|
|
on. This control is provided through restrictions on which IP
|
|
addresses the peer may use, based on its authenticated identity (if
|
|
any), and through restrictions on which options a non-privileged user
|
|
may use. Several of pppd's options are privileged, in particular
|
|
those which permit potentially insecure configurations; these options
|
|
are only accepted in files which are under the control of the system
|
|
administrator, or if pppd is being run by root.
|
|
<P>
|
|
|
|
The default behaviour of pppd is to allow an unauthenticated peer to
|
|
use a given IP address only if the system does not already have a
|
|
route to that IP address. For example, a system with a
|
|
permanent connection to the wider internet will normally have a
|
|
default route, and thus all peers will have to authenticate themselves
|
|
in order to set up a connection. On such a system, the <I>auth</I>
|
|
option is the default. On the other hand, a system where the
|
|
PPP link is the only connection to the internet will not normally have
|
|
a default route, so the peer will be able to use almost any IP address
|
|
without authenticating itself.
|
|
<P>
|
|
|
|
As indicated above, some security-sensitive options are privileged,
|
|
which means that they may not be used by an ordinary non-privileged
|
|
user running a setuid-root pppd, either on the command line, in the
|
|
user's ~/.ppprc file, or in an options file read using the <I>file</I>
|
|
option. Privileged options may be used in /etc/ppp/options file or in
|
|
an options file read using the <I>call</I> option. If pppd is being
|
|
run by the root user, privileged options can be used without
|
|
restriction.
|
|
<P>
|
|
|
|
When opening the device, pppd uses either the invoking user's user ID
|
|
or the root UID (that is, 0), depending on whether the device name was
|
|
specified by the user or the system administrator. If the device name
|
|
comes from a privileged source, that is, /etc/ppp/options or an
|
|
options file read using the <I>call</I> option, pppd uses full root
|
|
privileges when opening the device. Thus, by creating an appropriate
|
|
file under /etc/ppp/peers, the system administrator can allow users to
|
|
establish a ppp connection via a device which they would not normally
|
|
have permission to access. Otherwise pppd uses the invoking user's
|
|
real UID when opening the device.
|
|
<A NAME="lbAI"> </A>
|
|
<H2>AUTHENTICATION</H2>
|
|
|
|
Authentication is the process whereby one peer convinces the other of
|
|
its identity. This involves the first peer sending its name to the
|
|
other, together with some kind of secret information which could only
|
|
come from the genuine authorized user of that name. In such an
|
|
exchange, we will call the first peer the "client" and the other the
|
|
"server". The client has a name by which it identifies itself to the
|
|
server, and the server also has a name by which it identifies itself
|
|
to the client. Generally the genuine client shares some secret (or
|
|
password) with the server, and authenticates itself by proving that it
|
|
knows that secret. Very often, the names used for authentication
|
|
correspond to the internet hostnames of the peers, but this is not
|
|
essential.
|
|
<P>
|
|
|
|
At present, pppd supports three authentication protocols: the Password
|
|
Authentication Protocol (PAP), Challenge Handshake Authentication
|
|
Protocol (CHAP), and Extensible Authentication Protocol (EAP). PAP
|
|
involves the client sending its name and a cleartext password to the
|
|
server to authenticate itself. In contrast, the server initiates the
|
|
CHAP authentication exchange by sending a challenge to the client (the
|
|
challenge packet includes the server's name). The client must respond
|
|
with a response which includes its name plus a hash value derived from
|
|
the shared secret and the challenge, in order to prove that it knows
|
|
the secret. EAP supports CHAP-style authentication, and also includes
|
|
the SRP-SHA1 mechanism, which is resistant to dictionary-based attacks
|
|
and does not require a cleartext password on the server side.
|
|
<P>
|
|
|
|
The PPP protocol, being symmetrical, allows both peers to require the
|
|
other to authenticate itself. In that case, two separate and
|
|
independent authentication exchanges will occur. The two exchanges
|
|
could use different authentication protocols, and in principle,
|
|
different names could be used in the two exchanges.
|
|
<P>
|
|
|
|
The default behaviour of pppd is to agree to authenticate if
|
|
requested, and to not require authentication from the peer. However,
|
|
pppd will not agree to authenticate itself with a particular protocol
|
|
if it has no secrets which could be used to do so.
|
|
<P>
|
|
|
|
Pppd stores secrets for use in authentication in secrets
|
|
files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP,
|
|
MS-CHAP, MS-CHAPv2, and EAP MD5-Challenge, and /etc/ppp/srp-secrets
|
|
for EAP SRP-SHA1).
|
|
All secrets files have the same format. The secrets files can
|
|
contain secrets for pppd to use in authenticating itself to other
|
|
systems, as well as secrets for pppd to use when authenticating other
|
|
systems to itself.
|
|
<P>
|
|
|
|
Each line in a secrets file contains one secret. A given secret is
|
|
specific to a particular combination of client and server - it can
|
|
only be used by that client to authenticate itself to that server.
|
|
Thus each line in a secrets file has at least 3 fields: the name of
|
|
the client, the name of the server, and the secret. These fields may
|
|
be followed by a list of the IP addresses that the specified client
|
|
may use when connecting to the specified server.
|
|
<P>
|
|
|
|
A secrets file is parsed into words as for a options file, so the
|
|
client name, server name and secrets fields must each be one word,
|
|
with any embedded spaces or other special characters quoted or
|
|
escaped. Note that case is significant in the client and server names
|
|
and in the secret.
|
|
<P>
|
|
|
|
If the secret starts with an `@', what follows is assumed to be the
|
|
name of a file from which to read the secret. A "*" as the client or
|
|
server name matches any name. When selecting a secret, pppd takes the
|
|
best match, i.e. the match with the fewest wildcards.
|
|
<P>
|
|
|
|
Any following words on the same line are taken to be a list of
|
|
acceptable IP addresses for that client. If there are only 3 words on
|
|
the line, or if the first word is "-", then all IP addresses are
|
|
disallowed. To allow any address, use "*". A word starting with "!"
|
|
indicates that the specified address is <I>not</I> acceptable. An
|
|
address may be followed by "/" and a number <I>n</I>, to indicate a
|
|
whole subnet, i.e. all addresses which have the same value in the most
|
|
significant <I>n</I> bits. In this form, the address may be followed
|
|
by a plus sign ("+") to indicate that one address from the subnet is
|
|
authorized, based on the ppp network interface unit number in use.
|
|
In this case, the host part of the address will be set to the unit
|
|
number plus one.
|
|
<P>
|
|
|
|
Thus a secrets file contains both secrets for use in authenticating
|
|
other hosts, plus secrets which we use for authenticating ourselves to
|
|
others. When pppd is authenticating the peer (checking the peer's
|
|
identity), it chooses a secret with the peer's name in the first
|
|
field and the name of the local system in the second field. The
|
|
name of the local system defaults to the hostname, with the domain
|
|
name appended if the <I>domain</I> option is used. This default can be
|
|
overridden with the <I>name</I> option, except when the
|
|
<I>usehostname</I> option is used. (For EAP SRP-SHA1, see the
|
|
<A HREF="/cgi-bin/man/man2html?8+srp-entry">srp-entry</A>(8) utility for generating proper validator entries to be
|
|
used in the "secret" field.)
|
|
<P>
|
|
|
|
When pppd is choosing a secret to use in authenticating itself to the
|
|
peer, it first determines what name it is going to use to identify
|
|
itself to the peer. This name can be specified by the user with the
|
|
<I>user</I> option. If this option is not used, the name defaults to
|
|
the name of the local system, determined as described in the previous
|
|
paragraph. Then pppd looks for a secret with this name in the first
|
|
field and the peer's name in the second field. Pppd will know the
|
|
name of the peer if CHAP or EAP authentication is being used, because
|
|
the peer will have sent it in the challenge packet. However, if PAP
|
|
is being used, pppd will have to determine the peer's name from the
|
|
options specified by the user. The user can specify the peer's name
|
|
directly with the <I>remotename</I> option. Otherwise, if the remote
|
|
IP address was specified by a name (rather than in numeric form), that
|
|
name will be used as the peer's name. Failing that, pppd will use the
|
|
null string as the peer's name.
|
|
<P>
|
|
|
|
When authenticating the peer with PAP, the supplied password is first
|
|
compared with the secret from the secrets file. If the password
|
|
doesn't match the secret, the password is encrypted using crypt() and
|
|
checked against the secret again. Thus secrets for authenticating the
|
|
peer can be stored in encrypted form if desired. If the
|
|
<I>papcrypt</I> option is given, the first (unencrypted) comparison is
|
|
omitted, for better security.
|
|
<P>
|
|
|
|
Furthermore, if the <I>login</I> option was specified, the username and
|
|
password are also checked against the system password database. Thus,
|
|
the system administrator can set up the pap-secrets file to allow PPP
|
|
access only to certain users, and to restrict the set of IP addresses
|
|
that each user can use. Typically, when using the <I>login</I> option,
|
|
the secret in /etc/ppp/pap-secrets would be "", which will match any
|
|
password supplied by the peer. This avoids the need to have the same
|
|
secret in two places.
|
|
<P>
|
|
|
|
Authentication must be satisfactorily completed before IPCP (or any
|
|
other Network Control Protocol) can be started. If the peer is
|
|
required to authenticate itself, and fails to do so, pppd will
|
|
terminated the link (by closing LCP). If IPCP negotiates an
|
|
unacceptable IP address for the remote host, IPCP will be closed. IP
|
|
packets can only be sent or received when IPCP is open.
|
|
<P>
|
|
|
|
In some cases it is desirable to allow some hosts which can't
|
|
authenticate themselves to connect and use one of a restricted set of
|
|
IP addresses, even when the local host generally requires
|
|
authentication. If the peer refuses to authenticate itself when
|
|
requested, pppd takes that as equivalent to authenticating with PAP
|
|
using the empty string for the username and password. Thus, by adding
|
|
a line to the pap-secrets file which specifies the empty string for
|
|
the client and password, it is possible to allow restricted access to
|
|
hosts which refuse to authenticate themselves.
|
|
<A NAME="lbAJ"> </A>
|
|
<H2>ROUTING</H2>
|
|
|
|
<P>
|
|
|
|
When IPCP negotiation is completed successfully, pppd will inform the
|
|
kernel of the local and remote IP addresses for the ppp interface.
|
|
This is sufficient to create a host route to the remote end of the
|
|
link, which will enable the peers to exchange IP packets.
|
|
Communication with other machines generally requires further
|
|
modification to routing tables and/or ARP (Address Resolution
|
|
Protocol) tables. In most cases the <I>defaultroute</I> and/or
|
|
<I>proxyarp</I> options are sufficient for this, but in some cases
|
|
further intervention is required. The /etc/ppp/ip-up script can be
|
|
used for this.
|
|
<P>
|
|
|
|
Sometimes it is desirable to add a default route through the remote
|
|
host, as in the case of a machine whose only connection to the
|
|
Internet is through the ppp interface. The <I>defaultroute</I> option
|
|
causes pppd to create such a default route when IPCP comes up, and
|
|
delete it when the link is terminated.
|
|
<P>
|
|
|
|
In some cases it is desirable to use proxy ARP, for example on a
|
|
server machine connected to a LAN, in order to allow other hosts to
|
|
communicate with the remote host. The <I>proxyarp</I> option causes
|
|
pppd to look for a network interface on the same subnet as the remote
|
|
host (an interface supporting broadcast and ARP, which is up and not a
|
|
point-to-point or loopback interface). If found, pppd creates a
|
|
permanent, published ARP entry with the IP address of the remote host
|
|
and the hardware address of the network interface found.
|
|
<P>
|
|
|
|
When the <I>demand</I> option is used, the interface IP addresses have
|
|
already been set at the point when IPCP comes up. If pppd has not
|
|
been able to negotiate the same addresses that it used to configure
|
|
the interface (for example when the peer is an ISP that uses dynamic
|
|
IP address assignment), pppd has to change the interface IP addresses
|
|
to the negotiated addresses. This may disrupt existing connections,
|
|
and the use of demand dialling with peers that do dynamic IP address
|
|
assignment is not recommended.
|
|
<A NAME="lbAK"> </A>
|
|
<H2>MULTILINK</H2>
|
|
|
|
Multilink PPP provides the capability to combine two or more PPP links
|
|
between a pair of machines into a single `bundle', which appears as a
|
|
single virtual PPP link which has the combined bandwidth of the
|
|
individual links. Currently, multilink PPP is only supported under
|
|
Linux.
|
|
<P>
|
|
|
|
Pppd detects that the link it is controlling is connected to the same
|
|
peer as another link using the peer's endpoint discriminator and the
|
|
authenticated identity of the peer (if it authenticates itself). The
|
|
endpoint discriminator is a block of data which is hopefully unique
|
|
for each peer. Several types of data can be used, including
|
|
locally-assigned strings of bytes, IP addresses, MAC addresses,
|
|
randomly strings of bytes, or E-164 phone numbers. The endpoint
|
|
discriminator sent to the peer by pppd can be set using the endpoint
|
|
option.
|
|
<P>
|
|
|
|
In some circumstances the peer may send no endpoint discriminator or a
|
|
non-unique value. The bundle option adds an extra string which is
|
|
added to the peer's endpoint discriminator and authenticated identity
|
|
when matching up links to be joined together in a bundle. The bundle
|
|
option can also be used to allow the establishment of multiple bundles
|
|
between the local system and the peer. Pppd uses a TDB database in
|
|
/var/run/pppd2.tdb to match up links.
|
|
<P>
|
|
|
|
Assuming that multilink is enabled and the peer is willing to
|
|
negotiate multilink, then when pppd is invoked to bring up the first
|
|
link to the peer, it will detect that no other link is connected to
|
|
the peer and create a new bundle, that is, another ppp network
|
|
interface unit. When another pppd is invoked to bring up another link
|
|
to the peer, it will detect the existing bundle and join its link to
|
|
it.
|
|
<P>
|
|
|
|
If the first link terminates (for example, because of a hangup or a
|
|
received LCP terminate-request) the bundle is not destroyed unless
|
|
there are no other links remaining in the bundle. Rather than
|
|
exiting, the first pppd keeps running after its link terminates, until
|
|
all the links in the bundle have terminated. If the first pppd
|
|
receives a SIGTERM or SIGINT signal, it will destroy the bundle and
|
|
send a SIGHUP to the pppd processes for each of the links in the
|
|
bundle. If the first pppd receives a SIGHUP signal, it will terminate
|
|
its link but not the bundle.
|
|
<P>
|
|
|
|
Note: demand mode is not currently supported with multilink.
|
|
<A NAME="lbAL"> </A>
|
|
<H2>EXAMPLES</H2>
|
|
|
|
<P>
|
|
|
|
The following examples assume that the /etc/ppp/options file contains
|
|
the <I>auth</I> option (as in the default /etc/ppp/options file in the
|
|
ppp distribution).
|
|
<P>
|
|
|
|
Probably the most common use of pppd is to dial out to an ISP. This
|
|
can be done with a command such as
|
|
<DL COMPACT>
|
|
<DT id="185"><DD>
|
|
pppd call isp
|
|
</DL>
|
|
<P>
|
|
|
|
where the /etc/ppp/peers/isp file is set up by the system
|
|
administrator to contain something like this:
|
|
<DL COMPACT>
|
|
<DT id="186"><DD>
|
|
ttyS0 19200 crtscts
|
|
<BR>
|
|
|
|
connect '/usr/sbin/chat -v -f /etc/ppp/chat-isp'
|
|
<BR>
|
|
|
|
noauth
|
|
</DL>
|
|
<P>
|
|
|
|
In this example, we are using chat to dial the ISP's modem and go
|
|
through any logon sequence required. The /etc/ppp/chat-isp file
|
|
contains the script used by chat; it could for example contain
|
|
something like this:
|
|
<DL COMPACT>
|
|
<DT id="187"><DD>
|
|
ABORT "NO CARRIER"
|
|
<BR>
|
|
|
|
ABORT "NO DIALTONE"
|
|
<BR>
|
|
|
|
ABORT "ERROR"
|
|
<BR>
|
|
|
|
ABORT "NO ANSWER"
|
|
<BR>
|
|
|
|
ABORT "BUSY"
|
|
<BR>
|
|
|
|
ABORT "Username/Password Incorrect"
|
|
<BR>
|
|
|
|
"" "at"
|
|
<BR>
|
|
|
|
OK "at&d0&c1"
|
|
<BR>
|
|
|
|
OK "atdt2468135"
|
|
<BR>
|
|
|
|
"name:" "^Umyuserid"
|
|
<BR>
|
|
|
|
"word:" "\qmypassword"
|
|
<BR>
|
|
|
|
"ispts" "\q^Uppp"
|
|
<BR>
|
|
|
|
"~-^Uppp-~"
|
|
</DL>
|
|
<P>
|
|
|
|
See the <A HREF="/cgi-bin/man/man2html?8+chat">chat</A>(8) man page for details of chat scripts.
|
|
<P>
|
|
|
|
Pppd can also be used to provide a dial-in ppp service for users. If
|
|
the users already have login accounts, the simplest way to set up the
|
|
ppp service is to let the users log in to their accounts and run pppd
|
|
(installed setuid-root) with a command such as
|
|
<DL COMPACT>
|
|
<DT id="188"><DD>
|
|
pppd proxyarp
|
|
</DL>
|
|
<P>
|
|
|
|
To allow a user to use the PPP facilities, you need to allocate an IP
|
|
address for that user's machine and create an entry in
|
|
/etc/ppp/pap-secrets, /etc/ppp/chap-secrets, or /etc/ppp/srp-secrets
|
|
(depending on which authentication method the PPP implementation on
|
|
the user's machine supports), so that the user's machine can
|
|
authenticate itself. For example, if Joe has a machine called
|
|
"joespc" that is to be allowed to dial in to the machine called
|
|
"server" and use the IP address joespc.my.net, you would add an entry
|
|
like this to /etc/ppp/pap-secrets or /etc/ppp/chap-secrets:
|
|
<DL COMPACT>
|
|
<DT id="189"><DD>
|
|
joespc<TT> </TT>server<TT> </TT>"joe's secret"<TT> </TT>joespc.my.net<BR>
|
|
</DL>
|
|
<P>
|
|
|
|
(See <A HREF="/cgi-bin/man/man2html?8+srp-entry">srp-entry</A>(8) for a means to generate the server's entry when
|
|
SRP-SHA1 is in use.)
|
|
Alternatively, you can create a username called (for example) "ppp",
|
|
whose login shell is pppd and whose home directory is /etc/ppp.
|
|
Options to be used when pppd is run this way can be put in
|
|
/etc/ppp/.ppprc.
|
|
<P>
|
|
|
|
If your serial connection is any more complicated than a piece of
|
|
wire, you may need to arrange for some control characters to be
|
|
escaped. In particular, it is often useful to escape XON (^Q) and
|
|
XOFF (^S), using <I>asyncmap a0000</I>. If the path includes a telnet,
|
|
you probably should escape ^] as well (<I>asyncmap 200a0000</I>). If
|
|
the path includes an rlogin, you will need to use the <I>escape ff</I>
|
|
option on the end which is running the rlogin client, since many
|
|
rlogin implementations are not transparent; they will remove the
|
|
sequence [0xff, 0xff, 0x73, 0x73, followed by any 8 bytes] from the
|
|
stream.
|
|
<A NAME="lbAM"> </A>
|
|
<H2>DIAGNOSTICS</H2>
|
|
|
|
<P>
|
|
|
|
Messages are sent to the syslog daemon using facility LOG_DAEMON.
|
|
(This can be overridden by recompiling pppd with the macro
|
|
LOG_PPP defined as the desired facility.) See the <A HREF="/cgi-bin/man/man2html?8+syslog">syslog</A>(8)
|
|
documentation for details of where the syslog daemon will write the
|
|
messages. On most systems, the syslog daemon uses the
|
|
/etc/syslog.conf file to specify the destination(s) for syslog
|
|
messages. You may need to edit that file to suit.
|
|
<P>
|
|
|
|
The <I>debug</I> option causes the contents of all control packets sent
|
|
or received to be logged, that is, all LCP, PAP, CHAP, EAP, or IPCP packets.
|
|
This can be useful if the PPP negotiation does not succeed or if
|
|
authentication fails.
|
|
If debugging is enabled at compile time, the <I>debug</I> option also
|
|
causes other debugging messages to be logged.
|
|
<P>
|
|
|
|
Debugging can also be enabled or disabled by sending a SIGUSR1 signal
|
|
to the pppd process. This signal acts as a toggle.
|
|
<A NAME="lbAN"> </A>
|
|
<H2>EXIT STATUS</H2>
|
|
|
|
The exit status of pppd is set to indicate whether any error was
|
|
detected, or the reason for the link being terminated. The values
|
|
used are:
|
|
<DL COMPACT>
|
|
<DT id="190"><B>0</B>
|
|
|
|
<DD>
|
|
Pppd has detached, or otherwise the connection was successfully
|
|
established and terminated at the peer's request.
|
|
<DT id="191"><B>1</B>
|
|
|
|
<DD>
|
|
An immediately fatal error of some kind occurred, such as an essential
|
|
system call failing, or running out of virtual memory.
|
|
<DT id="192"><B>2</B>
|
|
|
|
<DD>
|
|
An error was detected in processing the options given, such as two
|
|
mutually exclusive options being used.
|
|
<DT id="193"><B>3</B>
|
|
|
|
<DD>
|
|
Pppd is not setuid-root and the invoking user is not root.
|
|
<DT id="194"><B>4</B>
|
|
|
|
<DD>
|
|
The kernel does not support PPP, for example, the PPP kernel driver is
|
|
not included or cannot be loaded.
|
|
<DT id="195"><B>5</B>
|
|
|
|
<DD>
|
|
Pppd terminated because it was sent a SIGINT, SIGTERM or SIGHUP
|
|
signal.
|
|
<DT id="196"><B>6</B>
|
|
|
|
<DD>
|
|
The serial port could not be locked.
|
|
<DT id="197"><B>7</B>
|
|
|
|
<DD>
|
|
The serial port could not be opened.
|
|
<DT id="198"><B>8</B>
|
|
|
|
<DD>
|
|
The connect script failed (returned a non-zero exit status).
|
|
<DT id="199"><B>9</B>
|
|
|
|
<DD>
|
|
The command specified as the argument to the <I>pty</I> option could
|
|
not be run.
|
|
<DT id="200"><B>10</B>
|
|
|
|
<DD>
|
|
The PPP negotiation failed, that is, it didn't reach the point where
|
|
at least one network protocol (e.g. IP) was running.
|
|
<DT id="201"><B>11</B>
|
|
|
|
<DD>
|
|
The peer system failed (or refused) to authenticate itself.
|
|
<DT id="202"><B>12</B>
|
|
|
|
<DD>
|
|
The link was established successfully and terminated because it was
|
|
idle.
|
|
<DT id="203"><B>13</B>
|
|
|
|
<DD>
|
|
The link was established successfully and terminated because the
|
|
connect time limit was reached.
|
|
<DT id="204"><B>14</B>
|
|
|
|
<DD>
|
|
Callback was negotiated and an incoming call should arrive shortly.
|
|
<DT id="205"><B>15</B>
|
|
|
|
<DD>
|
|
The link was terminated because the peer is not responding to echo
|
|
requests.
|
|
<DT id="206"><B>16</B>
|
|
|
|
<DD>
|
|
The link was terminated by the modem hanging up.
|
|
<DT id="207"><B>17</B>
|
|
|
|
<DD>
|
|
The PPP negotiation failed because serial loopback was detected.
|
|
<DT id="208"><B>18</B>
|
|
|
|
<DD>
|
|
The init script failed (returned a non-zero exit status).
|
|
<DT id="209"><B>19</B>
|
|
|
|
<DD>
|
|
We failed to authenticate ourselves to the peer.
|
|
</DL>
|
|
<A NAME="lbAO"> </A>
|
|
<H2>SCRIPTS</H2>
|
|
|
|
Pppd invokes scripts at various stages in its processing which can be
|
|
used to perform site-specific ancillary processing. These scripts are
|
|
usually shell scripts, but could be executable code files instead.
|
|
Pppd does not wait for the scripts to finish (except for the ip-pre-up
|
|
script). The scripts are
|
|
executed as root (with the real and effective user-id set to 0), so
|
|
that they can do things such as update routing tables or run
|
|
privileged daemons. Be careful that the contents of these scripts do
|
|
not compromise your system's security. Pppd runs the scripts with
|
|
standard input, output and error redirected to /dev/null, and with an
|
|
environment that is empty except for some environment variables that
|
|
give information about the link. The environment variables that pppd
|
|
sets are:
|
|
<DL COMPACT>
|
|
<DT id="210"><B>DEVICE</B>
|
|
|
|
<DD>
|
|
The name of the serial tty device being used.
|
|
<DT id="211"><B>IFNAME</B>
|
|
|
|
<DD>
|
|
The name of the network interface being used.
|
|
<DT id="212"><B>IPLOCAL</B>
|
|
|
|
<DD>
|
|
The IP address for the local end of the link. This is only set when
|
|
IPCP has come up.
|
|
<DT id="213"><B>IPREMOTE</B>
|
|
|
|
<DD>
|
|
The IP address for the remote end of the link. This is only set when
|
|
IPCP has come up.
|
|
<DT id="214"><B>PEERNAME</B>
|
|
|
|
<DD>
|
|
The authenticated name of the peer. This is only set if the peer
|
|
authenticates itself.
|
|
<DT id="215"><B>SPEED</B>
|
|
|
|
<DD>
|
|
The baud rate of the tty device.
|
|
<DT id="216"><B>ORIG_UID</B>
|
|
|
|
<DD>
|
|
The real user-id of the user who invoked pppd.
|
|
<DT id="217"><B>PPPLOGNAME</B>
|
|
|
|
<DD>
|
|
The username of the real user-id that invoked pppd. This is always set.
|
|
</DL>
|
|
<P>
|
|
|
|
For the ip-down and auth-down scripts, pppd also sets the following
|
|
variables giving statistics for the connection:
|
|
<DL COMPACT>
|
|
<DT id="218"><B>CONNECT_TIME</B>
|
|
|
|
<DD>
|
|
The number of seconds from when the PPP negotiation started until the
|
|
connection was terminated.
|
|
<DT id="219"><B>BYTES_SENT</B>
|
|
|
|
<DD>
|
|
The number of bytes sent (at the level of the serial port) during the
|
|
connection.
|
|
<DT id="220"><B>BYTES_RCVD</B>
|
|
|
|
<DD>
|
|
The number of bytes received (at the level of the serial port) during
|
|
the connection.
|
|
<DT id="221"><B>LINKNAME</B>
|
|
|
|
<DD>
|
|
The logical name of the link, set with the <I>linkname</I> option.
|
|
<DT id="222"><B>CALL_FILE</B>
|
|
|
|
<DD>
|
|
The value of the <I>call</I> option.
|
|
<DT id="223"><B>DNS1</B>
|
|
|
|
<DD>
|
|
If the peer supplies DNS server addresses, this variable is set to the
|
|
first DNS server address supplied (whether or not the usepeerdns
|
|
option was given).
|
|
<DT id="224"><B>DNS2</B>
|
|
|
|
<DD>
|
|
If the peer supplies DNS server addresses, this variable is set to the
|
|
second DNS server address supplied (whether or not the usepeerdns
|
|
option was given).
|
|
</DL>
|
|
<P>
|
|
|
|
Pppd invokes the following scripts, if they exist. It is not an error
|
|
if they don't exist.
|
|
<DL COMPACT>
|
|
<DT id="225"><B>/etc/ppp/auth-up</B>
|
|
|
|
<DD>
|
|
A program or script which is executed after the remote system
|
|
successfully authenticates itself. It is executed with the parameters
|
|
<DT id="226"><DD>
|
|
<I>interface-name peer-name user-name tty-device speed</I>
|
|
<DT id="227"><DD>
|
|
Note that this script is not executed if the peer doesn't authenticate
|
|
itself, for example when the <I>noauth</I> option is used.
|
|
<DT id="228"><B>/etc/ppp/auth-down</B>
|
|
|
|
<DD>
|
|
A program or script which is executed when the link goes down, if
|
|
/etc/ppp/auth-up was previously executed. It is executed in the same
|
|
manner with the same parameters as /etc/ppp/auth-up.
|
|
<DT id="229"><B>/etc/ppp/ip-pre-up</B>
|
|
|
|
<DD>
|
|
A program or script which is executed just before the ppp network
|
|
interface is brought up. It is executed with the same parameters as
|
|
the ip-up script (below). At this point the interface exists and has
|
|
IP addresses assigned but is still down. This can be used to
|
|
add firewall rules before any IP traffic can pass through the
|
|
interface. Pppd will wait for this script to finish before bringing
|
|
the interface up, so this script should run quickly.
|
|
<DT id="230"><B>/etc/ppp/ip-up</B>
|
|
|
|
<DD>
|
|
A program or script which is executed when the link is available for
|
|
sending and receiving IP packets (that is, IPCP has come up). It is
|
|
executed with the parameters
|
|
<DT id="231"><DD>
|
|
<I>interface-name tty-device speed local-IP-address
|
|
remote-IP-address ipparam</I>
|
|
<DT id="232"><B>/etc/ppp/ip-down</B>
|
|
|
|
<DD>
|
|
A program or script which is executed when the link is no longer
|
|
available for sending and receiving IP packets. This script can be
|
|
used for undoing the effects of the /etc/ppp/ip-up and
|
|
/etc/ppp/ip-pre-up scripts. It is
|
|
invoked in the same manner and with the same parameters as the ip-up
|
|
script.
|
|
<DT id="233"><B>/etc/ppp/ipv6-up</B>
|
|
|
|
<DD>
|
|
Like /etc/ppp/ip-up, except that it is executed when the link is available
|
|
for sending and receiving IPv6 packets. It is executed with the parameters
|
|
<DT id="234"><DD>
|
|
<I>interface-name tty-device speed local-link-local-address
|
|
remote-link-local-address ipparam</I>
|
|
<DT id="235"><B>/etc/ppp/ipv6-down</B>
|
|
|
|
<DD>
|
|
Similar to /etc/ppp/ip-down, but it is executed when IPv6 packets can no
|
|
longer be transmitted on the link. It is executed with the same parameters
|
|
as the ipv6-up script.
|
|
<DT id="236"><B>/etc/ppp/ipx-up</B>
|
|
|
|
<DD>
|
|
A program or script which is executed when the link is available for
|
|
sending and receiving IPX packets (that is, IPXCP has come up). It is
|
|
executed with the parameters
|
|
<DT id="237"><DD>
|
|
<I>interface-name tty-device speed network-number local-IPX-node-address
|
|
remote-IPX-node-address local-IPX-routing-protocol remote-IPX-routing-protocol
|
|
local-IPX-router-name remote-IPX-router-name ipparam pppd-pid</I>
|
|
<DT id="238"><DD>
|
|
The local-IPX-routing-protocol and remote-IPX-routing-protocol field
|
|
may be one of the following:
|
|
<DT id="239"><DD>
|
|
NONE to indicate that there is no routing protocol
|
|
<BR>
|
|
|
|
RIP to indicate that RIP/SAP should be used
|
|
<BR>
|
|
|
|
NLSP to indicate that Novell NLSP should be used
|
|
<BR>
|
|
|
|
RIP NLSP to indicate that both RIP/SAP and NLSP should be used
|
|
<DT id="240"><B>/etc/ppp/ipx-down</B>
|
|
|
|
<DD>
|
|
A program or script which is executed when the link is no longer
|
|
available for sending and receiving IPX packets. This script can be
|
|
used for undoing the effects of the /etc/ppp/ipx-up script. It is
|
|
invoked in the same manner and with the same parameters as the ipx-up
|
|
script.
|
|
</DL>
|
|
<A NAME="lbAP"> </A>
|
|
<H2>FILES</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="241"><B>/var/run/ppp</B><I>n</I><B>.pid </B>(BSD or Linux), <B>/etc/ppp/ppp</B><I>n</I><B>.pid </B>(others)
|
|
|
|
<DD>
|
|
Process-ID for pppd process on ppp interface unit <I>n</I>.
|
|
<DT id="242"><B>/var/run/ppp-</B><I>name</I><B>.pid </B>(BSD or Linux),
|
|
|
|
<DD>
|
|
<B>/etc/ppp/ppp-</B><I>name</I><B>.pid </B>(others)
|
|
Process-ID for pppd process for logical link <I>name</I> (see the
|
|
<I>linkname</I> option).
|
|
<DT id="243"><B>/var/run/pppd2.tdb</B>
|
|
|
|
<DD>
|
|
Database containing information about pppd processes, interfaces and
|
|
links, used for matching links to bundles in multilink operation. May
|
|
be examined by external programs to obtain information about running
|
|
pppd instances, the interfaces and devices they are using, IP address
|
|
assignments, etc.
|
|
<B>/etc/ppp/pap-secrets</B>
|
|
|
|
Usernames, passwords and IP addresses for PAP authentication. This
|
|
file should be owned by root and not readable or writable by any other
|
|
user. Pppd will log a warning if this is not the case.
|
|
<DT id="244"><B>/etc/ppp/chap-secrets</B>
|
|
|
|
<DD>
|
|
Names, secrets and IP addresses for CHAP/MS-CHAP/MS-CHAPv2 authentication.
|
|
As for /etc/ppp/pap-secrets, this file should be owned by root and not
|
|
readable or writable by any other user. Pppd will log a warning if
|
|
this is not the case.
|
|
<DT id="245"><B>/etc/ppp/srp-secrets</B>
|
|
|
|
<DD>
|
|
Names, secrets, and IP addresses for EAP authentication. As for
|
|
/etc/ppp/pap-secrets, this file should be owned by root and not
|
|
readable or writable by any other user. Pppd will log a warning if
|
|
this is not the case.
|
|
<DT id="246"><B>~/.ppp_pseudonym</B>
|
|
|
|
<DD>
|
|
Saved client-side SRP-SHA1 pseudonym. See the <I>srp-use-pseudonym</I>
|
|
option for details.
|
|
<DT id="247"><B>/etc/ppp/options</B>
|
|
|
|
<DD>
|
|
System default options for pppd, read before user default options or
|
|
command-line options.
|
|
<DT id="248"><B>~/.ppprc</B>
|
|
|
|
<DD>
|
|
User default options, read before /etc/ppp/options.<I>ttyname</I>.
|
|
<DT id="249"><B>/etc/ppp/options.</B><I>ttyname</I>
|
|
|
|
<DD>
|
|
System default options for the serial port being used, read after
|
|
~/.ppprc. In forming the <I>ttyname</I> part of this
|
|
filename, an initial /dev/ is stripped from the port name (if
|
|
present), and any slashes in the remaining part are converted to
|
|
dots.
|
|
<DT id="250"><B>/etc/ppp/peers</B>
|
|
|
|
<DD>
|
|
A directory containing options files which may contain privileged
|
|
options, even if pppd was invoked by a user other than root. The
|
|
system administrator can create options files in this directory to
|
|
permit non-privileged users to dial out without requiring the peer to
|
|
authenticate, but only to certain trusted peers.
|
|
</DL>
|
|
<A NAME="lbAQ"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+chat">chat</A></B>(8),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+pppstats">pppstats</A></B>(8)
|
|
|
|
<DL COMPACT>
|
|
<DT id="251"><B>RFC1144</B>
|
|
|
|
<DD>
|
|
Jacobson, V.
|
|
<I>Compressing TCP/IP headers for low-speed serial links.</I>
|
|
February 1990.
|
|
<DT id="252"><B>RFC1321</B>
|
|
|
|
<DD>
|
|
Rivest, R.
|
|
<I>The MD5 Message-Digest Algorithm.</I>
|
|
|
|
April 1992.
|
|
<DT id="253"><B>RFC1332</B>
|
|
|
|
<DD>
|
|
McGregor, G.
|
|
<I>PPP Internet Protocol Control Protocol (IPCP).</I>
|
|
|
|
May 1992.
|
|
<DT id="254"><B>RFC1334</B>
|
|
|
|
<DD>
|
|
Lloyd, B.; Simpson, W.A.
|
|
<I>PPP authentication protocols.</I>
|
|
|
|
October 1992.
|
|
<DT id="255"><B>RFC1661</B>
|
|
|
|
<DD>
|
|
Simpson, W.A.
|
|
<I>The Point-to-Point Protocol (PPP).</I>
|
|
|
|
July 1994.
|
|
<DT id="256"><B>RFC1662</B>
|
|
|
|
<DD>
|
|
Simpson, W.A.
|
|
<I>PPP in HDLC-like Framing.</I>
|
|
|
|
July 1994.
|
|
<DT id="257"><B>RFC2284</B>
|
|
|
|
<DD>
|
|
Blunk, L.; Vollbrecht, J.,
|
|
<I>PPP Extensible Authentication Protocol (EAP).</I>
|
|
|
|
March 1998.
|
|
<DT id="258"><B>RFC2472</B>
|
|
|
|
<DD>
|
|
Haskin, D.
|
|
<I>IP Version 6 over PPP</I>
|
|
|
|
December 1998.
|
|
<DT id="259"><B>RFC2945</B>
|
|
|
|
<DD>
|
|
Wu, T.,
|
|
<I>The SRP Authentication and Key Exchange System</I>
|
|
|
|
September 2000.
|
|
<DT id="260"><B>draft-ietf-pppext-eap-srp-03.txt</B>
|
|
|
|
<DD>
|
|
Carlson, J.; et al.,
|
|
<I>EAP SRP-SHA1 Authentication Protocol.</I>
|
|
|
|
July 2001.
|
|
</DL>
|
|
<A NAME="lbAR"> </A>
|
|
<H2>NOTES</H2>
|
|
|
|
Some limited degree of control can be exercised over a running pppd
|
|
process by sending it a signal from the list below.
|
|
<DL COMPACT>
|
|
<DT id="261"><B>SIGINT, SIGTERM</B>
|
|
|
|
<DD>
|
|
These signals cause pppd to terminate the link (by closing LCP),
|
|
restore the serial device settings, and exit. If a connector or
|
|
disconnector process is currently running, pppd will send the same
|
|
signal to its process group, so as to terminate the connector or
|
|
disconnector process.
|
|
<DT id="262"><B>SIGHUP</B>
|
|
|
|
<DD>
|
|
This signal causes pppd to terminate the link, restore the serial
|
|
device settings, and close the serial device. If the <I>persist</I> or
|
|
<I>demand</I> option has been specified, pppd will try to reopen the
|
|
serial device and start another connection (after the holdoff period).
|
|
Otherwise pppd will exit. If this signal is received during the
|
|
holdoff period, it causes pppd to end the holdoff period immediately.
|
|
If a connector or disconnector process is running, pppd will send the
|
|
same signal to its process group.
|
|
<DT id="263"><B>SIGUSR1</B>
|
|
|
|
<DD>
|
|
This signal toggles the state of the <I>debug</I> option.
|
|
<DT id="264"><B>SIGUSR2</B>
|
|
|
|
<DD>
|
|
This signal causes pppd to renegotiate compression. This can be
|
|
useful to re-enable compression after it has been disabled as a result
|
|
of a fatal decompression error. (Fatal decompression errors generally
|
|
indicate a bug in one or other implementation.)
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAS"> </A>
|
|
<H2>AUTHORS</H2>
|
|
|
|
Paul Mackerras (<A HREF="mailto:paulus@samba.org">paulus@samba.org</A>), based on earlier work by
|
|
Drew Perkins,
|
|
Brad Clements,
|
|
Karl Fox,
|
|
Greg Christy,
|
|
and
|
|
Brad Parker.
|
|
<P>
|
|
<A NAME="lbAT"> </A>
|
|
<H2>COPYRIGHT</H2>
|
|
|
|
Pppd is copyrighted and made available under conditions which provide
|
|
that it may be copied and used in source or binary forms provided that
|
|
the conditions listed below are met. Portions of pppd are covered by
|
|
the following copyright notices:
|
|
<P>
|
|
|
|
Copyright (c) 1984-2000 Carnegie Mellon University. All rights
|
|
reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 1993-2004 Paul Mackerras. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 1995 Pedro Roque Marques. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 1995 Eric Rosenquist. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 1999 Tommi Komulainen. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (C) Andrew Tridgell 1999
|
|
<BR>
|
|
|
|
Copyright (c) 2000 by Sun Microsystems, Inc. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 2001 by Sun Microsystems, Inc. All rights reserved.
|
|
<BR>
|
|
|
|
Copyright (c) 2002 Google, Inc. All rights reserved.
|
|
<P>
|
|
|
|
The copyright notices contain the following statements.
|
|
<P>
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions
|
|
are met:
|
|
<P>
|
|
|
|
1. Redistributions of source code must retain the above copyright
|
|
<BR> notice, this list of conditions and the following disclaimer.
|
|
<P>
|
|
|
|
2. Redistributions in binary form must reproduce the above copyright
|
|
<BR> notice, this list of conditions and the following disclaimer in
|
|
<BR> the documentation and/or other materials provided with the
|
|
<BR> distribution.
|
|
<P>
|
|
|
|
3. The name "Carnegie Mellon University" must not be used to
|
|
<BR> endorse or promote products derived from this software without
|
|
<BR> prior written permission. For permission or any legal
|
|
<BR> details, please contact
|
|
<BR>
|
|
|
|
<BR> Office of Technology Transfer
|
|
<BR>
|
|
|
|
<BR> Carnegie Mellon University
|
|
<BR>
|
|
|
|
<BR> 5000 Forbes Avenue
|
|
<BR>
|
|
|
|
<BR> Pittsburgh, PA 15213-3890
|
|
<BR>
|
|
|
|
<BR> (412) 268-4387, fax: (412) 268-7395
|
|
<BR>
|
|
|
|
<BR> <A HREF="mailto:tech-transfer@andrew.cmu.edu">tech-transfer@andrew.cmu.edu</A>
|
|
<P>
|
|
|
|
3b. The name(s) of the authors of this software must not be used to
|
|
<BR> endorse or promote products derived from this software without
|
|
<BR> prior written permission.
|
|
<P>
|
|
|
|
4. Redistributions of any form whatsoever must retain the following
|
|
<BR> acknowledgements:
|
|
<BR>
|
|
|
|
<BR> "This product includes software developed by Computing Services
|
|
<BR> at Carnegie Mellon University (<A HREF="http://www.cmu.edu/computing/).">http://www.cmu.edu/computing/).</A>"
|
|
<BR>
|
|
|
|
<BR> "This product includes software developed by Paul Mackerras
|
|
<BR> <<A HREF="mailto:paulus@samba.org">paulus@samba.org</A>>".
|
|
<BR>
|
|
|
|
<BR> "This product includes software developed by Pedro Roque Marques
|
|
<BR> <<A HREF="mailto:pedro_m@yahoo.com">pedro_m@yahoo.com</A>>".
|
|
<BR>
|
|
|
|
<BR> "This product includes software developed by Tommi Komulainen
|
|
<BR> <<A HREF="mailto:Tommi.Komulainen@iki.fi">Tommi.Komulainen@iki.fi</A>>".
|
|
<P>
|
|
|
|
CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO
|
|
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
|
|
AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE
|
|
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
|
|
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
|
|
OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
<P>
|
|
|
|
THE AUTHORS OF THIS SOFTWARE DISCLAIM ALL WARRANTIES WITH REGARD TO
|
|
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
|
|
AND FITNESS, IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY
|
|
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
|
|
AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
|
|
OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="265"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="266"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="267"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="268"><A HREF="#lbAE">FREQUENTLY USED OPTIONS</A><DD>
|
|
<DT id="269"><A HREF="#lbAF">OPTIONS</A><DD>
|
|
<DT id="270"><A HREF="#lbAG">OPTIONS FILES</A><DD>
|
|
<DT id="271"><A HREF="#lbAH">SECURITY</A><DD>
|
|
<DT id="272"><A HREF="#lbAI">AUTHENTICATION</A><DD>
|
|
<DT id="273"><A HREF="#lbAJ">ROUTING</A><DD>
|
|
<DT id="274"><A HREF="#lbAK">MULTILINK</A><DD>
|
|
<DT id="275"><A HREF="#lbAL">EXAMPLES</A><DD>
|
|
<DT id="276"><A HREF="#lbAM">DIAGNOSTICS</A><DD>
|
|
<DT id="277"><A HREF="#lbAN">EXIT STATUS</A><DD>
|
|
<DT id="278"><A HREF="#lbAO">SCRIPTS</A><DD>
|
|
<DT id="279"><A HREF="#lbAP">FILES</A><DD>
|
|
<DT id="280"><A HREF="#lbAQ">SEE ALSO</A><DD>
|
|
<DT id="281"><A HREF="#lbAR">NOTES</A><DD>
|
|
<DT id="282"><A HREF="#lbAS">AUTHORS</A><DD>
|
|
<DT id="283"><A HREF="#lbAT">COPYRIGHT</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:15 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|