PPPD(8)							  PPPD(8)


NAME
       pppd - Point to Point Protocol daemon

SYNOPSIS
       pppd [ tty_name ] [ speed ] [ options ]

DESCRIPTION
       The  Point-to-Point  Protocol  (PPP) provides a method for
       transmitting datagrams over serial  point-to-point  links.
       PPP is composed of three parts: a method 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  sup-
       port,  and  an  NCP  for	 establishing and configuring the
       Internet Protocol (IP) (called the  IP  Control	Protocol,
       IPCP).

FREQUENTLY USED OPTIONS
       <tty_name>
	      Communicate  over	 the  named  device.   The string
	      "/dev/" is prepended if necessary.   If  no  device
	      name  is given, or if the name of the terminal con-
	      nected 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.

       <speed>
	      Set the baud rate to <speed>  (a	decimal	 number).
	      On systems such as 4.4BSD and NetBSD, any speed can
	      be specified.  Other  systems  (e.g.  SunOS)  allow
	      only a limited set of speeds.

       asyncmap <map>
	      Set  the	async  character  map to <map>.	 This map
	      describes which control characters cannot	 be  suc-
	      cessfully received over the serial line.	Pppd will
	      ask the peer to send these characters as	a  2-byte
	      escape sequence.	The argument is a 32 bit hex num-
	      ber with	each  bit  representing	 a  character  to
	      escape.	Bit 0 (00000001) represents the character
	      0x00; bit 31 (80000000)  represents  the	character
	      0x1f  or	^_.   If  multiple  asyncmap  options are
	      given,  the  values  are	ORed  together.	  If   no
	      asyncmap	option	is  given, no async character map
	      will be negotiated for the receive  direction;  the
	      peer should then escape all control characters.  To
	      escape  transmitted  characters,	use  the   escape
	      option.
	      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 pppdump(8) program.

       remotename name
	      Set the assumed  name  of	 the  remote  system  for
	      authentication purposes to name.

       refuse-chap
	      With  this option, pppd will not agree to authenti-
	      cate itself to the peer using CHAP.

       refuse-pap
	      With this option, pppd will not agree to	authenti-
	      cate itself to the peer using PAP.

       require-chap
	      Require  the peer to authenticate itself using CHAP
	      [Challenge   Handshake   Authentication	Protocol]
	      authentication.

       require-pap
	      Require  the  peer to authenticate itself using PAP
	      [Password Authentication Protocol]  authentication.

       show-password
	      When  logging  the  contents  of	PAP packets, this
	      option causes pppd to show the password  string  in
	      the log message.

       silent With  this option, pppd will not transmit LCP pack-
	      ets to initiate a	 connection  until  a  valid  LCP
	      packet  is received from the peer (as for the `pas-
	      sive' option with ancient versions of pppd).

       sync   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.

       updetach
	      With this option, pppd will detach  from	its  con-
	      trolling	terminal  once it has successfully estab-
	      lished the ppp connection (to the point  where  the
	      first network control protocol, usually the IP con-
	      trol protocol, has come up).

       usehostname
	      Enforce the use of the hostname (with  domain  name
	      appended, if given) as the name of the local system
	      for authentication  purposes  (overrides	the  name
	      option).	 This option is not normally needed since
	      the name option is privileged.

       usepeerdns
	      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.  In addition, pppd will
	      create an /etc/ppp/resolv.conf file containing  one
	      or  two  nameserver lines with the address(es) sup-
	      plied by the peer.

       user name
	      Sets the name used  for  authenticating  the  local
	      system to the peer to name.

       vj-max-slots n
	      Sets  the	 number of connection slots to be used by
	      the Van  Jacobson	 TCP/IP	 header	 compression  and
	      decompression  code  to  n, which must be between 2
	      and 16 (inclusive).

       welcome script
	      Run the executable or shell  command  specified  by
	      script 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.

       xonxoff
	      Use software flow control (i.e. XON/XOFF)	 to  con-
	      trol the flow of data on the serial port.

OPTIONS FILES
       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.ttyname	(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.ttyname	 file  is  read.)
       In  forming the name of the options.ttyname file, the ini-
       tial /dev/ is removed from  the	terminal  name,	 and  any
       remaining / characters are replaced with dots.

       An  options  file is parsed into a series of words, delim-
       ited 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 file or call options within
       an options file.

SECURITY
       pppd provides system administrators with sufficient access
       control that PPP access to a server machine  can	 be  pro-
       vided to legitimate users without fear of compromising the
       security of the server or the network it's on.  This  con-
       trol   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.

       The default behaviour of pppd is to allow  an  unauthenti-
       cated  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 auth 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.

       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 file option.   Privi-
       leged  options  may be used in /etc/ppp/options file or in
       an options file read using the call option.   If	 pppd  is
       being run by the root user, privileged options can be used
       without restriction.

       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 call option, pppd uses full root priv-
       ileges when opening the	device.	  Thus,	 by  creating  an
       appropriate file under /etc/ppp/peers, the system adminis-
       trator 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.

AUTHENTICATION
       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  authentica-
       tion  correspond	 to  the internet hostnames of the peers,
       but this is not essential.

       At present, pppd supports  two  authentication  protocols:
       the  Password  Authentication Protocol (PAP) and the Chal-
       lenge  Handshake	 Authentication	 Protocol  (CHAP).    PAP
       involves the client sending its name and a cleartext pass-
       word 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.

       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 authentica-
       tion protocols, and in principle, different names could be
       used in the two exchanges.

       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.

       Pppd  stores  secrets for use in authentication in secrets
       files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets
       for  CHAP).  Both 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.

       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 authen-
       ticate 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.

       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  spe-
       cial characters quoted or escaped.  Note that case is sig-
       nificant in the client and server names and in the secret.

       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.

       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 not acceptable.  An  address
       may be followed by "/" and a number n, to indicate a whole
       subnet, i.e. all addresses which 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 will be set to the unit number
       plus one.

       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  authen-
       ticating	 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 domain option is used.
       This default can	 be  overridden	 with  the  name  option,
       except when the usehostname option is used.

       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  user  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 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 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.   Failing that, pppd will use the null string as the
       peer's name.

       When authenticating the peer with PAP, the supplied  pass-
       word  is	 first	compared with the secret from the secrets
       file.  If the password doesn't match the secret, the pass-
       word  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
       papcrypt option is given, the first (unencrypted) compari-
       son is omitted, for better security.

       Furthermore,  if the login option was specified, the user-
       name 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  cer-
       tain  users,  and to restrict the set of IP addresses that
       each user  can  use.   Typically,  when	using  the  login
       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.

       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.

       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 authenti-
       cate themselves.

ROUTING
       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  rout-
       ing   tables  and/or  ARP  (Address  Resolution	Protocol)
       tables.	In most cases the  defaultroute	 and/or	 proxyarp
       options are sufficient for this, but in some cases further
       intervention is required.  The /etc/ppp/ip-up  script  can
       be used for this.

       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 defaultroute option	causes	pppd  to  create  such	a
       default	route  when IPCP comes up, and delete it when the
       link is terminated.

       In some cases it is desirable to use proxy ARP, for  exam-
       ple  on	a  server machine connected to a LAN, in order to
       allow other hosts to communicate	 with  the  remote  host.
       The  proxyarp  option  causes  pppd  to look for a network
       interface on the same subnet as the remote host (an inter-
       face  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.

       When the demand 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 assign-
       ment), pppd has to change the interface	IP  addresses  to
       the  negotiated addresses.  This may disrupt existing con-
       nections, and the use of demand dialling with  peers  that
       do dynamic IP address assignment is not recommended.

EXAMPLES
       The  following  examples	 assume that the /etc/ppp/options
       file  contains  the  auth  option  (as  in   the	  default
       /etc/ppp/options file in the ppp distribution).

       Probably	 the most common use of pppd is to dial out to an
       ISP.  This can be done with a command such as

	      pppd call isp

       where the /etc/ppp/peers/isp file is set up by the  system
       administrator to contain something like this:

	      ttyS0 19200 crtscts
	      connect '/usr/sbin/chat -v -f /etc/ppp/chat-isp'
	      noauth

       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:

	      ABORT "NO CARRIER"
	      ABORT "NO DIALTONE"
	      ABORT "ERROR"
	      ABORT "NO ANSWER"
	      ABORT "BUSY"
	      ABORT "Username/Password Incorrect"
	      "" "at"
	      OK "at&d0&c1"
	      OK "atdt2468135"
	      "name:" "^Umyuserid"
	      "word:" "\qmypassword"
	      "ispts" "\q^Uppp"
	      "~-^Uppp-~"

       See the chat(8) man page for details of chat scripts.

       Pppd can also be used to provide a dial-in ppp service for
       users.  If the users already have login accounts, the sim-
       plest 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

	      pppd proxyarp

       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 or  /etc/ppp/chap-secrets
       (depending  on  which authentication method the PPP imple-
       mentation on the user's machine	supports),  so	that  the
       user's  machine	can authenticate itself.  For example, if
       Joe has a machine called "joespc" which 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:

	      joespc	server	  "joe's secret" joespc.my.net

       Alternatively, you can create a username called (for exam-
       ple) "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.

       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 use-
       ful  to	escape	XON  (^Q)  and	XOFF (^S), using asyncmap
       a0000.  If the path includes a telnet, you probably should
       escape  ^]  as  well  (asyncmap	200a0000).   If	 the path
       includes an rlogin, you will need to  use  the  escape  ff
       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.

DIAGNOSTICS
       Messages are sent to  the  syslog  daemon  using	 facility
       LOG_DAEMON.   (This  can	 be overriden by recompiling pppd
       with the macro LOG_PPP defined as the  desired  facility.)

       In  order  to  see  the error and debug messages, you will
       need to edit your /etc/syslog.conf file to direct the mes-
       sages to the desired output device or file.

       The  debug option causes the contents of all control pack-
       ets sent or received to be logged, that is, all LCP,  PAP,
       CHAP or IPCP packets.  This can be useful if the PPP nego-
       tiation does not succeed or if authentication  fails.   If
       debugging  is  enabled  at  compile time, the debug option
       also causes other debugging messages to be logged.

       Debugging can also be enabled or	 disabled  by  sending	a
       SIGUSR1 signal to the pppd process.  This signal acts as a
       toggle.

EXIT STATUS
       The exit status of pppd is set  to  indicate  whether  any
       error  was detected, or the reason for the link being ter-
       minated.	 The values used are:

       0      Pppd has detached, or otherwise the connection  was
	      successfully  established	 and  terminated  at  the
	      peer's request.

       1      An immediately fatal error of some  kind	occurred,
	      such  as	an essential system call failing, or run-
	      ning out of virtual memory.

       2      An error was detected  in	 processing  the  options
	      given, such as two mutually exclusive options being
	      used.

       3      Pppd is not setuid-root and the  invoking	 user  is
	      not root.

       4      The  kernel  does not support PPP, for example, the
	      PPP kernel driver is  not	 included  or  cannot  be
	      loaded.

       5      Pppd  terminated	because	 it  was  sent	a SIGINT,
	      SIGTERM or SIGHUP signal.

       6      The serial port could not be locked.

       7      The serial port could not be opened.

       8      The connect script failed (returned a non-zero exit
	      status).

       9      The  command  specified  as the argument to the pty
	      option could not be run.

       10     The PPP negotiation  failed,  that  is,  it  didn't
	      reach the point where at least one network protocol
	      (e.g. IP) was running.

       11     The peer system failed (or refused) to authenticate
	      itself.

       12     The  link	 was  established successfully and termi-
	      nated because it was idle.

       13     The link was established	successfully  and  termi-
	      nated because the connect time limit was reached.

       14     Callback was negotiated and an incoming call should
	      arrive shortly.

       15     The link was terminated because  the  peer  is  not
	      responding to echo requests.

       16     The link was terminated by the modem hanging up.

       17     The  PPP negotiation failed because serial loopback
	      was detected.

       18     The init script failed (returned	a  non-zero  exit
	      status).

       19     We failed to authenticate ourselves to the peer.

SCRIPTS
       Pppd  invokes  scripts at various stages in its processing
       which can be used to perform site-specific ancillary  pro-
       cessing.	  These	 scripts  are  usually shell scripts, but
       could be executable code files  instead.	  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), 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 vari-
       ables that pppd sets are:

       DEVICE The name of the serial tty device being used.

       IFNAME The name of the network interface being used.

       IPLOCAL
	      The IP address for the local end of the link.  This
	      is only set when IPCP has come up.

       IPREMOTE
	      The  IP  address	for  the  remote end of the link.
	      This is only set when IPCP has come up.


       PEERNAME
	      The authenticated name of the peer.  This	 is  only
	      set if the peer authenticates itself.

       SPEED  The baud rate of the tty device.

       ORIG_UID
	      The real user-id of the user who invoked pppd.

       PPPLOGNAME
	      The username of the real user-id that invoked pppd.
	      This is always set.

       For the ip-down and auth-down scripts, pppd also sets  the
       following variables giving statistics for the connection:

       CONNECT_TIME
	      The number of seconds from when the PPP negotiation
	      started until the connection was terminated.

       BYTES_SENT
	      The number of bytes  sent	 (at  the  level  of  the
	      serial port) during the connection.

       BYTES_RCVD
	      The  number  of bytes received (at the level of the
	      serial port) during the connection.

       LINKNAME
	      The logical name of the link, set with the linkname
	      option.

       Pppd  invokes the following scripts, if they exist.  It is
       not an error if they don't exist.

       /etc/ppp/auth-up
	      A program or script which	 is  executed  after  the
	      remote  system  successfully  authenticates itself.
	      It is executed with the parameters

	      interface-name peer-name user-name tty-device speed

	      Note  that  this script is not executed if the peer
	      doesn't authenticate itself, for example	when  the
	      noauth option is used.

       /etc/ppp/auth-down
	      A program or script which is executed when the link
	      goes down, if /etc/ppp/auth-up was previously  exe-
	      cuted.   It is executed in the same manner with the
	      same parameters as /etc/ppp/auth-up.

       /etc/ppp/ip-up
	      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

	      interface-name  tty-device  speed	 local-IP-address
	      remote-IP-address ipparam

       /etc/ppp/ip-down
	      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	 script.   It  is
	      invoked in the same manner and with the same param-
	      eters as the ip-up script.

       /etc/ppp/ipv6-up
	      Like  /etc/ppp/ip-up,  except  that  it is executed
	      when the link is available for sending and  receiv-
	      ing  IPv6	 packets. It is executed with the parame-
	      ters

	      interface-name tty-device	 speed	local-link-local-
	      address remote-link-local-address ipparam

       /etc/ppp/ipv6-down
	      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.

       /etc/ppp/ipx-up
	      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

	      interface-name   tty-device   speed  network-number
	      local-IPX-node-address	  remote-IPX-node-address
	      local-IPX-routing-protocol  remote-IPX-routing-pro-
	      tocol local-IPX-router-name  remote-IPX-router-name
	      ipparam pppd-pid

	      The local-IPX-routing-protocol and remote-IPX-rout-
	      ing-protocol field may be one of the following:

	      NONE	to indicate that there is no routing pro-
	      tocol
	      RIP	to indicate that RIP/SAP should be used
	      NLSP	 to  indicate  that Novell NLSP should be
	      used
	      RIP NLSP	to indicate that both  RIP/SAP	and  NLSP
	      should be used

       /etc/ppp/ipx-down
	      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 param-
	      eters as the ipx-up script.

FILES
       /var/run/pppn.pid (BSD or Linux), /etc/ppp/pppn.pid (oth-
       ers)
	      Process-ID  for  pppd process on ppp interface unit
	      n.

       /var/run/ppp-name.pid (BSD or Linux),
       /etc/ppp/ppp-name.pid (oth- ers)
	      Process-ID for pppd process for logical  link  name
	      (see the linkname option).

       /etc/ppp/pap-secrets
	      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.

       /etc/ppp/chap-secrets
	      Names, secrets and IP addresses for CHAP	authenti-
	      cation.	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 warn-
	      ing if this is not the case.

       /etc/ppp/options
	      System default options for pppd, read  before  user
	      default options or command-line options.

       ~/.ppprc
	      User	default	     options,	  read	   before
	      /etc/ppp/options.ttyname.

       /etc/ppp/options.ttyname
	      System default options for the  serial  port  being
	      used,  read after ~/.ppprc.  In forming the ttyname
	      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.

       /etc/ppp/peers
	      A directory containing options files which may con-
	      tain  privileged	options, even if pppd was invoked
	      by a user other than root.  The system  administra-
	      tor  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.

SEE ALSO
       RFC1144
	      Jacobson, V.  Compressing TCP/IP headers	for  low-
	      speed serial links.  February 1990.

       RFC1321
	      Rivest,	R.   The  MD5  Message-Digest  Algorithm.
	      April 1992.

       RFC1332
	      McGregor, G.  PPP Internet Protocol Control  Proto-
	      col (IPCP).  May 1992.

       RFC1334
	      Lloyd, B.; Simpson, W.A.	PPP authentication proto-
	      cols.  October 1992.

       RFC1661
	      Simpson, W.A.  The Point-to-Point	 Protocol  (PPP).
	      July 1994.

       RFC1662
	      Simpson,	W.A.   PPP  in	HDLC-like  Framing.  July
	      1994.

       RFC2472
	      Haskin, D.  IP Version 6 over PPP December 1998.

NOTES
       The following signals have the specified effect when  sent
       to pppd.

       SIGINT, SIGTERM
	      These  signals cause pppd to terminate the link (by
	      closing LCP), restore the serial	device	settings,
	      and exit.

       SIGHUP This  signal  causes  pppd  to  terminate the link,
	      restore the serial device settings, and  close  the
	      serial device.  If the persist or demand 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  immedi-
	      ately.

       SIGUSR1
	      This  signal toggles the state of the debug option.

       SIGUSR2
	      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  decom-
	      pression error.  (Fatal decompression errors gener-
	      ally indicate a bug in  one  or  other  implementa-
	      tion.)


AUTHORS
       Paul  Mackerras	(Paul.Mackerras@cs.anu.edu.au),	 based on
       earlier work by Drew Perkins,  Brad  Clements,  Karl  Fox,
       Greg Christy, and Brad Parker.


