University of Delaware


Note: this is not a supported setup. The University of Delaware will provide some basic information for Linux users, but does not support PPP under Linux at the same level as PPP for the Macintosh and Windows operating systems.

Kernel Driver Installation

This depends on the kernel version you're using.

Since 1.1.14, Linux kernels have had built-in support for PPP. You'll be asked whether you want PPP when you run "make config". It's as easy as that. Reboot with the new kernel.

If you have one of the latter 1.3 kernels or any one after the stable release: 2.0, you have dynamic allocation of PPP lines. This means that your PPP support will not be loaded until you run the PPP daemon (pppd). The messages you receive at startup will look like this:

  PPP: version 2.2.0 (dynamic channel allocation)
  TCP compression code copyright 1989 Regents of the University of California
  PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
  PPP line discipline registered.

If you have a stable release 1.2 kernel or an earlier one, then 4 PPP channels are entered into your network devices. The messages you receive at startup will look like this:

  PPP: version 0.2.7 (4 channels) NEW_TTY_DRIVERS OPTIMIZE_FLAGS
  TCP compression code copyright 1989 Regents of the University of California
  PPP line discipline registered.
Don't worry if the words in capitals on the first line are slightly different.

Now, if your kernel is version 1.2 or below you can look at your network devices and 4 ppp devices will be registered. You can do this by looking at the contents of /proc/net/dev. It should look something like this:

  Inter-|   Receive                  |  Transmit
   face |packets errs drop fifo frame|packets errs drop fifo colls carrier
      lo:      0    0    0    0    0        0    0    0    0     0    0
    ppp0:      0    0    0    0    0        0    0    0    0     0    0
    ppp1:      0    0    0    0    0        0    0    0    0     0    0
    ppp2:      0    0    0    0    0        0    0    0    0     0    0
    ppp3:      0    0    0    0    0        0    0    0    0     0    0

This indicates that the driver is successfully installed.

(Of course, you should keep a kernel without PPP around, in case something goes wrong.)

General Network Configuration

Since many people don't use the Linux networking code at all until they get a PPP link, this section describes generally what's needed to get things running. In principle, none of this is special to PPP. For more details, you should consult the relevant Linux HOWTOs. If you already understand network setup, you can skip this section.

The first file that requires attention is the rc script that does network configuration at boot time, called /etc/ or /etc/rc.d/{1,2} or something similar, depending on your Linux distribution. If you are using the Red Hat distribution, you should use the control-panel program which comes with this distribution to edit your network settings unless you really know what you are doing. But if you are using another distribution, this file should 'ifconfig' the loopback interface lo, and should add an interface route for it. These lines might look something like this:

        $CONFIG lo
	$ROUTE add loopback
        /sbin/ifconfig lo
        /sbin/route add
However, it should *not* config an ethernet card or install any other routes (unless you actually have an ethernet card, in which case I'll assume you know what to do). Many distributions will provide scripts that expect you to have an ethernet card.

You also need to decide whether you want to allow incoming telnet/ftp/finger, etc. If so, you should have the rc startup script run the 'inetd' daemon.

Next, you should set up /etc/hosts to have two lines. The first should just give the loopback or localhost address and the second should give your own host name and the IP address your PPP connection will use. For example:   loopback localhost          # useful aliases bill  # my hostname
where my IP address is and my hostname is (Not really, you understand.) If your PPP server does dynamic IP address assignment, give a guess as to an address you might get (see also "Dynamic Address Assignment" below).

Finally, you need to configure the domain name system by putting appropriate lines in /etc/resolv.conf . It should look something like this:

Assuming there are nameservers at and, then when you get connected with PPP, you can reach hosts whose full names are '' and '' by the names 'hillarypc' and 'chelseapc'. You can probably find out the right domain name to use and the IP numbers of nameservers from whoever's providing your PPP link.

Connecting To a PPP Server

To use PPP, you invoke the pppd program with appropriate options. Everything you need to know is contained in the pppd(8) manual page. However, it's useful to see some examples:

Example: A simple dial-up connection.

Here's a command for connecting to a PPP server by modem.

  pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater' \
      /dev/cua1 38400 -detach debug crtscts modem defaultroute
Going through pppd's options in order:

connect 'chat etc...'
This gives a command to run to contact the PPP server. Here the supplied 'chat' program is used to dial a remote computer. The whole command is enclosed in single quotes because pppd expects a one-word argument for the 'connect' option. The options to 'chat' itself are:
verbose mode; log what we do to syslog
don't wait for any prompt, but instead...
dial the modem, then
wait for answer
send a return (null text followed by usual return)
ogin: ppp word: whitewater
log in.
specify the callout serial port cua1
specify baud rate
normally, pppd forks and puts itself in the background; this option prevents this
log status in syslog
use hardware flow control between computer and modem (at 38400 this is a must)
indicate that this is a modem device; pppd will hang up the phone before and after making the call
once the PPP link is established, make it the default route; if you have a PPP link to the Internet this is probably what you want
this is a degenerate case of a general option of the form x.x.x.x:y.y.y.y . Here x.x.x.x is the local IP address and y.y.y.y is the IP address of the remote end of the PPP connection. If this option is not specified, or if just one side is specified, then x.x.x.x defaults to the IP address associated with the local machine's hostname (in /etc/hosts), and y.y.y.y is determined by the remote machine. So if this example had been taken from the fictional machine 'billpc', this option would actually be redundant.

pppd will write error messages and debugging logs to the syslogd daemon using the facility name "local2". (Verbose output from chat is the same.) These messages may already be logged to the console or to a file like /usr/adm/messages; consult your /etc/syslog.conf file to see. If you want to make all pppd and chat messages go to the console, add the line

   local2.*					/dev/console
to syslog.conf; make sure to put one or more TAB characters between the two fields.

Anyway, assuming your connection is working, you should see chat dial the modem, then perhaps some messages from pppd (depending on your syslog.conf setup), then some kernel messages like this:

	ppp: channel ppp0 mtu changed to 1500
	ppp: channel ppp0 open
	ppp: channel ppp0 going up for IP packets!
(These messages will only appear if you gave the option "kdebug 2" and have messages directed to the screen.) Simultaneously, pppd is also writing interesting things to /usr/adm/messages (or other log file, depending on syslog.conf).

If It Works

If you think you've got a connection, there are a number of things you can do to test it.

First, type

(ifconfig may live elsewhere, depending on your distribution.) This should show you all the network interfaces that are 'UP'. ppp0 should be one of them, and you should recognize the first IP address as your own and the "POINT-TO-POINT ADDR" as the address of your server. Here's what it looks like on my machine:
lo        Link encap Local Loopback  
          inet addr  Bcast  Mask
          RX packets 0 errors 0 dropped 0 overruns 0
          TX packets 1468 errors 1 dropped 0 overruns 0

ppp0      Link encap UNSPEC  HWaddr 00-00-00-00-00-00-00-F5-00-00-00-00-00-00-00-00
          inet addr  P-t-P  Mask
          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
If you have a kernel version 2.0 or later you should now have a networking device for ppp, you can check this by looking at /proc/net/dev, it could like like this:
# cat /proc/net/dev
Inter-|   Receive                  |  Transmit
 face |packets errs drop fifo frame|packets errs drop fifo colls carrier
    lo:      0    0    0    0    0        0    0    0    0     0    0
  ppp0:    551    1    1    0    0      700    0    0    0     0    0
Now, try this:
	ping z.z.z.z
where z.z.z.z is the address of your server. This should work. Here's what it looks like for me:
# ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=446.5 ms
64 bytes from icmp_seq=1 ttl=255 time=459.0 ms
64 bytes from icmp_seq=2 ttl=255 time=420.4 ms
64 bytes from icmp_seq=3 ttl=255 time=460.4 ms
64 bytes from icmp_seq=4 ttl=255 time=440.4 ms
64 bytes from icmp_seq=5 ttl=255 time=440.4 ms
64 bytes from icmp_seq=6 ttl=255 time=399.7 ms
--- ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 399.7/438.1/460.4 ms
Try typing:
	netstat -nr
This should show three routes, something like this:
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface UH    0      0        7 ppp0       U     0      0     1640 lo         UG    0      0       30 ppp0
If your output looks similar but doesn't have the destination line (which refers to the default route used for connections), you may have run pppd without the 'defaultroute' option.

At this point you can try telnetting/ftping/fingering whereever you want, bearing in mind that you'll have to use numeric IP addresses unless you've set up your /etc/resolv.conf correctly.

If It Doesn't Work

If you don't seem to get a connection, the thing to do is to collect 'debug' output from pppd. To do this, make sure you run pppd with the 'debug' option, and put the following two lines in your /etc/syslog.conf file:
    local2.*					/dev/console
    local2.*					/usr/adm/ppplog
This will cause pppd's messages to be written to the current virtual console and to the file /usr/adm/ppplog. Note that the left-hand field and the right-hand field must be separated by at least one TAB character. After modifying /etc/syslog.conf, you must execute the command 'kill -HUP ' where is the process ID of the currently running syslogd process to cause it to re-read the configuration file.

Some messages to look for:

"pppd[NNN]: Connected..."
the "connect" script has completed successfully.
"pppd[NNN]: sent [LCP ConfReq"...
pppd has attempted to begin negotiation with the remote end.
"pppd[NNN]: recv [LCP ConfReq"...
pppd has received a negotiation frame from the remote end.
"pppd[NNN]: ipcp up"
pppd has reached the point where it believes the link is ready for IP traffic to travel across it.
If you never see a "recv" message then there may be serious problems with your link. (For example, the link may not be passing all 8 bits.) If that's the case, it would be useful to collect a debug log which contains all the bytes being passed between your computer and the remote PPP server. To do this, alter your syslog.conf lines to look like this
    local2.*,kern.*				/dev/console
    local2.*,kern.*				/usr/adm/ppplog
and HUP the syslog daemon as before. Then, run pppd with the option "kdebug 5". Whatever characters arrive over the PPP terminal line will appear in the debugging output.

Occasionally you may see a message like

   ppp_toss: tossing frame, reason = 4
The PPP code is throwing away a packet ("frame") from the remote server because of a serial overrun. This means your CPU isn't able to read characters from the serial port as quickly as they arrive; the best solution is to get a 16550A serial chip, which gives the CPU some grace period. Reasons other than 4 indicate other kinds of serial errors, which should not occur.

During the initial connection sequence, you may see one or more messages which indicate "bad fcs". This refers to a checksum error in a received PPP frame, and usually occurs at the start of a session when the peer system is sending some "text" messages, such as "hello this is the XYZ company". Messages of "bad fcs" once the link is established and the routes have been added are not normal and indicate transmssion errors or noise on the telephone line.


You can use Linux PPP with a PPP server which assigns a different IP address every time you connect. You need to use the 'noipdefault' option to tell pppd to request the IP address from the remote host.

The University of Delaware uses dynamic IP assignment.

Sometimes you may get an error message like "Cannot assign requested address" when you use a Linux client (for example, "talk"). This happens when the IP address given in /etc/hosts for our hostname differs from the IP address used by the PPP interface. The solution is to use ifconfig ppp0 to get the interface address and then edit /etc/hosts appropriately.

About PPP Detailed PPP Configuration
Instructions Menu
McAfee Anti-Virus

IT Help Center
Copyright © 2002 University of Delaware
Last updated: July 27, 2002