ipppd man page on SuSE

Man page or keyword search:  
man Server   14857 pages
apropos Keyword Search (all sections)
Output format
SuSE logo
[printable version]

IPPPD(8)		  Linux System Administration		      IPPPD(8)

NAME
       ipppd - (ISDN) Point to Point Protocol daemon

SYNOPSIS
       /usr/sbin/ipppd [ options ] [ device ]

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.
       ipppd  provides	the  basic LCP, authentication support, and an NCP for
       establishing and configuring the Internet Protocol (IP) (called the  IP
       Control Protocol, IPCP).

NOTES for (ISDN) IPPPD
       This  special  (ISDN) PPP daemon is a modified version of pppd and pro‐
       vides synchronous PPP for ISDN connections.

       If you need asynchronous PPP over ISDN lines use pppd instead with  the
       ISDN character devices, see ttyI(4).

       The  ipppd  can handle multiple devices. This is necessary to link sev‐
       eral connections together to one bundle.	 ipppd should be started once.
       It  opens the devices and waits for connections.	 If the connections is
       closed ipppd reopens the device automatically (the  device,  that's  it
       ...  not	 the  link to the remote).  So you shouldn't kill the ipppd to
       close a link. Instead, trigger a hangup	on  the	 netdevice  layer   by
       'isdnctrl hangup <device>'.

       The  facility  to configure the daemon via file /etc/ppp/ioptions.<dev‐
       name> is disabled.  The 'file' option or the command line may  be  used
       for individual configuration.

       Do  not set the permissions of the program to 'setuid to root on execu‐
       tion'. Call the daemon as root instead.	No common user should have the
       need to call the daemon!

OPTIONS
       <device>
	      Communicate  over	 the  named  device.   The  string  "/dev/" is
	      prepended if necessary.  If no device name is given, or  if  the
	      name  of	the  controlling terminal is given, ipppd will use the
	      controlling terminal, and will not fork to  put  itself  in  the
	      background.

       <local_IP_address>:<remote_IP_address>
	      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  noipdefault	 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,	 ipppd
	      will  not	 accept	 a  different  value from the peer in the IPCP
	      negotiation, unless the  ipcp-accept-local  and/or  ipcp-accept-
	      remote options are given, respectively.

       active-filter filter-expression
	      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 idle option if there are packets being sent or received
	      regularly over the link (for example, routing information	 pack‐
	      ets)  which would otherwise prevent the link from ever appearing
	      to be idle.  The filter-expression syntax is  as	described  for
	      tcpdump(1), except that qualifiers which are inappropriate for a
	      PPP link, such as ether and arp, 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 if both the
	      kernel and ipppd were compiled with IPPP_FILTER defined.

       -ac    Disable Address/Control compression  negotiation	(use  default,
	      i.e.  address/control field compression disabled).

       -all   Don't  request  or  allow negotiation of any options for LCP and
	      IPCP (use default values).

       auth   Require the peer to authenticate itself before allowing  network
	      packets to be sent or received.

       bsdcomp nr,nt
	      Request  that the peer compress packets that it sends, using the
	      BSD-Compress scheme, with a maximum code size of	nr  bits,  and
	      agree  to	 compress packets sent to the peer with a maximum code
	      size of nt bits.	If nt is not specified,	 it  defaults  to  the
	      value given for nr.  Values in the range 9 to 15 may be used for
	      nr and nt; larger values give  better  compression  but  consume
	      more kernel memory for compression dictionaries.	Alternatively,
	      a value of 0 for nr or nt disables  compression  in  the	corre‐
	      sponding direction.

       -bsdcomp
	      Disables	compression;  ipppd  will not request or agree to com‐
	      press packets using the BSD-Compress scheme.

       callback <string>
	      Request the peer to call back at the location given in <string>.
	      Ususally	this is a phone number, but it may be interpreted dif‐
	      ferently (or ignored) depending on the callback-type option.  If
	      <string> is the empty string, ipppd automatically tries to nego‐
	      tiate a callback type that does not need a location to be speci‐
	      fied.

       callback-delay <n>
	      Callback	delay  for  CBCP in seconds. If callback is negotiated
	      using CBCP, request that the peer waits  at  least  <n>  seconds
	      before calling back. Ignored if callback is negotiated as speci‐
	      fied in RFC 1570. Legal range is 0..255, default is 5.

       callback-cbcp
	      Enable callback negotiation via CBCB (default).

       -callback-cbcp
	      Disable callback negotiation via CBCB.

       no-callback-cbcp
	      Disable callback negotiation via CBCB.

       callback-cbcp-preferred
	      If both CBCP and RFC 1570 style callback negotiation is enabled,
	      CBCP is preferred (default)

       callback-rfc1570-preferred
	      If both CBCP and RFC 1570 style callback negotiation is enabled,
	      RFC 1570 style is preferred.

       callback-rfc1570
	      Enable RFC 1570 style callback negotiation (default).

       -callback-rfc1570
	      Disable RFC 1570 style callback negotiation.

       no-callback-rfc1570
	      Disable RFC 1570 style callback negotiation (default).

       callback-type <n>
	      Specifies how to interpret  the  location	 identifier  given  as
	      parameter of the callback option. Legal values are 0..4. A value
	      of 0 means that only callback types should  be  negotiated  that
	      need no extra location id. No location id is sent to the peer in
	      this case.  For RFC 1570 style callback negotiation, the	values
	      1..4 indicate how the peer should interpret the location identi‐
	      fier: 1 - id is a system specific dial string,  2 - id  is  used
	      for database lookup by the peer, 3 - id is a phone number, and 4
	      id is a name. For CBCP callback negotiation, the location id  is
	      always interpreted as a phone number.

       -ccp   Necessary for a few netblazers on the remote side.

       noccp  same as -ccp

       +chap  Require  the  peer  to  authenticate  itself using CHAP [Crypto‐
	      graphic Handshake Authentication Protocol] authentication.

       -chap  Don't agree to authenticate using CHAP.

       chap-interval <n>
	      If this option is given, ipppd will rechallenge the  peer	 every
	      <n> seconds.

       chap-max-challenge <n>
	      Set  the	maximum	 number of CHAP challenge transmissions to <n>
	      (default 10).

       chap-restart <n>
	      Set the CHAP restart interval (retransmission timeout for	 chal‐
	      lenges) to <n> seconds (default 3).

       debug  Increase debugging level (same as -d).  If this option is given,
	      ipppd will log the contents  of  all  control  packets  sent  or
	      received	in  a  readable	 form.	The packets are logged through
	      syslog with facility daemon and level debug.   This  information
	      can  be directed to a file by setting up /etc/syslog.conf appro‐
	      priately (see syslog.conf(5)).

       -d     Increase debugging level (same as the debug option).

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

       -defaultroute
	      Disable the defaultroute option.	The system  administrator  who
	      wishes  to prevent users from creating default routes with ipppd
	      can do so by placing this option in the /etc/ppp/ioptions file.

       deldefaultroute
	      Replace default route if it already exists.  Together  with  the
	      option  defaultroute,  this  will	 replace  any existing default
	      route by a new one through this ipppd's interface when it	 comes
	      up.

       -detach
	      Don't  fork to become a background process (otherwise ipppd will
	      do so if a serial device other than its controlling terminal  is
	      specified).

       domain <d>
	      Append  the domain name <d> to the local host name for authenti‐
	      cation purposes.	For example, if gethostname() returns the name
	      porsche,	  but	 the	fully	qualified   domain   name   is
	      porsche.Quotron.COM, you would use the domain option to set  the
	      domain name to Quotron.COM.

       file <f>
	      Read options from file <f> (the format is described below).

       -ip    Disable  IP  address  negotiation.   If this option is used, the
	      remote IP address must be specified with an option on  the  com‐
	      mand line or in an options file.

       +ip-protocol
	      Enable the IPCP and IP protocols. This is the default condition.
	      This option is only needed if the default setting is  -ip-proto‐
	      col.

       -ip-protocol
	      Disable  the  IPCP and IP protocols. This should only be used if
	      you know that you are using a client which only understands  IPX
	      and you don't want to confuse the client with the IPCP protocol.

       +ipx-protocol
	      Enable  the  IPXCP and IPX protocols. This is the default condi‐
	      tion if your kernel supports IPX. This option is only needed  if
	      the  default  setting  is -ipx-protocol. If your kernel does not
	      support IPX then this option will have no effect.

       -ipx-protocol
	      Disable the IPXCP and IPX protocols. This should only be used if
	      you  know	 that you are using a client which only understands IP
	      and you don't want to confuse the client with the	 IPXCP	proto‐
	      col.

       ipcp-accept-local
	      With this option, ipppd will accept the peer's idea of our local
	      IP address, even if the local IP address	was  specified	in  an
	      option.

       ipcp-accept-remote
	      With  this  option,  ipppd  will	accept	the peer's idea of its
	      (remote) IP address, even if the remote IP address was specified
	      in an option.

       ipcp-max-configure <n>
	      Set  the	maximum number of IPCP configure-request transmissions
	      to <n> (default 10).

       ipcp-max-failure <n>
	      Set the maximum number of IPCP  configure-NAKs  returned	before
	      starting to send configure-Rejects instead to <n> (default 10).

       ipcp-max-terminate <n>
	      Set  the	maximum number of IPCP terminate-request transmissions
	      to <n> (default 3).

       ipcp-restart <n>
	      Set the IPCP restart interval (retransmission  timeout)  to  <n>
	      seconds (default 3).

       ipparam string
	      Provides	an  extra  parameter to the ip-up and ip-down scripts.
	      If this option is given, the string supplied is given as the 6th
	      parameter to those scripts.

       ipx-network <n>
	      Set  the IPX network number in the IPXCP configure request frame
	      to <n>. There is no valid default. If this option is not	speci‐
	      fied  then  the network number is obtained from the peer. If the
	      peer does not have the network number, the IPX protocol will not
	      be  started. This is a hexadecimal number and is entered without
	      any leading sequence such as 0x. It is  related  to  the	ipxcp-
	      accept-network option.

       ipx-node <n>:<m>
	      Set  the	IPX  node  numbers. The two node numbers are separated
	      from each other with a colon character. The first number <n>  is
	      the  local node number. The second number <m> is the peer's node
	      number. Each node number is a hexadecimal number, to the maximum
	      of  ten  significant digits. The node numbers on the ipx-network
	      must be unique. There is no valid default. If this option is not
	      specified	 then  the node number is obtained from the peer. This
	      option is a related to the ipxcp-accept-local and	 ipxcp-accept-
	      remote options.

       ipx-router-name <string>
	      Set  the name of the router. This is a string and is sent to the
	      peer as information data.

       ipx-routing <n>
	      Set the routing protocol to be received by this  option.	Use  a
	      comma-serperated	list if you want to specify more than one pro‐
	      tocol.  The 'none' option (0)  may  be  specified	 as  the  only
	      instance	of  ipx-routing.  The  values may be 0 for NONE, 2 for
	      RIP/SAP, and 4 for NLSP.

       ipxcp-accept-local
	      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.

       ipxcp-accept-network
	      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.

       ipxcp-accept-remote
	      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.

       ipxcp-max-configure <n>
	      Set  the	maximum number of IPXCP configure request frames which
	      the system will send to <n>. The default is 10.

       ipxcp-max-failure <n>
	      Set the maximum number of IPXCP NAK frames which the local  sys‐
	      tem  will	 send before it rejects the options. The default value
	      is 3.

       ipxcp-max-terminate <n>
	      Set the maximum nuber of IPXCP terminate request	frames	before
	      the  local  system  considers  that the peer is not listening to
	      them. The default value is 3.

       kdebug n
	      Enable debugging code in the kernel-level PPP driver.  The argu‐
	      ment  n  is a number which is the sum of the following values: 1
	      to enable general debug messages, 2 to request that the contents
	      of  received  packets be printed, and 4 to request that the con‐
	      tents of transmitted packets be printed.

       lcp-echo-failure <n>
	      If this option is given, ipppd will presume the peer to be  dead
	      if  n  LCP  echo-requests are sent without receiving a valid LCP
	      echo-reply.  If this happens, ipppd will terminate  the  connec‐
	      tion.  Use of this option requires a non-zero value for the lcp-
	      echo-interval parameter.	This option  can  be  used  to	enable
	      ipppd to terminate after the physical connection has been broken
	      (e.g., the line hung up) in situations where no  hardware	 modem
	      control lines are available.

       lcp-echo-interval <n>
	      If  this	option	is  given, ipppd will send an LCP echo-request
	      frame to the peer every n seconds.  With Linux, the echo-request
	      is  sent	when no packets have been received from the peer for n
	      seconds.	Normally the peer should respond to  the  echo-request
	      by sending an echo-reply.	 This option can be used with the lcp-
	      echo-failure option to detect that the peer is  no  longer  con‐
	      nected.

       lcp-max-configure <n>
	      Set the maximum number of LCP configure-request transmissions to
	      <n> (default 10).

       lcp-max-failure <n>
	      Set the maximum number of	 LCP  configure-NAKs  returned	before
	      starting to send configure-Rejects instead to <n> (default 10).

       lcp-max-terminate <n>
	      Set the maximum number of LCP terminate-request transmissions to
	      <n> (default 3).

       lcp-restart <n>
	      Set the LCP restart interval  (retransmission  timeout)  to  <n>
	      seconds (default 3).

       lock   Specifies	 that  ipppd  should create a UUCP-style lock file for
	      the serial device to ensure exclusive access to the device.

       login  Use the system password database	for  authenticating  the  peer
	      using PAP, and record the user in the system wtmp file.

       -mn    Disable  magic number negotiation.  With this option, ipppd can‐
	      not detect a looped-back line.

       +mp    enables MPPP negotiation

       mru <n>
	      Set the MRU [Maximum Receive Unit] value to <n> for negotiation.
	      ipppd  will  ask	the  peer  to send packets of no more than <n>
	      bytes.  The minimum MRU value is 128.  The default MRU value  is
	      1500.   A	 value	of 296 is recommended for slow links (40 bytes
	      for TCP/IP header + 256 bytes of data).

       -mru   Disable MRU  [Maximum  Receive  Unit]  negotiation.   With  this
	      option, ipppd will use the default MRU value of 1500 bytes.

       ms-dns <n>
	      This option sets the IP address or addresses for the Domain Name
	      Server. It is used by Microsoft Windows clients. The primary DNS
	      address is specified by the first instance of the ms-dns option.
	      The secondary is specified by the second instance.

       ms-get-dns
	      Implements the client side of RFC1877.  If ipppd is acting as  a
	      client  to a server that implements RFC1877 such as one intended
	      to be used with Microsoft Windows clients,  this	option	allows
	      ipppd  to	 obtain	 one or two DNS (Domain Name Server) addresses
	      from the server.	It does not do anything with  these  addresses
	      except  put  them	 in  the environment (MS_DNS1 MS_DNS2) that is
	      passed to scripts.  For compatibility with the async pppd,  DNS1
	      DNS2 environment variables are also set. A sample resolv.conf is
	      created  in  /etc/ppp/resolv.conf.   The	/etc/ppp/ip-up	script
	      should  use  this	 information to perform whatever adjustment is
	      necessary.  Note: RFC1877 is a horrible protocol layering viola‐
	      tion,  the  correct approach would be to use DHCP after the IPCP
	      phase.

       ms-get-wins
	      As ms-get-dns but for  WINS  (Windows  Internet  Name  Services)
	      server   addresses.   Environment	 variables  are	 MS_WINS1  and
	      MS_WINS2.

       mtu <n>
	      Set the MTU [Maximum Transmit Unit] value to  <n>.   Unless  the
	      peer  requests  a	 smaller value via MRU negotiation, ipppd will
	      request that the kernel networking code send data packets of  no
	      more than n bytes through the PPP network interface.

       name <n>
	      Set  the name of the local system for authentication purposes to
	      <n>.

       netmask <n>
	      Set the interface netmask to <n>, a 32 bit netmask  in  "decimal
	      dot"  notation  (e.g.  255.255.255.0).  If this option is given,
	      the value specified is  ORed  with  the  default	netmask.   The
	      default  netmask	is  chosen  based  on the negotiated remote IP
	      address; it is the appropriate network mask for the class of the
	      remote  IP address, ORed with the netmasks for any non point-to-
	      point network interfaces in the system which  are	 on  the  same
	      network.

       noipdefault
	      Disables the default behaviour when no local IP address is spec‐
	      ified, which is to determine (if possible) the local IP  address
	      from the hostname.  With this option, the peer will have to sup‐
	      ply the local IP address	during	IPCP  negotiation  (unless  it
	      specified explicitly on the command line or in an options file).

       passive
	      Enables  the  "passive"  option  in  the LCP.  With this option,
	      ipppd will attempt to initiate a	connection;  if	 no  reply  is
	      received	from the peer, ipppd will then just wait passively for
	      a valid LCP packet from the peer (instead of exiting, as it does
	      without this option).

       -p     Same as the passive option.

       +pap   Require the peer to authenticate itself using PAP.

       -pap   Don't agree to authenticate using PAP.

       papcrypt
	      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  ipppd  should not accept a password which
	      (before  encryption)  is	identical  to  the  secret  from   the
	      /etc/ppp/pap-secrets file.

       pap-max-authreq <n>
	      Set the maximum number of PAP authenticate-request transmissions
	      to <n> (default 10).

       pap-restart <n>
	      Set the PAP restart interval  (retransmission  timeout)  to  <n>
	      seconds (default 3).

       pap-timeout <n>
	      Set  the	maximum	 time  that  ipppd  will  wait for the peer to
	      authenticate itself with PAP to <n> seconds (0 means no limit).

       pass-filter filter-expression
	      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 basic firewall capability.  The filter-expression syntax is as
	      described for tcpdump(1), except that qualifiers which are inap‐
	      propriate for a PPP link, such as ether and arp, are not permit‐
	      ted. Generally the filter expression should be enclosed in  sin‐
	      gle-quotes  to  prevent  whitespace in the expression from being
	      interpreted by the shell. Note that it is possible to apply dif‐
	      ferent  constraints  to  incoming and outgoing packets using the
	      inbound and outbound qualifiers. This option is  currently  only
	      available	 if  both  the	kernel	and  ipppd  were compiled with
	      IPPP_FILTER defined.

       -pc    Disable protocol field  compression  negotiation	(use  default,
	      i.e.  protocol field compression disabled).

       pidfile <filename>
	      Use <filename> instead of /var/run/ipppd.pid

       pred1comp
	      Attempt  to  request  that the peer send the local system frames
	      which have been compressed by the Predictor-1  compression.  The
	      compression  protocols  must  be	loaded	or this option will be
	      ignored.

       -pred1comp
	      Do not accept Predictor-1 comprssion, even if the peer wants  to
	      send  this  type	of compression and support has been defined in
	      the kernel.

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

       -proxyarp
	      Disable the  proxyarp  option.   The  system  administrator  who
	      wishes  to  prevent  users  from creating proxy ARP entries with
	      ipppd can do so by placing this option in the  /etc/ppp/ioptions
	      file.

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

       set_userip
	      You may define valid IPs in /etc/ppp/useriptab

       silent With this option, ipppd will not transmit LCP packets to	initi‐
	      ate  a  connection until a valid LCP packet is received from the
	      peer (as for the	`passive'  option  with	 ancient  versions  of
	      ipppd).

       +ua <p>
	      Agree  to authenticate using PAP [Password Authentication Proto‐
	      col] if requested by the peer, and use the data in file <p>  for
	      the user and password to send to the peer. The file contains the
	      remote user name, followed by a newline, followed by the	remote
	      password, followed by a newline.	This option is obsolescent.

       usefirstip
	      Gets  the	 remote	 address from the first entry in the auth file
	      (if there is an IP address entry). This address should be a full
	      IP  address  not	an  address  from  a masked area.  Ipppd calls
	      'gethostbyname()' and negotiates the result.  IP from auth  file
	      will  overwrite  the  remote  address gotten from the interface.
	      'usefirstip' is UNTESTED!

       usehostname
	      Enforce the use of the hostname as the name of the local	system
	      for authentication purposes (overrides the name option).

       usepeerdns
	      Same as ms-get-dns for compatibility with async pppd.

       user <u>
	      Set  the	user  name to use for authenticating this machine with
	      the peer using PAP to <u>.

       useifip
	      will get (if not set to 0.0.0.0) the IP address for the negotia‐
	      tion from the attached network-interface.	 (also: ipppd will try
	      to negotiate 'pointopoint' IP as remote IP) interface address ->
	      local IP pointopoint address -> remote IP

       -vj    Disable negotiation of Van Jacobson style TCP/IP header compres‐
	      sion (use default, i.e. no compression).

       -vjccomp
	      Disable the connection-ID compression  option  in	 Van  Jacobson
	      style  TCP/IP  header compression.  With this option, ipppd will
	      not omit the connection-ID byte  from  Van  Jacobson  compressed
	      TCP/IP headers, nor ask the peer to do so.

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

OPTIONS FILES
       Options	can  be	 taken	from files as well as the command line.	 ipppd
       reads options from the file /etc/ppp/ioptions  before  looking  at  the
       command line.  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 quotes (").  A backslash (\) quotes the following charac‐
       ter.  A hash (#) starts a comment, which continues until the end of the
       line.

AUTHENTICATION
       ipppd  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.	 In part this is provided by the /etc/ppp/ioptions file, where
       the  administrator can place options to require authentication whenever
       ipppd is run, and in part by the PAP and CHAP secrets files, where  the
       administrator  can  restrict  the  set of IP addresses which individual
       users may use.

       The  default  behaviour	of  ipppd  is  to  agree  to  authenticate  if
       requested,  and	to not require authentication from the peer.  However,
       ipppd will not agree to authenticate itself with a particular  protocol
       if it has no secrets which could be used to do so.

       Authentication  is  based  on  secrets, which are selected from secrets
       files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets  for	CHAP).
       Both secrets files have the same format, and both can store secrets for
       several combinations of server (authenticating peer) and	 client	 (peer
       being authenticated).  Note that ipppd can be both a server and client,
       and that different protocols can be  used  in  the  two	directions  if
       desired.

       A secrets file is parsed into words as for a options file.  A secret is
       specified by a line containing at least 3 words, in  the	 order	client
       name,  server  name,  secret.  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, it is assumed that any IP address
       is OK; to disallow all IP addresses, use "-".   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, ipppd takes the best match, i.e.
       the match with the fewest wildcards.

       Thus a secrets file contains both secrets  for  use  in	authenticating
       other  hosts, plus secrets which we use for authenticating ourselves to
       others.	Which secret to use is chosen based on the names of  the  host
       (the `local name') and its peer (the `remote name').  The local name is
       set as follows:

       if the usehostname option is given,
	  then the local name is the hostname of this machine (with the domain
	  appended, if given)

       else if the name option is given,
	  then use the argument of the first name option seen

       else if the local IP address is specified with a hostname,
	  then use that name

       else  use  the  hostname	 of this machine (with the domain appended, if
       given)

       When authenticating ourselves using PAP, there  is  also	 a  `username'
       which is the local name by default, but can be set with the user option
       or the +ua option.

       The remote name is set as follows:

       if the remotename option is given,
	  then use the argument of the last remotename option seen

       else if the remote IP address is specified with a hostname,
	  then use that host name

       else the remote name is the null string "".

       Secrets are selected from the PAP secrets file as follows:

       * For authenticating the peer, look for a secret with client  ==	 user‐
	 name  specified  in the PAP authenticate-request, and server == local
	 name.

       * For authenticating ourselves to the peer,  look  for  a  secret  with
	 client == our username, server == remote name.

       When authenticating the peer with PAP, a secret of "" matches any pass‐
       word supplied by the peer.  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  the  papcrypt  option is given, the first (unen‐
       crypted) comparison is omitted, for better security.

       If the login option was specified, the username and password  are  also
       checked	against the system password database.  Thus, the system admin‐
       istrator 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  login  option,  the  secret  in
       /etc/ppp/pap-secrets  would  be	"", to avoid the need to have the same
       secret in two places.

       Secrets are selected from the CHAP secrets file as follows:

       * For authenticating the peer, look for a secret with  client  ==  name
	 specified in the CHAP-Response message, and server == local name.

       * For  authenticating  ourselves	 to  the  peer, look for a secret with
	 client == local name, and server == name specified in the  CHAP-Chal‐
	 lenge message.

       Authentication  must  be	 satisfactorily	 completed before IPCP (or any
       other Network Control Protocol)	can  be	 started.   If	authentication
       fails,  ipppd will terminated the link (by closing LCP).	 If IPCP nego‐
       tiates 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 authenti‐
       cate 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, ipppd	 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 pass‐
       word, it is possible to allow restricted access to hosts	 which	refuse
       to authenticate themselves.

ROUTING
       When  IPCP negotiation is completed successfully, ipppd 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.   Communica‐
       tion  with  other  machines  generally requires further modification to
       routing tables and/or ARP (Address  Resolution  Protocol)  tables.   In
       some  cases  this will be done automatically through the actions of the
       routed or gated daemons, but in most cases some further intervention is
       required.

       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 ipppd 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 example on a server
       machine connected to a LAN, in order to allow other hosts  to  communi‐
       cate  with  the	remote host.  The proxyarp option causes ipppd 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,	 ipppd	creates	 a  permanent,
       published  ARP  entry  with  the	 IP address of the remote host and the
       hardware address of the network interface found.

DIAGNOSTICS
       Messages are sent to  the  syslog  daemon  using	 facility  LOG_DAEMON.
       (This  can  be  overriden  by  recompiling ipppd 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 messages to the desired output device or file.

       The debug option causes the contents of all  control  packets  sent  or
       received	 to  be	 logged,  that is, all LCP, PAP, CHAP or IPCP packets.
       This can be useful if the PPP negotiation does not succeed.  If	debug‐
       ging  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  to  the
       ipppd process.  This signal acts as a toggle.

FILES
       /var/run/ipppd.pid
	      Process-ID for ipppd process on ppp interface unit n.

       /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

	      and with its standard input, output and error streams redirected
	      to /dev/null.

	      This program or script is executed with the same real and effec‐
	      tive user-ID as ipppd, that is, at least the  effective  user-ID
	      and  possibly the real user-ID will be root.  This is so that it
	      can be used to manipulate routes, run privileged	daemons	 (e.g.
	      sendmail),   etc.	   Be	careful	  that	the  contents  of  the
	      /etc/ppp/ip-up and /etc/ppp/ip-down scripts  do  not  compromise
	      your system's security.

       /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 with the same parameters as the ip-up script,  and
	      the  same	 security  considerations  apply, since it is executed
	      with the same effective and real user-IDs as ipppd.

       /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-protocol  local-IPX-router-name   remote-IPX-
	      router-name ipparam ipppd-pid

	      and with its standard input, output and error streams redirected
	      to /dev/null.

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

	      NONE	to indicate that there is no routing protocol
	      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

	      This program or script is executed with the same real and effec‐
	      tive user-ID as ipppd, that is, at least the  effective  user-ID
	      and  possibly the real user-ID will be root.  This is so that it
	      can be used to manipulate routes, run privileged	daemons	 (e.g.
	      ripd), etc.  Be careful that the contents of the /etc/ppp/ipx-up
	      and /etc/ppp/ipx-down scripts do not  compromise	your  system's
	      security.

       /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 with the same parameters  as  the	ipx-up
	      script,  and the same security considerations apply, since it is
	      executed with the same effective and real user-IDs as ipppd.

       /etc/ppp/auth-up
	      This program or script is executed after successful  authentica‐
	      tion  with the following parameters: interface name, authentica‐
	      tion user name, username of  ipppd,  devicename,	speed,	remote
	      number

       /etc/ppp/auth-down
	      This  program  or	 script is executed after a disconnection with
	      the following parameters: interface  name,  authentication  user
	      name, username of ipppd, devicename, speed, remote number

       /etc/ppp/auth-fail
	      This  program or script is executed after a authentication fail‐
	      ure with the following parameters: interface  name,  authentica‐
	      tion  user  name,	 username  of ipppd, devicename, speed, remote
	      number, failure reason
	       Valid reasons are:
		1 = Timeout during pap auth
		2 = pap protocol rejected
		3 = pap secrets invalid
		9 = Timeout during chap auth
	       10 = chap protocol rejected
	       11 = chap secrets invalid

       /etc/ppp/pap-secrets
	      Usernames, passwords and IP addresses for PAP authentication.

       /etc/ppp/chap-secrets
	      Names, secrets and IP addresses for CHAP authentication.

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

SEE ALSO
       ttyI(4), isdnctrl(8), ipppstats(8),

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

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

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

       RFC1334
	      Lloyd,  B.;  Simpson,  W.A.  PPP authentication protocols.  1992
	      October.

       RFC1548
	      Simpson, W.A.  The Point-to-Point Protocol (PPP).	  1993	Decem‐
	      ber.

       RFC1549
	      Simpson, W.A.  PPP in HDLC Framing.  1993 December

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

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

       SIGHUP This  signal  causes  ipppd  to  terminate the link, restore the
	      serial device settings, and close the  serial  device.   If  the
	      persist  option has been specified, ipppd will try to reopen the
	      serial device and start  another	connection.   Otherwise	 ipppd
	      will exit.

       SIGUSR2
	      This  signal  causes ipppd to renegotiate compression.  This can
	      be useful to re-enable compression after it has been disabled as
	      a	 result of a fatal decompression error.	 With the BSD Compress
	      scheme, fatal decompression errors generally indicate a  bug  in
	      one or other implementation.

AUTHORS
       Originally  written  by	Drew  Perkins,	Brad  Clements, Karl Fox, Greg
       Christy, Brad Parker, Paul Mackerras <paulus@cs.anu.edu.au> for (origi‐
       nal) pppd.

       Changes	for  ipppd  by	Klaus  Franken	<kfr@suse.de> and Michael Hipp
       <Michael.Hipp@student.uni-tuebingen.de>.

       Removal	of  pppd  specific  options  and  polish   by	Frank	Elsner
       <Elsner@zrz.TU-Berlin.DE>.

isdn4k-utils-3.13		  2003/07/01			      IPPPD(8)
[top]

List of man pages available for SuSE

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net