*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> ppp (8)              



NAME    [Toc]    [Back]

     ppp - Point to Point Protocol (a.k.a. user-ppp)

SYNOPSIS    [Toc]    [Back]

     ppp [-mode] [-nat] [-quiet] [-unitN] [system ...]

DESCRIPTION    [Toc]    [Back]

     This is a user process PPP software package.  Normally,  PPP
is implemented
 as a part of the kernel (e.g., as managed by pppd(8)) and
it's thus
     somewhat hard to debug and/or modify its behaviour.   However, in this implementation
  PPP is done as a user process with the help of
the tunnel
     device driver, tun(4).

     The -nat flag does the equivalent of a ``nat  enable  yes'',
enabling ppp's
     network  address  translation  features.  This allows ppp to
act as a NAT or
     masquerading engine for all machines  on  an  internal  LAN.
Refer to the
this manual page
     for details on how to configure NAT in ppp.

     The -quiet flag tells ppp to be  silent  at  startup  rather
than displaying
     the mode and interface to standard output.

     The  -unit flag tells ppp to only attempt to open /dev/tunN.
     ppp will start with a value of 0 for N, and keep  trying  to
open a tunnel
     device by incrementing the value of N by one each time until
it succeeds.
     If it fails three times in a row because the device file  is
missing, it
     gives up.

     The following modes are understood by ppp:

             ppp  opens  the  tun  interface, configures it, then
goes into the
             background.  The link isn't brought up until  outgoing data is detected
  on  the tun interface at which point ppp attempts to bring
             up the link.  Packets received (including the  first
one) while
             ppp  is  trying  to  bring  the  link up will remain
queued for a default
 of 2 minutes.  See the set choked command  below.

             In  -auto mode, at least one system must be given on
the command
             line (see below) and a set ifaddr must  be  done  in
the system profile
  that  specifies  a peer IP address to use when
configuring the
             interface.  Something like ``'' is usually
             See       the       ``pmdemand''      system      in
/etc/ppp/ppp.conf.sample for an

             Here, ppp attempts to establish  a  connection  with
the peer immediately.
   If  it  succeeds, ppp goes into the background and the
             parent process returns an exit code  of  0.   If  it
fails, ppp exits
             with a non-zero result.

             In foreground mode, ppp attempts to establish a connection with
             the peer immediately, but never  becomes  a  daemon.
The link is
             created  in  background mode.  This is useful if you
wish to control
 ppp's invocation from another process.

             This is used  for  receiving  incoming  connections.
ppp ignores the
             set device line and uses descriptor 0 as the link.

             If  callback  is  configured,  ppp  will use the set
device information
 when dialing back.

             This option is designed for machines connected  with
a dedicated
             wire.  ppp will always keep the device open and will
never use
             any configured chat scripts.

             This mode is equivalent to -auto  mode  except  that
ppp will bring
             the  link back up any time it's dropped for any reason.

             This is a no-op, and gives the same behaviour as  if
none of the
             above modes have been specified.  ppp loads any sections specified
 on the command line, then provides an  interactive prompt.

     One  or  more configuration entries or systems (as specified
     /etc/ppp/ppp.conf) may also  be  specified  on  the  command
line.  ppp will
     read the ``default'' system from /etc/ppp/ppp.conf at startup, followed
     by each of the systems specified on the command line.

Major Features    [Toc]    [Back]

     Provides an interactive user interface.  Using  its  command
mode, the user
     can  easily  enter commands to establish the connection with
the remote
     end, check the status of the connection and close  the  connection.  All
     functions  can also be optionally password protected for security.

     Supports both manual  and  automatic  dialing.   Interactive
mode has a term
     command  which  enables  you to talk to the device directly.
When you are
     connected to the remote peer and it starts to talk PPP,  ppp
detects it
     and  switches  to  packet mode automatically.  Once you have
determined the
     proper sequence for connecting with the remote host, you can
write a chat
     script  to  define the necessary dialing and login procedure
for later convenience.

     Supports on-demand dialup capability.  By using -auto  mode,
ppp will act
     as  a  daemon  and wait for a packet to be sent over the PPP
link.  When
     this happens, the daemon automatically dials and establishes
the connection.
   In  almost  the same manner -ddial mode (direct-dial
mode) also automatically
 dials and establishes the connection.   However,
it differs in
     that  it  will  dial the remote site any time it detects the
link is down,
     even if there are no packets to be sent.  This mode is  useful for fulltime
  connections where we worry less about line charges and
more about
     being connected full time.  A third -dedicated mode is  also
     This  mode  is  targeted at a dedicated link between two machines.  ppp will
     never voluntarily quit from dedicated mode - you  must  send
it the ``quit
     all''  command  via  its  diagnostic  socket.  A SIGHUP will
force an LCP
     renegotiation, and a SIGTERM will force it to exit.

     Supports client callback.  ppp can use either  the  standard
LCP callback
     protocol   or   the   Microsoft  CallBack  Control  Protocol

     Supports NAT or packet aliasing.  Packet aliasing (a.k.a. IP
  allows computers on a private, unregistered network to
access the
     Internet.  The PPP host acts as a masquerading gateway.   IP
addresses as
     well  as  TCP  and  UDP  port numbers are NAT'd for outgoing
packets and deNAT'd
 for returning packets.

     Supports background PPP connections.  In background mode, if
ppp successfully
  establishes  the connection, it will become a daemon.
Otherwise, it
     will exit with an error.  This allows the setup  of  scripts
that wish to
     execute  certain commands only if the connection is successfully established.

     Supports server-side PPP connections.  In direct  mode,  ppp
acts as server
     which accepts incoming PPP connections on stdin/stdout.

     Supports   PAP   and   CHAP   (RFC  1994,  2433,  and  2759)
authentication.  With
     PAP or CHAP, it is possible to skip the Unix style  login(1)
     and use the PPP protocol for authentication instead.  If the
peer requests
 Microsoft CHAP authentication  and  ppp  is  compiled
with DES support,
 an appropriate MD4/DES response will be made.

     Supports RADIUS (RFC 2138 & 2548) authentication.  An extension to PAP
     and CHAP, Remote Access Dial In User Service allows  authentication information
  to  be  stored  in a central or distributed database
along with various
 per-user framed connection characteristics.

     Supports Proxy Arp.  ppp can be configured to  make  one  or
more proxy arp
     entries on behalf of the peer.  This allows routing from the
peer to the
     LAN without configuring each machine on that LAN.

     Supports packet filtering.  User can define  four  kinds  of
filters: the in
     filter  for  incoming  packets,  the out filter for outgoing
packets, the
     dial filter to define a  dialing  trigger  packet,  and  the
alive filter for
     keeping a connection alive with the trigger packet.

     Tunnel  driver supports bpf.  The user can use tcpdump(8) to
check the
     packet flow over the PPP link.

     Supports PPP over TCP and PPP over UDP.  If a device name is
specified as
     host:port[/tcp|udp],  ppp  will open a TCP or UDP connection
for transporting
 data rather than using  a  conventional  serial  device.
UDP connections
     force ppp into synchronous mode.

     Supports PPP over Ethernet (RFC 2516).  PPP over Ethernet is
     with the external program pppoe(8).

     Supports IETF draft Predictor-1 (RFC 1978) and DEFLATE  (RFC
     compression.   ppp supports not only VJ-compression but also
     and DEFLATE compression.  Normally,  a  modem  has  built-in
     (e.g., v42.bis) and the system may receive higher data rates
from it as a
     result of such compression.  While this is generally a  good
thing in most
     other  situations,  this higher speed data imposes a penalty
on the system
     by increasing the number of serial interrupts the system has
to process
     in  talking to the modem and also increases latency.  Unlike
 Predictor-1 and DEFLATE compression pre-compresses all
     traffic flowing through the link, thus reducing overheads to
a minimum.

     Supports Microsoft's IPCP extensions (RFC 1877).  Name Server Addresses
     and  NetBIOS  Name  Server  Addresses can be negotiated with
clients using
     the Microsoft PPP stack (i.e., Win95, WinNT)

     Supports Multi-link PPP (RFC 1990).  It is possible to  configure ppp to
     open  more than one physical connection to the peer, combining the bandwidth
 of all links for better throughput.

     Supports MPPE (draft-ietf-pppext-mppe).  MPPE  is  Microsoft
Point to Point
     Encryption  scheme.  It is possible to configure ppp to participate in Microsoft's
 Windows VPN.  For now, ppp can only get encryption
keys from
     CHAP  81  authentication.  ppp must be compiled with DES for
MPPE to operate.

     Supports IPV6CP (RFC 2023).  An IPv6 connection can be  made
in addition
     to or instead of the normal IPv4 connection.

PERMISSIONS    [Toc]    [Back]

     ppp  is  installed  as  user ``root'' and group ``network'',
with permissions
     04550.  By default, ppp will not run if the invoking user ID
is not zero.
     This may be overridden by using the allow users command in
     /etc/ppp/ppp.conf.   When  running  as  a  normal  user, ppp
switches to user
     ID 0 in order to alter the system routing table, set up system lock files
     and read the ppp configuration files.  All external commands
     via the shell or !bg commands) are executed as the  user  ID
that invoked
     ppp.   Refer  to the `ID0' logging facility if you're interested in what
     exactly is done as user ID zero.

GETTING STARTED    [Toc]    [Back]

     When you first run ppp you may need to deal with  some  initial configuration

     +o    Your  kernel  must include a tunnel device (the GENERIC
kernel includes
         one by default).  If it doesn't, you'll need to  rebuild
your kernel
         with  the  following  line  in your kernel configuration

               pseudo-device tun

         Tun interfaces can  be  created  at  runtime  using  the
ifconfig tunN
         create  command  or by opening the character special device /dev/tunN.
         See ifconfig(8) and tun(4) for more information.

     +o   Check your /dev directory for the tunnel device  entries
         where  `N'  represents  the  number  of  the tun device,
starting at zero.
         If they don't exist, you can create them by running  "sh
         tunN".  This will create tun devices 0 through N.

     +o   Make sure that your system has a group named ``network''
in the
         /etc/group file and that the group contains the names of
all users
         expected  to use ppp.  Refer to the group(5) manual page
for details.
         Each of these users must also be given access using  the
allow users
         command in /etc/ppp/ppp.conf.

     +o    Create  a log file.  ppp uses syslog(3) to log information.  A common
         log file name is /var/log/ppp.log.  To make output go to
this file,
         put the following lines in the /etc/syslog.conf file:


         It  is  possible  to  have more than one PPP log file by
creating a link
         to the ppp executable:

               # cd /usr/sbin
               # ln ppp ppp0

         and using


         in /etc/syslog.conf.  Don't forget to send a HUP  signal
to syslogd(8)
         after altering /etc/syslog.conf.

     +o    Although  not strictly relevant to ppp's operation, you
should configure
 your resolver so that it works correctly.  This  can
be done by
         configuring  a  local  DNS (using named(8)) or by adding
the correct
         ``nameserver'' lines to the file /etc/resolv.conf.   Refer to the
         resolv.conf(5) manual page for details.

         Alternatively,  if the peer supports it, ppp can be configured to ask
         the peer for the nameserver address(es) and to update
         /etc/resolv.conf automatically.  Refer to the enable dns
and resolv
         commands below for details.

MANUAL DIALING    [Toc]    [Back]

     In  the following examples, we assume that your machine name
     ``awfulhak''.  When you invoke ppp (see  PERMISSIONS  above)
with no arguments,
 you are presented with a prompt:

           ppp ON awfulhak>

     The `ON' part of your prompt should always be in upper case.
If it is in
     lower case, it means that you must supply a  password  using
the ``passwd''
     command.  This only ever happens if you connect to a running
version of
     ppp and have not authenticated yourself  using  the  correct

     You can start by specifying the device name and speed:

           ppp ON awfulhak> set device /dev/cua00
           ppp ON awfulhak> set speed 38400

     Normally, hardware flow control (CTS/RTS) is used.  However,
under certain
 circumstances (as may happen when you are connected directly to certain
  PPP-capable  terminal servers), this may result in ppp
hanging as
     soon as it tries to write data to your  communications  link
as it is waiting
  for  the  CTS (clear to send) signal - which will never
come.  Thus, if
     you have a direct line and can't seem to make a  connection,
try turning
     CTS/RTS  off  with  ``set  ctsrts  off''.  If you need to do
this, check the
     ``set accmap'' description below too - you'll probably  need
to ``set
     accmap 000a0000''.

     Usually,  parity  is  set to ``none'', and this is ppp's default.  Parity is
     a rather archaic error checking mechanism that is no  longer
used because
     modern  modems  do  their own error checking, and most linklayer protocols
     (that's what ppp is) use much more reliable checking  mechanisms.  Parity
     has a relatively huge overhead (a 12.5% increase in traffic)
and as a result,
 it is always disabled (set to ``none'')  when  PPP  is
opened.  However,
  some ISPs (Internet Service Providers) may use specific
parity settings
 at connection time (before PPP is  opened).   Notably,
Compuserve insist
 on even parity when logging in:

           ppp ON awfulhak> set parity even

     You can now see what your current device settings look like:

           ppp ON awfulhak> show physical
           Name: deflink
            State:           closed
            Device:          N/A
            Link Type:       interactive
            Connect Count:   0
            Queued Packets:  0
            Phone Number:    N/A

            Device List:     /dev/cua00
            Characteristics: 38400bps, cs8, even parity,  CTS/RTS

           Connect time: 0 secs
           0 octets in, 0 octets out
           Overall 0 bytes/sec
           ppp ON awfulhak>

     The term command can now be used to talk directly to the device:

           ppp ON awfulhak> term
           login: myispusername
           Password: myisppassword
           Protocol: ppp

     When the peer starts to talk in PPP, ppp detects this  automatically and
     returns to command mode.

           ppp  ON awfulhak>               # No link has been established
           Ppp ON awfulhak>                #  We've  connected  &
finished LCP
           PPp ON awfulhak>               # We've authenticated
           PPP  ON awfulhak>               # We've agreed IP numbers

     If it does not, it's probable that the peer is  waiting  for
your end to
     start  negotiating.   To force ppp to start sending PPP configuration packets
 to the peer, use the ~p command to drop out of  terminal
mode and enter
 packet mode.

     If you never even receive a login prompt, it is quite likely
that the
     peer wants to use PAP or CHAP authentication instead of  using Unix-style
     login/password  authentication.   To set things up properly,
drop back to
     the prompt and set your authentication name  and  key,  then

           ppp ON awfulhak> set authname myispusername
           ppp ON awfulhak> set authkey myisppassword
           ppp ON awfulhak> term

     You  may  need to tell ppp to initiate negotiations with the
peer here too:

           ppp ON awfulhak>               # No link has been  established
           Ppp  ON  awfulhak>                #  We've connected &
finished LCP
           PPp ON awfulhak>               # We've authenticated
           PPP ON awfulhak>               # We've agreed IP  numbers

     You  are  now  connected!  Note that `PPP' in the prompt has
changed to capital
 letters to indicate that you have  a  peer  connection.
If only some
     of  the three Ps go upper case, wait until either everything
is upper case
     or lower case.  If they revert to lower case, it means  that
ppp couldn't
     successfully negotiate with the peer.  A good first step for
 at this point would be:

           ppp ON awfulhak> set log local phase lcp ipcp

     ...and try again.  Refer to the set log command  description
below for
     further  details.  If things fail at this point, it is quite
     that you turn logging on and try again.  It is  also  important that you
     note  any prompt changes and report them to anyone trying to
help you.

     When the link is established, the show command can  be  used
to see how
     things are going:

           PPP ON awfulhak> show physical
           * Modem related information is shown here *
           PPP ON awfulhak> show ccp
           *  CCP (compression) related information is shown here
           PPP ON awfulhak> show lcp
           * LCP (line control) related information is shown here
           PPP ON awfulhak> show ipcp
           * IPCP (IP) related information is shown here *
           PPP ON awfulhak> show ipv6cp
           * IPV6CP (IPv6) related information is shown here *
           PPP ON awfulhak> show link
           *  Link (high level) related information is shown here
           PPP ON awfulhak> show bundle
           * Logical (high level) connection related  information
is shown here *

     At  this  point,  your machine has a host route to the peer.
This means
     that you can only make a connection with  the  host  on  the
other side of
     the link.  If you want to add a default route entry (telling
your machine
     to send all packets without another  routing  entry  to  the
other side of
     the PPP link), enter the following command:

           PPP ON awfulhak> add default HISADDR

     The string ``HISADDR'' represents the IP address of the connected peer.
     If the add command fails due to an existing route,  you  can
overwrite the
     existing route using add!:

           PPP ON awfulhak> add! default HISADDR

     This command can also be executed before actually making the
     If a new IP address is negotiated at  connection  time,  ppp
will update
     your default route accordingly.

     You  can  now  use  your network applications (ping, telnet,
ftp, etc.) in
     other windows or terminals on your machine.  If you wish  to
reuse the
     current  terminal, you can put ppp into the background using
your standard
     shell suspend and background commands (usually `^Z' followed
by `bg').

     Refer  to  the  PPP  COMMAND LIST section for details on all
available commands.

AUTOMATIC DIALING    [Toc]    [Back]

     To use automatic dialing, you must prepare some Dial and Login chat
     scripts.      See     the     example     definitions     in
/etc/ppp/ppp.conf.sample (the
     format of /etc/ppp/ppp.conf is pretty  simple).   Each  line
contains one
     comment, inclusion, label, or command:

     +o    A  line  starting  with a `#' character is treated as a
comment line.
         Leading whitespace is ignored when  identifying  comment

     +o    An  inclusion  is a line beginning with the word ``!include''.  It must
         have one argument - the file to include.  You  may  wish
to ``!include
         ~/.ppp.conf''  for  compatibility with older versions of

     +o   A label name starts in the first column and is  followed
by a colon

     +o    A command line must contain a space or tab in the first

     The /etc/ppp/ppp.conf file should  consist  of  at  least  a
``default'' section.
  This section is always executed.  It should also contain one or
     more sections, named according to their purpose,  for  example, ``MyISP''
     would  represent your ISP, and ``ppp-in'' would represent an
incoming ppp
     configuration.  You can now specify  the  destination  label
name when you
     invoke  ppp.  Commands associated with the ``default'' label
are executed,
     followed by those associated with the destination label provided.  When
     ppp is started with no arguments, the ``default'' section is
still executed.
  The load command can be used to manually load a section from the
     /etc/ppp/ppp.conf file:

           ppp ON awfulhak> load MyISP

     Note,  no  action is taken by ppp after a section is loaded,
whether it's
     the result of passing a label on the command line  or  using
the load command.
   Only  the  commands  specified for that label in the
     file are executed.  However,  when  invoking  ppp  with  the
     -ddial,  or  -dedicated switches, the link mode tells ppp to
establish a
     connection.  Refer to the set mode command below for further

     Once  the  connection  is  made,  the ``ppp'' portion of the
prompt will
     change to ``PPP'':

           # ppp MyISP
           ppp ON awfulhak> dial
           Ppp ON awfulhak>
           PPp ON awfulhak>
           PPP ON awfulhak>

     The Ppp prompt indicates that ppp has entered the  authentication phase.
     The  PPp  prompt  indicates that ppp has entered the network
phase.  The PPP
     prompt indicates that ppp has successfully negotiated a network layer
     protocol and is in a usable state.

     If  the  /etc/ppp/ppp.linkup file is available, its contents
are executed
     when the PPP connection is established.   See  the  provided
     example  in  /etc/ppp/ppp.conf.sample which runs a script in
the background
     after the connection is established (refer to the shell  and
bg commands
     below  for  a description of possible substitution strings).
     when  a  connection  is  closed,   the   contents   of   the
     file are executed.  Both of these files have the same format

     In previous versions of ppp,  it  was  necessary  to  re-add
routes such as
     the  default  route  in  the  ppp.linkup file.  ppp supports
`sticky routes',
     where all routes that contain the HISADDR, MYADDR, HISADDR6,
     literals  will  automatically  be updated when the values of
these variables


     If you want to establish a connection using ppp non-interactively (such
     as  from a crontab(5) entry or an at(1) job), you should use
     -background option.  When -background is specified, ppp  attempts to establish
  the connection immediately.  If multiple phone numbers are specified,
 each phone number will be tried once.  If the  attempt
fails, ppp
     exits  immediately  with  a  non-zero exit code.  If it succeeds, then ppp
     becomes a daemon, and returns an exit status of zero to  its
caller.  The
     daemon  exits  automatically if the connection is dropped by
the remote
     system, or it receives a TERM signal.

DIAL ON DEMAND    [Toc]    [Back]

     Demand dialing is enabled with the -auto or -ddial  options.
You must also
  specify  the  destination  label in /etc/ppp/ppp.conf to
use.  It must
     contain the set ifaddr command to define the  remote  peer's
IP address
     (refer to /etc/ppp/ppp.conf.sample).

           # ppp -auto pmdemand

     When  -auto or -ddial is specified, ppp runs as a daemon but
you can still
     configure or examine its  configuration  by  using  the  set
server command in
     /etc/ppp/ppp.conf  (for  example, ``set server +3000 mypasswd'') and connecting
 to the diagnostic port as follows:

           # pppctl 3000   (assuming tun0)
           PPP ON awfulhak> show who
           tcp ( *

     The show who command lists users that are currently connected to ppp itself.
   If  the  diagnostic socket is closed or changed to a
different socket,
 all connections are immediately dropped.

     In -auto mode, when an outgoing packet is detected, ppp will
perform the
     dialing  action  (chat  script)  and try to connect with the
peer.  In -ddial
     mode, the dialing action is performed any time the  line  is
found to be
     down.   If  the  connect  fails, the default behaviour is to
wait 30 seconds
     and then attempt to connect when another outgoing packet  is
     This behaviour can be changed using the set redial command:

           set redial secs[+inc[-max]][.next] [attempts]

     secs      The number of seconds to wait before attempting to
               again.  If the  argument  is  the  literal  string
`random', the delay
 period is a random value between 1 and 30 seconds inclusive.

     inc       The number of seconds that secs should  be  incremented each time
               a  new  dial attempt is made.  The timeout reverts
to secs only
               after a successful connection is established.  The
default value
 for inc is zero.
     max        The  maximum number of times ppp should increment
secs.  The default
 value for max is 10.
     next      The number of seconds to wait before attempting to
dial the
               next  number  in  a  list  of numbers (see the set
phone command).
               The default is 3 seconds.  Again, if the  argument
is the literal
  string  `random', the delay period is a random
value between
               1 and 30 seconds.
     attempts  The maximum number of times to try to connect  for
each outgoing
               packet  that  triggers a dial.  The previous value
is unchanged
               if this parameter is omitted.  If a value of  zero
is specified
               for attempts, ppp will keep trying until a connection is made.

     So, for example:

           set redial 10.3 4

     ...will attempt to connect 4 times for each outgoing  packet
that causes a
     dial attempt with a 3 second delay between each number and a
10 second
     delay after all numbers have been tried.  If multiple  phone
numbers are
     specified,  the total number of attempts is still 4 (it does
not attempt
     each number 4 times).


           set redial 10+10-5.3 20

     ...tells ppp to attempt to  connect  20  times.   After  the
first attempt,
     ppp pauses for 10 seconds.  After the next attempt it pauses
for 20 seconds
 and so on until after the sixth attempt it pauses for 1
minute.  The
     next  14 pauses will also have a duration of one minute.  If
ppp connects,
     disconnects, and fails to connect again, the timeout  starts
again at 10

     Modifying  the dial delay is very useful when running ppp in
-auto mode on
     both ends of the link.  If each end has  the  same  timeout,
both ends wind
     up calling each other at the same time if the link drops and
both ends
     have packets queued.  At some locations, the serial link may
not be reliable,
 and carrier may be lost at inappropriate times.  It is
possible to
     have ppp redial should carrier be unexpectedly lost during a

           set reconnect timeout ntries

     This command tells ppp to re-establish the connection ntries
times on
     loss of carrier with a pause of timeout seconds before  each
try.  For example,

           set reconnect 3 5

     ...tells  ppp  that  on  an  unexpected  loss of carrier, it
should wait 3 seconds
 before attempting to reconnect.  This may happen up  to
5 times before
  ppp gives up.  The default value of ntries is zero (no
     Care should be taken with this option.  If the local timeout
is slightly
     longer  than  the remote timeout, the reconnect feature will
always be
     triggered (up to the given number of times) after the remote
side times
     out  and  hangs  up.  NOTE: In this context, losing too many
LQRs constitutes
 a loss of carrier and will trigger  a  reconnect.   If
the -background
     flag is specified, all phone numbers are dialed at most once
until a connection
 is made.  The next number  redial  period  specified
with the set
     redial command is honoured, as is the reconnect tries value.
If your redial
 value is less than the number of phone  numbers  specified, not all
     the  specified numbers will be tried.  To terminate the program, type:

           PPP ON awfulhak> close
           ppp ON awfulhak> quit all

     A simple quit command will terminate the pppctl(8)  or  telnet(1) connection
  but not the ppp program itself.  You must use quit all
to terminate
     ppp as well.


     To handle an incoming PPP connection request,  follow  these

     1.   Make sure the modem is configured correctly:

          +o    Use Hardware Handshake (CTS/RTS) for flow control.
          +o   Modem should be set to NO echo back (ATE0)  and  NO
results string

     2.    Edit  /etc/ttys to enable a getty(8) on the port where
the modem is
          attached.  For example:

                ttyd1 "/usr/libexec/getty  std.38400"  dialup  on

          Don't  forget  to send a HUP signal to the init(8) process to start
          the getty(8):

                # kill -HUP 1

          It is usually also necessary to train your modem to the
same DTR
          speed as the getty:

                # ppp
                ppp ON awfulhak> set device /dev/cua01
                ppp ON awfulhak> set speed 38400
                ppp ON awfulhak> term
                deflink: Entering terminal mode on /dev/cua01
                Type `~?' for help
                ppp ON awfulhak> quit

     3.    Create a /usr/local/bin/ppplogin file with the following contents:

                #! /bin/sh
                exec /usr/sbin/ppp -direct incoming

          Direct mode (-direct) lets ppp work with stdin and stdout.  You can
          also  use pppctl(8) to connect to a configured diagnostic port, in
          the same manner as with client-side ppp.

          Here,  the  incoming  section  must  be   set   up   in

          Make  sure that the incoming section contains the ``allow users''
          command as appropriate.

     4.   Prepare an account for the incoming user.

          ppp:xxxx:66:66:PPP    Login     User:/home/ppp:/usr/local/bin/ppplogin

          Refer  to the manual entries for adduser(8) and vipw(8)
for details.

     5.   Support for IPCP Domain Name Server  and  NetBIOS  Name
Server negotiation
  can  be enabled using the accept dns and set nbns
commands.  Refer
 to their descriptions below.


     This method differs in that we use ppp to  authenticate  the
     rather than login(1):

     1.    Configure  your  default section in /etc/gettytab with
automatic ppp
          recognition by specifying the `pp' capability:

                default:                             :pp=/usr/local/bin/ppplogin:                        .....

     2.   Configure your serial device(s), enable a getty(8), and
          /usr/local/bin/ppplogin as in the first three steps for
method 1

     3.    Add either ``enable chap'' or ``enable pap'' (or both)
          /etc/ppp/ppp.conf  under  the  ``incoming''  label  (or
whatever label
          ppplogin uses).

     4.    Create an entry in /etc/ppp/ppp.secret for each incoming user:


     Now, as soon as getty(8) detects a ppp connection (by recognising the
     HDLC frame headers), it runs /usr/local/bin/ppplogin.

     It  is  VITAL  that either PAP or CHAP are enabled as above.
If they are
     not, you are allowing anybody to  establish  a  ppp  session
with your machine
  without  a password, opening yourself up to all sorts
of potential


     Normally, the receiver of a  connection  requires  that  the
peer authenticates
 itself.  This may be done using login(1), but alternatively, you
     can use PAP or CHAP.  CHAP is the more secure  of  the  two,
but some
     clients  may not support it.  Once you decide which you wish
to use, add
     the command ``enable chap'' or ``enable pap'' to  the  relevant section of

     You  must then configure the /etc/ppp/ppp.secret file.  This
file contains
     one line per possible client, each  line  containing  up  to
five fields:

           name key [hisaddr [label [callback-number]]]

     The  name  and key specify the client username and password.
If key is `*'
     and PAP is  being  used,  ppp  will  look  up  the  password
database (passwd(5))
     when  authenticating.   If the client does not offer a suitable response
     based on any name/key combination in ppp.secret, authentication fails.

     If  authentication  is successful, hisaddr (if specified) is
used when negotiating
 IP numbers.  See the set ifaddr  command  for  details.

     If  authentication is successful and label is specified, the
current system
 label is changed to match the given  label.   This  will
change the subsequent
 parsing of the ppp.linkup and ppp.linkdown files.

     If authentication is successful and callback-number is specified and
     ``set callback'' has been used in ppp.conf, the client  will
be called
     back   on   the  given  number.   If  CBCP  is  being  used,
callback-number may also
 contain a list of numbers or a `*', as if passed  to  the
``set cbcp''
     command.   The  value  will be used in ppp's subsequent CBCP

PPP OVER TCP and UDP (a.k.a. Tunnelling)    [Toc]    [Back]

     Instead of running ppp over a serial link, it is possible to
use a TCP
     connection  instead by specifying the host, port, and protocol as the device:

           set device ui-gate:6669/tcp

     Instead of opening a serial device, ppp will open a TCP connection to the
     given  machine on the given socket.  It should be noted however that ppp
     doesn't use the telnet protocol and will be unable to  negotiate with a
     telnet  server.  You should set up a port for receiving this
PPP connection
 on the receiving machine (ui-gate).  This  is  done  by
first updating
     /etc/services to name the service:

           ppp-in 6669/tcp # Incoming PPP connections over TCP

     and  updating  /etc/inetd.conf  to tell inetd(8) how to deal
with incoming
     connections on that port:

           ppp-in stream tcp nowait root /usr/sbin/ppp  ppp  -direct ppp-in

     Don't  forget  to send a HUP signal to inetd(8) after you've
     /etc/inetd.conf.  Here, we use  a  label  named  ``ppp-in''.
The entry in
     /etc/ppp/ppp.conf  on  ui-gate (the receiver) should contain
the following:

            set timeout 0
            set ifaddr

     and the entry in /etc/ppp/ppp.linkup should contain:

            add HISADDR

     It is necessary to put the ``add'' command in ppp.linkup  to
ensure that
     the  route  is  only  added after ppp has negotiated and assigned addresses
     to its interface.

     You may also want to enable PAP or CHAP  for  security.   To
enable PAP, add
     the following line:

            enable PAP

     You'll   also   need   to  create  the  following  entry  in

           MyAuthName MyAuthPasswd

     If MyAuthPasswd is a `*', the password is looked up  in  the

     The  entry  in /etc/ppp/ppp.conf on awfulhak (the initiator)
should contain
     the following:

            set escape 0xff
            set device ui-gate:ppp-in/tcp
            set dial
            set timeout 30
            set log Phase Chat Connect hdlc LCP IPCP  IPV6CP  CCP
            set ifaddr

     ...with the route set up in /etc/ppp/ppp.linkup:

            add HISADDR

     Again, if you're enabling PAP, you'll also need this in the
     /etc/ppp/ppp.conf profile:

            set authname MyAuthName
            set authkey MyAuthKey

     We're  assigning the address of to ui-gate, and the
address to awfulhak.  To open the connection, just type

           awfulhak # ppp -background ui-gate

     The result will be an additional "route" on awfulhak to  the
     network via the TCP connection, and an additional "route" on
ui-gate to
     the  network.   The  networks  are  effectively
bridged - the underlying
 TCP connection may be across a public network (such
as the Internet),
 and the PPP traffic  is  conceptually  encapsulated
(although not
     packet  by  packet)  inside  the  TCP stream between the two

     The major disadvantage of this mechanism is that  there  are
two "guaranteed
  delivery"  mechanisms  in  place  - the underlying TCP
stream and whatever
 protocol is used over  the  PPP  link  -  probably  TCP
again.  If packets
     are  lost, both levels will get in each others way trying to
     sending of the missing packet.

     To avoid this overhead, it is also possible to do  all  this
using UDP instead
  of TCP as the transport by simply changing the protocol from "tcp"
     to "udp".  When using UDP as a transport, ppp  will  operate
in synchronous
     mode.   This  is  another gain as the incoming data does not
have to be rearranged
 into packets.

     Care should be taken when adding a default route  through  a
tunnelled setup
  like  this.   It  is  quite common for the default route
(added in
     /etc/ppp/ppp.linkup) to end up routing the link's  TCP  connection through
     the tunnel, effectively garrotting the connection.  To avoid
this, make
     sure you add a static route for the benefit of the link:

            set escape 0xff
            set device ui-gate:ppp-in/tcp
            add ui-gate x.x.x.x

     where ``x.x.x.x'' is the IP number that your route to  ``uigate'' would
     normally use.

     When routing your connection across a public network such as
the Internet,
 it is preferable to encrypt the data.  This can be done
with the
     help  of  the  MPPE  protocol, although currently this means
that you will
     not be able to also compress the traffic as MPPE  is  implemented as a compression
  layer  (thank Microsoft for this).  To enable MPPE
     add the following lines to /etc/ppp/ppp.conf on the server:

             enable MSCHAPv2
             disable deflate pred1
             deny deflate pred1

     Ensure   that   you've   put   the   requisite   entry    in
     (MSCHAPv2  is challenge based, so passwd(5) cannot be used).

     MSCHAPv2 and MPPE are accepted by default, so the client end
should work
     without  any  additional  changes  (although ensure you have
``set authname''
     and ``set authkey'' in your profile).


     The -nat command line option enables network address  translation (a.k.a.
     packet aliasing).  This allows the ppp host to act as a masquerading
     gateway for other computers over a local area network.  Outgoing IP packets
 are NAT'd so that they appear to come from the ppp host,
and incoming
     packets are de-NAT'd so that they are routed to the  correct
machine on
     the  local  area  network.  NAT allows computers on private,
     subnets to have Internet access, although they are invisible
from the
     outside  world.   In  general,  correct ppp operation should
first be verified
 with network address translation disabled.   Then,  the
-nat option
     should  be switched on, and network applications (web browser, telnet(1),
     ftp(1), ping(8), traceroute(8), etc.) should be  checked  on
the ppp host.
     Finally,  the same or similar applications should be checked
on other computers
 in the LAN.  If network applications  work  correctly
on the ppp
     host,  but  not  on other machines in the LAN, then the masquerading software
 is working properly, but the host is  either  not  forwarding or possibly
  receiving  IP packets.  Check that IP forwarding is enabled in
     /etc/sysctl.conf and that other machines have designated the
ppp host as
     the gateway for the LAN.

PACKET FILTERING    [Toc]    [Back]

     This  implementation  supports  packet filtering.  There are
four kinds of
     filters: the in filter, the out filter, the dial filter, and
the alive
     filter.  Here are the basics:

     +o   A filter definition has the following syntax:

         set    filter    name   rule-no   action   [!]   [[host]
         [dst_addr[/width]]] [proto [src cmp port] [dst cmp port]
         [syn] [finrst] [timeout secs]]

         1.   Name should be one of ``in'', ``out'', ``dial'', or

         2.   Rule-no is a numeric value between 0 and 39  specifying the rule
              number.   Rules  are specified in numeric order according to rule-
              no, but only if rule 0 is defined.

         3.   Action may be specified as ``permit'' or  ``deny'',
in which case
              if  a given packet matches the rule, the associated
action is
              taken immediately.  Action can also be specified as
``clear'' to
              clear  the  action  associated with that particular
rule, or as a
              new rule number greater than the current rule.   In
this case, if
              a given packet matches the current rule, the packet
will next be
              matched against the new rule  number  (rather  than
the next rule

              The  action  may optionally be followed with an exclamation mark
              (`!'), telling ppp to reverse the sense of the following match.

         4.    [src_addr[/width]]  and [dst_addr[/width]] are the
source and
              destination IP number specifications.  If  [/width]
is specified,
              it  gives  the number of relevant netmask bits, allowing the specification
 of an address range.

              Either src_addr or dst_addr may be given the values
              HISADDR,  MYADDR6,  or  HISADDR6  (refer to the description of the
              bg command for  a  description  of  these  values).
When these values
  are used, the filters will be updated any time
the values
              change.  This is similar to the  behaviour  of  the
add command below.

         5.   Proto may be any protocol from protocols(5).

         6.    Cmp  is  one of `lt', `eq', or `gt', meaning lessthan, equal, and
              greater-than, respectively.  Port can be  specified
as a numeric
              port or by a service name from /etc/services.

         7.   The `estab', `syn', and `finrst' flags are only allowed when
              proto is set to `tcp', and  represent  the  TH_ACK,
TH_SYN, and
              TH_FIN or TH_RST TCP flags, respectively.

         8.    The timeout value adjusts the current idle timeout
to at least
              secs seconds.  If a timeout is given in  the  alive
filter as well
              as  in the in/out filter, the in/out value is used.
If no timeout
 is given, the default timeout  (set  using  set
timeout and defaulting
 to 180 seconds) is used.

     +o    Each filter can hold up to 40 rules, starting from rule
0.  The entire
 rule set is not effective until rule 0 is  defined,
i.e., the default
 is to allow everything through.

     +o    If  no rule in a defined set of rules matches a packet,
that packet
         will be discarded (blocked).  If there are no rules in a
given filter,
 the packet will be permitted.

     +o    It's  possible  to  filter  based on the payload of UDP
frames where
         those frames contain a PROTO_IP PPP frame  header.   See
the filter-
         decapsulation option below for further details.

     +o   Use ``set filter name -1'' to flush all rules.

     See /etc/ppp/ppp.conf.sample.


     To  check/set  the  idle  timer, use the show bundle and set
timeout commands:

           ppp ON awfulhak> set timeout 600

     The timeout period is measured in seconds, the default value
for which is
     180 seconds (or 3 min).  To disable the idle timer function,
use the following

           ppp ON awfulhak> set timeout 0

     In -ddial and -dedicated modes, the idle timeout is ignored.
In -auto
     mode,  when  the  idle  timeout causes the PPP session to be
closed, the ppp
     program itself remains running.  Another trigger packet will
cause it to
     attempt to re-establish the link.


     ppp  supports both Predictor type 1 and deflate compression.
By default,
     ppp will attempt to use (or be willing to accept) both  compression protocols
  when  the peer agrees (or requests them).  The deflate
protocol is
     preferred by ppp.  Refer to the disable and deny commands if
you wish to
     disable this functionality.

     It  is  possible to use a different compression algorithm in
each direction
     by using only one of  ``disable  deflate''  and  ``deny  deflate'' (assuming
     that the peer supports both algorithms).

     By  default, when negotiating DEFLATE, ppp will use a window
size of 15.
     Refer to the set deflate command if you wish to change  this

     A  special algorithm called DEFLATE24 is also available, and
is disabled
     and denied by default.  This is exactly the same as  DEFLATE
except that
     it uses CCP ID 24 to negotiate.  This allows ppp to successfully negotiate
 DEFLATE with pppd version 2.3.*.


     For IPv4, ppp uses IPCP to  negotiate  IP  addresses.   Each
side of the connection
  specifies  the IP address that it's willing to use,
and if the requested
 IP address is acceptable then ppp returns an ACK  to
the requester.
   Otherwise,  ppp  returns  NAK to suggest that the
peer use a different
 IP address.  When both sides of the connection  agree
to accept the
     received  request (and send an ACK), IPCP is set to the open
state and a
     network level connection is established.   To  control  this
IPCP behaviour,
     this  implementation has the set ifaddr command for defining
the local and
     remote IP address:

           set  ifaddr  [src_addr[/nn]  [dst_addr[/nn]   [netmask

     src_addr is the IP address that the local side is willing to
     dst_addr is the IP address which the remote side should use,
and netmask
     is  the  netmask  that should be used.  src_addr defaults to
the current
     hostname(1), dst_addr defaults to, and  netmask  defaults to whatever
  mask is appropriate for src_addr.  It is only possible
to make
     netmask smaller  than  the  default.   The  usual  value  is, as
     most  kernels ignore the netmask of a POINTOPOINT interface.

     Some incorrect PPP implementations require that the peer negotiates a
     specific  IP  address  instead  of src_addr.  If this is the
     trigger_addr may be used to specify this  IP  number.   This
will not affect
     the  routing  table  unless  the other side agrees with this
proposed number.

           set      ifaddr

     The above specification means:

     +o    I  will  first  suggest  that  my  IP address should be, but I will
         only accept an address of
     +o   I strongly insist that the peer  uses  as
his own address
         and   won't  permit  the  use  of  any  IP  address  but  When
         the peer requests another IP address, I will always suggest that it
     +o     The  routing  table  entry  will  have  a  netmask  of

     This is all fine when each side has a pre-determined IP  address, however
     it  is  often  the  case that one side is acting as a server
which controls
     all IP addresses and the other side should go along with it.
In order to
     allow more flexible behaviour, the set ifaddr command allows
the user to
     specify IP addresses more loosely:

           set ifaddr

     A number followed by a slash (`/') represents the number  of
bits significant
 in the IP address.  The above example means:

     +o    I'd  like  to use as my address if it is
possible, but
         I'll also accept any IP  address  between
     +o    I'd  like  to make him use as his own address, but I'll
         also  permit  him  to  use  any   IP   address   between and
     +o   As you may have already noticed, is equivalent to saying
     +o   As an exception, 0 is equivalent to,  meaning
that I have no
         preferred IP address and will obey the remote peer's selection.  When
         using zero, no routing table entries will be made  until
a connection
         is established.
     +o means that I'll accept/permit any IP address but I'll
         suggest that be used first.

     When negotiating IPv6 addresses, no control is given to  the
user.  IPV6CP
     negotiation is fully automatic.


     The  following steps should be taken when connecting to your

     1.   Describe your providers phone  number(s)  in  the  dial
script using the
          set phone command.  This command allows you to set multiple phone
          numbers for dialing and redialing separated by either a
pipe (`|')
          or a colon (`:'):

                set phone telno[|backupnumber]...[:nextnumber]...

          Numbers after the first in a  pipe-separated  list  are
only used if
          the  previous number was used in a failed dial or login
script.  Numbers
 separated by a colon are used sequentially,  irrespective of
          what happened as a result of using the previous number.
For example:

                set phone "1234567|2345678:3456789|4567890"

          Here, the 1234567 number is attempted.  If the dial  or
login script
          fails, the 2345678 number is used next time, but *only*
if the dial
          or login script fails.  On the  dial  after  this,  the
3456789 number
          is  used.   The 4567890 number is only used if the dial
or login
          script  using  the  3456789  fails.   Irrespective   of
whether the login
          script  of  the  2345678  number succeeds or fails, the
next number is
          still the 3456789 number.

          As many pipes and colons can be used as  are  necessary
(although a
          given  site would usually prefer to use either the pipe
or the colon,
          but not both).  The next number redial timeout is  used
between all
          numbers.  When the end of the list is reached, the normal redial period
 is used before starting at  the  beginning  again.
The selected
          phone  number  is  substituted for the \T string in the
set dial command
 (see below).

     2.   Set up your redial requirements using set redial.   For
example, if
          you  have a bad telephone line or your provider is usually engaged
          (not so common these days), you may want to specify the

                set redial 10 4

          This  says that up to 4 phone calls should be attempted
with a pause
          of 10 seconds before dialing the first number again.

     3.   Describe your login procedure using the  set  dial  and
set login commands.
   The  set  dial command is used to talk to your
modem and establish
 a link with your ISP, for example:

                set dial "ABORT BUSY ABORT NO\sCARRIER TIMEOUT 4
                  ATZ OK-ATZ-OK ATDT\T TIMEOUT 60 CONNECT"

          This modem "chat" string means:

          +o   Abort if the string "BUSY" or "NO CARRIER"  is  received.

          +o   Set the timeout to 4 seconds.

          +o   Expect nothing.

          +o   Send ATZ.

          +o    Expect  OK.   If  that's not received within the 4
second timeout,
              send ATZ and expect OK.

          +o   Send ATDTxxxxxxx where xxxxxxx is the  next  number
in the phone
              list from above.

          +o   Set the timeout to 60.

          +o   Wait for the CONNECT string.

          Once the connection is established, the login script is
          This script is written in the same style  as  the  dial
script, but
          care  should  be  taken  to  avoid having your password


 Similar pages
Name OS Title
pppoesd.conf HP-UX PPPoE (Point to Point Protocol over Ethernet) server configuration file
pppoerd.conf HP-UX PPPoE (Point to Point Protocol over Ethernet) relay configuration file
pppoec.conf HP-UX PPPoE (Point to Point Protocol over Ethernet) client configuration file
sppp OpenBSD point to point protocol network layer for synchronous lines
sppp FreeBSD point to point protocol network layer for synchronous lines
pppoesd HP-UX PPPoE (Point-to-Point Protocol over Ethernet) server daemon
pppoerd HP-UX PPPoE (Point to Point Protocol over Ethernet) relay
pppoec HP-UX PPPoE (Point to Point Protocol over Ethernet) client
if_ppp FreeBSD point to point protocol network interface
ppp FreeBSD point to point protocol network interface
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service