PPPD(8) | Maintenance Commands and Procedures | PPPD(8) |
pppd - point to point protocol daemon
pppd [tty_name] [speed] [options]
The point-to-point protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three components: a facility for encapsulating datagrams over serial links, an extensible link control protocol (LCP), and a family of network control protocols (NCP) for establishing and configuring different network-layer protocols.
The encapsulation scheme is provided by driver code in the kernel. pppd provides the basic LCP authentication support and several NCPs for establishing and configuring the Internet Protocol (referred to as the IP Control Protocol or "IPCP") and IPv6 (IPV6CP).
The following sections discuss the pppd options:
Options are taken from files and the command line. pppd reads options from the files /etc/ppp/options, $HOME/.ppprc and /etc/ppp/options.ttyname (in that order) before processing the options on the command line. (Command-line options are scanned for the terminal name before the options.ttyname file is read.) To form the name of the options.ttyname file, the initial /dev/ is removed from the terminal name, and any remaining forward slash characters (/) are replaced with dots. For example, with serial device /dev/cua/a, option file /etc/ppp/options.cua.a is read.
An options file is parsed into a series of words that are delimited by whitespace. Whitespace can be included in a word by enclosing the word in double-quotes ("). A backslash (\) quotes the succeeding character. A hash (#) starts a comment, which continues until the end of the line. There is no restriction on using the file or call options within an options file.
<tty_name>
<speed>
asyncmap <map>
auth
call name
callback number
connect script
crtscts
defaultroute
disconnect script
escape xx,yy,...
file name
init script
lock
mru n
mtu n
passive
<local_IP_address>:<remote_IP_address>
allow-fcs fcs-type
allow-ip address(es)
bsdcomp nr,nt
cdtrcts
chap-interval n
chap-max-challenge n
chap-restart n
connect-delay n
datarate n
debug
default-asyncmap
default-fcs
default-mru
deflate nr,nt,e
demand
domain d
endpoint endpoint-value
fcs fcs-type
hide-password
holdoff n
ident string
idle n
ipcp-accept-local
ipcp-accept-remote
ipcp-max-configure n
ipcp-max-failure n
ipcp-max-terminate n
ipcp-restart n
ipparam string
ipv6 <local_interface_identifier>,<remote_interface_identifier>
ipv6cp-accept-local
ipv6cp-max-configure n
ipv6cp-max-failure n
ipv6cp-max-terminate n
ipv6cp-restart n
ipv6cp-use-ipaddr
ipv6cp-use-persistent
kdebug n
lcp-echo-failure n
lcp-echo-interval n
lcp-max-configure n
lcp-max-failure n
lcp-max-terminate n
lcp-restart n
linkname name
local
logfd n
logfile filename
login
maxconnect n
maxfail n
modem
ms-dns <addr>
ms-lanman
ms-wins <addr>
name name
no-accm-test
noaccomp
noauth
nobsdcomp
noccp
nocrtscts
nocdtrcts
nodefaultroute
nodeflate
nodeflatedraft
nodetach
noendpoint
noident
noip
noipv6
noipdefault
nolog
nomagic
nopam
nopcomp
nopersist
noplink
nopredictor1
noproxyarp
notty
novj
novjccomp
pam
papcrypt
pap-max-authreq n
pap-restart n
pap-timeout n
password string
persist
plink
plugin filename
plumbed
pppmux timer
privgroup group-name
proxyarp
pty script
receive-all
record filename
remotename name
refuse-chap
refuse-mschap
refuse-mschapv2
refuse-pap
require-chap
require-mschap
require-mschapv2
require-pap
show-password
silent
small-accm-test
socket host:port
sync
unit n
updetach
usehostname
usepeerdns
user name
vj-max-slots n
welcome script
xonxoff
The following options are obsolete:
+ua name
+ipv6
--version
--help
The following sections discuss miscellaneous features of pppd:
pppd allows system administrators to provide legitimate users with PPP access to a server machine without fear of compromising the security of the server or the network it runs on. Access control is provided by restricting IP addresses the peer may use based on its authenticated identity (if any), and through restrictions on options a non-privileged user may use. Options that permit potentially insecure configurations are privileged. Privileged options are accepted only in files that are under the control of the system administrator or when pppd is being run by root.
By default, pppd allows 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, meaning all peers must authenticate themselves to set up a connection. On such a system, the auth option is the default. Conversely, a system with a PPP link that comprises the only connection to the Internet probably does not possess a default route, so the peer can use virtually any IP address without authenticating itself.
Security-sensitive options are privileged and cannot be accessed by a non-privileged user running pppd, either on the command line, in the user's $HOME/.ppprc file, or in an options file read using the file option. Privileged options may be used in /etc/ppp/options file or in an options file read using the call option. If pppd is run by the root user, privileged options can be used without restriction. If the /etc/ppp/options file does not exist, then only root may invoke pppd. The /etc/ppp/options file must be created (but may be empty) to allow ordinary non-root users to access pppd.
When opening the device, pppd uses the invoking user's user ID or the root UID (that is, 0), depending if 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 call 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 that they would not normally have access to. Otherwise pppd uses the invoking user's real UID when opening the device.
During the authentication process, one peer convinces the other of its identity by sending its name and some secret information to the other. During authentication, the first peer becomes the "client" and the second becomes the "server." Authentication names can (but are not required to) correspond to the peer's Internet hostnames.
pppd supports four authentication protocols: the Password Authentication Protocol (PAP) and three forms of the Challenge Handshake Authentication Protocol (CHAP). With the PAP protocol, the client sends its name and a cleartext password to the server to authenticate itself. With CHAP, the server initiates the authentication exchange by sending a challenge to the client who must respond with its name and a hash value derived from the shared secret and the challenge.
The PPP protocol is symmetrical, meaning that each peer may be required to authenticate itself to the other. Different authentication protocols and names can be used for each exchange.
By default, pppd authenticates if requested and does not require authentication from the peer. However, pppd does not authenticate itself with a specific protocol if it has no secrets that can do so.
pppd stores authentication secrets in the /etc/ppp/pap-secrets (for PAP), and /etc/ppp/chap-secrets (for CHAP) files. Both files use the same format. pppd uses secrets files to authenticate itself to other systems and to authenticate other systems to itself.
Secrets files contain one secret per line. Secrets are specific to a particular combination of client and server and can only be used by that client to authenticate itself to that server. Each line in a secrets file has a minimum of three fields that contain the client and server names followed by the secret. Often, these three fields are followed by IP addresses that are used by clients to connect to a server.
A secrets file is parsed into words, with client name, server name and secrets fields allocated one word each. Embedded spaces or other special characters within a word must be quoted or escaped. Case is significant in all three fields.
A secret beginning with an at sign ("@") is followed by the name of a file containing the secret. An asterisk (*) as the client or server name matches any name. When choosing a match, pppd selects the one with the fewest wildcards. Succeeding words on a line are interpreted by pppd as acceptable IP addresses for that client. IP Addresses are disallowed if they appear in lines that contain only three words or lines whose first word begins with a hyphen ("-"). To allow any address, use "*". An address starting with an exclamation point ("!") indicates that the specified address is not acceptable. An address may be followed by "/" and a number n to indicate a whole subnet (all addresses that have the same value in the most significant n 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 is set to the unit number, plus one.
When authenticating the peer, pppd chooses a secret with the peer's name in the first field of the secrets file and the name of the local system in the second field. The local system name defaults to the hostname, with the domain name appended if the domain option is used. The default can be overridden with the name option unless the usehostname option is used.
When authenticating to the peer, pppd first determines the name it will use to identify itself to the peer. This name is specified with the user option. If the user option is not used, the name defaults to the host name of the local system. pppd then selects a secret from the secrets file by searching for an entry with a local name in the first field and the peer's name in the second field. pppd will know the name of the peer if standard CHAP authentication is used because the peer will have sent it in the Challenge packet. However, if MS-CHAP or PAP is being used, pppd must determine the peer's name from the options specified by the user. The user can specify the peer's name directly with the remotename 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. If that fails, pppd uses the null string as the peer's name.
When authenticating the peer with PAP, the supplied password is compared with data in the secrets file. If the password and secret do not match, the password is encrypted using crypt() and checked against the secret again. If the papcrypt option is given, the first unencrypted comparison is omitted for better security, and entries must thus be in encrypted crypt(3C) form.
If the login option is specified, the username and password are also checked against the system password database. This allows you to set up the pap-secrets file to enable PPP access only to certain users, and to restrict the set of IP addresses available to users. Typically, when using the login option, the secret in /etc/ppp/pap-secrets would be "", which matches any password supplied by the peer. This makes having the same secret in two places unnecessary. When login is used, the pam option enables access control through pam(3PAM).
Authentication must be completed before IPCP (or other network protocol) can be started. If the peer is required to authenticate itself and fails, pppd closes LCP and terminates the link. If IPCP negotiates an unacceptable IP address for the remote host, IPCP is closed. IP packets are sent or received only when IPCP is open.
To allow hosts that cannot authenticate themselves to connect and use one of a restricted set of IP addresses, add a line to the pap-secrets file specifying the empty string for the client name and secret.
Additional pppd options for a given peer may be specified by placing them at the end of the secrets entry, separated by two dashes (--). For example
peername servername secret ip-address -- novj
When IPCP negotiation is complete, pppd informs the kernel of the local and remote IP addresses for the PPP interface and creates a host route to the remote end of the link that enables peers to exchange IP packets. Communication with other machines generally requires further modification to routing tables and/or Address Resolution Protocol (ARP) tables. In most cases the defaultroute and/or proxyarp options are sufficient for this, but further intervention may be necessary. If further intervention is required, use the /etc/ppp/ip-up script or a routing protocol daemon.
To add a default route through the remote host, use the defaultroute option. This option is typically used for "client" systems; that is, end-nodes that use the PPP link for access to the general Internet.
In some cases it is desirable to use proxy ARP, for example on a server machine connected to a LAN, to allow other hosts to communicate with the remote host. proxyarp instructs pppd to look for a network interface on the same subnet as the remote host. That is, an interface supporting broadcast and ARP that is not a point-to-point or loopback interface and that is currently up. 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.
When the demand option is used, the interface IP addresses are already set at the time when IPCP comes up. If pppd cannot negotiate the same addresses it used to configure the interface, it changes the interface IP addresses to the negotiated addresses. This may disrupt existing connections. Using demand dialing with peers that perform dynamic IP address assignment is not recommended.
pppd invokes scripts at various stages during processing that are used to perform site-specific ancillary processing. These scripts may be shell scripts or executable programs. pppd does not wait for the scripts to finish. The scripts are executed as root (with the real and effective user-id set to 0), enabling them to update routing tables, run privileged daemons, or perform other tasks. Be sure 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 pppd environment variables are:
DEVICE
IFNAME
IPLOCAL
IPREMOTE
PEERNAME
SPEED
ORIG_UID
PPPLOGNAME
pppd also sets the following variables for the ip-down and auth-down scripts:
CONNECT_TIME
BYTES_SENT
BYTES_RCVD
LINKNAME
If they exist, pppd invokes the following scripts. It is not an error if they do not exist.
/etc/ppp/auth-up
/etc/ppp/auth-down
/etc/ppp/ip-up
/etc/ppp/ip-down
/etc/ppp/ipv6-up
/etc/ppp/ipv6-down
Example 1 Using the auth Option
The following examples assume that the /etc/ppp/options file contains the auth option.
pppd is commonly used to dial out to an ISP. You can do this using the "pppd call isp" command where the /etc/ppp/peers/isp file is set up to contain a line similar to the following:
cua/a 19200 crtscts connect '/usr/bin/chat -f /etc/ppp/chat-isp' noauth
For this example, chat(8) is used to dial the ISP's modem and process any login sequence required. The /etc/ppp/chat-isp file is used by chat and could contain the following:
ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "ERROR" ABORT "NO ANSWER" ABORT "BUSY" ABORT "Username/Password Incorrect" "" "at" OK "at&f&d2&c1" OK "atdt2468135" "name:" "^Umyuserid" "word:" "\qmypassword" "ispts" "\q^Uppp" "~-^Uppp-~"
See the chat(8) man page for details of chat scripts.
Example 2 Using pppd with proxyarp
pppd can also 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 as shown in the following example:
example% pppd proxyarp
Example 3 Providing a User with Access to PPP Facilities
To provide a user with access to the PPP facilities, allocate an IP address for the user's machine, create an entry in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets. This enables the user's machine to authenticate itself. For example, to enable user "Joe" using machine "joespc" to dial in to machine "server" and use the IP address "joespc.example.net," add the following entry to the /etc/ppp/pap-secrets or /etc/ppp/chap-secrets files:
joespc server "joe's secret" joespc.example.net
Alternatively, you can create another username, for example "ppp," whose login shell is /usr/bin/pppd and whose home directory is /etc/ppp. If you run pppd this way, add the options to the /etc/ppp/.ppprc file.
If your serial connection is complex, it may be useful to escape such control characters as XON (^Q) and XOFF (^S), using asyncmap a0000. If the path includes a telnet, escape ^] (asyncmap 200a0000). If the path includes a rlogin command, add escape ff option to the options, because rlogin removes the window-size-change sequence [0xff, 0xff, 0x73, 0x73, followed by any 8 bytes] from the stream.
The pppd exit status indicates errors or specifies why a link was terminated. Exit status values are:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/var/run/spppn.pid
/var/run/ppp-name.pid
/etc/ppp/pap-secrets
/etc/ppp/chap-secrets
/etc/ppp/options
$HOME/.ppprc
/etc/ppp/options.ttyname
/etc/ppp/peers
See attributes(7) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
Interface Stability | Evolving |
crypt(3C), pam(3PAM), attributes(7), chat(8), ifconfig(8)
Haskin, D., Allen, E. RFC 2472 - IP Version 6 Over PPP. Network Working Group. December 1998.
Jacobson, V. RFC 1144, Compressing TCP/IP Headers for Low-Speed Serial Links. Network Working Group. February, 1990
Lloyd, B., Simpson, W. RFC 1334, PPP Authentication Protocols. Network Working Group. October 1992.
McGregor, G. RFC 1332, The PPP Internet Protocol Control Protocol (IPCP). Network Working Group. May 1992.
Rivest, R. RFC 1321, The MD5 Message-Digest Algorithm. Network Working Group. April 1992
Simpson, W. RFC 1661, The Point-to-Point Protocol (PPP). Network Working Group. July 1994.
Simpson, W. RFC 1662, HDLC-like Framing . Network Working Group. July 1994.
These signals affect pppd behavior:
SIGINT, SIGTERM
SIGHUP
SIGUSR1
SIGUSR2
Messages are sent to the syslog daemon using facility LOG_DAEMON. To see error and debug messages, edit the /etc/syslog.conf file to direct the messages to the desired output device or file, or use the updetach or logfile options.
The debug option causes the contents of all LCP, PAP, CHAP or IPCP control packets sent or received to be logged. This is useful if PPP negotiation does not succeed or if authentication fails.
Debugging can also be enabled or disabled by sending a SIGUSR1 signal, which acts as a toggle to the pppd process.
February 5, 2022 | OmniOS |