PC World 1999 August/PCWorld_1999-08_cd.bin/doc/FAQ/txt/PPP-FAQ

Text File | 1999-04-09 | 87KB | 1,958 lines

  Linux PPP FAQ
  Al Longyear, [e-mail]
  v1.13, 9 December 1996

  This document contains a list the most Frequently Asked Questions
  (FAQ) about PPP for Linux (and their answers). It is really not a
  HOWTO, but is in ┤classical┤ Question / Answer form.  We have a dif¡
  ferent document which represents the PPP-HOWTO. It is written by
  Robert Hart.

  1.  Preface

  Please send any corrections to [e-mail].

  This is but one of the Linux HOWTO/FAQ documents. You can get the
  HOWTO┤s from sunsite.unc.edu:/pub/Linux/docs/HOWTO (this is the
  ┤official┤ place) or via WWW from the Linux Documentation home page.
  You cannot rely on the HOWTO┤s being posted to comp.os.linux.answers,
  as some news feeds have complained about their size.

  Throughout this document, I have used the word ┤remote┤ to mean 'the
  system at the other end of the modem link┤. It is also called ┤peer┤
  in the PPP documentation. Another name for this is called the
  ┤gateway┤ when the term is use for routing.  Its IP address will show
  as the ┤P-t-P┤ address if you use ifconfig.

  Microsoft is a registered trademark of Microsoft Corporation. Morning
  Star is a registered trademark of Morning Star Technologies
  Incorporated. All other products mentioned are trademarks of their
  respective companies.

  2.  General information

  2.1.  What is PPP?

  PPP, or Point-to-Point Protocol, is a recognized ┤official┤ Internet
  protocol. It is a protocol used to exchange IP frames (and others)
  over a serial link. The current base RFC for PPP is 1661. There are
  many related ones.

  Contrary to what some people think, it does not mean ┤Peer to Peer
  Processing┤; although you may do peer-peer communications using TCP/IP
  over a PPP link.

  2.2.  My university (company) does not support PPP. Can I use PPP?

  In general, no. A ┤classical┤ PPP implementation requires that you
  make changes to the routes and network devices supported by the
  operating system. This may mean that you will have to rebuild the
  kernel for the remote computer.

  This is not a job for a general user. If you can convince your
  administration people that PPP is a ┤good thing┤ then you stand a
  chance of getting it implemented. If you can't, then you probably
  can't use PPP.

  However, if you are using a system which is supported by the people
  who are marketing the ┤TIA┤ (The Internet Adapter) package, then there
  is hope. I do not have much information on this package, however, from
  what I have found, they plan to support PPP in ┤the next version┤. (My
  information may be old. Contact them directly. Information on TIA is
  available at ftp.marketplace.com in the /pub/tia directory.)
  If your system is not supported by TIA, and you choose not to use
  slirp, and you can┤t convince the admin group to support PPP then you
  should use the ┤term┤ package. Some service providers will object to
  you running ┤term┤. They have many different reasons, however the most
  common is ┤security concerns┤.

  There is a version of TIA for Linux.

  In addition to TIA, Danny Gasparovski wrote a program called slirp
  which will perform functions similar to TIA. The program is currently
  available with the source code from the ftp site
  blitzen.canberra.edu.au:/pub/slirp.  You should obtain the code if you
  wish additional information about this program. From the initial
  examination, it is seems to be an excellent contender to the
  commercial TIA program.

  2.3.  Where is PPP?

  It is in two parts. The first part is in the kernel.  In the kernels
  from 1.1.13, the driver is part of the network system drivers.

  The second part is the ┤daemon┤ process, pppd.  This is a required
  process. The source to it is in the file ppp-2.2.0e.tar.gz located on
  sunsite.unc.edu in the /pub/Linux/system/Network/serial directory.

  Version 2.2 and above are designed to be used only with the 1.2 and
  later kernels. Please don't use this version with the 1.1 series
  kernels as they are out of date for either the tty driver or the
  networking software.

  2.4.  I just obtained PPP. What do I do with it?

  Read The Fine Material available.

  Start by reading the README file and then the README.linux file.  The
  documentation sources are listed below.

  2.5.  Where are additional sources of information for PPP?

  (Where┤s the documentation? Is there a HOWTO?, etc.)

  There are several sources of information for the PPP protocol as
  implemented under Linux.

  ╖  The README file in the source package.

  ╖  The README.linux file in the source package.

  ╖  The Net-2-HOWTO document.

  ╖  The PPP-HOWTO document.

  ╖  The Network Administration Guide.

  ╖  The pppd man page.

  ╖  The FAQ document for the comp.protocols.ppp newsgroup.

  The HOWTO and this FAQ are stored in the usual place for the Linux
  HOWTOs. That is currently on sunsite.unc.edu in the directory
  /pub/Linux/docs/HOWTO.

  The Network Administration Guide is available in the
  /pub/Linux/docs/LPD/network-guide directory on sunsite. It is also
  published by O┤Riellly and Associates.  So, if you want a really
  professional document, then buy a copy from your local bookstore.

  The ┤man┤ pages are included in the source package. You will probably
  have to move them to the normal man directory, /usr/man/man8 before
  the man command may find them.  Alternately, you may use nroff and
  more to view them directly.

  The FAQ for comp.protocols.ppp describes the PPP protocol itself and
  the various implementations. You will find the FAQ for the usenet news
  group, comp.protocols.ppp, archived on rtfm.mit.edu in the /usenet
  directory. It is in eight parts at the present time.

  2.6.  Would someone please send me scripts for PPP so that I may see
  how they are written?

  There are a few scripts which are included with the source package for
  pppd. It will cover the normal types of access where you are requested
  to enter a UNIX login and password.

  Specific ┤scripts┤ for specific systems are not included.  If you have
  problems with a specific connection then you should contact the help
  desk for your site, the local news group at the site, or the general
  usenet groups for Linux. Unfortunately, time does not permit me to
  answer questions for help on supplying a script for your specific
  system.

  2.7.  Where should I post questions about PPP?

  The primary usenet group for the PPP implementations is
  comp.protocols.ppp or comp.os.linux.setup.  Use this group for general
  questions such as ┤How do I use pppd?┤ or ┤Why doesn't this work?┤.

  Questions such as ┤Why wont pppd compile?┤ are generally linux related
  and belong on the comp.os.linux.networking group.

  Please don't use comp.os.linux.help even if your site should still
  carry this obsolete news group.

  2.8.  The PPP software doesn't work. HELP!!!

  This is one of the most sickening questions. I realize that this is a
  plea for help. However, it is practically useless to post this message
  with no other information. I, and most others, will only ignore it.

  Please see the question regarding errors which normally occur at the
  modem┤s disconnection. They are not the cause of a problem, only a
  symptom. Posting a message with only those errors is also meaningless.

  What is needed is the output of the system log (syslog) when you run
  the pppd program with the option ┤debug┤. In addition, if you are
  using chat then please use the ┤-v┤ option to run the sequence with
  verbose output.

  Please include the output from the kernel┤s startup.  This shows the
  various kernel hardware information such as your UART type, PPP
  version, etc.

  Please include all information that you can relating to the problem.
  However your system configuration, disk drive configuration, terminal
  type, mouse location and button status, etc. are irrelevant. What is
  important is the system to which your are trying to contact, the PPP
  (or terminal server) that they are using, the modem types and speed
  that you are using, etc.

  Take care and go through the output. Remove the references to the
  telephone number, your account name, and the password.  They are not
  important to analyzing the problem and would pose a security risk to
  you if you published them to usenet. Also discard the lines which
  neither come from the kernel nor pppd.

  Do NOT run the pppd program with the option ┤kdebug 31┤ and post that!

  If the problem warrants examining the data stream, then you will be
  contacted by email and asked to mail the trace.  Usenet already costs
  too much for too many people.

  Information is written to various levels. The debug information is
  written to the debug level. The informational messages are written to
  the info level. The errors are written to the error level. Please
  include all levels the ┤local2┤ group which come from the pppd
  process.

  In addition, please do not delete the time stamp information. It is
  important.

  3.  Other implementations

  3.1.  Do you know of a implementation for PPP other than Linux? I
  would like one for HP-UX, or AIX, or ... (you fill in the blank)?

  Check the PPP FAQ document mentioned above.

  HP-UX is supported by the commercial Morningstar package. AIX is in
  the current 2.2 pppd package.

  If you don't find one listed then post to the comp.protocols.ppp group
  and not the Linux group.

  (Please don't mail me asking for ┤Do you know of a PPP package for
  ...┤? These requests will now be ┤appropriately┤ filed. ;-))

  The pppd package placed on sunsite does not contain the code which
  would use the some of the ports which use the streams interface. This
  is due to the reason that the streams interface contains a restrictive
  copyright which prevents the commercial packaging of the source which
  contains the module. We, the people who have been working on the pppd
  package, have tried to contact the author of the original module for
  streams in an attempt to have the copyright changed. He was un-
  responsive at first. Now he can not be located.

  For this reason, and due to the fact that the sunsite site is for
  Linux, I decided to remove the AIX, Next, and any other port of pppd
  which involved the original streams code. The SunOS and Solaris ports
  are included since their streams implementation has been rewritten.
  You should continue to find the BSD variation as well as the Linux
  form in the package. If you wish the pppd code for a system which uses
  streams then you will have to consult the PPP-FAQ for the location of
  the pppd archive site near you. Alternately, you can use archie.  Just
  don't use the mirrors for sunsite as they will not have the code.

  3.2.  Did you know that there is a program called ┤dp┤?

  Yes, we know. The dp package was considered very early in the
  development stage quite a few months back. It is nice. It supports
  ┤demand dial┤. It also only works with systems which support streams.
  This is primarily the SunOS (Solaris) operating systems.
  The question of demand dial is covered later in this document.

  Linux, at the present time, does not supports streams.

  There are several other packages for PPP available on the ┤net┤. The
  ┤portable PPP┤ package is very much like the TIA code. There is
  another package called simply ┤PPP┤. There is code for PPP in the KA9Q
  package.

  The slirp and TIA code will do PPP as well.

  Of all of the packages available, the pppd package was the closest to
  the requirements and functions of Linux to warrant the port.

  (If you want more information about these other packages, ask in the
  comp.protocols.ppp group!)

  3.3.  What RFCs describe the PPP protocol?

  The current implementation of PPP is a mixture of several.

  The major portion of the PPP code is written against the RFCs 1331 and
  1332. These RFCs were later obsoleted. 1331 was replaced by 1548 and
  that, in turn, was obsoleted by 1661 six months later. Most
  implementations of PPP will be happy to talk to the Linux PPP code.

  This does not mean that the Linux PPP package is obsolete. It is only
  that at the time that the package was written the current RFC was
  1331. Any changes in subsequent RFC documents has been incorportated
  within the pppd package and it is ┤current┤ by today┤s standards.

  A complete list is in the faq for comp.protocols.ppp.

  [to quote the FAQ document]:

       All of 1134, 1171, and 1172 (and 1055, for that matter :-)
       have been obsoleted. They┤re interesting only if you want to
       debug a connection with an ancient PPP implementation, and
       you┤re wondering why (e.g.) it asked you for IPCP option 2
       with a length of only 4, and Compression-Type 0x0037.

       (There┤s a lot of that still running around - be careful out
       there.)

  Linux PPP will automatically detect these conditions and compensate
  for it.

  4.  Compatibility

  4.1.  Can PPP talk to a SLIP interface?

  No. SLIP works with SLIP. PPP works with PPP.

  Some vendors may offer products which work both as SLIP and PPP.
  However, they must be configured to run in one mode or the other.
  There is no present method to determine, based upon the protocol
  passed at the time of a connection, which combination of SLIP
  protocols or PPP is being requested.

  4.2.  Which is better? PPP or SLIP?

  IT DEPENDS UPON MANY FACTORS.

  The people who post this type of question have usually not read the
  Net-2-HOWTO document.

  A good technical discussion is available at Morning Star┤s www server,
  www.morningstar.com.

  4.3.  Is CHAP or PAP better for authentication?

  If you have the choice, use CHAP. Failing that, PAP is better than
  nothing.

  4.4.  What about CHAP which Microsoft uses with Windows NT?

  CHAP is a Cryptographic Handshake Authentication Protocol.  It means
  that it takes some form of a key and will encrypt the response using a
  one-way encryption algorithm. The algorithm is negotiated at the time
  that the CHAP protocol is requested. The most common is called MD5. It
  has an encryption code of 05 in the CHAP request.

  Microsoft uses a DES algorithm which, until recently, was incompatible
  with the pppd process. If you wish to connect to a Windows NT server,
  there are a set of patches which are included with the pppd source
  code to support the DES style used by Microsoft.

  Contrary to what some un-informed people believe at Stanford
  University believe, Microsoft did not just go against the
  recommendations of the IETF working group. The code values were
  properly requested and the implementation has been fully documented.

  5.  Authentication files

  5.1.  What goes into the /etc/ppp/pap-secrets file? Do you have a sam¡
  ple? Or, my ISP requires that I use PAP. How do I do that?

  The PAP protocol is most often implemented as your user name and
  password. You need to include the name of the remote system, your
  account name, and the password. If the user on abbot wishes to call
  costello, the entry would be similar to the following.

       #account   remote    password     IP address list
       abbott     *         firstbase

  To use PAP authentication with the simplest case, you should also
  include the ┤user┤ option to specify which of the pap-secrets file
  entries is to be used. The option is explained in the pppd man page.
  However, the simplest for this example is:

  user abbott

  If your system needs to use PAP to authenticate itself with an ISP who
  requires that you use PAP then you need only do two things.

  1. Add the entry to the /etc/ppp/pap-secrets file which lists your
     account name, an asterisk, and your password. If you have multiple
     accounts at different providers, each with the same name, then you
     would use the provider's name with in lieu of the asterisk and use
     the remotename option with pppd to specify the provider's name.

  2. Use the 'user' option to pppd to specify the account name so that
     pppd knows which entry in the /etc/ppp/pap-secrets file is to be
     used.

  That's all that you should do. Do NOT attempt to use the +pap, or
  +chap, or auth options. These will only cause your authentication
  sequence to fail since they all force the ISP to authenticate itself
  with you. Since most ISP's will not do this, and you have told pppd
  that the ISP must by using these options, then pppd will not permit
  the ISP to connect to you -- or, to put it in practical terms, you
  connect to the ISP.

  5.2.  What goes into the /etc/ppp/chap-secrets file? Do you have a
  sample?

  The most common problem is that people don't recognize that CHAP deals
  with a pair of secrets. Both computers involved in the link must have
  both secrets to work.

  For example, if abbot wants to talk to costello, then abbot┤s file
  would have:

       #account   remote     password    IP address list
       abbott     costello   firstbase
       costello   abbott     who

  And costello┤s file would have:

       #account   remote     password    IP address list
       abbott     costello   firstbase
       costello   abbott     who

  (Yes, it is the same data.)

  The difference between abbott and costello would be the options that
  are used with pppd. The abbott system would have

       name abbott remotename costello

  while the costello system has just the opposite of

  name costello remotename abbott

  6.  Construction problems

  6.1.  I get compile errors when I try to compile the kernel

  This usually comes from skipping the ┤make kernel┤ step in the
  instructions. The ┤make kernel┤ is not a sequence telling you to build
  the kernel, but the actual command to be entered. That is, issue the
  command for ┤make┤ and build the target called ┤kernel┤.

  There are some problems with this logic however. If you are using
  Slackware 3.0, there is a bug in the ┤rev┤ program with this package.
  Before the kernel sequence may be patched properly, you must first
  update the ┤rev┤ program from the file
  <ftp://ftp.cdrom.com/pub/linux/slakware/a8/util.tgz>.

  It is very important that you do not attempt to replace any file which
  this package does not replace itself. Do not attempt to force it to
  replace the ppp.c driver if the ┤make kernel┤ does not wish to do
  this. There is a date stamp within the files and the files will not be
  replaced if you currently have a more current version of the driver
  already in the kernel.

  Once the pieces have been installed, please rebuild the kernel at this
  time. Do this even if you have previously constructed the kernel to
  support PPP. The driver shipped with the 1.2 and early 1.3 kernels is
  not compatible with the 2.2 version of pppd.

  Once you have rebuilt the kernel then you may resume to build the pppd
  process, chat, and pppstats.

  7.  Problems running pppd

  7.1.  pppd says that version 0.0.0 is out of date

  There are several reasons which will generate this message.

  ╖  You are attempting to run the 2.1 version of pppd with the 2.2
     kernel drivers.

     This may occur if you are using the 2.x series kernels and did not
     see the notice in the Changes file that you need the 2.2.0 version
     of pppd.

     It may also occur if you are using a script which has a fixed
     location for the pppd process. The 2.1 version of pppd was stored
     in the default location of /usr/lib/ppp/pppd. The 2.2 version moved
     to the more ┤standard┤ location of /usr/sbin/pppd. If you have a
     script which is using the /usr/lib/pppd then it is probable that
     you are actually using the wrong version of pppd.

     This may also require that you re-compile front end programs such
     as dip or diald. These programs have the location of pppd embedded
     within them.

  ╖  You are attempting to run the pppd process from an account other
     than the root user and the process is not secured setuid to root.

     What happens is that the pppd process attempts to issue a request
     to find the version of the driver in the kernel. This request is
     only acceptable if the calling process is the root account. Since
     you are not running as the root user and have not secured the
     program to be setuid to root, then the request fails. Since the
     request to fetch the driver version fails, the default value is
     0.0.0. This is the wrong version and the message is generated.

     Additional information is in the next question.

  7.2.  pppd says that that the kernel is not configured for PPP. I know
  that I enabled the option and built the kernel.

  Make sure that you did rebuild the kernel and that you are running it.

  Make sure that you don't have an old copy of pppd on your disk and you
  are running that version. The previous version of pppd was stored on
  /usr/lib/ppp. Many people objected to this location. The 2.2 code has
  moved the pppd, chat, and pppstats to the /usr/sbin directory. If your
  scripts still reference /usr/lib/ppp then you will probably run the
  old code.

  7.3.  pppd wont run unless you are root

  The pppd process needs to make changes to the networking system and
  this can only be done if you are the root user. If you wish to run
  pppd from other than the root user then the pppd program needs to be
  secured ┤suid to root┤.

       chown root /usr/sbin/pppd
       chmod 4755 /usr/sbin/pppd

  If you wish to control the pppd access to a select group of people,
  then make the pppd process owned by the group and do not permit all
  others to run the program.

  7.4.  unable to create pid file: no such file or directory

  You need to create the directory /var/run.  On earlier Slackware
  distributions, this was a symbolic link to the /etc directory.

  This is a warning. The PPP software will work normally in spite of
  this message. However, the ppp-off script depends upon this file. It
  is a good idea to create the directory or make the link to the
  appropriate location.

  The posix header, paths.h, defines the location for the pid file under
  the name ┤_VAR_RUN┤.  If you wish to use a different directory for PPP
  and others, change the value for this define and rebuild the software.

  7.5.  /etc/ppp/options: no such file or directory

  You must create the directory /etc/ppp and have a file called
  ┤options┤ in that directory. It needs to be readable by the pppd
  process (root).

  The file may be empty. To make an empty file use the ┤touch┤ command.

  See the pppd man page, pppd.8, for a description of this file.

  7.6.  Could not determine local IP address

  This happens with many configurations of the Telebit Netblazer. The
  problem is not the terminal server, but the site which has not
  configured the terminal server with a set of IP addresses.

  The Netblazer does not have your IP address. You do not have your IP
  address. The link will not work unless both IP addresses are known.

  ╖  The Netblazer does not have your IP address and you do not have
     your IP address.

  ╖  The Netblazer does know its IP address and you do not have its IP
     address.

  The link will not work unless both IP addresses are known.

  You must tell the Netblazer the IP addresses to be used. Use the local
  IP address and the remote IP address as a parameter to the pppd
  process.

  Use the pppd option format of:

  local_ip:remote_ip

  (That is the local IP address, a colon, and the remote IP address.)

  7.7.  Could not determine remote IP address

  See the previous answer.

  7.8.  I keep getting the message to the effect that the magic number
  is always NAKed. The system will not connect.

  There is a one in over four billion chance that the two systems have
  chosen the same magic number. If you get a continual failure about the
  magic number, the chances that this is a fluke will geometrically
  reduce.

  The two most common reasons for this failure are:

  ╖  The remote PPP software is not running when you think it is. Is the
     remote system configured to run PPP? Did you use the proper
     account? Did you use the proper password for this account? If you
     are using a scripting tool such as chat, then did you miss a prompt
     and are really talking to the logon process and not the PPP code?
     Is the PPP process in the expected location? Is the privileges
     suitable so that you may run it?

     This would indicate that the shell is doing the local echo of the
     data. This is the more common reason.

  ╖  The modem has disconnected immediately upon making the connection
     and logging you on to the remote. Most modems are configured to
     echo the data sent to them and you are seeing the local echo from
     the modem.

  In either case, the Linux system is sending data to the remote which
  is being fed immediately back into the serial receiver. This is not an
  acceptable condition. You have what is called a ┤loop┤.

  7.9.  protocol reject for protocol fffb

  This usually occurs when you are trying to connect to a Xyplex
  terminal server. Version 5.1 of the Xyplex terminal server software,
  according to Xyplex, has numerous problems with PPP. It is strongly
  recommended that you update the Xyplex software to at least version
  5.3.

  If you must use Xyplex version 5.1, then use the pppd option ┤vj-max-
  slots 3┤ to limit the number of slots to three. The problem on the
  Xyplex server is that it will accept the request for the default 16
  slots, but fail to operate beyond the third slot. It should have
  return a NAK frame with the limit, but it does not.

  Alternately, you can disable the Van Jacobson header compression with
  the option ┤-vj┤.

  7.10.  The PPP software connects, sends quite a few frames, but still
  does not seem to connect. Why is that?

  Linux does not support RPI modems. If your modem is RPI then you will
  have to find a different modem. This is not likely to change in the
  future given the statements made by Rockwell┤s management.

  Examine the system log when you use the ┤debug┤ option. (You will need
  the system log data anyway if you are going to ask for help.) If the
  trace shows that it is sending the LCP-request frame over and over
  again and the id number is not incrementing then you are not
  exchanging frames with the remote PPP software.

  The common reasons for this for this are:

  ╖  You don't have the PPP software running on the other end.  You are
     sending the PPP frames to some other program which is probably
     saying ┤What is this #$%percent;^ ?┤

  ╖  Please make sure that you have the PPP software started on the
     other end before you enter the PPP protocol sequence. Try to use a
     normal modem program and go through the logon sequence that you
     would normally do. Do you see the PPP frames being sent to you?

     The PPP frames are fairly distinctive. They will be about 40
     characters in length and contain several { characters. They should
     not have a carriage return character after them and are sent out in
     a burst with a pause between the bursts.

  ╖  The line is not ┤eight bit clean┤. This means that you need to have
     eight data bits, no parity, and one stop bit.  The PPP link
     absolutely requires eight data bits.

     The pppd software will automatically put the line into eight data
     bits, no parity, and one stop bit. The remote must match this
     configuration or framing and parity errors may occur.

     PPP will escape characters. It is not possible for it to escape
     bits as kermit does. PPP will not work with a seven bit
     communications link.
  ╖  The remote is configured to require authentication such as PAP or
     CHAP. You have not configured the local system to use this feature.
     Therefore, the remote is discarding all of your frames until it
     sees a valid authentication frame from you. Since you are not
     configured to generate the frames, the IPCP frames which you send
     are being ignored.

     In this case, either configure the remote to not expect
     authentication or configure the local system to do authentication
     and supply the proper secrets.

     Examine the receipt of the LCP configure frame. If it shows an
     ┤auth┤ type, then the remote is configured for authentication.

  7.11.  The /etc/ppp/ip-up scripts won't work.

  The pppd process launches the program at the location /etc/ppp/ip-up
  when the IP layer goes up. It gives it parameters which define the
  line status. Such things include the device name, communications
  speed, and IP addresses.

  However, what may not be clear is that it treats this file as a
  program. It is not a script. The program is started by using the
  exec() function of Linux.

  What this means is that if you wish to use a script for these
  programs, then you must do two things.

  ╖  You need to have the file marked as executable with chmod.  The
     proper mode for the file should be mode 100. Mode 500 is acceptable
     if you wish to read the file and mode 700 is acceptable if you wish
     to write to the file. The file should be owned by the root user.

  ╖  The file must have as the first line the sequence:

       #!/bin/sh

  The # character must be in the first character position of the very
  first line of the file. The interpreter program, /bin/sh in this case,
  may be any program which is expected to run the script. Most people
  will use the Bourne shell for this purpose.  It is commonly stored in
  the location /bin/sh. Other commonly used interpreters are perl and
  csh. What is important is that the first two characters of the file be
  the # and ! characters respectively.

  7.12.  I can't execute /etc/ppp/ip-up: Exec format error

  Please refer to the answer to the previous question.

  7.13.  How do I use PPP with a system which uses dynamic IP assign¡
  ments? It assigns a different IP address to me with each call.

  The assignment of the local IP address is a function of the options
  given to pppd and the IPCP protocol. You should use the ┤magic┤ IP
  address of 0.0.0.0 if you must specify the local IP address. Most
  people simply leave the local IP address out of the option list.

  The other option which is closely tied to this is called
  ┤noipdefault┤. The noipdefault option instructs the pppd process to
  not attempt to guess the local IP address from your hostname and the
  IP addresses in the /etc/hosts file. Most people use this option when
  the IP address is dynamically assigned. However, this option does not
  mean ┤use dynamic IP addresses┤. The use of dynamic IP addresses is
  automatic when the local IP address is not given.

  7.14.  How do I know what IP address was given to me when it is dynam¡
  ically assigned?

  Use the /etc/ppp/ip-up hook. The local IP address is the fourth
  parameter. This will be executed when pppd knows the IP address for
  the local system. The fifth parameter is the remote IP address if you
  should wish to know this value as well.

  If you are curious about the value assigned then you may use the
  ifconfig program to display the current settings. It will show you the
  current values for both the local IP address and the IP address
  assigned to the remote under the P-t-P heading.

  7.15.  I just upgraded my system and now pppd reports that the option
  -v is not supported. Why?

  Did you just upgrade to Linux ┤96 from Walnut Creek CDROM? It is also
  known as the Slackware 3.1 package. The problem is that the pppd
  executable in the /usr/sbin directory was renamed in that distribution
  and a script was installed in its place. This script was to find the
  version of the operating system and then either run the 2.2 or 2.1
  version of pppd.

  Unfortunately, the script does not work properly with the pppd process
  when you use the connect option.

  So, to correct the problem, remove the script and replace it with the
  proper pppd executable.

  7.16.  The pppd process reports that it won't replace the existing
  default route. How do I get it to use the default route?

  This is another Slackware ┤enhancement┤. The Slackware package added a
  default route to the ethernet controller during the startup sequence
  in the /etc/rc.init1 script. This statement is:

       /usr/bin/route add default dev eth0

  The problem is that the statement has absolutely no functionality with
  the proper routing. A default route is designed to be sent to a
  router, not just dumped on the ethernet controller.

  The pppd process is configured to not replace a default route if a
  default route is currently used before it starts. It does this for
  security reasons. Since Slackware uses the default route incorrectly,
  the pppd process is unable to install a new default route.

  To correct the problem you need to replace the default route statement
  in the /etc/rc.init1 script with a proper network route. See the
  Net-2-HOWTO for the instructions on what should be used.
  7.17.  When I run pppd it says that support is not in the kernel.

  There are a few reasons for this to be generated.

  ╖  You are running the pppd process from an account other than the
     root account and the pppd process is not secured as being setuid to
     root. To correct for this, issue the command ┤chmod 4555
     /usr/sbin/pppd┤ while you are signed on as the root user.

  ╖  You are using modules and have not loaded the ppp.o module.  This
     may require that you first load the slhc.o module to provide for
     the VJ header compression logic.

  ╖  You are not running the proper pppd process. If you are using the
     2.x series kernels then you must use at least the 2.2.0 version of
     the pppd process. The 2.1 version is not supported with the 2.x
     series kernels.

  ╖  Likewise, if you are running the 1.2.13 kernel and have built the
     2.1 version of the drivers into the kernel then you must run the
     2.1.2d version of pppd.

  ╖  The pppd process as moved from /usr/lib/ppp/pppd used in the 2.1
     version of the pppd process, to the ┤new┤ home of /usr/sbin/pppd.
     It is expected that all future versions of pppd will be stored in
     this location. The change was in response to the FSSTND document
     for Linux. This change may require that you rebuild the dip or
     diald programs to reflect the new location of pppd.

  7.18.  How do I use PPP and a local network at the same time?

  Break the problem into two parts. The first part is to get the
  ethernet network working properly. See the question about the default
  route concerning a problem with the Slackware ┤96 package.

  Once you have the ethernet network working, then get the PPP link
  between the one system running pppd and the internet provider working.
  Do not concern yourself with the local network at this time. Just get
  the PPP link working.

  Then, once you have the two pieces working, you can get the two of
  them working together. Use either a firewall system on the computer
  with the PPP link or use the IP masquerading software.

  For more instructions on the firewall code, see the Firewall-HOWTO.

  For more instructions on the masquerading code, see the Net-2-HOWTO.

  7.19.  Can I use the same local IP address for each line of a PPP
  server?

  Yes, you may use the same IP address for all of the local addresses on
  each of your PPP devices. You may even use the same IP address as one
  of your ethernet or token ring controllers.

  However, you must use a unique IP address for each of your remote IP
  addresses.

  The routing for a point-to-point link is to the remote IP address, not
  to the local IP address.

  7.20.  How do I find my local IP address??

  The local IP address is one of the parameters given to the
  /etc/ppp/ip-up program. It is the 4th (counting from the first)
  argument. The easiest method is to simply save the value at the time
  that the ip-up program is executed.

  If you don't wish to do this then you can use the ifconfig program to
  display the parameters for the specific PPP device. One of the values
  is the IP address.

  If you don't wish to do this then you can obtain the information from
  the system log. This is the least desirable method as parsing the
  standard log file is much more complicated than parsing the output
  from ifconfig.

  The easiest solution is to simply store the value during the ip-up
  program in some specific file which you may access at a later date.

  7.21.  I can't connect to the merit network.

  Some users of the merit network have indicated that it needs PAP. Did
  you try PAP authentication?

  8.  DIP

  8.1.  DIP does not have support for PPP┤s mode

  The current version of dip-uri supports PPP in that it will execute
  the pppd process when you execute ┤mode PPP┤.  However, there are many
  options which are needed for the proper operation of pppd. Since dip
  does not pass these to the program, they must be stored in the
  /etc/ppp/options file.

  The dip program controls the establishment of the SLIP link. It
  controls the SLIP link with the aid of slattach, ifconfig, and route.
  These programs may be used to establish a SLIP link. They are not
  useful for the establishment of a PPP link.

  The dip program may be used to dial the telephone and start the PPP
  software on the remote system. It is best used in this mode as the
  parameter to the ┤connect┤ option. However, you have the option to use
  dip to control the link. It is not important how pppd be executed to
  run the PPP link. It is only important that it be executed as it is a
  mandatory program for the PPP protocol.

  While this is not a FAQ for dip, there is a common problem with dip
  and pppd. The dip process has the absolute pathname to the pppd
  process embedded within it. Until recently, the location for pppd was
  /usr/lib/ppp/pppd. It has moved to the /usr/sbin/pppd location. So, if
  you are unable to get dip to start pppd then check the pathnames in
  dip.

  Additional information about the dip process is in the Net-2-HOWTO
  document.

  8.2.  DIP dies immediately when I do ┤mode ppp┤

  The location of the pppd program file is stored within dip.

  The 2.1 version of pppd was stored in /usr/lib/ppp/pppd. The 2.2
  version has moved to the more ┤standard┤ location of /usr/sbin/pppd.
  That is well and good. However, the problem is that now dip has the
  wrong location for pppd. When it attempts to run the pppd process as
  you do ┤mode ppp┤, the dip program attempts to run the pppd program
  and it can┤t because it isn┤ there.

  You can temporarily make a symbolic link from the /usr/lib/ppp/pppd
  location to the /usr/sbin/pppd file. However, a better solution is to
  rebuild the dip program so that it knows that pppd is at
  /usr/sbin/pppd.

  9.  Process termination

  9.1.  Is there a ┤dip -k┤ for PPP?

  No. There is no ┤dip -k┤.

  However, if you run dip -k, and have properly built the dip process so
  that it knows that the lock file directory is /var/locks, then you may
  use the command to terminate the pppd process. The reason that this
  works is that dip will terminate any process which owns the tty
  device, not just the one which it started. This may be a security
  concern for some (perhaps many) people. However, it is just the way
  that the program works. If you are concerned about dip doing this
  action then either secure dip so that it is executable by only
  specific people or remove it from your system and use slattach, route,
  ifconfig, and arp to do the dial-in functions of SLIP.

  In the chat directory, there is a ┤PPP-off┤ script. This will stop the
  PPP link in the same manner as the ┤dip -k┤.

  I have included it below. (Cut it out. Store it in its own file.

  Make the file executable with chmod.)

       #!/bin/sh
       DEVICE=ppp0
       #
       # If the ppp0 pid file is present then the program is running. Stop it.
       if [ -r /var/run/$DEVICE.pid ]; then
               kill -INT `head -1 /var/run/$DEVICE.pid`
       #
       # If the kill did not work then there is no process running for this
       # pid. It may also mean that the lock file will be left. You may wish
       # to delete the lock file at the same time.
               if [ ! "$?" = "0" ]; then
                       rm -f /var/run/$DEVICE.pid
                       echo "ERROR: Removed stale pid file"
                       exit 1
               fi
       #
       # Success. Let pppd clean up its own junk.
               echo "PPP link to $DEVICE terminated."
               exit 0
       fi
       #
       # The PPP process is not running for ppp0
       echo "ERROR: PPP link is not active on $DEVICE"
       exit 1

  In addition, you may still use ┤dip -k┤ to terminate the pppd link.
  The reason is that dip does not care if it started the program which
  is using the serial device. It sends a SIGTERM to any process which
  owns the serial device. (This is not a great idea, however, that is
  the way that dip works.)

  9.2.  PPP does not hangup the modem when it terminates

  There are several reasons for this.

  ╖  Did you use the pppd ┤modem┤ parameter? This parameter controls
     whether or not the pppd process is to control and honor the signals
     reflecting the modem status. This parameter is explained in the man
     page for pppd.

  ╖  Do you have the modem presenting the DCD signal and honoring DTR?
     The Hayes sequence for this is usually ┤&C1┤.  If you reset the
     modem during the connection sequence with ┤ATZ┤ then ensure that
     your modem is configured correctly.

  ╖  The DTR signal is generated by the computer and instructs the modem
     to disconnect. Hayes sequence for this is usually ┤&D1┤ or ┤&D2┤
     with ┤&D2┤ being the preferred setting for PPP. Many manufacturers
     will ignore the DTR condition in their ┤factory defaults┤ setting.

  ╖  Did you use a cheap cable which does not pass the DCD signal?
     Macintosh ┤Classic┤ cables are notorious for this problem. The
     Macintosh Classic does not use this signal.

  ╖  For dial-in connections, did you exec the pppd process properly?
     The pppd process should be ┤exec┤ed from the script rather than
     simply executed. If you attempt to simply run the pppd process then
     it will be the shell which will receive the SIGHUP hangup signal
     and not the pppd process.

     The ┤shell┤ script should have a format similar to the following:

       #!/bin/sh
       exec pppd -detach modem ...

  ╖  The use of dip and diald has, on occasion, interfered with the
     ability of pppd to sense the loss of the carrier. In this case, you
     should use the lcp-echo-request and lcp-echo-failure options to
     detect the loss of the connection in-band.

     [Ed: Sorry for the technical terminology. ┤in-band┤ refers to the
     use of the protocol itself to detect a condition. It is similar to
     using XON and XOFF as flow control characters. These characters are
     sent along with the data and perform the flow control operations.
     The ┤in-band┤ is the opposite of ┤out-of-band┤. They both refer to
     ┤band┤ as being short for ┤bandwidth┤. When something is ┤in-band┤,
     it is within the bandwidth of the signals. That is, it takes some
     of the bandwidth to perform the additional function. ┤out-of-band┤
     would be the equivalent of using the RTS and CTS signal lines to do
     flow control. These do not take a character. These are not sent
     with the data. The signals are just additional lines that happen to
     do the required function.]

  10.  Data Transfer related issues

  10.1.  The ftp transfers seems to die when I do a ┤put┤ operation.
  They will work correctly if I ┤get┤ a file. Why?

  Do you have the flow control enabled?

  Flow control is set by the pppd option crtscts for RTS/CTS and xonxoff
  for XON/XOFF. If you don't enable the flow control then you will
  probably overrun the modem┤s buffers and this will prove to be
  disastrous with vj header compression.

  It is important that the modem, not just the computer, have the proper
  setting for flow control. If the modem does not do flow control and
  the computer is expecting that the modem will tell it when the buffer
  overruns, then the buffer will overrun because the modem is not
  configured to tell the computer that it is full.

  Likewise if the modem is configured to use RTS/CTS and your computer
  is configured to use XON/XOFF then you will not be able to recognize
  the modem┤s request to suspend transmission.

  The modern modems are configured with the use of a command code to do
  flow control. Check in your manual for the appropriate command code
  and include it along with the modem initialization.

  Do not fall into the "well, the modem does this by default so I don't
  have to configure the modem before I use it." trap. Do the
  configuration. Do it explicitly. If the manual says that &H1 sets RTS
  and CTS flow control (what is also commonly called ┤hardware┤ flow
  control) then send the modem AT&H1 to set the flow control. Do it
  before you dial the number. Don't expect that just giving the modem
  ATZ will enable the flow control properly.

  10.2.  How do I use XON/XOFF for flow control?

  The better flow control is CTS/RTS. However, if you can not do the
  hardware flow control with the signals CTS and RTS, then use XON/XOFF.
  The following three steps need to be performed.

  ╖  You need to specify the pppd option xonxoff. This tells the pppd
     process to configure the serial device for XON/XOFF flow control
     and to load the two characters into the tty driver.

  ╖  You need to specify the XON and XOFF characters in the pppd
     parameter asyncmap. This tells the remote system that is should
     quote the XON and XOFF characters when it wishes to send them to
     you. It is normally specified as the pppd parameter ┤asyncmap
     a0000┤.

  ╖  Of course, don't forget to tell the modem to use XON/XOFF flow
     control. My ZyXEL modem uses a sequence ┤&R1&H4┤ to do this.

  10.3.  The modem seems to always connect at a strange rate. When I use
  minicom, the modem will always use 14400. However, PPP is using 9600
  or 7200 or even 2400. How do I fix this?

  Put the desired rate as an option to the pppd process.  If you don't
  put the rate, then pppd process will use whatever rate is set
  currently at the time. Not all programs will restore all of the
  parameters to the previous settings properly upon exit.  This may lead
  to strange rates configured for the serial device.
  Linux does not support modems which use the RPI (Rockwell Protocol
  Interface) proprietary specification. Given the proprietary nature of
  the specification (even if you signed a NDA Rockwell will not release
  the code needed to interface to the modem) it is extremely unlikely
  that Linux will ever support this modem. The only solution, should you
  have a RPI modem, is to take it back to the dealer and get one which
  does not use RPI.

  Some of the catch phrases to avoid are modems which are marked as
  having error correction in software, ┤windows┤ compatible, or
  ┤requiring a special driver┤ for full operation. These usually
  indicate that the modem uses RPI.

  10.4.  The ftp transfers seems to be very slow when I do a ┤get┤ oper¡
  ation. The ┤put┤ operation is much faster. Why?

  Did you specify the option:

  asyncmap 0

  when you ran pppd? If you forgot the option, the peer must quote
  (double) all of the control characters in the range from 00 to 1F
  (hex). This will result in a statistical loss of about 12.5% in speed
  for all of the data which you receive.

  Did you configure the remote system? If so, did you forget flow
  control on its modem?

  10.5.  The proxyarp function fails to find the hardware address.

  Use the ppp-2.1.2d.tar.gz package. The pppd process was erroneously
  compiled with the 1.1.8 kernel and it used Net-3 rather than Net-2
  definitions.

  Additionally, you should refer to the proxy-ARP mini-HOWTO about the
  requirements for using proxy-ARP.

  The 2.1 package had a limit of 64 network devices.  At the the that
  the proxyarp function was written, 64 seemed to be a very likely limit
  as most people had one or two ethernet controllers. This is no longer
  the case when we consider that some systems routinely have 128 network
  devices.

  The 2.2 package has raised the limit to 5000 network devices. That
  limit is excessive. However, it means that in all practial purposes,
  there is no limit. It is a compile-time define in the sys-linux.c
  module.

  11.  Routing and other problems

  11.1.  My route to the remote keeps disappearing! It last for about 3
  minutes and then the route just goes away. Help!

  This is not a question for PPP.

  Hint: DON'T RUN routed!

  If you need to send RIP frames to the peer for its routing purposes
  then use the bcastd program. The bcastd program is on sunsite.unc.edu.

  11.2.  I would like to attach my other computers on my network to the
  Internet through my PPP connection. I have only the one IP address
  which is assigned to me from my service provider. (It may even have
  been dynamically assigned.) How may I do this?

  You may not. At least, you can't do it in the manner that you would
  normally want to do it. The problem is that your provider would not
  know about the IP addresses of your local network and therefore wont
  route the frames to your local system.

  There are other solutions, however.

  ╖  You may telnet to your one computer running pppd and then use
     telnet or ftp to reach out to the rest of the Internet. This is not
     really much better then just using the computer directly, but it
     does work for simple things.

  ╖  You may run a 2.x series kernel and use the ┤IP Masquerade┤ option.
     For instructions on how to use this facility you should refer to
     the Net-2-HOWTO document.

  ╖  You may run the socks program on your PPP system.  This will
     perform the same facility as the IP Masquerade but it will take
     modified clients or a replacement run-time library. The advantage
     is that the socks program has been around for some years and many
     clients will understand the concept of a ┤proxy┤ server which is
     needed to work with socks.

  11.3.  I can reach the remote server, but I can not get anywhere else.

  Did you forget the ┤defaultroute┤ parameter to pppd? This parameter
  adds a default route into your routing system so that frames to all
  other IP addresses will be sent to the PPP device.

  The PPP software will not replace the default route if you have one
  already set when you run pppd. This is done to prevent people from
  destroying their default route to the ethernet routers by accident. A
  warning message is written to the system log if the defaultroute
  parameter is not performed for this reason.

  11.4.  I have a default route and I still can't get anywhere else! Now
  what?

  The problem then is not with the local Linux system.  It most likely
  is routing problem on the remote end.

  The remote system is not configured for ┤IP forwarding┤. It is an RFC
  requirement that this option NOT be enabled by default. You must
  enable the option.  For Linux systems, you will need to build the
  kernel and specify that you want IP forwarding/gatewaying.

  The remote computers need a route back to you just as you need a route
  to them. This may be accomplished by one of four methods. Each has
  advantages and limitations. You need to do one and only one of these.

  ╖  Use a host route. At each host on the remote system, add a host
     route to your Linux IP address with the gateway being the terminal
     server that you use for your local access. This will work if you
     have a small number of host systems and a simple network without
     bridges, routers, gateways, etc.
  ╖  Use a network route. Subdivide the remote IP addresses so that your
     local Linux IP address and the remote terminal server address and
     the remote terminal server┤s ethernet address is on the same IP
     network. This will work if you have the IP addresses to spare. It
     will work very well if you have a Class-B IP network and can afford
     to put the all of the remote addresses on the same IP network. Then
     add a network route on each of the gateways and routers so that any
     address of the remote network is sent to the terminal server. Most
     configurations have many hosts but few routers.  (At sii.com, we
     have over 300 active host systems with only 3 routers.)

  ╖  Use gated on all of the gateways and on the terminal server. This
     will cause the terminal server to broadcast to the gateways that it
     can accept the frames for your IP address. Since the hosts will
     have a default route to one of the gateways, the gateways will
     generate the ICMP re-direct frame and the specific host will
     automatically add its host route.

  ╖  Use proxy ARP on the terminal server. This will only work if your
     remote IP address is in the same IP domain as one of the domains
     for the network cards.

  There is no clear solution. You must choose one of these.

  If your remote router requires to receive RIP frames in order to
  update the route to your system then you should use the bcastd program
  on sunsite.unc.edu.  This will generate the RIP frames without
  actually running gated.

  11.5.  I can not ping my local IP address

  You are not able to do this because you wont normally have a route to
  the address. This is the normal operating environment.

  If you wish to ping your own system then use the loopback address of
  127.0.0.1.

  You may be able to ping the remote address. However, some terminal
  servers may not allow this as the address may be ┤phony┤ to them. It
  depends upon their environment.

  In general, don't try to ping either address. Choose a third address
  which is well known to be available on the remote network such as one
  of your name server IP address.

  While the PPP software will not perform this task, you may add the
  route table entry yourself once the link has been established. The
  syntax for the route statement is:

       route add -host 192.187.163.32 lo

  where the local IP address is represented as 192.187.163.32 in this
  example. This will tell the network software to route all frames
  destined to your local IP address to the loopback adapter.  Once you
  add the appropriate route to the local IP address then you may use
  this address as the target to IP frames.

  You will be responsible for deleting the route when the link goes
  down.

  12.  Interactions with other PPP implementations

  12.1.  How do I connect to a Windows NT server?

  This question is becomming one of the most frequently asked questions
  about PPP. The Microsoft Windows NT platform is making substantial
  inroads into the corporate and commerial service organizations and the
  use of it's RAS services is seen as one of the reasons. It is just so
  easy to fill a few items in a form and have your Windows 95 system
  connect to the Windows NT platform that it is extremely tempting for
  many companies to offer Windows NT as their method of connection to
  either the corporate intranet or the Internet.

  Yet, there are some difficulties with the use of Linux PPP and
  Microsoft Windows NT. There are a few different things with Windows NT
  as opposed to a UNIX platform.

  There is no special script for connecting to Windows NT servers. If
  you are using chat (a UUCP expect-reply scripting tool), the script is
  nothing more than:

       chat "" ATDT5551212 CONNECT

  since it only needs to dial the Windows NT server and get the
  telephone to return a connected status. You can embelish it to look
  for things such as BUSY or VOICE or other errors from the modem, but
  those are not required. The only thing is to not expect "login:" or
  any other form of textual login sequence. Also, Windows NT server is
  ┤quiet┤. It does not send anything until you do. It will just answer
  the telephone and then wait.

  There is nothing special about using PAP or MSCHAP with Windows NT and
  Linux PPP. The Linux PPP process supports the MSCHAP protocol if you
  apply the patches which are included with the source package and get
  the D.E.S. library from ftp.funet.fi. (The DES library was originally
  developed in Australia. That country has the same restrictions on
  export of cryptography as do the countries of NORAD. So, since it has
  leaked to Finland, people should get it from there. I do not know who
  broke Australian law and that does not matter as long as it was not
  I.)

  If you require to interface to a server which is configured to accept
  only encrypted authentication then you must use MSCHAP. If you can
  open up the server and accept "any authentication, including clear
  text" then you are best using PAP.

  If you use PAP, then edit the /etc/ppp/pap-secrets file and put the
  entry which corresponds to:

       account        remote            password

  This is three words, seperated by one or more spaces, on the same
  line. I have left out the IP addresses as they are used more for the
  ┤dial-in server┤ side of the pppd process. There is no limit to the
  line length. If your password or account name has spaces in it then
  use "password" or "account" (put quotes around it.) If the password
  has special characters which are not glyphs (printable characters such
  as a, b, c, etc.) then you may use \nnn for octal or \xNN for
  hexadecimal to enter the raw data as needed.

  The field marked account is the name of the account on the Windows NT
  server, remote is either an "*" to mean that it is not used or it
  corresponds to the value used with the ┤remotename┤ option to pppd and
  password is, obviously, the password.

  Then you need to add either "user account" or "name account" where
  "account" is the matching item to your user name on the Windows NT
  server and matches the entry in the pap-secrets file.

  Do not use the "+chap", "+pap", or "auth" options since these require
  that the remote system (Windows NT) authenticate itself with you.
  Normally the administrator won┤t put in your codes so this will fail
  and you will not be able to communicate.

  The entry for the chap-secrets file is basically the same. The MSCHAP
  code will convert the ASCII code to UNICODE that Windows NT requires
  since it is a simple mapping function from ASCII to UNICODE for the
  first 128 characters.

  The double entry in the chap-secrets file is because the CHAP
  authentication is assumed to work both ways. In fact, since the MSCHAP
  sequence only works in one direction at the present time (because the
  Windows NT server does not authenticate itself with the client because
  Microsoft chose not to do that section of the code) the second entry
  is just noise. However, the parser for the option in pppd will require
  that you have it to make MSCHAP an acceptable authentication protocol
  when requested by the Windows NT peer. The "secret" for this item can
  be anything but an empty string.

  The difference between "name", "remotename", and "user" is:

  user : Used for PAP authentication. It will default to the value
  assigned to "name" if you do not specify the "user" option directly.

  name : The name of the local system. It is used by the CHAP and MSCHAP
  code to select the secret from the chap-secrets file. It will default
  to name of the local IP address if you don't specify it.

  remotename : The name of the remote (peer) system. It is used by PAP,
  CHAP, and MSCHAP to select the item from the file. It will default to
  the name of the peer's IP address if you don't specify it.

  The Microsoft authentication sequence is a CHAP style authentication
  with their DES encryption algorithm for the passwords.

  So why didn┤t Microsoft just use CHAP with MD5 encryption then?  CHAP
  does not send the clear text password across the ┤wire┤. The answer is
  that in order to use CHAP protocol, you need the clear text for the
  password to be used with the encryption algorithm. You would need to
  store this clear text on your disk file. (The pppd process stores it
  in the /etc/ppp/chap-secrets file.)  Storing a password in clear text
  on the disk also violates the requirements for C2 registration.

  The only real difference between CHAP and MSCHAP is that MSCHAP does
  not store the clear text for the secret (password). They are both as
  vulnerable for middle-man imposter threats. They are both just as
  secure. Yet, MSCHAP can be used on a C2 registered system; CHAP can
  not.

  12.2.  I tried to use MSCHAP or PAP with Windows NT and it fails with
  "E=691". Now what?

  The error condition identified as 691 is Windows NT way of telling you
  "invalid user name or password". Cute, isn┤t it? It would have been
  better if they had included just a little more text with the message
  such as 'E=691 R="invalid user name or password"', but I guess that
  they had to save some memory some place and that was the place that
  they chose to do it. So, they left it as just this cryptic code
  number.

  (There are about five other errors which may occur. Each is just a
  code number as well. For a list of the code numbers and their textual
  translation, you will have to query Microsoft's knowledge base on
  http://www.microsoft.com.)

  Aside from the obvious reason of really not giving it a valid user
  name and password, the other reason is that it can not validate the
  entry that you did give it.

  If your RAS server is a member or a secondary domain controller of a
  domain then you need to prefix the user name with the domain name. The
  reason that you must specify the domain name is that the RAS server
  must ask some other server to validate your account, it needs to know
  the domain name which corresponds to your account.

  The domain name is pre-pended to the user name with a \ character
  separator.

  However, since \ is special to pppd as it has the normal "C" language
  meanings then you need to use an entry in the pap-secrets or chap-
  secrets file which looks like:

       domain\\account     remote         password

  and use name "domain\\account" or user "domain\\account" as the option
  for pppd.

  Then, you need to be careful about putting the \ character on the
  runline or as an un-quoted parameter to the connect option. The shell
  also uses \ for special purposes. This may mean that you would have to
  use name domain\\\\account just so that the pppd process sees name
  domain\\account so that it can give to Windows NT the sequence
  domain\account.

  12.3.  How do I support Windows 95?

  Windows 95 PPP support is designed to work with Windows NT and similar
  servers which do not use a login and password prompt. For this to
  work, you would need to use a getty process which will recognize the
  LCP configure-request.

  12.4.  I am using a Trumpet (for MSDOS) and the connection simply ter¡
  minates. Why is this happening?

  Trumpet does not like any VJ header compression.  Use the pppd option
  ┤-vj┤ to turn it off.

  12.5.  I am using dp-3.1.2 (with SunOS) and the system will not allow
  me to use anything but ping, or nslookup. Why is this happening?

  There is a bug in the 3.1.2 version of dp.  Please get the 3.1.2a or
  later file from the dp ftp home site harbor.ecn.purdue.ecu. Until you
  can put the patch into dp, disable the vj header compression.

  12.6.  My provider wants to use a dynamic DNS address which is not the
  same with every connection. Yet, Linux wants just one address in the
  /etc/resolv.conf file. This works with Microsoft Windows 95, but how
  do I make it work with Linux?

  Run a local ┤cache-only┤ nameserver on your own Linux system.

  Instructions on running the nameserver are in the Named-HOWTO. The
  only file which you need to obtain from the internet to enable the
  nameserver is the named.boot file. This is available from the ftp site
  at ds.internic.net. Then, use the address 127.1 as the address of the
  nameserver.

  You will need to create a named.boot file as well as a primary for a
  dummy domain which will hold your localhost name and a primary domain
  for the 127 IP network. Again, instructions on how to do this are in
  the Named-HOWTO file.

  13.  Other messages written to the system log

  13.1.  Alarm

  This is not a problem. It means that a timer has expired. Timers are a
  necessary part of the protocol establishment phase. This is a message
  to help the authors debug the program.

  13.2.  SIGHUP

  The pppd process has received a HUP signal. The HUP signal is
  generated by the tty software when the remote system has disconnected
  the modem link. It means that the modem has put the ┤telephone
  receiver back on the hook┤, or, ┤Hung UP┤ the connection.

  The kill program may also be used to send this signal to the pppd
  process.

  The pppd process will terminate the link in an orderly fashion when it
  receives this signal.

  13.3.  SIGINT

  The pppd process has received an INT signal. The INT signal is
  generated by the console software when you press the Ctrl-C key
  combination and pppd is the foreground process.

  The kill program may also be used to send this signal to the pppd
  process. In fact, the recommended method to terminate the pppd link is
  to send the process an INT. See the question relating to ┤dip -k┤ for
  a script which will perform this task. The pppd process will terminate
  the link in an orderly fashion when it receives this signal.

  13.4.  Unknown protocol (c025) received!.

  The remote wishes to exchange Link Quality Reporting protocol with the
  Linux system. This protocol is presently not supported. This is not an
  error. It is merely saying that it has received the request and will
  tell the remote that ┤I can't do this now. Don't bother me with this!┤

  The Morning Star PPP package will always try to do LQR protocol. This
  is normal.

  13.5.  Unknown protocol (80fd) received!.

  The remote wishes to exchange Compression Control Protocol with the
  Linux system. This type of protocol is layered upon the basic data
  protocol and will, if successfully negotiated, result in a fewer
  number of bytes transmitted for the frame. This means that the
  transfer will be quicker.

  However, there are many types of compressors which are used under the
  general ┤umbrella┤ of a Compression Control Protocol. The 2.2 PPP
  package understands only one; the BSD compressor.  This compressor
  works very similar to the Unix ┤compress┤ program and uses a LZW
  compressor. Depending upon the size of the code, there can be a
  significant amount of kernel space needed to hold the compression and
  decompression dictionaries. This should not be used if you have a
  limited memory space and should not even be contemplated if you have
  8Meg or less real (RAM) memory. In those cases you should invest in a
  decent modem which support compression.

  Unless both sides can agree upon the type of compression the
  compression will not be used.

  Another common compressor is called Predictor-1.  This will take less
  memory and run faster. However, its compression is not as good in that
  it will send a little more data than the equivalent frame given to the
  BSD compressor.

  Many commercial terminal servers will employ a compressor called
  ┤Stacker(TM) LZW┤ or LZS protocol. This is a commercial compression
  agent. Apparently Stacker will give you a license for no charge.
  However, a specific license is required and that will usually prevent
  it being included with the pppd process.

  The 2.3 package will additionally include the compressor known as
  ┤deflate┤. It is a variation of the common package called ┤gzip┤.

  13.6.  The connection fails with errors ┤ioctl(TIOCGETD): I/O error┤
  or ┤ioctl(PPPIOCSINPSIG): I/O error┤. What now?

  Look at the boot messages when you boot the kernel.  If it says ┤PPP
  version 0.1.2┤ then you have an old version of the ppp.c driver.

  If it says ┤PPP version 0.2.7┤ then you have the current driver, for
  the 2.1.2 package however, it was not built with the same set of
  defines for the ioctl numbers.  Ensure that you have only one file
  called ┤if_ppp.h┤.  It should be located in the kernel┤s include/linux
  directory. Once you have done this, rebuild the kernel and the pppd
  process.

  If it says ┤PPP version 2.2.0┤ then you are using the driver for the
  2.2.0 package. This version of the driver will only work with the 2.2
  series of the pppd package.  The 2.2 pppd program will only work with
  this version of the driver.

  13.7.  Sometimes the messages ┤ioctl(PPPIOCGDEBUG): I/O error┤,
  ┤ioctl(TIOCSETD): I/O error┤ and ┤ioctl(TIOCNXCL): I/O error┤ occur.
  Why?

  The remote system has disconnected the telephone.  The tty drivers
  will re-establish the proper tty discipline and these errors are the
  result of the pppd process trying to do the same thing. These are to
  be expected.

  13.8.  My ifconfig has strange output for PPP.

  Usually the ifconfig program reports information similar to the
  following. You will have different IP addresses.

       ppp0      Link encap:Point-Point Protocol
                 inet addr:155.190.0.1  P-t-P:155.190.8.1  Mask:255.255.0.0
                 UP POINTOPOINT RUNNING  MTU:1500  Metric:1
                 RX packets:0 errors:0 dropped:0 overruns:0
                 TX packets:0 errors:0 dropped:0 overruns:0

  The information is for display purposes only. If you are using a
  recent kernel then update the nettools package with the current one on
  sunacm.swan.ac.uk in the directory /pub/Linux/networking/nettools.

  13.9.  The file /proc/net/dev seems to be empty

  Do not be concerned with the contents of the /proc/net/dev file. There
  was a time when it was suggested that you check this file to determine
  if the ppp devices have been created. Now this check causes more
  confusion than satisfaction since the devices are dynamically created.

  Did you just issue the command ┤ls -l /proc/net┤ and are wondering why
  the size is zero? If so, this is normal. Instead, issue the command:

       cat /proc/net/dev

  You should not find the file empty. The size is always shown as zero,
  but that is the ┤proc┤ file system. Don't believe the size. Do the
  command.

  The ┤more┤, ┤less┤, and ┤most┤ programs may not be used to view the
  file directly. If you wish to use these programs, use it as follows:

       cat /proc/net/dev | less

  The current versions of pppd do not pre-create the ppp devices as the
  earlier versions did. If you have instructions which say that you
  should look at the /proc/net/dev file to see if there are ppp devices
  then you should ignore them. The ppp devices will be automatically
  created as they are needed and when they are needed.

  13.10.  The kernel reports that the PPP devices are being unlinked
  when the system is being started.

  This message is generated only from earlier attempts at making the ppp
  devices dynamic. The current code no longer generates these messages.
  If you are seeing these messages then you should upgrade the pppd
  package to at least the 2.2.0 code.

  13.11.  I just checked /proc/net/dev and there are no PPP devices.
  Where did they go?

  They went nowhere. They were all unlinked during the startup of the
  system.

  The devices will be created again as they are needed.

  14.  Network routing issues (using PPP as a ┤cheap┤ bridge)

  14.1.  Slattach and ifconfig don't work as they do with SLIP

  Do not use slattach and ifconfig with PPP. These are used for SLIP.
  The pppd process does these functions at the appropriate time. These
  must occur after the LCP and IPCP protocols have been exchanged.

  You can not replace pppd with slattach and ifconfig. Most of the
  protocol support for PPP is in the pppd process. Only the IP and IPX
  processing is in the kernel.

  The host route to the remote system will be automatically added by
  pppd. There is no option to NOT add the route. The pppd process will
  terminate if the route could not be added.

  The default route may or may not be added. This is controlled by the
  option ┤defaultroute┤.  If you have a default route, it will not be
  changed.

  If you must do routing for an entire network, then put the route
  command into the /etc/ppp/ip-up script. The parameters to the script
  are:

       $0 - name of the script (/etc/ppp/ip-up or /etc/ppp/ip-down)
       $1 - name of the network device (such as ppp0)
       $2 - name of the tty device (such as /dev/cua0)
       $3 - speed of the tty device in Bits Per Second (such as 38400)
       $4 - the local IP address in dotted decimal notation
       $5 - the remote IP address in dotted decimal notation
       $6 - the value of the ipparam parameter

  14.2.  I want the route to the network and not the route to the host.

  On sunsite there is a package called devinfo.tar.gz.  It contains some
  useful little programs which will extract the data from the device and
  to do various things with the dotted IP addresses.
  The documentation is in the man pages in the file.

  For example, if you want to route the entire IP domain to the remote,
  the following may be used in /etc/ppp/ip-up.

  Of course, if the values are not variable, then simply use the
  appropriate entry in the route command.

       # Obtain the netmask for the ppp0 (or whatever) device
       NETMASK = `devinfo -d $1 -t mask`

       # Obtain the IP domain (without the host address by removing the extra bits)
       DOMAIN = `netmath -a $5 $NETMASK`

       # Do the network route now that the IP domain is known
       route -net add $DOMAIN gw $5

  15.  Other features and protocols

  15.1.  What about support for ┤demand dial┤

  Use the diald package. This is on sunsite in the same directory as the
  PPP source, /pub/Linux/system/Network/serial.

  15.2.  What about ┤filtering┤

  There are no plans to put filtering into the PPP code. The 1.3 kernel
  supports a firewall option and you should use that rather than attempt
  to find a method of putting firewall logic into a network device
  driver. Use either the ipfw or ipfwadm programs to define the rules
  for the firewall code in the kernel.

  15.3.  How about IPX?

  It is in the 2.2.0e package.

  15.4.  How about NETBIOS?

  There is a netbios PPP protocol. However, your better solution would
  be to use TCP/IP and the ┤samba┤ code.

  Microsoft and others have used Netbios PPP protocol.

  The nbfcp protocol is a public document and available from several
  sources. The Netbios protocol is not a valid address family at the
  present time for Linux. Until Linux supports the protocol, there is
  little need to support Netbios over PPP for Linux.

  15.5.  I need ISDN support. Is there any?

  ISDN support revolves around having a working ISDN driver. The present
  design of the PPP driver does not lend itself well to the concept of a
  block of data being received. This is being changed. A driver for the
  Sonix interface is being developed.

  15.6.  I would like multi-point support. Is there any support?

  Multi-point would be nice. I am not aware of anyone working on multi-
  point support at the present time.

  15.7.  How about just standard synchronous PPP?

  There are small changes needed to support a serial interface which
  uses synchronous communications. The redesign of the PPP driver will
  help with this function as well. Kate Marika Alhola has expressed an
  interest in writing such a synchronous driver for her hardware. You
  should contact her at [e-mail] or [e-mail] for further
  information.

  She informs me that the current status of sync ppp is, that I have had
  it few months in ┤production┤ use talking with Cisco(TM) in speeds 64K
  and 256K. The source is under the GPL license and it may be found in
  ftp://nic.funet.fi/pub/Linux/kernel/xnet-sync-driver-1.0.tar.gz.

  16.  Miscellaneous

  16.1.  Do you have a PPP compatible mail reader?

  Huh? You have the wrong group if you want MSDOS.  PPP has nothing to
  do with the mail user agent. All of the mail agents are compatible
  with PPP.

  16.2.  How about a news reader?

  Refer to the previous answer.

  17.  Questions about chat

  The chat program is packages with the pppd executable. This is not an
  endorsement for chat. Any program which will arrange to start the PPP
  protocol on the remote system may be used. However, since chat is
  included with pppd, many people use it. There are only a few common
  questions about chat.

  17.1.  My modem wont dial when I run chat

  The modem is required to be in the command mode to issue dial
  commands. If your modem is ┤online┤ then characters sent to the modem
  will be sent to the remote system.

  If possible, configure the modem to monitor the DTR signal and to
  return to the command mode when the DTR signal drops.  This will
  permit the computer to force the modem back to the command mode when
  the pppd process terminates at the end of a connection.  It will then
  be in the proper state when the next execution attempts to dial the
  telephone.

  If you can┤t do this then you should change the dial sequence so that
  it is similar to the following. It will ensure that the modem is in
  the command state prior to attempting to send the dial sequence.

  TIMEOUT 3 \'\' \rAT OK-+++\c-OK AT&D2&C1 TIMEOUT 60 OK ATDT555-1212 CONNECT

  The commands will change the timeout period to three seconds. This
  accommodates the guard time period used by many modems. It will then
  send AT to the modem and look for its response of OK. If it is not
  received in the three seconds, it will send the +++ sequence to the
  modem and wait for the modem to present the expected OK response. Once
  it receives the valid response it will configure the modem and dial
  the telephone number.

  17.2.  The modem dials only on every second attempt

  Please refer to the above answer. It is usually the same issue.

  17.3.  The chat script stops after sending the account name and it
  never receives the password prompt.

  Some systems, notably SCO, will flush the receive buffers after
  writing the prompts for user name and password.  The chat program
  normally transmits the response immediately upon seeing the prompt.
  The result is that the reply from chat is flushed by SCO. The chat
  program continues to wait for the password prompt.  However, the
  remote system is still waiting for the user to enter the account name.

  The solution is simple. Slow down the responses from chat so that
  there is time for the remote system to flush the receive buffer before
  chat starts to send the response. Chat supports this with the \d
  parameter. Change the response strings similar to the following:

         ogin:--ogin: \d\daccount assword: \d\dhello2u2

  17.4.  The chat script stops before finishing and fails to make the
  connection

  A common method of using chat is to use the connect option and have it
  directly run the chat program, i.e. connect "chat ...". What is not so
  obvious is the method by which pppd implements the connect processing.

  The pppd process uses the execl() function to start a shell. The shell
  is given the command line string which you supplied with the connect
  option. This has several advantages in that the parameters do not need
  to be parsed by pppd, they may be expanded, the path is automatically
  searched, etc. However, it does have some disadvantages as well.

  The disadvantage is that the shell will re-interpret the option string
  again for special characters and act upon them. It will use the \
  character to take the next character as a different meaning, it will
  use the & character to start a new sub-shell, and it will use the <
  and > to do I/O redirection.

  So, if your prompt string is "protocol>" and you use just the string
  protocol> or even > then the shell will cause chat to fail to run.
  This is not a problem with chat. This is not a problem with the shell.
  They are both doing exactly what is expected.

  So, how do you actually use the string protocol> as a prompt? Well,
  the answer is simple. Put a \ before the > character as in protocol\>.
  This tells the shell that the > is not an I/O redirection sequence but
  a simple character which is to be given to the chat program just like
  any other.

  The same thing is required for the modem configuration options of
  AT&D2, etc. The & needs to be quoted as in AT\&D2.

  The chat program also recognizes the \ character as being special
  within its own processing. This is performed so that strings may have
  special characters within them such as \r for a carriage return. If
  your prompt or the reply contains a \ then you need to give chat \\
  for each \ character that you wish to use. (Remember that the shell
  will also need \\ for each of those as well if you don't put the
  sequence within quotes.)

  17.5.  When I attempt to run chat, it says that the -l parameter is
  invalid. Why?

  There was a time when chat had the ability to set a lock file for the
  modem device. The name of the file was given to chat with the
  parameter -l.

  However, that was a seriously bad idea and should not have been in the
  code in the first place.

  The reason is that chat is a filter. It does not attempt to configure
  the modem for the proper rate. So, what people would do is run stty to
  set the rate, then run chat, and then attempt to run pppd. This was
  definitely not the way to do the connection.

  The serial port sharing only works if all of the programs on your
  system follow the same rules and play by the same game. If you want to
  share the serial port then you need to use a lock file. This lock file
  must be created using the proper method before the serial port is
  touched. You are not permitted to run stty on the serial port until
  the lock file is first created.

  Consider what would happen if you had run chat, and chat was in the
  middle of the dial sequence and then some cron event occurred which
  launched another program. That program just changed the BPS rate on
  your modem without attempting to lock the serial device first. I can
  tell you what would happen. The chat connection script won't complete.

  So, for that reason, since chat is a filter and not meant to be a
  controlling program, the lock option was removed. Chat is not able to
  create a lock file for the modem. The lock file must be created by the
  program which configures the serial port and then runs chat, such as
  pppd.

  17.6.  I ran chat. It seems to want to use the local terminal as the
  modem and it does not talk to the modem. How do I specify the modem
  name to chat?

  Chat is in a class of programs called a ┤filter┤. That is, it reads
  from the standard input, does some processing internally, and writes
  to the standard output.

  So, if you really want to just run chat and have it talk to a modem
  then you need to use the I/O redirection operators < and > so that the
  standard input and output are redirected to the modem.

  HOWEVER, if you are using chat with pppd, please do not run chat first
  and then attempt to run pppd after it. You should only use the
  combination of chat and pppd if you use the connect option for pppd to
  run the chat program.

  The reason for this is that pppd will automatically redirect the
  standard input and standard output to the appropriate modem device
  before it runs the connect script (and chat). In addition, the
  necessary device locking will have been performed before it attempts
  to run the chat program.

  If you just run chat first and then expect to run pppd, your system
  will fail should you have another program which is sharing the serial
  device. The locking will not have been performed, chat will not have
  re-configured the serial device so that it has the proper transmission
  rate, parity, stop bits, etc. and then when the other program, such as
  mgetty, comes along it will find that the lock file is not valid and
  re-configure the modem again. In so doing, it will destroy the use of
  the modem by chat and chat or pppd will fail.

  17.7.  When I run pppd and chat along with mgetty then the connection
  does not start. If I stop mgetty, then pppd will work. Why?

  For the serial port to be shared properly, a lock file is needed
  between the use of the serial port by mgetty and the use by pppd (and
  chat).

  The pppd process uses the FSSTND location of /var/lock/LCK..ttyS0 to
  lock the device called 'ttyS0'.

  There have been some pre-built binaries of mgetty in some
  distributions which use the much older location of
  /usr/spool/uucp/LCK..ttyS0.

  In addition to the file location, the file format must be the same.
  There are two common methods of recording the pid information in the
  file. The first is the older method, used commonly by some pre-built
  binaries for the kermit terminal emulator, of storing the pid as a
  binary value. You can tell this format in that the lock file is four
  bytes in size.

  The more modern method is to store the pid as an ASCII string. This
  file has a size of eleven bytes (ten bytes for the pid, one for the
  trailing newline character.)

  If the file format does not match what mgetty expects then mgetty
  treats the lock as being invalid and seizes the device, drops the DTR
  (which usually hangs up on the connection), and reconfigures the
  modem.

  The other cause for the condition is that you simply forgot to tell
  pppd that it must lock the serial port. To tell pppd that it needs to
  lock the serial port, use the option 'lock' when you run pppd.

  In the context of the lock file, the name of the lock file is formed
  from the name of the serial device. That is good for the most part.
  The problem comes when people use 'modem' and 'ttyS0' to be the same
  thing. Some people have a symbolic link from /dev/modem to /dev/ttyS0.
  They then forget that mgetty is using the name ttyS0 for the name of
  the serial port and they use /dev/modem when they run pppd, telling it
  to create the lock. The pppd process does so, but the lock file
  created is called "LCK..modem". Then mgetty comes along and does not
  see that the serial device is locked (because there is no "LCK..ttyS0"
  file) and drops the DTR signal and the PPP connection is broken.

  So, either use /dev/modem or /dev/ttyS0 for your modem. Choose one
  name. Get rid of the other. Use that name everywhere, not just in
  "most" of the places, but in "every" place.

  We have been working on a solution to this problem. It involves
  getting rid of the reliance upon the name of the serial device and
  using the values that the operating systems really uses, the major and
  minor device numbers. However, that is not in place yet. Until it is,
  be careful and use the proper names for the devices on the system and
  you should not have a problem.