LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/PPP-HOWTO/PPP-HOWTO.sgml

6560 lines
183 KiB
Plaintext
Raw Blame History

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<BOOK>
<BOOKINFO>
<Title><ULINK URL="http://www.linuxports.com/howto/ppp">Linux PPP HOWTO</ULINK></Title>
<AUTHOR>
<FirstName>Corwin</FirstName> <Surname>Light-Williams</Surname></AUTHOR>
<AUTHOR><FirstName>Joshua</FirstName> <Surname>Drake</Surname></AUTHOR>
<PubDate>v4.0, 8 July 2000</PubDate>
<COPYRIGHT><YEAR>2000</YEAR><HOLDER>Commandprompt, Inc</HOLDER></COPYRIGHT>
<COPYRIGHT><YEAR>1997</YEAR><HOLDER>Robert Hart</HOLDER></COPYRIGHT>
<ABSTRACT>
<PARA>
This is a LinuxPorts.Com Document for the Linux Documentation Project.
</PARA>
</ABSTRACT>
</BOOKINFO>
<PREFACE><TITLE>About This Document</TITLE>
<Para>
This document was updated via assistance from the
<ULINK URL="http://www.opendocspublishing.com/">Open Source Documentation Fund.</ULINK>
This is a <ULINK URL="http://www.linuxports.com/">LinuxPorts.Com</ULINK> Document for the
<ULINK URL="http://www.linuxdoc.org/">Linux Documentation Project</ULink>
</Para>
<Para>
This document shows how to connect your Linux PC to a PPP server, how to
use PPP to link two LANs together and provides one method of setting up
your Linux computer as a PPP server.The document also provides help in
debugging non-functional PPP connections.
</Para>
<Para>
This document is distributed under the terms of the GPL (GNU Public
License).
</Para>
</PREFACE>
<CHAPTER><TITLE>How can I help?</TITLE>
<Para>
We will try to provide comprehensive coverage for all Linux PPP implementations. However
time is of the essence and this document is not a revenue maker. We provide this information
in hopes that it will be useful to the Linux Community and newly converted Linux users.
We are always interested in feedback and will implement every relevant topic possible to
this HOWTO.
</Para>
<Para>
If you would like to assist with this document, there are two primary avenues that are extremely
helpful.
</Para>
<ItemizedList>
<ListItem>
<Para>
<Ulink URL="http://www.linuxports.com/cart/">Purchase an OpenBook!</Ulink> If you purchase
OpenDocs books, OpenDocs Publishing will donate a portion of the proceeds back to the
<Ulink URL="http://www.opendocspublishing.com/">Open Source Documentation Fund.</Ulink> This
fund assists authors financially while they continue to write documentation for Open Source
projects.
</Para>
</ListItem>
<ListItem>
<Para>
<EMPHASIS>Provide a monetary contribution to the document</EMPHASIS>. By doing so you can even request what
you would like to have updated, written, or expanded with in the document. If it is a
major revision (such as writing sections specifically for Mandrake or Caldera) please
contact <Ulink URL="http://www.commandprompt.com/">Command Prompt, Inc.</Ulink>
</Para>
</ListItem>
<ListItem>
<Para>
If you have written something that you would like to contribute just email it to
<Ulink URL="mailto:poet@linuxports.com">poet@linuxports.com</Ulink>
</Para>
</ListItem>
</ItemizedList>
</Chapter>
<CHAPTER>
<Title>Introduction</Title>
<Para>
PPP (the Point to Point Protocol) is a mechanism for creating and
running IP (the Internet Protocol) and other network protocols over a
serial link - be that a direct serial connection (using a null-modem
cable), over a telnet established link, or a link made using modems and
telephone lines (and of course using digital lines such as ISDN).
</Para>
<Para>
Using PPP, you can connect your Linux PC to a PPP server and access the
resources of the network to which the server is connected (almost) as if
you were directly connected to that network.
</Para>
<Para>
You can also set up your Linux PC as a PPP server, so that other
computers can dial into your computer and access the resources on your
local PC and/or network.
</Para>
<Para>
As PPP is a peer-to-peer system, you can also use PPP on two Linux PCs
to link together two networks (or a local network to the Internet),
creating a Wide Area Network (WAN).
</Para>
<Para>
One major difference between serial based PPP and an Ethernet connection is of course
speed - a standard Ethernet connection operates at 10 Mbs (Mega - million bits
per second) or 100 Mbs maximum theoretical throughput, whereas an analogue modem
operates at speeds up to 56 kbps (kilo - thousand bits per second).
</Para>
<Para>
Also, depending on the type of PPP connection, there may be some
limitations in usage of some applications and services.
</Para>
<Sect1>
<Title>Clients and Servers</Title>
<Para>
PPP is strictly a <Emphasis>peer to peer</Emphasis> protocol; there is (technically) no
difference between the machine that dials in and the machine that is
dialed into. However, for clarity's sake, it is useful to think in terms
of <Emphasis>servers</Emphasis> and <Emphasis>clients</Emphasis>.
</Para>
<Para>
When you dial into a site to establish a PPP connection, you are a
<Emphasis>client</Emphasis>. The machine to which you connect is the <Emphasis>server</Emphasis>.
</Para>
<Para>
When you are setting up a Linux box to receive and handle dial-in PPP
connections, you are setting up a PPP <Emphasis>server</Emphasis>.
</Para>
<Para>
Any Linux PC can be both a PPP server and client - even
simultaneously if you have more than one serial port (and modem if
necessary). As stated above, there is no real difference between clients
and servers as far as PPP is concerned, once the connection is made.
</Para>
<Para>
This document refers to the machine that initiates the call (that dials
in) as the <Emphasis>CLIENT</Emphasis>, whilst the machine that answers the telephone,
checks the authentication of the dial in request (using user names,
passwords and possibly other mechanisms) is referred to as the
<Emphasis>SERVER</Emphasis>.
</Para>
<Para>
The use of PPP as a client to link one or more machines at a location
into the Internet is, probably, the one in which most people are
interested - that is using their Linux PC as a client.
</Para>
<Para>
The procedure described in this document will allow you to
establish and automate your Internet connection.
</Para>
<Para>
This document will also give you guidance in setting up your Linux PC as
a PPP <Emphasis>server</Emphasis> and in linking two LANs together (with full routing)
using PPP (this is frequently characterized as establishing a WAN - wide
area network - link).
</Para>
</Sect1>
<Sect1>
<Title>Differences between Linux distributions</Title>
<Para>
There are many different Linux distributions and they all have their own
idiosyncrasies and ways of doing things.
</Para>
<Para>
In particular, there are two different ways a Linux (and Unix) computer
actually starts up, configures its interfaces, and so forth.
</Para>
<Para>
These are <Emphasis>BSD system initialization</Emphasis> and <Emphasis>System V system
initialization</Emphasis>. If you dip into some of the Unix news groups, you
will find occasional religious wars between proponents of these two
systems. If that sort of thing amuses you, have fun burning bandwidth
and join in!
</Para>
<Para>
Possibly the most widely used distributions are
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
Slackware
which uses BSD style system initialization
</Para>
</ListItem>
<ListItem>
<Para>
Red Hat (and its former associate Caldera)
which use SysV system initialization (although in a slightly modified form)
</Para>
</ListItem>
<ListItem>
<Para>
Debian
which uses SysV system initialization
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
BSD style initialization typically keeps its initialization files in
<Literal remap="tt">/etc/...</Literal> and these files are:-
</Para>
<Para>
<ProgramListing>
/etc/rc
/etc/rc.local
/etc/rc.serial
(and possibly other files)
</ProgramListing>
</Para>
<Para>
Of recent times, some BSD system initialization schemes use a <Literal remap="tt">/etc/rc.d...</Literal>
directory to hold the start up file rather than putting everything into <Literal remap="tt">/etc</Literal>.
</Para>
<Para>
System V initialization keeps its initialization files in directories under
<Literal remap="tt">/etc/...</Literal> or <Literal remap="tt">/etc/rc.d/...</Literal> and a number of
subdirectories under there:-
</Para>
<Para>
<ProgramListing>
drwxr-xr-x 2 root root 1024 Jul 6 15:12 init.d
-rwxr-xr-x 1 root root 1776 Feb 9 05:01 rc
-rwxr-xr-x 1 root root 820 Jan 2 1996 rc.local
-rwxr-xr-x 1 root root 2567 Jul 5 20:30 rc.sysinit
drwxr-xr-x 2 root root 1024 Jul 6 15:12 rc0.d
drwxr-xr-x 2 root root 1024 Jul 6 15:12 rc1.d
drwxr-xr-x 2 root root 1024 Jul 6 15:12 rc2.d
drwxr-xr-x 2 root root 1024 Jul 18 18:07 rc3.d
drwxr-xr-x 2 root root 1024 May 27 1995 rc4.d
drwxr-xr-x 2 root root 1024 Jul 6 15:12 rc5.d
drwxr-xr-x 2 root root 1024 Jul 6 15:12 rc6.d
</ProgramListing>
</Para>
<Para>
If you are trying to track down where your Ethernet interface and
associated network routes are actually configured, you will need to
track through these files to actually find where the commands are
that do this.
</Para>
</Sect1>
<Sect1>
<Title>PPP configuration tools</Title>
<Para>
There are many good tools available for configuring and using PPP
on Linux. This document will try to cover some of the more popular
ones, including:
</Para>
<ItemizedList>
<ListItem>
<Para>
kppp
A PPP setup and dialer tool for KDE.
</Para>
</ListItem>
<ListItem>
<Para>
WvDial
Another PPP driver for Linux, with an emphasis on simplicity.
</Para>
</ListItem>
<ListItem>
<Para>
RP3...(short for RedHat PPP). It is a simple configuration program
with a "wizard" interface- it asks a series of questions.
</Para>
</ListItem>
<ListItem>
<Para>
Linuxconf
A generalized tool for configuring and managing your Linux machine,
it has a section that helps configure PPP.
</Para>
</ListItem>
</ItemizedList>
</Sect1>
</Chapter>
<CHAPTER>
<Title>IP Numbers</Title>
<Para>
Every device that connects to the Internet must have its own, unique IP
number. These are assigned centrally by a designated authority for each
country.
</Para>
<Para>
If you are connecting a local area network (LAN) to the Internet,
<Emphasis>YOU MUST</Emphasis> use an IP number from your own assigned network range for
all the computers and devices you have on your LAN. You <Emphasis>MUST NOT</Emphasis>
pick IP numbers out of the air and use these whilst connecting to
another LAN (let alone the Internet). At worst this will simply not work
at all and could cause total havoc as your 'stolen' IP number starts
interfering with the communications of another computer that is already
using the IP number you have picked out of the air.
</Para>
<Para>
Please note that the IP numbers used throughout this document (with some
exceptions) are from the 'unconnected network numbers' series that are
reserved for use by networks that are not (ever) connected to the
Internet.
</Para>
<Para>
There are IP numbers that are specifically dedicated to LANs that do not
connect to the Internet. The IP number sequences are:-
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
One A Class Network Address
10.0.0.0 (netmask 255.0.0.0)
</Para>
</ListItem>
<ListItem>
<Para>
16 B Class Network Addresses
172.16.0.0 - 172.31.0.0 (netmask 255.255.0.0)
</Para>
</ListItem>
<ListItem>
<Para>
256 C Class Network Addresses
192.168.0.0 - 192.168.255.0 (netmask 255.255.255.0)
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
If you have a LAN for which you have <Emphasis>not</Emphasis> been allocated IP
numbers by the responsible authority in your country, you should use one
of the network numbers from the above sequences for your machines.
</Para>
<Para>
These numbers should <Emphasis>never</Emphasis> be used on the Internet.
</Para>
<Para>
However, they can be used for the local Ethernet on a machine that is
connecting to the Internet. This is because IP numbers are actually
allocated to a network interface, not to a computer. So whilst your
Ethernet interface may use 10.0.0.1 (for example), when you hook onto
the Internet using PPP, your PPP interface will be given another (and
valid) IP number by the server. Your PC will have Internet connectivity,
but the other computers on your LAN will not.
</Para>
<Para>
However, using Linux and the IP Masquerade (also known as NAT - Network
address Translation) capabilities of the Linux and the ipfwadm
software, you can connect your LAN to the Internet (with some
restriction of services), even if you do not have valid IP numbers for the
machines on your Ethernet.
</Para>
<Para>
For more information on how to do this see the IP Masquerade mini-HOWTO
at <ULink
URL="http://metalab.unc.edu/mdw/HOWTO/IP-Masquerade-HOWTO.html"
>Linux IP Masquerade mini HOWTO</ULink
>
</Para>
<Para>
For most users, who are connecting a single machine to an Internet
service provider via PPP, obtaining an IP number (or more accurately, a
network number) will not be necessary.
</Para>
<Para>
If you wish to connect a small LAN to the Internet, many Internet
Service Providers (ISPs) can provide you with a dedicated subnet (a specific
sequence of IP numbers) from their existing IP address space.
Alternatively, use IP Masquerading.
</Para>
<Para>
For users, who are connecting a single PC to the Internet via an ISP,
most providers use <Emphasis>dynamic</Emphasis> IP number assignment. That is, as part
of the connection process, the PPP service you contact will tell your
machine what IP number to use for the PPP interface during the current
session. This number will not be the same every time you connect to your
ISP.
</Para>
<Para>
With dynamic IP numbers, you are <Emphasis>not</Emphasis> necessarily
given the same IP number each time you connect. This has implications for
server type applications on your Linux machine such as sendmail, ftpd, httpd
and so forth. These services are based on the premise that the computer
offering the service is accessible at the same IP number all the time
(or at least the same fully qualified domain name - FQDN - and that DNS
resolution of the name to IP address is available).
</Para>
<Para>
The limitations of service due to dynamic IP number assignment (and ways
to work around these, where possible) are discussed later in the
document.
</Para>
</Chapter>
<CHAPTER>
<Title>Aims of this Document</Title>
<Sect1>
<Title>Setting up a PPP Client</Title>
<Para>
This document provides guidance to people who wish to use Linux and PPP to
dial into a PPP server and set up an IP connection using PPP. It assumes
that PPP has been compiled and installed on your Linux machine (but does
briefly cover reconfiguring/recompiling your kernel to include PPP support).
</Para>
<Para>
Whilst DIP (the standard way of creating a SLIP connection) can be used
to set up a PPP connection, DIP scripts are generally quite complex. For
this reason, this document does NOT cover using DIP to set up a PPP
connection.
</Para>
<Para>
Instead, this document describes the standard Linux PPP software
(chat/pppd).
</Para>
</Sect1>
<Sect1>
<Title>Linking two LANs or a LAN to the Internet using PPP</Title>
<Para>
This document provides (basic) information on linking two LANs or a LAN
to the Internet using PPP.
</Para>
</Sect1>
<Sect1>
<Title>Using intuitive configuration tools to set up PPP</Title>
<Para>
There are many tools used for configuring your PPP connection.
This document will try to cover the most common and easiest to
use of said programs.
</Para>
</Sect1>
<Sect1>
<Title>Setting up a PPP server</Title>
<Para>
This document provides guidance on how to configure your Linux PC
as a PPP server (allowing other people to dial into your Linux PC and
establish a PPP connection).
</Para>
<Para>
You should note that there are a myriad of ways of setting up Linux as a
PPP server. This document gives one method - that used by
the author to set up several small PPP servers (each of 16 modems).
</Para>
<Para>
This method is known to work well. However, it is not necessarily
the best method.
</Para>
</Sect1>
<Sect1>
<Title>Using PPP over a direct null modem connection</Title>
<Para>
This document provides a brief overview of using PPP to link two Linux
PCs via a null modem cable. It is possible to link other OS's to Linux
this way as well. To do so, you will need to consult the documentation
for the operating system you are interested in.
</Para>
</Sect1>
<Sect1>
<Title>This document at present does NOT cover...</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Compiling the PPP daemon software
See the documentation that comes with the version of pppd you are using.
</Para>
</ListItem>
<ListItem>
<Para>
Connecting and configuring a modem to Linux (in detail)
See the Serial-HOWTO and for modem specific initialization, see <ULink
URL="http://www.in.net/info/modems/index.html"
>Modem Setup Information</ULink
> for information that may help you to configure your modem.
</Para>
</ListItem>
<ListItem>
<Para>
Using DIP to make PPP connections.
Use chat instead...
</Para>
</ListItem>
<ListItem>
<Para>
Using socks or IP Masquerade.
There are perfectly good documents already covering these two packages.
</Para>
</ListItem>
<ListItem>
<Para>
Using EQL to gang together two modems into a single PPP link. This is covered in the
<Ulink URL="http://www.linuxports.com/howto/networking">Networking-HOWTO</Ulink>.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect1>
</Chapter>
<CHAPTER>
<Title>Software versions covered</Title>
<Para>
This HOWTO assumes that you are using a Linux 1.2.x kernel with the
PPP 2.1.2 software or 1.3.x/2.0.x/2.2.x kernel with the PPP 2.4.0 software.
</Para>
<Para>
This HOWTO will cover version 1.6.18 of KPPP.
</Para>
<Para>
This HOWTO will cover version 1.41 of WvDial.
</Para>
<Para>
This HOWTO will cover version 0.03 of PPPoE.
</Para>
<Para>
This HOWTO will cover version 1.18 of Linuxconf.
</Para>
<Para>
<Emphasis>
Please try to use the latest versions of software, as many bugs are fixed
as time goes on.
</Emphasis>
</Para>
</Chapter>
<CHAPTER>
<Title>Other Useful/Important Documents</Title>
<Para>
Users are advised to read :-
<ItemizedList>
<ListItem>
<Para>
The documentation that comes with the PPP package.
</Para>
</ListItem>
<ListItem>
<Para>
The pppd and chat man pages;
(use <Literal remap="tt">man chat</Literal> and <Literal remap="tt">man pppd</Literal> to explore these.)
</Para>
</ListItem>
<ListItem>
<Para>
The Linux Network Administration Guide (NAG);
see <ULink
URL="http://metalab.unc.edu/mdw/LDP/nag/nag.html"
>The Network Administrators' Guide</ULink
>.
</Para>
</ListItem>
<ListItem>
<Para>
The Net-2/3 HOWTO;
see <ULink
URL="http://metalab.unc.edu/mdw/HOWTO/NET3-4-HOWTO.html"
>Linux Networking-HOWTO</ULink
>.
</Para>
</ListItem>
<ListItem>
<Para>
Linux kernel documentation installed in
<Literal remap="tt">/usr/src/linux/Documentation</Literal> when you install the Linux source
code.
</Para>
</ListItem>
<ListItem>
<Para>
The modem setup information page - see <ULink
URL="http://www.in.net/info/modems/index.html">
Modem Setup Information</ULink>.
</Para>
</ListItem>
<ListItem>
<Para>
The excellent Unix/Linux books published by O'Reilly and
Associates. See (<ULink
URL=" http://www.ora.com/"
>O'Reilly and Associates On-Line Catalogue</ULink
>). If you are new
to Unix/Linux, <Emphasis>run</Emphasis> (don't walk) to your nearest computer book shop
and invest in a number of these immediately!
</Para>
</ListItem>
<ListItem>
<Para>
The PPP-FAQ maintained by Al Longyear, available from <ULink
URL="ftp://sunsite.unc.edu/pub/Linux/docs/faqs/PPP-FAQ/PPP-FAQ"
>Linux PPP-FAQ</ULink
>.
This contains a great deal of useful information in question/answer
format that is very useful when working out why PPP is not working
(properly).
</Para>
</ListItem>
<ListItem>
<Para>
The growing number of Linux books from various publishing houses and
authors;
You are actively encouraged to check the currency of these
books. Linux development and distributions tend to evolve fairly
rapidly, whilst the revision of books move (generally) much more slowly!
Buying an excellent book (and there are many) that is now out of date
will cause new users considerable confusion and frustration.
</Para>
</ListItem>
<ListItem>
<Para>
The documentation associated with the PPP tool(s) you are using
The package specific documentation, usually easily available, is
often the most useful when dealing with a specific tool.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
The best general starting point for Linux documentation is <ULink
URL="http://www.linuxdoc.org"
>The Linux Documentation Project Home Page</ULink
>. The HOWTO's tend to be revised reasonably regularly.
</Para>
<Para>
Whilst you can use this document to create your PPP link without reading
any of these documents, you will have a far better understanding of what
is going on if you do so! You will also be able to address problems
yourself (or at least ask more intelligent questions on the
comp.os.linux... newsgroups or Linux mailing lists).
</Para>
<Para>
These documents (as well as various others, including the relevant RFCs)
provide additional and more detailed explanation than is possible in
this HOWTO.
</Para>
<Para>
If you are connecting a LAN to the Internet using PPP, you will need
to know a reasonable amount about TCP/IP networking. In addition to the
documents above, you will find the O'Reilly books "TCP/IP Network Administration"
and "Building Internet Firewalls" of considerable benefit!
</Para>
<Sect1>
<Title>Useful Linux Mailing Lists</Title>
<Para>
There are many Linux mailing lists that operate as a means of communication
between users of many levels of ability. By all means subscribe to those
that interest you and contribute your expertise and views.
</Para>
<Para>
<Emphasis>A word to the wise</Emphasis>: some lists are specifically aimed at "high powered"
users and/or specific topics. Whilst no-one will complain if you 'lurk'
(subscribe but don't post messages), you are likely to earn heated
comments (if not outright flames) if you post 'newbie' questions to
inappropriate lists.
</Para>
<Para>
This is not because guru level users hate new users, but because these
lists are there to handle the specific issues at particular levels of
difficulty.
</Para>
<Para>
By all means join the lists that offer open subscription, but keep your
comments relevant to the subject of the list!
</Para>
<Para>
A good starting point for Linux mailing lists is
<ULink
URL="http://oslab.snu.ac.kr/~djshin/linux/mail-list/index.shtml"
>Linux Mailing List Directory</ULink>
</Para>
</Sect1>
</Chapter>
<Chapter id="tools">
<Title>Easy Configuration Utilities for PPP</Title>
<Sect1>
<Title>KPPP - The KDE PPP Dialer</Title>
<Para>
http://devel-home.kde.org/~kppp/index.html
</Para>
<Para>
KPPP is an easy tool for configuring your PPP links. It comes with the
default installation of KDE, and is quite well integrated into that
environment.
</Para>
<Para>
KPPP also has a good help system built in. If you just right click
on the majority of the buttons in the application, a menu will pop
up with an item called "Quickhelp". Clicking it will give a quick
summary of whatever item you clicked on.
</Para>
<Para>
The opening screen of kppp will list any available connections, and
allow you to specify a Login ID and password for the connection.
There is also a "Show Log Window" option. Selecting this will show
a log window. This can be handy if you are trying to debug a connection.
</Para>
<mediaobject>
<imageobject>
<imagedata fileref="images/snapshot05.eps" format="eps">
</imageobject>
<imageobject>
<imagedata fileref="images/snapshot05.jpg" format="jpg">
</imageobject>
</mediaobject>
<Para>
For now, click on the "Setup" button. This will bring up the setup
window. It has a series of tabs across the top. Select the one called
"Accounts". There will be a list of Accounts, if any.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot06.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot06.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Select "New" from the right hand side. Another menu will pop up.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot01.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot01.jpg" format="jpg"></imageobject></mediaobject>
<Para>
First, specify a name for this connection in the "Connection Name" box.
A good name would be the name of your ISP. Then enter the phone number.
Select the type of authentication. If your ISP hasn't specified otherwise,
leave it as "PAP". You can optionally store your password between sessions,
but this may be a security risk.
</Para>
<Para>
Click on the tab marked "IP". Here you have the option to configure your
IP address, either a Dynamic or Static address. You should know what kind
you want, specified by your ISP. You can also optionally specify that
you wish to configure the hostname for this IP, which means that kppp will
name your machine according to the name given to it by your ISP.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot07.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot07.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click on the tab marked "DNS". Here you can set up DNS. Fill in the appropriate
fields with the information supplied from your ISP.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot08.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot08.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click on the "Gateway" tab. Here you can configure your gateway, or router
address. If a gateway or router address was specified by your ISP, select
"Static Gateway" and enter it in the box below. Otherwise leave this alone.
The box marked "Assign the Default Route" should be checked.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot09.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot09.jpg" format="jpg"></imageobject></mediaobject>
<Para>
The "Login Script" tag is only useful if you specified "Login Script"
authentication under the "Dial" tab. If you need to use a Login Script,
you can enter it here, as a series of commands. Select the type of command
you wish to use, followed by the argument, then click "Add". Click "Remove"
to remove a selected command.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot10.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot10.jpg" format="jpg"></imageobject></mediaobject>
<Para>
The "Accounting" tab allows you to track the number of bytes that you
have sent and recieved for a given connection. This can be useful if your
ISP tracks the amount of data that you use, and perhaps charges you based
on that. If you wish to use accounting, click on the "Enable accounting" box.
You can then select a country, if you live in a country that has taxes,
tariffs, or other charges based on data transfer. Otherwise, just select
either "Bytes in", "Bytes in and out", or "Bytes out". For more information,
consult the KPPP manual.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot11.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot11.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click OK to finish the creation of this new account.
</Para>
<Para>
Now we'll cover the other tabs in the kppp configuration window.
</Para>
<Para>
The next one is "Device". It contains configuration information about
your modem. You can select the device, flow control, line termination,
and connection speed. It is recommended that you leave these alone unless
otherwise specified by your ISP. You can also specify values for using
a lock file for your modem device(recommended) and a modem timeout.
Modem timeout refers to the amount of time that kppp will wait for your
modem to respond.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot12.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot12.jpg" format="jpg"></imageobject></mediaobject>
<Para>
The "Modem" tab is mainly useful for debugging your modem. You can also
adjust your modem volume. For more information on these commands, consult
the kppp documentation.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot13.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot13.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Next is the "PPP" tag. It contains many useful items for making kppp tailor
fit to your needs. The "pppd Timeout" field specifies how long kppp should
wait for pppd to bring up a connection. The "Dock" option states that kppp
should recede into the KDE dock when it is connected. The "Automatic redial"
specifies that kppp should redial if it is disconnected. The "show clock"
option will display how time you have been connected. The "Disconnect on
X-server shutdown" means that if you leave KDE, PPP should shut down.
The "Quit on Disconnect" option will close kppp if you disconnect from your
ISP. Finally, the "Minimize window on connect" option will minimize kppp
when it connects.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot14.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot14.jpg" format="jpg"></imageobject></mediaobject>
<Para>
The "Graph" tab is useful for kppp's throughput graphing. For more information
on this feature, see kppp's documentation.
</Para>
<Para>
Click Ok to leave this menu. Now ensure your connection is selected in
the "Connect to:" box, and click "connect". You're all set!
</Para>
</Sect1>
<Sect1><Title>WvDial - A command-line pppd driver</Title>
<Para>
The WvDial homepage is <ULink URL="http://www.worldvisions.ca/wvdial/">here</Ulink>
</Para>
<Para>
WvDial is a command-line pppd driver. It has two main components, wvdialconf
and wvdial. Both must be run as root.
</Para>
<Para>
First you must run wvdialconf. wvdialconf is generates a configuration
file containing information on your modem and ISP information. Running
wvdialconf will probe your comm ports, looking for a modem, and determine
the capabilities of any modems it finds.
</Para>
<Para>
wvdialconf is invoked with the name of your wvdial configuration file-
which is always /etc/wvdial.conf. Here's what the output should look like.
</Para>
<SCREEN>
[root@blah /root]# wvdialconf newconffile
Scanning your serial ports for a modem.
ttyS1<*1>: ATQ0 V1 E1 -- OK
ttyS1<*1>: ATQ0 V1 E1 Z -- OK
ttyS1<*1>: ATQ0 V1 E1 S0=0 -- OK
ttyS1<*1>: ATQ0 V1 E1 S0=0 &amp;C1 -- OK
ttyS1<*1>: ATQ0 V1 E1 S0=0 &amp;C1 &amp;D2 -- OK
ttyS1<*1>: ATQ0 V1 E1 S0=0 &amp;C1 &amp;D2 S11=55 -- OK
ttyS1<*1>: ATQ0 V1 E1 S0=0 &amp;C1 &amp;D2 S11=55 +FCLASS=0 -- OK
ttyS1<*1>: Modem Identifier: ATI -- 28800
ttyS1<*1>: Speed 2400: AT -- OK
ttyS1<*1>: Speed 4800: AT -- OK
ttyS1<*1>: Speed 9600: AT -- OK
ttyS1<*1>: Speed 19200: AT -- OK
ttyS1<*1>: Speed 38400: AT -- OK
ttyS1<*1>: Speed 57600: AT -- OK
ttyS1<*1>: Speed 115200: AT -- OK
ttyS1<*1>: Max speed is 115200; that should be safe.
ttyS1<*1>: ATQ0 V1 E1 S0=0 &amp;C1 &amp;D2 S11=55 +FCLASS=0 -- OK
ttyS0<*1>: ATQ0 V1 E1 -- ATQ0 V1 E1 -- ATQ0 V1 E1 -- nothing.
Port Scan<*1>: S2 S3
Found a modem on /dev/ttyS1.
</SCREEN>
<Para>
If your output looks different, check that your modem is plugged in,
turned on, and connected to a com port.
</Para>
<Para>
Once you have run wvdialconf, you need to edit the /etc/wvdial.conf file
to reflect the phone number to dial, and your username and password.
Open up /etc/wvdial.conf in your favorite text editor. It should look
something like this:
</Para>
<Screen>
[Dialer Defaults]
Modem = /dev/ttyS1
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &amp;C1 &amp;D2 S11=55 +FCLASS=0
; Phone = 555-1212
; Username = my_login_name
; Password = my_login_password
</Screen>
<Para>
Remove the ';' and fill in the appropriate fields- phone number,
login name and password. Now you should be all set to run wvdial.
</Para>
<Para>
Run wvdial. Assuming that you filled in your phone number, username,
and password correctly, wvdial will now dial your ISP. wvdial will not
exit until the connection is terminated- you can do a Ctrl-C to terminate
it.
</Para>
<Para>
wvdial is fairly new and untested software, so if you run into any
problems along the way, you should contact the authors. You can find
their contact info on the homepage listed above.
</Para>
</Sect1>
<Sect1>
<Title>rp3 - RedHat PPP dialer</Title>
<Para>
A good page about rp3 is located <ULink URL="http://www.redhat.com/support/manuals/RHL-6.2-Manual/getting-started-guide/ch-ppp.html">here</ULink>.
</Para>
<Para>
rp3 is available on any RedHat system running RedHat 6.2 or later.
It is located on your GNOME menu under Internet- called
"Dialup Configuration Tool". It is perhaps the simplest to use
of the tools this HOWTO covers. When you start it up, it presents
you with a screen that looks like this:
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot04.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot04.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click "Next". If rp3 can't find a modem, it will try to confiugre one.
Select your modem from the list and click next if this happens. You should
see a screen asking for an "Account name" and a phone number. Enter your
ISP's name and number in the appropriate fields. Click "Next".
</Para>
<Para>
rp3 will then ask you for your username and password. Enter them
in the appropriate fields and click "Next". Next rp3 will ask you
if your ISP is named in a list. If it is, select it and click
next. If not, select "Normal ISP" and click next.
</Para>
<Para>
That's it! Click "Finish" to complete account creation.
</Para>
<Para>
To initiate a connection, go to the GNOME menu again, and look under Internet
for "RH PPP Dialer". Click on it. When asked for an interface, select
"ppp0". This should bring up a small window. Right click on the window,
then on "Connect to ppp0". Wait a few seconds, and you're online! To
disconnect, right click on the window again, and then click "Disconnect".
That's it.
</Para>
</Sect1>
<Sect1>
<Title>Linuxconf - Universal (almost) Linux PPP dialer</Title>
<Para>
<ULink URL="http://dns.solucorp.qc.ca/linuxconf/">Linuxconf homepage</ULink>
</Para>
<Para>
For help at any time while using Linuxconf, just hit the help key. Linuxconf
has contextual help menus for most its functionality.
</Para>
<Para>
Linuxconf's PPP section is fairly simple. First of all, open up Linuxconf.
This must be done as root. Here's a shot of Linuxconf in action:
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot02.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot02.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click on the box next to "Config", then the box on "Networking", then the
box next to "Client tasks". You should see an entry called "PPP/SLIP/PLIP".
Click on that. On the right hand side of Linuxconf, you should now see
a box called "PPP/Slip/Plip configurations". There should be an area
below that, listing existing PPP devices(if any) and three buttons below
that.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot15.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot15.jpg" format="jpg"></imageobject></mediaobject>
<Para>
Click "Add" to add a new connection. It will then ask you to
select a type of interface. Make sure "PPP" is selected, then press
Accept.
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot03.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot03.jpg" format="jpg"></imageobject></mediaobject>
<Para>
In this box, there are fields for phone number, modem, username and password.
Enter the appropriate information into the appropriate fields, and
you should be configured.
</Para>
<Para>
To bring up the PPP link, open the "Control" tab on the left hand side,
then go to "Control Panels", then "Control PPP/SLIP/PLIP Link".
You should see a list of PPP devices. Click on the one you just made.
A question will pop up, asking you if you wish to activate the connection.
Click "Yes".
</Para>
<mediaobject><imageobject><imagedata fileref="images/snapshot16.eps" format="eps"></imageobject><imageobject><imagedata fileref="images/snapshot16.jpg" format="jpg"></imageobject></mediaobject>
<Para>
There are also advanced configuration options, such as modem speed,
connect scripts and etc. If you need to configure any of that, go
back to the place where you originally configured the link, and click
on the link you wish to customize. It should bring up a screen with
four tabs: Hardware, Communication, Networking,and PAP.
</Para>
<Para>
It is advisable to not change any of these options unless you are specifically
told to do so by your ISP or modem vendor. Most of them will work just fine
without any additional configuration.
</Para>
<Para>
Linuxconf also has command line tools for use in bringing your
PPP connection up and down:
</Para>
<ItemizedList>
<ListItem>
<Para>
netconf --connect pppsetup [--fore]
This will bring the link up. The optional --fore means that it remains
in the foreground. Otherwise it will terminate either if the connection is
successful or if it fails. It will return 0 if successful, higher if otherwise.
</Para>
<Para>
</Para>
</ListItem>
<ListItem>
<Para>
netconf --dialctl
This will display all the available connections and their status.
</Para>
</ListItem>
<ListItem>
<Para>
netconf --disconnect pppsetup
This will disconnect the link.
</Para>
</ListItem>
</ItemizedList>
</Sect1>
</Chapter>
<Chapter id=PROBLEMS><Title>Debugging</Title>
<Para>
There are any number of reasons that your connection does not work -
chat has failed to complete correctly, you have a dirty line, etc. So
check your syslog for indications.
</Para>
<Sect1><Title>I have compiled PPP support into the kernel, but...</Title>
<Para>
A very common problem is that people compile PPP support into the kernel
and yet when they try to run pppd, the kernel complains that it does not
support ppp! There are a variety of reasons this can occur.
</Para>
<Sect2>
<Title>Are you booting the right kernel?</TITLE>
<Para>
Whilst you <Emphasis>have</Emphasis> recompiled your kernel to support ppp, you
are not booting the new kernel. This can happen if you do not update
<Literal remap="tt">/etc/lilo.conf</Literal> and rerun lilo.
</Para>
<Para>
A good check on the kernel can be obtained by issuing the command
<Literal remap="tt">uname -a</Literal>, which should produce a line like:-
</Para>
<Para>
<ProgramListing>
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
</ProgramListing>
</Para>
<Para>
This gives the kernel version and the date on which this kernel was
compiled - which should give you a pretty good idea of what is going on.
</Para>
</Sect2>
<Sect2>
<Title>Did you compile ppp kernel support as a module?</Title>
<Para>
If you compiled your kernel ppp support as a module, but did not make
and install the modules, then you can get this error. Check the
kernel-HOWTO and the README file in <Literal remap="tt">/usr/src/linux</Literal>!
</Para>
<Para>
Another module connected possibility is that you are expecting required
modules to be automatically loaded, but are not running the <Literal remap="tt">kerneld</Literal>
daemon (which auto-loads and unloads modules on the fly). Check the
kerneld mini-HOWTO for information on setting up kerneld.
</Para>
</Sect2>
<Sect2>
<Title>Are you using the correct version of PPP for your kernel?</Title>
<Para>
You <Emphasis>must</Emphasis> use ppp-2.2 with kernel version 2.0.x. You can use ppp-2.2
with kernel version 1.2.x (if you patch the kernel), otherwise you must
use ppp-2.1.2.
</Para>
</Sect2>
<Sect2>
<Title>Are you running pppd as root?</Title>
<Para>
If you are not running pppd as the root user (and pppd is not suid to
root), you can receive this message.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>My modem connects but ppp never starts up</Title>
<Para>
There are innumerable variations on this (take a look in comp.os.linux...).
</Para>
<Para>
A <Emphasis>VERY</Emphasis> common mistake is that you have mistyped something in your
scripts. The only thing to do here is to make sure you are logging the
chat conversation between you Linux PC and the server into your syslog
(/var/log/messages) and then go through this <Emphasis>line by line</Emphasis> to make
sure there are no mistakes.You may need to dial into the ppp server manually to check
things out again.
</Para>
<Para>
You need to check the log against the actual prompts very carefully -
and bear in mind that we humans have a tendency to read what we THINK we
have typed - not what is actually there!
</Para>
</Sect1>
<Sect1>
<Title>The syslog says "serial line is not 8 bit clean"</Title>
<Para>
There are variations on this too - such as <Literal remap="tt">serial line looped back</Literal>
etc., and the cause can be one (or a sequence) of a number of things.
</Para>
<Para>
To understand what is going on here, it is necessary to grasp a bit of
what is going on behind the scenes in pppd itself.
</Para>
<Para>
When pppd starts up, it sends LCP (link control protocol) packets to the
remote machine. If it receives a valid response it then goes on to the
next stage (using IPCP - IP control protocol packets) and only when
this negotiation completes is the actual IP layer started so that you
can use the PPP link.
</Para>
<Para>
If there is no ppp server operating at the remote end when your PC sends
lcp packets, these get reflected by the login process at the far end. As
these packets use 8 bits, reflecting them strips the 8th bit (remember,
ASCII is a 7 bit code). PPP sees this and complains accordingly.
</Para>
<Para>
There are several reasons this reflection can occur.
</Para>
<Sect2>
<Title>You are not correctly logging into the server</Title>
<Para>
When your chat script completes, pppd starts on your PC. However, if you
have not completed the log in process to the server (including sending
any command required to start PPP on the server), PPP will not start.
</Para>
<Para>
So, the lcp packets are reflected and you receive this error.
</Para>
<Para>
You need to carefully check and correct (if necessary) your chat script
(see above).
</Para>
</Sect2>
<Sect2>
<Title>You are not starting PPP on the server</Title>
<Para>
Some PPP servers require you to enter a command and/or a RETURN after
completing the log in process before the remote end starts ppp.
</Para>
<Para>
Check your chat script (see above).
</Para>
<Para>
If you log in manually and find you need to send a RETURN after this to
start PPP, simply add a blank expect/send pair to the end of your chat
script (an empty send string actually sends a RETURN).
</Para>
</Sect2>
<Sect2>
<Title>The remote PPP process is slow to start</Title>
<Para>
This one is a bit tricksy!
</Para>
<Para>
By default, your Linux pppd is compiled to send a maximum of 10 lcp
configuration requests. If the server is a bit slow to start up, all 10
such requests can be sent before the remote PPP is ready to receive
them.
</Para>
<Para>
On your machine, pppd sees all 10 requests reflected back (with the 8th
bit stripped) and exits.
</Para>
<Para>
There are two ways round this:-
</Para>
<Para>
Add "<Literal remap="tt">lcp-max-configure 30</Literal>" to your ppp options. This increases
the maximum number of lcp configure packets pppd sends before giving up.
For really slow server, you may need even more than this.
</Para>
<Para>
Alternatively, you can get a bit tricksy in return. You may have noticed
that when you logged in by hand to the PPP server and PPP started there,
the <Emphasis>first</Emphasis> character of the ppp garbage that appears was always the
tilde character (&tilde;).
</Para>
<Para>
Using this knowledge we can add a new <Literal remap="tt">expect/send</Literal> pair to the
end of the chat script which expects a tilde and sends nothing. This
would look like:-
</Para>
<Para>
<ProgramListing>
\~ ''
</ProgramListing>
</Para>
<Para>
Note: as the tilde character has a special meaning in the shell, it must
be escaped (and hence the leading backslash).
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Default route not set</Title>
<Para>
If pppd refuses to set up a default route, it is because (quite
correctly) it refuses to remove/replace an existing default route.
</Para>
<Para>
The usual reason that this error occurs is that some distributions set
up a default route via your Ethernet card as opposed to setting up a
specific network route.
</Para>
<Para>
See the Linux NAG and the Net2/3 HOWTOs for information on correctly
setting up your Ethernet card and associated routes.
</Para>
<Para>
An alternative to this is that your LAN uses a gateway/router already and your
routing table has been set up to point the default route at this.
</Para>
<Para>
Fixing up this last situation can require a fair bit of IP networking knowledge
and is beyond the scope of this HOWTO. It is suggested you obtain some
expert advice (via the news groups of from someone locally you can ask).
</Para>
</Sect1>
<Sect1>
<Title>Other Problems</Title>
<Para>
There are many reasons apart from these that ppp fails to connect and/or
operate properly.
</Para>
<Para>
Look in the PPP FAQ (which is really a series of questions and
answers). This is a very comprehensive document and the answers ARE
there! From my own (sad) experience, if the answer to your
problems is not there, the problem is NOT ppp's fault! In my case I was
using an ELF kernel that I had not upgraded to the appropriate
kernel modules. I only wasted about 2 days (and most of one night)
cursing what had been a perfect PPP server before the light dawned!
</Para>
</Sect1>
</Chapter>
<CHAPTER>
<Title>Overview of what has to be done to get PPP working as a client</Title>
<Para>
This document contains a great deal of information - and with each
version it grows!
</Para>
<Para>
As a consequence, this section aims to provide a concise overview of the
actions you will need to take to get your Linux system connected as a
client to a PPP server.
</Para>
<Sect1>
<Title>Obtaining/Installing the software</Title>
<Para>
If your Linux distribution does not include the PPP software, you will
need to obtain this from <ULink
URL="ftp://ftp.linuxcare.com.au/pub/ppp/"
>the Linux PPP daemon</ULink>.
</Para>
<Para>
Select the latest possible version(2.4.0 at the time of this writing.)
</Para>
<Para>
The PPP package contains instructions on how to compile and install the
software <Emphasis>so this HOWTO does not</Emphasis>!
</Para>
</Sect1>
<Sect1>
<Title>Compiling PPP support into the kernel</Title>
<Para>
Linux PPP operations come in two parts
<ItemizedList>
<ListItem>
<Para>
the PPP daemon mentioned above
</Para>
</ListItem>
<ListItem>
<Para>
kernel support for PPP
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Most distributions seem to provide PPP kernel support in their default
installation kernels, but others do not.
</Para>
<Para>
If at boot your kernel reports messages like
</Para>
<Para>
<ProgramListing>
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
</ProgramListing>
</Para>
<Para>
your kernel does have PPP support compiled in.
</Para>
<Para>
That said, you may want to compile your own kernel, whatever
your distribution, to provide the most efficient use of system resources
given your particular hardware configuration. It is worth remembering
that the kernel cannot be swapped out of memory and so keeping the
kernel as small as possible has advantages on a memory limited machine.
</Para>
<Para>
This document provides minimal kernel re-compilation instructions at
section <XRef LinkEnd="Kernel-configuration">.
</Para>
<Para>
For greater detail, see the Kernel-HOWTO at <ULink
URL="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html"
>The Linux Kernel HOWTO</ULink>
</Para>
</Sect1>
<Sect1>
<Title>Obtaining information from your ISP</Title>
<Para>
There are an almost infinite number of ways in which a PPP server can be
set up. In order to connect to your ISP (or corporate PPP server to access
your intranet), you will need to obtain information on how the PPP
server operates.
</Para>
<Para>
Because you are using Linux, you may have some difficulty with some ISP
help desks (and work site based PPP intranet servers) which know only
about MS Windows clients.
</Para>
<Para>
However, a rapidly growing number of ISPs use Linux to provide their
service - and Linux is also penetrating the corporate environment as
well, so you may be lucky if you do strike problems.
</Para>
<Para>
Section <XRef LinkEnd="Server-info"> tells you what you need to know about the PPP server
to which you are going to connect - and how to find out the information
you need to know.
</Para>
</Sect1>
<Sect1>
<Title>Configuring your modem and serial port</Title>
<Para>
In order to connect to a PPP server and to obtain the best possible
data transfer rate, your modem needs to be configured correctly.
</Para>
<Para>
Similarly, the serial ports on your modem and computer need to be set up
correctly.
</Para>
<Para>
Section <XRef LinkEnd="Modem">
provides information on this.
</Para>
</Sect1>
<Sect1>
<Title>Setting up Name to Address Resolution (DNS)</Title>
<Para>
In addition to the files that run PPP and perform the automated log in
to the PPP server, there are a number of text configuration files that
have to be set up for your computer to be able to resolve names like
<Literal remap="tt">www.interweft.com.au</Literal> to the IP address
that is actually used to contact that computer. These are:-
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
<Literal remap="tt">/etc/resolv.conf</Literal>
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">/etc/host.conf</Literal>
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Section <XRef LinkEnd="DNS">
for details on setting this up.
</Para>
<Para>
In particular, you do <Emphasis>NOT</Emphasis> need to run a name server on your Linux
PC in order to connect to the Internet (although you may wish to). All
you need is to know the IP number of at least one name server that you
can use (preferably one at your ISPs site).
</Para>
</Sect1>
<Sect1>
<Title>PPP and root Privileges</Title>
<Para>
As establishing a PPP link between you Linux computer and another PPP
server requires manipulation of network devices (the PPP interface is a
network interface) and the kernel routing table, pppd requires root
privileges.
</Para>
<Para>
For details on this, see section <XRef LinkEnd="root">.
</Para>
</Sect1>
<Sect1>
<Title>Checking your distribution PPP Files and setting up the PPP Options</Title>
<Para>
There are a number of configuration and dialer files that need to be set up
to get PPP operational. There are examples as part of the PPP
distribution and this section shows what files you should have:-
</Para>
<Para>
<ProgramListing>
/etc/ppp/options
/etc/ppp/scripts/ppp-on
/etc/ppp/scripts/ppp-on-dialer
/etc/ppp/options.tpl
</ProgramListing>
</Para>
<Para>
You may need to create some additional files depending on exactly what
you are aiming to achieve with PPP:-
</Para>
<Para>
<ProgramListing>
/etc/ppp/options.ttyXX
/etc/ppp/ip-up
/etc/ppp/pap-secrets
/etc/ppp/chap-secrets
</ProgramListing>
</Para>
<Para>
In addition, the PPP daemon can use a large number of command line
options and it is important to use the right ones; so this section takes
you through the standard PPP options and helps you choose the options
you should use.
</Para>
<Para>
For details on this, see <XRef LinkEnd="options">.
</Para>
</Sect1>
<Sect1>
<Title>If your PPP server uses PAP (Password Authentication Protocol)</Title>
<Para>
Many ISPs and corporate PPP servers use PAP. If your server does
<Emphasis>not</Emphasis> require you to use PAP (if you can log in manually and receive
the standard user name/password text based prompts it does not use PAP),
you can safely ignore this section.
</Para>
<Para>
Instead of logging into such a server using a user name and password
when prompted to enter them by the server, a PPP server using PAP does
not require a text based login.
</Para>
<Para>
The user authentication information instead is exchanged as part of the
link control protocol (LCP), which is the first part of establishing a
PPP link.
</Para>
<Para>
Section <XRef LinkEnd="pap"> provides information on the files you need to set up to
establish a PPP link using PAP.
</Para>
</Sect1>
<Sect1>
<Title>Connecting to the PPP server by hand</Title>
<Para>
Having set up the basic files, it is a good idea to test these by
connecting (using minicom or seyon) and starting pppd on your Linux PC
by hand.
</Para>
<Para>
See Section <XRef LinkEnd="manual"> for
full details of setting this up.
</Para>
</Sect1>
<Sect1>
<Title>Automating your PPP Connection</Title>
<Para>
Once you are able to log in by hand, you can now move to setting up a
set of scripts that will automate the establishment of the connection.
</Para>
<Para>
Section <XRef LinkEnd="automate"> covers setting up the necessary scripts, with
considerable attention paid to <Literal remap="tt">chat</Literal> and scripting the login process
to the PPP server.
</Para>
<Para>
This section discusses scripts for user name/password authentication as
well as scripts for PAP/CHAP authenticating servers.
</Para>
</Sect1>
<Sect1>
<Title>Shutting down the link</Title>
<Para>
Once your link is up and working, you need to be able to deactivate the
link.
</Para>
<Para>
This is covered in Section <XRef LinkEnd="off">.
</Para>
</Sect1>
<Sect1>
<Title>If you have problems</Title>
<Para>
Many people have problems getting PPP to work straight away. The
variation in PPP servers and how they require you to set up the
connection is enormous. Similarly, there are many options to PPP - and
some combinations of these just do not work together, ever.
</Para>
<Para>
In addition to the problems of logging in and starting the PPP service,
there are problems with the modems and the actual telephone lines as well!
</Para>
<Para>
Section <XRef LinkEnd="problems"> provides some basic
information about common errors, how to isolate these and fix them.
</Para>
<Para>
This is <Emphasis>NOT</Emphasis> intended to provide more than just the basics. Al
Longyear maintains the PPP-FAQ which contains much more information on
this topic!
</Para>
</Sect1>
<Sect1>
<Title>After the link comes up</Title>
<Para>
Once a PPP link is operational (specifically, once the IP layer is
operational), Linux PPP can automatically run (as the root user), a script
to perform <Emphasis>any</Emphasis> function you can write a script to accomplish.
</Para>
<Para>
Section <XRef LinkEnd="ip-up"> provides information on the
<Literal remap="tt">/etc/ppp/ip-up</Literal> script, the parameters it receives from PPP, and
how to use it to do things like, acquire your email from your ISP
account, send any queued email waiting transmission on your machine and
such.
</Para>
</Sect1>
<Sect1>
<Title>Problems with standard IP services on a Dynamic IP number PPP link</Title>
<Para>
As noted in the introduction, dynamic IP numbers affect the
ability of your Linux PC to act as a server on the Internet.
</Para>
<Para>
Section <XRef LinkEnd="dynamic-server"> provides information on the (main) services
affected and what you can do (if anything) to overcome this.
</Para>
</Sect1>
<Sect1>
<Title>Maintaining a permanent connection to the net with <Emphasis>pppd</Emphasis>.</Title>
<Para>
If you are fortunate enough to have a semi permanent connection to the net and
would like to have your machine automatically redial your PPP connection if it
is lost then here is a simple trick to do so.
</Para>
<Para>
Configure PPP such that it can be started by the <Literal remap="tt">root</Literal> user by issuing the
command:
<Screen>
# pppd
</Screen>
<Emphasis remap="bf">Be sure</Emphasis> that you have the `<Literal remap="tt">-detach</Literal>' option configured in your
<Literal remap="tt">/etc/ppp/options</Literal> file. Then, insert the following line into your
<Literal remap="tt">/etc/inittab</Literal> file, down with the <Emphasis>getty</Emphasis> definitions:
<Screen>
pd:23:respawn:/usr/sbin/pppd
</Screen>
This will cause the <Emphasis>init</Emphasis> program to spawn and monitor the
<Emphasis>pppd</Emphasis>
program and automatically restart it if it dies.
</Para>
</Sect1>
</Chapter>
<Chapter id="Kernel-configuration">
<Title>Configuring your Linux Kernel</Title>
<Para>
In order to use PPP, your Linux kernel must be compiled to include PPP
support. Obtain the Linux source code for your kernel if you do not
already have this - it belongs in <Literal remap="tt">/usr/src/linux</Literal> on Linux's standard
file system.
</Para>
<Para>
Check out this directory - many Linux distributions install the source
tree (the files and subdirectories) as part of their installation process.
</Para>
<Para>
At bootup, your Linux kernel prints out a great deal of information.
Amongst this is information about PPP support and if the kernel includes
it. To view this information, look at your syslog file or use
<ProgramListing>
dmesg &verbar; less
</ProgramListing>
to display the information to the screen. If your kernel includes
PPP support, you will see lines like
</Para>
<Para>
<ProgramListing>
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
</ProgramListing>
</Para>
<Para>
(this is for the Linux 2.x.x kernel series).
</Para>
<Para>
Linux kernel sources can be obtained by ftp from <Literal remap="tt">sunsite.unc.edu</Literal> or its
mirror sites.
</Para>
<Sect1>
<Title>Installing the Linux Kernel source</Title>
<Para>
The following are brief instructions for obtaining and installing the
Linux kernel sources. Full information can be obtained from <ULink
URL="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html"
>The Linux Kernel HOWTO</ULink
>.
</Para>
<Para>
In order to install and compile the Linux kernel, you need to be logged
in as root.
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
Change directory to the <Literal remap="tt">/usr/src</Literal> directory
<Literal remap="tt">cd /usr/src</Literal>.
</Para>
</ListItem>
<ListItem>
<Para>
Check in <Literal remap="tt">/usr/src/linux</Literal> to see if you already have the
sources installed.
</Para>
</ListItem>
<ListItem>
<Para>
If you don't have the sources, get them from <ULink
URL="ftp://sunsite.unc.edu/pub/Linux/kernel/"
>Linux kernel source directory</ULink
> or your nearest mirror.
Select the appropriate directory- v2.0 if you are running a 2.0.x
kernel, or v2.2 if you are running a 2.2.x kernel.
If you are looking for earlier versions of the kernel (such as 1.2.X),
these are kept in <ULink
URL="ftp://sunsite.unc.edu/pub/Linux/kernel/old"
>Old Linux kernel source directory</ULink
>.
</Para>
</ListItem>
<ListItem>
<Para>
Choose the appropriate kernel - usually the most recent one
available is what you are looking for. Retrieve this and put the source
tar file in <Literal remap="tt">/usr/src</Literal>.
<Emphasis>Note</Emphasis>: a 'tar' file is an archive - possibly compressed (as are the
Linux kernel source tar files) containing many files in a number of
directories. It is the Linux equivalent of a DOS multi-directory zip file.
</Para>
</ListItem>
<ListItem>
<Para>
If you already have the Linux sources installed but are upgrading
to a new kernel, you must remove the old sources. Use the
command
<Literal remap="tt">rm -rf /usr/src/linux</Literal>.
</Para>
</ListItem>
<ListItem>
<Para>
Now uncompress and extract the sources using the command
<Literal remap="tt">tar xzf linux-X.X.XX.tar.gz</Literal>
where "X.X.XX" is the version of the kernel you downloaded.
</Para>
</ListItem>
<ListItem>
<Para>
Now, <Literal remap="tt">cd /usr/src/linux</Literal> and read the README file. This contains
an excellent explanation of how to go about configuring and compiling a
new kernel. Read this file, (it's a good idea to print it out and have a
copy handy whilst you are compiling until you have done this enough
times to know your way around).
</Para>
</ListItem>
</OrderedList>
</Para>
</Sect1>
<Sect1>
<Title>Knowing your hardware</Title>
<Para>
You <Emphasis>MUST</Emphasis> know what cards/devices you have inside your PC if you are
going to recompile your kernel!!! For some devices (such as sound cards)
you will also need to know various settings (such as IRQ's, I/O
addresses and such).
</Para>
</Sect1>
<Sect1>
<Title>Kernel compilation - the Linux 1.2.13 kernel</Title>
<Para>
To start the configuration process, follow the instructions in the
README file to properly install the sources. You start the kernel
configuration process with...
</Para>
<Para>
<Screen>
make config
</Screen>
</Para>
<Para>
In order to use PPP, you must configure the kernel to include PPP
support (PPP requires BOTH pppd AND kernel support for PPP).
</Para>
<Para>
<ProgramListing>
PPP (point-to-point) support (CONFIG_PPP) [n] y
</ProgramListing>
</Para>
<Para>
Answer the other make config questions according to the
hardware in your PC and the features of the Linux operating system you
want. Then continue to follow the README to compile and install your new
kernel.
</Para>
<Para>
The 1.2.13 kernel creates only 4 PPP devices. For multi-
port serial cards, you will need to edit the kernel PPP
sources to obtain more ports. (See the README.linux file that comes as
part of the PPP-2.1.2 distribution for full details of the simple edits
you need to make).
</Para>
<Para>
Note: the 1.2.13 configuration dialogue does NOT allow you to go
backwards - so if you make a mistake in answering one of the questions
in the <Literal remap="tt">make config</Literal> dialogue, exit by typing CTRL C and start again.
</Para>
</Sect1>
<Sect1>
<Title>Kernel compilation - the Linux 1.3.x, 2.0.x, and 2.2.x kernels</Title>
<Para>
For Linux 1.3.x, 2.0.x, and 2.2.x you can use a similar process as for Linux
1.2.13. Again, follow the instructions in the README file to properly
install the sources. You start the kernel configuration process with...
</Para>
<Para>
<Screen>
make config
</Screen>
</Para>
<Para>
However, you also have the choice of...
<Screen>
make menuconfig
</Screen>
</Para>
<Para>
This provides a menu based configuration system with online help that
allows you to move backwards and forwards in the configuration process.
</Para>
<Para>
There is also a highly recommended X windows based configuration interface...
<Screen>
make xconfig
</Screen>
</Para>
<Para>
You can compile PPP support directly into your kernel or as a
loadable module.
</Para>
<Para>
If you only use PPP some of the time that your Linux machine is
operating, then compiling PPP support as a loadable module is
recommended. Using 'kerneld', your kernel will automatically load the
module(s) required to provide PPP support when you start your PPP link
process. This saves valuable memory space: no part of the kernel can be
swapped out of memory, but loadable modules are automatically removed if
they are not in use.
</Para>
<Para>
To do this, you need to enable loadable module support:-
<ProgramListing>
Enable loadable module support (CONFIG_MODULES) [Y/n/?] y
</ProgramListing>
</Para>
<Para>
To add PPP kernel support, answer the following question:-
<ProgramListing>
PPP (point-to-point) support (CONFIG_PPP) [M/n/y/?]
</ProgramListing>
</Para>
<Para>
For a PPP loadable module, answer <Emphasis>M</Emphasis>, otherwise for PPP compiled in as
part of the kernel, answer <Emphasis>Y</Emphasis>.
</Para>
<Para>
Unlike kernel 1.2.13, kernel 2.0.x creates PPP devices on the fly as
needed and it is not necessary to hack the sources to increase available
PPP device numbers at all.
</Para>
</Sect1>
<Sect1>
<Title>Note on PPP-2.x and <Literal remap="tt">/proc/net/dev</Literal></Title>
<Para>
If you are using PPP-2.x, you will find that a side effect of the 'on
the fly' creation of the PPP devices is that no devices show up if you
look in the <Literal remap="tt">/proc/net</Literal> file system until a device is created by
starting up pppd:-
</Para>
<Para>
<ProgramListing>
[hartr@archenland hartr]$ cat /proc/net/dev
Inter-| Receive | Transmit
face |packets errs drop fifo frame|packets errs drop fifo colls carrier
lo: 92792 0 0 0 0 92792 0 0 0 0 0
eth0: 621737 13 13 0 23 501621 0 0 0 1309 0
</ProgramListing>
</Para>
<Para>
Once you have one (or more) ppp services started, you will see entries
such as this (from a ppp server):-
</Para>
<Para>
<ProgramListing>
[root@kepler /root]# cat /proc/net/dev
Inter-| Receive | Transmit
face |packets errs drop fifo frame|packets errs drop fifo colls carrier
lo: 428021 0 0 0 0 428021 0 0 0 0 0
eth0:4788257 648 648 319 650 1423836 0 0 0 4623 5
ppp0: 2103 3 3 0 0 2017 0 0 0 0 0
ppp1: 10008 0 0 0 0 8782 0 0 0 0 0
ppp2: 305 0 0 0 0 297 0 0 0 0 0
ppp3: 6720 7 7 0 0 7498 0 0 0 0 0
ppp4: 118231 725 725 0 0 117791 0 0 0 0 0
ppp5: 38915 5 5 0 0 28309 0 0 0 0 0
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>General kernel config considerations for PPP</Title>
<Para>
If you are setting up your Linux PC as a PPP server, you must compile in
IP forwarding support. This is also necessary if you want to use Linux
to link to LANs together or your LAN to the Internet.
</Para>
<Para>
If you are linking a LAN to the Internet (or linking together two LANs), you
should be concerned about security. Adding support for IP fire walls to
the kernel is probably a MUST!
</Para>
<Para>
You will also need this if you want to use IP masquerade to connect a
LAN that uses any of the above mentioned 'unconnected' IP network
numbers.
</Para>
<Para>
To enable IP Masquerade and IP fire walling, you <Emphasis>MUST</Emphasis> answer yes to the
first question in the <Literal remap="tt">make config</Literal> process:-
<ProgramListing>
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL)?
</ProgramListing>
</Para>
<Para>
Whilst this may sound a bit off-putting to new users, many users are
actively using the IP Masquerade and IP fire walling features of the
Linux 2.0.x or 2.2.x kernels with no problems.
</Para>
<Para>
Once you have installed and rebooted your new kernel, you can start
configuring and testing your PPP link(s).
</Para>
</Sect1>
</Chapter>
<Chapter id="Server-info">
<Title>Getting the Information you need about the PPP server</Title>
<Para>
Before you can establish a PPP connection with a server, you need to
obtain the following information (from the sysadmin/user support people
of the PPP server):-
<ItemizedList>
<ListItem>
<Para>
The telephone number(s) to dial for the service
If you are behind a PABX. You also need the PABX number that gives you
an outside dial tone - this is frequently digit zero (0) or nine (9).
</Para>
</ListItem>
<ListItem>
<Para>
Does the server use DYNAMIC or STATIC IP numbers?
If the server uses STATIC IP numbers, then you may need to know what IP
number to use for your end of the PPP connection. If your ISP is
providing you with a subnet of valid IP numbers, you will need to know
the IP numbers you can use and the network mask (netmask).
Most Internet Service Providers use DYNAMIC IP numbers. As mentioned
above, this has some implications in terms of the services you can
use.
However, even if you are using STATIC IP numbers, most PPP servers will
never (for security reasons) allow the client to specify an IP number as
this is a security risk. You <Emphasis>do</Emphasis> still need to know this information!
</Para>
</ListItem>
<ListItem>
<Para>
What are the IP numbers of the ISPs Domain Name Servers?
There should be at least two, although only one is needed.
There could be a problem here. The MS Windows 95 PPP setup allows the
DNS address to be passed to the client as part of its connection
process. So your ISP (or corporate help desk) may well tell you
don't need the IP address of the DNS server(s).
For Linux, you <Emphasis>DO</Emphasis> need the address of at least one DNS. The linux
implementation of PPP does not allow the setting of the DNS IP number
dynamically at connection time - and quite possibly will never do
so.
<Emphasis>Note</Emphasis>: whilst Linux (as a PPP client) cannot accept the DNS address
from a server, it can, when acting as a server, pass this information to
clients using the <Literal remap="tt">dns-addr</Literal> pppd option.
</Para>
</ListItem>
<ListItem>
<Para>
Does the server require the use of PAP/CHAP?
If this is the case you need to know the "id" and "secret" you are to
use in connecting. (These are probably your user name and
password at your ISP).
</Para>
</ListItem>
<ListItem>
<Para>
Does the server automatically start PPP, or do you need to issue any
commands to start PPP on the server once you are logged in?
If you must issue a command to start PPP, what is it?
</Para>
</ListItem>
<ListItem>
<Para>
Is the server a Microsoft Windows NT system and, if so, is it
using the MS PAP/CHAP system?
Many corporate LANs seem to use MS Windows NT this way for increased security.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Carefully note down this information - you are going to use it!
</Para>
</Chapter>
<Chapter id="Modem">
<Title>Configuring your modem and serial port</Title>
<Para>
You should make sure that your modem is correctly set up and that you
know which serial port it is connected to.
</Para>
<Para>
<Emphasis>Remember</Emphasis>...
<ItemizedList>
<ListItem>
<Para>
DOS com1: = Linux /dev/cua0 (and /dev/ttyS0)
</Para>
</ListItem>
<ListItem>
<Para>
DOS com2: = Linux /dev/cua1 (and /dev/ttyS1)
et cetera
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
It is also worth remembering that if you have 4 serial ports, the
standard PC set up is to have com1 and com3 share IRQ4 and com2 and com4
share IRQ3.
</Para>
<Para>
If you have devices on standard serial ports that share an IRQ with your
modem you are going to have problems. You need to make sure that your
modem serial port is on its own, unique IRQ. Many modern serial cards
(and better quality motherboard serial ports) allow you to move the IRQ
of the serial ports around.
</Para>
<Para>
If you are running Linux kernel 2, you can check the in-use IRQs using
<Literal remap="tt">cat /proc/interrupts</Literal>, which will produce output like
<ProgramListing>
0: 6766283 timer
1: 91545 keyboard
2: 0 cascade
4: 156944 + serial
7: 101764 WD8013
10: 134365 + BusLogic BT-958
13: 1 math error
15: 3671702 + serial
</ProgramListing>
</Para>
<Para>
This shows a serial port on IRQ4 (a mouse) and a serial port
on IRQ15 (the permanent modem based PPP link to the Internet. (There is
also a serial port on com2, IRQ3 and com4 is on IRQ14, but as they are
not in use, they do not show up).
</Para>
<Para>
Be warned - you need to know what you are doing if you are going to play
with your IRQs! Not only do you have to open up you computer, pull out
cards and play with jumpers, but you need to know what is on which IRQ.
In my case, this is a totally SCSI based PC, and so I can disable the "on
motherboard" IDE interfaces that normally use IRQ14 and 15!
</Para>
<Para>
You should also remember that if your PC boots other operating systems,
moving IRQs around may well mean that OS cannot boot properly - or at all!
</Para>
<Para>
If you do move your serial ports to non-standard IRQs, then you need to
tell Linux which IRQ each port is using. This is done using "
<Literal remap="tt">setserial</Literal>" and is best done as part of the boot process in
<Literal remap="tt">rc.local</Literal> or <Literal remap="tt">rc.serial</Literal> which is called from <Literal remap="tt">rc.local</Literal> or as
part of the SysV initialization. For the machine illustrated above, the
commands used are...
<ProgramListing>
/bin/setserial -b /dev/ttyS2 IRQ 11
/bin/setserial -b /dev/ttyS3 IRQ 15
</ProgramListing>
</Para>
<Para>
However, if you are using serial modules dynamically loaded, when
required by the <Literal remap="tt">kerneld</Literal> process, you cannot set and forget the IRQs,
(etc.) once at boot time. This is because if the serial module is unloaded,
Linux forgets the special settings.
</Para>
<Para>
So, if you are loading the serial module on demand, you will need to
reconfigure the IRQs, (etc.) each time the module is loaded.
</Para>
<Sect1>
<Title>A note about serial ports and speed capabilities</Title>
<Para>
If you are using a high speed (external) modem (14,400 Baud or above),
your serial port needs to be capable of handling the throughput that
such a modem is capable of producing, particularly when the modems are
compressing the data.
</Para>
<Para>
This requires your serial port to use a modern UART (Universal
Asynchronous Receiver Transmitter) such as a 16550(A). If you are using
an old machine (or old serial card), it is quite possible that your
serial port has only an 8250 UART, which will cause you considerable
problems when used with a high speed modem.
</Para>
<Para>
Use the command...
<Screen>
setserial -a /dev/ttySx
</Screen>
</Para>
<Para>
to get Linux to report to you the type of UART you have. If you
do not have a 16550A type UART, invest in a new serial card (available
for under &dollar;50). When you purchase a new card, make sure you can
move the IRQs around on it!
</Para>
<Para>
Note: the first versions of the 16550 UART chip had an error. This was
rapidly discovered and a revision of the chip was released - the 16550A
UART. A relatively small number of the faulty chips did however get into
circulation. It is unlikely that you will encounter one of these but you
should look for a response that says 16550A, particularly on serial
cards of some vintage.
</Para>
</Sect1>
<Sect1>
<Title>Serial Port Names</Title>
<Para>
Historically, Linux used <Literal remap="tt">cuaX</Literal> devices for dial-out and <Literal remap="tt">ttySx</Literal>
devices for dial-in.
</Para>
<Para>
The kernel code that required this was changed in kernel version 2.0.x
and you should now use <Literal remap="tt">ttySx</Literal> for both dial in and dial out. I
understand that the <Literal remap="tt">cuaX</Literal> device names may well disappear in future
kernel versions.
</Para>
</Sect1>
<Sect1>
<Title>Configuring your modem</Title>
<Para>
You will need to configure your modem correctly for PPP - to do this <Emphasis>READ
YOUR MODEM MANUAL</Emphasis>! Most modems come with a <Emphasis>factory default setting</Emphasis>
that selects the options required for PPP. The minimum configuration
specifies:-
<ItemizedList>
<ListItem>
<Para>
Hardware flow control (RTS/CTS) (<Literal remap="tt">&amp;</Literal>K3 on many Hayes modems)
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Other settings (in standard Hayes commands) you should investigate are:
<ItemizedList>
<ListItem>
<Para>
E1 Command/usr/src/linux-2.0.27/include/linux/serial.h Echo ON (required for chat to operate).
</Para>
</ListItem>
<ListItem>
<Para>
Q0 Report result codes (required for chat to operate).
</Para>
</ListItem>
<ListItem>
<Para>
S0=0 Auto Answer OFF (unless you want your modem to answer the phone).
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">&amp;</Literal>C1 Carrier Detect ON only after connect.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">&amp;</Literal>S0 Data Set Ready (DSR) always ON.
</Para>
</ListItem>
<ListItem>
<Para>
(depends) Data Terminal Ready.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
There is a site offering modem setups for a growing variety of modems,
makes and models at <ULink
URL="http://www.in.net/info/modems/index.html"
>Modem setup information</ULink
> which may assist you in this.
</Para>
<Para>
It is also worth while investigating how the modem's serial interface
between your computer and modem operates. Most modern modems allow you
to run the serial interface at a FIXED speed whilst allowing the
telephone line interface to change its speed to the highest speed it and
the remote modem can both handle.
</Para>
<Para>
This is known as split speed operation. If your modem supports this,
lock the modem's serial interface to its highest available speed
(usually 115,200 baud but maybe 38,400 baud for 14,400 baud modems).
</Para>
<Para>
Use your communications software (e.g. minicom or seyon) to find out
about your modem configuration and set it to what is required for PPP.
Many modems report their current settings in response to
AT<Literal remap="tt">&amp;</Literal>V, but you should consult your modem manual.
</Para>
<Para>
If you completely mess up the settings, you can return to sanity
(usually) by issuing an AT<Literal remap="tt">&amp;</Literal>F - return to factory settings.
(For most modem modems I have encountered, the factory settings include
all you need for PPP - but you should check).
</Para>
<Para>
Once you have worked out the modem setup string required, write it down.
You now have a decision: you can store these settings in your modem
non-volatile memory so they can be recalled by issuing the appropriate
AT command, or you can pass the correct settings to your
modem as part of the PPP dialing process.
</Para>
<Para>
If you only use your modem from Linux to call into your ISP or corporate
server, the simplest set up will have you save your modem configuration
in non-volatile RAM.
</Para>
<Para>
If on the other hand, you modem is used by other applications and
operating systems, it is safest to pass this information to the modem as
each call is made so that the modem is guaranteed to be in the correct
state for the call. (This has the added advantage also of recording the modem
setup string in case the modem looses the contents of its NV-RAM, which
can indeed happen).
</Para>
</Sect1>
<Sect1>
<Title>Note on Serial Flow Control</Title>
<Para>
When data is traveling on serial communication lines, it can happen
that data arrives faster than a computer can handle it (the computer may
be busy doing something else - remember, Linux is a multi-user, multi-
tasking operating system). In order to ensure that data is not lost
(data does not over run in the input buffer and hence get lost), some
method of controlling the flow of data is necessary.
</Para>
<Para>
There are two ways of doing this on serial lines:-
<ItemizedList>
<ListItem>
<Para>
Using hardware signals (Clear To Send/Request to Send - CTS/RTS).
</Para>
</ListItem>
<ListItem>
<Para>
Using software signals (control S and control Q, also known as XON/XOFF).
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Whilst the latter may be fine for a terminal (text) link, data on a
PPP link uses all 8 bits - and it is quite probable that somewhere in
the data there will be data bytes that translate as control S and
control Q. So, if a modem is set up to use software flow control, things
can rapidly go berserk!
</Para>
<Para>
For high speed links using PPP (which uses 8 bits of data) hardware flow
control is vital and it is for this reason that you must use hardware
flow control.
</Para>
</Sect1>
<Sect1>
<Title>Testing your modem for dial out</Title>
<Para>
Now that you have sorted out the serial port and modem settings it is a
good idea to make sure that these setting do indeed work by dialing you
ISP and seeing if you can connect.
</Para>
<Para>
Using you terminal communications package (such as minicom), set up the
modem initialisation required for PPP and dial into the PPP server you
want to connect to with a PPP session.
</Para>
<Para>
(Note: at this stage we are <Emphasis>NOT</Emphasis> trying to make a PPP connection
- just establishing that we have the right phone number and also to find
out <Emphasis>exactly</Emphasis> what the server sends to us in order to get logged in and
start PPP).
</Para>
<Para>
During this process, either capture (log to a file) the entire login
process or carefully (<Emphasis>very carefully</Emphasis>) write down <Emphasis>exactly</Emphasis> what
prompts the server gives to let you know it is time to enter your
user name and password (and any other commands needed to establish the
PPP connection).
</Para>
<Para>
If your server uses PAP, you should not see a login prompt, but should
instead see the (text representation) of the link control protocol
(which looks like garbage) starting on your screen.
</Para>
<Para>
A few words of warning:-
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
some servers are quite intelligent: you can log in
using text based user name/passwords OR using PAP. So if your ISP or
corporate site uses PAP but you do not see the garbage start up
immediately, this may not mean you have done something wrong.
</Para>
</ListItem>
<ListItem>
<Para>
some servers require you to enter some text initially and <Emphasis>then</Emphasis>
start a standard PAP sequence.
</Para>
</ListItem>
<ListItem>
<Para>
Some PPP servers are passive - that is they simply sit there
sending nothing until the client that is dialing in sends them a valid
lcp packet. If the ppp server you are connecting to operates in passive
mode, you will never see the garbage!
</Para>
</ListItem>
<ListItem>
<Para>
Some servers do not start PPP until you press ENTER - so it is
worth trying this if you correctly log in and do not see the garbage!
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
It is worth dialing in at least twice - some servers change their
prompts (e.g. with the time!) every time you log in. The two critical
prompts your Linux box needs to be able to identify every time you dial
in are:-
<ItemizedList>
<ListItem>
<Para>
the prompt that requests you to enter your user name;
</Para>
</ListItem>
<ListItem>
<Para>
the prompt that requests you to enter your password;
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
If you have to issue a command to start PPP on the server, you will also
need to find out the prompt the server gives you once you are logged in
to tell you that you can now enter the command to start ppp.
</Para>
<Para>
If your server automatically starts PPP, once you have logged in,
you will start to see garbage on your screen - this is the PPP server
sending your machine information to start up and configure the PPP
connection.
</Para>
<Para>
This should look something like this :-
</Para>
<Para>
<ProgramListing>
~y}#.!}!}!} }8}!}$}%U}"}&#38;} } } } }%}&#38; ...}'}"}(}"} .~~y}
</ProgramListing>
</Para>
<Para>
(and it just keeps on coming!)
</Para>
<Para>
On some systems PPP must be explicitly started on the server. This
is usually because the server has been set up to allow PPP logins and
shell logins using the same user name/password pair. If this is the case,
issue this command once you have logged in. Again, you will see the
garbage as the server end of the PPP connection starts up.
</Para>
<Para>
If you do not see this immediately after connecting (and logging in and
starting the PPP server if required), press <Emphasis>Enter</Emphasis> to see if this
starts the PPP server.
</Para>
<Para>
At this point, you can hang up your modem (usually, type <Literal remap="tt">+++</Literal>
quickly and then issue the ATHO command once your modem responds with
OK).
</Para>
<Para>
If you can't get your modem to work, read your modem manual, the man
pages for your communications software and the Serial HOWTO! Once you
have this sorted out, carry on as above.
</Para>
</Sect1>
</Chapter>
<Chapter id="DNS">
<Title>Setting up Name to Address Resolution (DNS)</Title>
<Para>
Whilst we humans like to give names to things, computers really like
numbers. On a TCP/IP network (which is what the Internet is), we call
machines by a particular name - and every machine lives in a
particular domain. For example, my Linux workstation is called
<Emphasis>archenland</Emphasis> and it resides in the <Emphasis>interweft.com.au</Emphasis>
domain. Its human readable address is thus archenland.interweft.com.au (which is known as
the FQDN - fully qualified domain name).
</Para>
<Para>
However, for this machine to be found by other computers on the
Internet, it is actually known by its IP number when computers are
communicating across the Internet.
</Para>
<Para>
Translating (resolving) machine (and domain) names into the numbers
actually used on the Internet is the business of machines that offer the
Domain Name Service.
</Para>
<Para>
What happens is this:-
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
your machine needs to know the
IP address of a particular computer. The application requiring this
information asks the 'resolver' on your Linux PC to provide this
information;
</Para>
</ListItem>
<ListItem>
<Para>
the resolver queries the local host file (<Literal remap="tt">/etc/hosts</Literal>
and/or the domain name servers it knows about (the exact behaviour of
the resolver is determined by <Literal remap="tt">/etc/host.conf</Literal>);
</Para>
</ListItem>
<ListItem>
<Para>
if the answer is found in the host file, this answer is returned;
</Para>
</ListItem>
<ListItem>
<Para>
if a domain name server is specified, your PC queries this
machine;
</Para>
</ListItem>
<ListItem>
<Para>
if the DNS machine already knows the IP number for the required
name, it returns it. If it does not, it queries other name servers across
the Internet to find the information. The name server than passes this
information back to the requesting resolver - which gives the
information to the requesting application.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
When you make a PPP connection, you need to tell your Linux machine
where it can get host name to IP number (address resolution) information
so that <Emphasis>you</Emphasis> can use the machine names but your <Emphasis>computer</Emphasis> can
translate these to the IP numbers it needs to do its work.
</Para>
<Para>
One way is to enter every host that you want to talk to into the
<Literal remap="tt">/etc/hosts</Literal> file (which is in reality totally impossible if you are
connecting to the Internet); another is to use the machine IP numbers as
opposed to the names (an impossible memory task for all but the smallest
LANs).
</Para>
<Para>
The best way is to set up Linux so that it knows where to go to get this
name to number information - automatically. This service is provided by
the Domain Name Server (DNS) system. All that is necessary is to enter
the IP number(s) for the domain name servers into your /etc/resolv.conf file.
</Para>
<Sect1>
<Title>The <Literal remap="tt">/etc/resolv.conf</Literal> file</Title>
<Para>
Your PPP server sysadmin/user support people should provide you with two
DNS IP numbers (only one is necessary - but two gives some
redundancy in the event of failure).
</Para>
<Para>
As previously mentioned, Linux cannot set its name server IP number
in the way that MS Windows 95 does. So you must <Emphasis>insist</Emphasis> (politely) that
your ISP provide you with this information!
</Para>
<Para>
Your <Literal remap="tt">/etc/resolv.conf</Literal> should look something like :-
</Para>
<Para>
<ProgramListing>
domain your.isp.domain.name
nameserver 10.25.0.1
nameserver 10.25.1.2
</ProgramListing>
</Para>
<Para>
Edit this file (creating it if necessary) to represent the information
that your ISP has provided. It should have ownership and permissions as
follows :-
</Para>
<Para>
<Screen>
-rw-r--r-- 1 root root 73 Feb 19 01:46 /etc/resolv.conf
</Screen>
</Para>
<Para>
If you have already set up a <Literal remap="tt">/etc/resolv.conf</Literal> because you are on a
LAN, simply add the IP numbers of the PPP DNS servers to your
existing file.
</Para>
</Sect1>
<Sect1>
<Title>The <Literal remap="tt">/etc/host.conf</Literal> file</Title>
<Para>
You should also check that your <Literal remap="tt">/etc/host.conf</Literal> file is
correctly set up. This should look like
<ProgramListing>
order hosts,bind
multi on
</ProgramListing>
</Para>
<Para>
This tells the resolver to use information in the host file before it
sends queries to the DNS for resolution.
</Para>
</Sect1>
</Chapter>
<Chapter id="root">
<Title>Using PPP and root privileges</Title>
<Para>
Because PPP needs to set up networking devices, change the kernel
routing table and so forth, it requires root privileges to do this.
</Para>
<Para>
If users other than root are to set up PPP connections, the pppd
program should be setuid root :-
</Para>
<Para>
<Screen>
-rwsr-xr-x 1 root root 95225 Jul 11 00:27 /usr/sbin/pppd
</Screen>
</Para>
<Para>
If /usr/sbin/pppd is not set up this way, then <Emphasis>as root</Emphasis> issue
the command:-
</Para>
<Para>
<Screen>
chmod u+s /usr/sbin/pppd
</Screen>
</Para>
<Para>
What this does is make pppd run with root privileges <Emphasis>even</Emphasis> if the
binary is run by an ordinary user. This allows a normal user to run pppd
with the necessary privileges to set up the network interfaces and the
kernel routing table.
</Para>
<Para>
Programs that run 'set uid root' are potential security holes and you
should be extremely cautious about making programs 'suid root'. A number
of programs (including pppd) have been carefully written to minimise the
danger of running suid root, so you should be safe with this one, (but no
guarantees).
</Para>
<Para>
Depending on how you want your system to operate - specifically if you
want ANY user on your system to be able to initiate a PPP link, you should
make your ppp-on/off scripts world read/execute. (This is probably fine if
your PC is used ONLY by you).
</Para>
<Para>
However, if you do NOT want just anyone to be able to start up a PPP
connection (for example, your children have accounts on your Linux PC
and you do not want them hooking into the Internet without your
supervision), you will need to establish a PPP group (as root, edit
/etc/group) and :-
<ItemizedList>
<ListItem>
<Para>
Make pppd suid root, owned by user root and group PPP, with the 'other'
permissions on this file empty. It should then look like:-
<Screen>
-rwsr-x--- 1 root PPP 95225 Jul 11 00:27 /usr/sbin/pppd
</Screen>
</Para>
</ListItem>
<ListItem>
<Para>
Make the ppp-on/off scripts owned by user root and group PPP.
</Para>
</ListItem>
<ListItem>
<Para>
Make the ppp-on/off scripts read/executable by group PPP.
<Screen>
-rwxr-x--- 1 root PPP 587 Mar 14 1995 /usr/sbin/ppp-on
-rwxr-x--- 1 root PPP 631 Mar 14 1995 /usr/sbin/ppp-off
</Screen>
</Para>
</ListItem>
<ListItem>
<Para>
Make the other access rights for ppp-on/off nill.
</Para>
</ListItem>
<ListItem>
<Para>
add the users who will be firing up PPP to the PPP group in /etc/group.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Even if you do this, ordinary users will STILL not be able to shut down
the link under software control! Running the <Literal remap="tt">ppp-off</Literal> script
requires root privileges. However, any user can just turn off the modem
(or disconnect the telephone line from an internal modem).
</Para>
<Para>
An alternative (and better method) to this set up is to use the
<Literal remap="tt">sudo</Literal> program. This offers superior security and will allow you to
set things up so that any (authorised) user can activate/deactivate the
link using the scripts. Using <Literal remap="tt">sudo</Literal> will allow an authorised user to
activate/deactivate the PPP link cleanly and securely.
</Para>
</Chapter>
<Chapter id="options">
<Title>Setting up the PPP connection files</Title>
<Para>
You now need to be logged in as <Emphasis>root</Emphasis> to create the directories and
edit the files needed to set up PPP, even if you want PPP to be
accessible to all users.
</Para>
<Para>
PPP uses a number of files to connect and set up a PPP connection. These
differ in name and location between PPP 2.1.2 and 2.2+.
</Para>
<Para>
For PPP 2.1.2 the files are:-
</Para>
<Para>
<ProgramListing>
/usr/sbin/pppd # the PPP binary
/usr/sbin/ppp-on # the dialer/connection script
/usr/sbin/ppp-off # the disconnection script
/etc/ppp/options # the options pppd uses for all connections
/etc/ppp/options.ttyXX # the options specific to a connection on this port
</ProgramListing>
</Para>
<Para>
For PPP 2.2 the files are:-
</Para>
<Para>
<ProgramListing>
/usr/sbin/pppd # the PPP binary
/etc/ppp/scripts/ppp-on # the dialer/connection script
/etc/ppp/scripts/ppp-on-dialer # part 1 of the dialer script
/etc/ppp/scripts/ppp-off # the actual chat script itself
/etc/ppp/options # the options pppd uses for all connections
/etc/ppp/options.ttyXX # the options specific to a connection on this port
</ProgramListing>
</Para>
<Para>
Red Hat Linux users should note that the standard Red Hat 4.X installation
places these scripts in <Literal remap="tt">/usr/doc/ppp-2.2.0f-2/scripts</Literal>.
</Para>
<Para>
In your /etc directory there should be a ppp directory:-
</Para>
<Para>
<Screen>
drwxrwxr-x 2 root root 1024 Oct 9 11:01 ppp
</Screen>
</Para>
<Para>
If it does not exist - create it with these ownerships and permissions.
</Para>
<Para>
If the directory already existed, it should contain a template options
file called <Emphasis>options.tpl</Emphasis>. This file is included below in case it
does not.
</Para>
<Para>
Print it out as it contains an explanation of nearly all the PPP options
(these are useful to read in conjunction with the pppd man pages).
Whilst you can use this file as the basis of your
<Literal remap="tt">/etc/ppp/options</Literal> file, it is probably better to create your own
options file that does not include all the comments in the template - it
will be much shorter and easier to read/maintain.
</Para>
<Para>
If you have multiple serial lines/modems, (typically the case for PPP
servers), create a general <Literal remap="tt">/etc/ppp/options</Literal> file containing the
options that are common for all the serial ports on which you are
supporting dial in/out and set up individual option files for each serial
line on which you will be establishing a PPP connection with the
individual settings required for each port.
</Para>
<Para>
These port specific option files are named <Literal remap="tt">options.ttyx1</Literal>,
<Literal remap="tt">options.ttyx2</Literal> and so forth (where x is the appropriate letter for
your serial ports).
</Para>
<Para>
However, for a single PPP connection, you can happily use the
<Literal remap="tt">/etc/ppp/options</Literal> file. Alternatively, you can put all the
options as arguments in the pppd command itself.
</Para>
<Para>
It is easier to maintain a setup that uses
<Literal remap="tt">/etc/ppp/options.ttySx</Literal> files. If you use PPP to connect to a
number of different sites, you can create option files for each site in
<Literal remap="tt">/etc/ppp/options.site</Literal> and then specify the option file as a
parameter to the PPP command as you connect (using the <Literal remap="tt">file
option-file</Literal> pppd option to pppd on the command line).
</Para>
<Sect1>
<Title>The supplied options.tpl file</Title>
<Para>
Some distributions of PPP seem to have lost the options.tpl file, so
here is the complete file. I suggest that you do NOT edit this file to
create your <Literal remap="tt">/etc/ppp/options</Literal> file(s). Rather, copy this to a
new file and then edit that. If you mess up your edits, you can then go
back to the original and start again.
</Para>
<Para>
<ProgramListing>
# /etc/ppp/options -*- sh -*- general options for pppd
# created 13-Jul-1995 jmk
# autodate: 01-Aug-1995
# autotime: 19:45
# Use the executable or shell command specified to set up the serial
# line. This script would typically use the "chat" program to dial the
# modem and start the remote ppp session.
#connect "echo You need to install a connect command."
# Run the executable or shell command specified after pppd has
# terminated the link. This script could, for example, issue commands
# to the modem to cause it to hang up if hardware modem control signals
# were not available.
#disconnect "chat -- \d+++\d\c OK ath0 OK"
# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it. 0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
#asyncmap 0
# Require the peer to authenticate itself before allowing network
# packets to be sent or received.
#auth
# Use hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
#crtscts
# Use software flow control (i.e. XON/XOFF) to control the flow of data
# on the serial port.
#xonxoff
# Add a default route to the system routing tables, using the peer as
# the gateway, when IPCP negotiation is successfully completed. This
# entry is removed when the PPP connection is broken.
#defaultroute
# Specifies that certain characters should be escaped on transmission
# (regardless of whether the peer requests them to be escaped with its
# async control character map). The characters to be escaped are
# specified as a list of hex numbers separated by commas. Note that
# almost any character can be specified for the escape option, unlike
# the asyncmap option which only allows control characters to be
# specified. The characters which may not be escaped are those with hex
# values 0x20 - 0x3f or 0x5e.
#escape 11,13,ff
# Don't use the modem control lines.
#local
# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
#lock
# Use the modem control lines. On Ultrix, this option implies hardware
# flow control, as for the crtscts option. (This option is not fully
# implemented.)
#modem
# Set the MRU [Maximum Receive Unit] value to &#60;n&#62; for negotiation. pppd
# will ask the peer to send packets of no more than &#60;n&#62; bytes. The
# minimum MRU value is 128. The default MRU value is 1500. A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data).
#mru 542
# Set the interface netmask to &#60;n&#62;, a 32 bit netmask in "decimal dot"
# notation (e.g. 255.255.255.0).
#netmask 255.255.255.0
# Disables the default behaviour when no local IP address is specified,
# which is to determine (if possible) the local IP address from the
# hostname. With this option, the peer will have to supply the local IP
# address during IPCP negotiation (unless it specified explicitly on the
# command line or in an options file).
#noipdefault
# Enables the "passive" option in the LCP. With this option, pppd will
# attempt to initiate a connection; if no reply is received from the
# peer, pppd will then just wait passively for a valid LCP packet from
# the peer (instead of exiting, as it does without this option).
#passive
# With this option, pppd will not transmit LCP packets to initiate a
# connection until a valid LCP packet is received from the peer (as for
# the "passive" option with old versions of pppd).
#silent
# Don't request or allow negotiation of any options for LCP and IPCP
# (use default values).
#-all
# Disable Address/Control compression negotiation (use default, i.e.
# address/control field disabled).
#-ac
# Disable asyncmap negotiation (use the default asyncmap, i.e. escape
# all control characters).
#-am
# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
#-detach
# Disable IP address negotiation (with this option, the remote IP
# address must be specified with an option on the command line or in an
# options file).
#-ip
# Disable magic number negotiation. With this option, pppd cannot
# detect a looped-back line.
#-mn
# Disable MRU [Maximum Receive Unit] negotiation (use default, i.e.
# 1500).
#-mru
# Disable protocol field compression negotiation (use default, i.e.
# protocol field compression disabled).
#-pc
# Require the peer to authenticate itself using PAP.
# This requires TWO WAY authentication - do NOT use this for a standard
# PAP authenticated link to an ISP as this will require the ISP machine
# to authenticate itself to your machine (and it will not be able to).
#+pap
# Don't agree to authenticate using PAP.
#-pap
# Require the peer to authenticate itself using CHAP [Cryptographic
# Handshake Authentication Protocol] authentication.
# This requires TWO WAY authentication - do NOT use this for a standard
# CHAP authenticated link to an ISP as this will require the ISP machine
# to authenticate itself to your machine (and it will not be able to).
#+chap
# Don't agree to authenticate using CHAP.
#-chap
# Disable negotiation of Van Jacobson style IP header compression (use
# default, i.e. no compression).
#-vj
# Increase debugging level (same as -d). If this option is given, pppd
# will log the contents of all control packets sent or received in a
# readable form. The packets are logged through syslog with facility
# daemon and level debug. This information can be directed to a file by
# setting up /etc/syslog.conf appropriately (see syslog.conf(5)). (If
# pppd is compiled with extra debugging enabled, it will log messages
# using facility local2 instead of daemon).
#debug
# Append the domain name &#60;d&#62; to the local host name for authentication
# purposes. For example, if gethostname() returns the name porsche,
# but the fully qualified domain name is porsche.Quotron.COM, you would
# use the domain option to set the domain name to Quotron.COM.
#domain &#60;d&#62;
# Enable debugging code in the kernel-level PPP driver. The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
#kdebug n
# Set the MTU [Maximum Transmit Unit] value to &#60;n&#62;. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface.
#mtu &#60;n&#62;
# Set the name of the local system for authentication purposes to &#60;n&#62;.
# This will probably have to be set to your ISP user name if you are
# using PAP/CHAP.
#name &#60;n&#62;
# Set the user name to use for authenticating this machine with the peer
# using PAP to &#60;u&#62;.
# Do NOT use this if you are using 'name' above!
#user &#60;u&#62;
# Enforce the use of the host name as the name of the local system for
# authentication purposes (overrides the name option).
#usehostname
# Set the assumed name of the remote system for authentication purposes
# to &#60;n&#62;.
#remotename &#60;n&#62;
# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.
#proxyarp
# Use the system password database for authenticating the peer using
# PAP.
#login
# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
#lcp-echo-interval &#60;n&#62;
# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection. Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
#lcp-echo-failure &#60;n&#62;
# Set the LCP restart interval (retransmission timeout) to &#60;n&#62; seconds
# (default 3).
#lcp-restart &#60;n&#62;
# Set the maximum number of LCP terminate-request transmissions to &#60;n&#62;
# (default 3).
#lcp-max-terminate &#60;n&#62;
# Set the maximum number of LCP configure-request transmissions to &#60;n&#62;
# (default 10).
# Some PPP servers are slow to start up. You may need to increase this
# if you keep getting 'serial line looped back' errors and your are SURE
# that you have logged in correctly and PPP should be starting on the server.
#lcp-max-configure &#60;n&#62;
# Set the maximum number of LCP configure-NAKs returned before starting
# to send configure-Rejects instead to &#60;n&#62; (default 10).
#lcp-max-failure &#60;n&#62;
# Set the IPCP restart interval (retransmission timeout) to &#60;n&#62;
# seconds (default 3).
#ipcp-restart &#60;n&#62;
# Set the maximum number of IPCP terminate-request transmissions to &#60;n&#62;
# (default 3).
#ipcp-max-terminate &#60;n&#62;
# Set the maximum number of IPCP configure-request transmissions to &#60;n&#62;
# (default 10).
#ipcp-max-configure &#60;n&#62;
# Set the maximum number of IPCP configure-NAKs returned before starting
# to send configure-Rejects instead to &#60;n&#62; (default 10).
#ipcp-max-failure &#60;n&#62;
# Set the PAP restart interval (retransmission timeout) to &#60;n&#62; seconds
# (default 3).
#pap-restart &#60;n&#62;
# Set the maximum number of PAP authenticate-request transmissions to
# &#60;n&#62; (default 10).
#pap-max-authreq &#60;n&#62;
# Set the CHAP restart interval (retransmission timeout for
# challenges) to &#60;n&#62; seconds (default 3).
#chap-restart &#60;n&#62;
# Set the maximum number of CHAP challenge transmissions to &#60;n&#62;
# (default 10).
#chap-max-challenge
# If this option is given, pppd will re-challenge the peer every &#60;n&#62;
# seconds.
#chap-interval &#60;n&#62;
# With this option, pppd will accept the peer's idea of our local IP
# address, even if the local IP address was specified in an option.
#ipcp-accept-local
# With this option, pppd will accept the peer's idea of its (remote) IP
# address, even if the remote IP address was specified in an option.
#ipcp-accept-remote
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>What options should I use? (No PAP/CHAP)</Title>
<Para>
Well, as in all things, that depends, (sigh). The options specified here
should work with most servers.
</Para>
<Para>
However, if it does NOT work, READ THE TEMPLATE FILE
(<Literal remap="tt">/etc/ppp/options.tpl</Literal>) <Emphasis>and</Emphasis> the pppd man pages <Emphasis>and</Emphasis>
speak to the sysadmin/user support people who run the server to which
you are connecting.
</Para>
<Para>
You should also note that the connect scripts presented here also use
some command line options to pppd to make things a bit easier to change.
</Para>
<Para>
<ProgramListing>
# /etc/ppp/options (NO PAP/CHAP)
#
# Prevent pppd from forking into the background
-detach
#
# use the modem control lines
modem
# use uucp style locks to ensure exclusive access to the serial device
lock
# use hardware flow control
crtscts
# create a default route for this connection in the routing table
defaultroute
# do NOT set up any "escaped" control sequences
asyncmap 0
# use a maximum transmission packet size of 552 bytes
mtu 552
# use a maximum receive packet size of 552 bytes
mru 552
#
#-------END OF SAMPLE /etc/ppp/options (no PAP/CHAP)
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>Other options to consider adding</Title>
<Para>
There are a couple useful things you might want to add to the /etc/ppp/options
file.
</Para>
<Para>
One is an idle time. Pppd can terminate the connection if it has been idle for
too long. This could be nice if your isp charges by time, or if you don't
want to keep your phone line tied up. To use this feature, simply add the
line:
</Para>
<ProgramListing>
# Idle after X seconds
idle X
</ProgramListing>
<Para>
Replace 'X' with the number of seconds you wish the connection to terminate
after.
</Para>
<Para>
The next feature is "dial on demand". This means that every time
you attempt to open an interent connection, pppd will try to open
a PPP connection to your ISP.
In order to do this, add the following lines to /etc/ppp/options
</Para>
<ProgramListing>
# dial on demand
demand
</ProgramListing>
<Para>
This should make pppd dial out when necessary.
</Para>
</Sect1>
</Chapter>
<Chapter id="pap">
<Title>If your PPP server uses PAP (Password Authentication
Protocol)</Title>
<Para>
If the server to which you are connecting requires PAP or CHAP
authentication, you have a little bit more work.
</Para>
<Para>
To the above options file, add the following lines
<ProgramListing>
#
# force pppd to use your ISP user name as your 'host name' during the
# authentication process
name &#60;your ISP user name&#62; # you need to edit this line
#
# If you are running a PPP *server* and need to force PAP or CHAP
# uncomment the appropriate one of the following lines. Do NOT use
# these is you are a client connecting to a PPP server (even if it uses PAP
# or CHAP) as this tells the SERVER to authenticate itself to your
# machine (which almost certainly can't do - and the link will fail).
#+chap
#+pap
#
# If you are using ENCRYPTED secrets in the /etc/ppp/pap-secrets
# file, then uncomment the following line.
# Note: this is NOT the same as using MS encrypted passwords as can be
# set up in MS RAS on Windows NT.
#+papcrypt
</ProgramListing>
</Para>
<Sect1>
<Title>Using MSCHAP</Title>
<Para>
Microsoft Windows NT RAS can be set up to use a variation on CHAP
(Challenge/Handshake Authentication Protocol). In your PPP sources tar
ball, you will find a file called README.MSCHAP80 that discusses this.
</Para>
<Para>
You can determine if the server is requesting authentication using this
protocol by enabling debugging for pppd. If the server is requesting MS
CHAP authentication, you will see lines like:-
</Para>
<Para>
<ProgramListing>
rcvd [LCP ConfReq id=0x2 &#60;asyncmap 0x0&#62; &#60;auth chap 80&#62; &#60;magic 0x46a3&#62;]
</ProgramListing>
</Para>
<Para>
The critical information here is <Emphasis>auth chap 80</Emphasis>.
</Para>
<Para>
In order to use MS CHAP, you will need to recompile pppd to support
this. Please see the instructions in the README.MSCHAP80 file in the PPP
source file for instructions on how to compile and use this variation.
</Para>
<Para>
You should note that at present this code supports only Linux PPP
clients connecting to an MS Windows NT server. It does <Emphasis>NOT</Emphasis> support
setting up a Linux PPP server to use MSCHAP80 authentication from clients.
</Para>
</Sect1>
<Sect1>
<Title>The PAP/CHAP secrets file</Title>
<Para>
If you are using pap or chap authentication, then you also need to
create the secrets file. These are:
<ProgramListing>
/etc/ppp/pap-secrets
/etc/ppp/chap-secrets
</ProgramListing>
</Para>
<Para>
They must be owned by user root, group root and have file permissions
740 for security.
</Para>
<Para>
The first point to note about PAP and CHAP is that they are designed to
authenticate <Emphasis>computer systems</Emphasis> not <Emphasis>users</Emphasis>.
</Para>
<Para>
Huh? What's the difference? I hear you ask.
</Para>
<Para>
Well now, once your computer has made its PPP connection to the server,
<Emphasis>ANY</Emphasis> user on your system can use that connection - not just you.
This is why you can set up a WAN (wide area network) link that joins two
LANs (local area networks) using PPP.
</Para>
<Para>
PAP can (and for CHAP <Emphasis>DOES</Emphasis>) require <Emphasis>bidirectional</Emphasis>
authentication - that is a valid name and secret is required on each
computer for the other computer involved. However, this is <Emphasis>NOT</Emphasis> the
way most PPP servers offering dial-up PPP PAP-authenticated connections
operate.
</Para>
<Para>
That being said, your ISP will probably have given you a user name and
password to allow you to connect to their system and thence the
Internet. Your ISP is not interested in your computer's name at all, so
you will probably need to use the user name at your ISP as the name for
your computer.
</Para>
<Para>
This is done using the <Literal remap="tt">name user name</Literal> option to pppd. So, if you are
to use the user name given you by your ISP, add the line
<ProgramListing>
name your_user name_at_your_ISP
</ProgramListing>
</Para>
<Para>
to your <Literal remap="tt">/etc/ppp/options</Literal> file.
</Para>
<Para>
Technically, you should really use <Literal remap="tt">user our&lowbar;user name&lowbar;at&lowbar;your&lowbar;ISP</Literal>
for PAP, but pppd is sufficiently intelligent to interpret <Literal remap="tt">name</Literal> as
<Literal remap="tt">user</Literal> if it is required to use PAP. The advantage of using the <Literal remap="tt">name</Literal>
option is that this is also valid for CHAP.
</Para>
<Para>
As PAP is for authenticating <Emphasis>computers</Emphasis>, technically you need
also to specify a remote computer name. However, as most people only
have one ISP, you can use a wild card (*) for the remote host name in
the secrets file.
</Para>
<Para>
It is also worth noting that many ISPs operate multiple modem banks
connected to different terminal servers - each with a different name,
but ACCESSED from a single (rotary) dial in number. It can therefore be
quite difficult in some circumstances to know ahead of time what the
name of the remote computer is, as this depends on which terminal server
you connect to!
</Para>
</Sect1>
<Sect1>
<Title>The PAP secrets file</Title>
<Para>
The <Literal remap="tt">/etc/ppp/pap-secrets</Literal> file looks like
<ProgramListing>
# Secrets for authentication using PAP
# client server secret acceptable_local_IP_addresses
</ProgramListing>
</Para>
<Para>
The four fields are white space delimited and the last one can be blank (which is
what you want for a dynamic and probably static IP allocation from your ISP).
</Para>
<Para>
Suppose your ISP gave you a user name of <Literal remap="tt">fred</Literal> and a password of
<Literal remap="tt">flintstone</Literal> you would set the <Literal remap="tt">name fred</Literal> option in
<Literal remap="tt">/etc/ppp/options[.ttySx]</Literal> and set up your
<Literal remap="tt">/etc/ppp/pap-secrets</Literal> file as follows
</Para>
<Para>
<ProgramListing>
# Secrets for authentication using PAP
# client server secret acceptable local IP addresses
fred * flintstone
</ProgramListing>
</Para>
<Para>
This says for the local machine name <Literal remap="tt">fred</Literal> (which we have told pppd
to use even though it is not our local machine name) and for <Emphasis>ANY</Emphasis>
server, use the password (secret) of <Literal remap="tt">flintstone</Literal>.
</Para>
<Para>
Note that we do not need to specify a local IP address, unless we are
required to FORCE a particular local, static IP address. Even if you try
this, it is unlikely to work as most PPP servers (for security reasons)
do not allow the remote system to set the IP number they are to be given.
</Para>
</Sect1>
<Sect1>
<Title>The CHAP secrets file</Title>
<Para>
This requires that you have mutual authentication
methods - that is you must allow for both your machine to authenticate
the remote server <Emphasis>AND</Emphasis> the remote server to authenticate your
machine.
</Para>
<Para>
So, if your machine is <Literal remap="tt">fred</Literal> and the remote is <Literal remap="tt">barney</Literal>, your
machine would set <Literal remap="tt">name fred remotename barney</Literal> and the remote
machine would set <Literal remap="tt">name barney remotename fred</Literal> in their respective
<Literal remap="tt">/etc/ppp/options.ttySx</Literal> files.
</Para>
<Para>
The <Literal remap="tt">/etc/chap-secrets</Literal> file for fred would look like
<ProgramListing>
# Secrets for authentication using CHAP
# client server secret acceptable local IP addresses
fred barney flintstone
barney fred wilma
</ProgramListing>
</Para>
<Para>
and for barney
</Para>
<Para>
<ProgramListing>
# Secrets for authentication using CHAP
# client server secret acceptable local IP addresses
barney fred flintstone
fred barney wilma
</ProgramListing>
</Para>
<Para>
Note in particular that both machines must have entries for
bidirectional authentication. This allows the local machine to
authenticate itself to the remote <Emphasis>AND</Emphasis> the remote machine to
authenticate itself to the local machine.
</Para>
</Sect1>
<Sect1>
<Title>Handling multiple PAP-authenticated connections</Title>
<Para>
Some users have more than one server to which they connect that use PAP.
Provided that your user name is different on each machine to which you
want to connect, this is not a problem.
</Para>
<Para>
However, many users have the same user name on two (or more - even all)
systems to which they connect. This then presents a problem in correctly
selecting the appropriate line from <Literal remap="tt">/etc/ppp/pap-secrets</Literal>.
</Para>
<Para>
As you might expect, PPP provides a mechanism for overcoming this. PPP
allows you to set an 'assumed name' for the remote (server) end of the
connection using the <Emphasis>remotename</Emphasis> option to pppd.
</Para>
<Para>
Let us suppose that you connect to two PPP servers using the username
fred. You set up your <Literal remap="tt">/etc/ppp/pap-secrets</Literal> something like
</Para>
<Para>
<ProgramListing>
fred pppserver1 barney
fred pppserver2 wilma
</ProgramListing>
</Para>
<Para>
Now, to set connect to pppserver1 you would use <Literal remap="tt">name fred remotename
pppserver1</Literal> in your ppp-options and for pppserver2 <Literal remap="tt">name fred
remotename pppserver2</Literal>.
</Para>
<Para>
As you can select the ppp options file to use with pppd using the
<Literal remap="tt">file filename</Literal> option, you can set up a script to connect to each of
your PPP servers, correctly picking the options file to use and hence
selecting the right <Literal remap="tt">remotename</Literal> option.
</Para>
</Sect1>
</Chapter>
<Chapter id="manual">
<Title>Setting up the PPP connection manually</Title>
<Para>
Now that you have created your <Literal remap="tt">/etc/ppp/options</Literal> and
<Literal remap="tt">/etc/resolv.conf</Literal> files (and, if necessary, the
<Literal remap="tt">/etc/ppp/pap&verbar;chap-secrets</Literal> file), you can test the settings by
manually establishing a PPP connection. (Once we have the manual
connection working, we will automate the process).
</Para>
<Para>
To do this, your communications software must be capable of quitting
WITHOUT resetting the modem. Minicom can do this - ALT Q (or in older
version of minicom CTRL A Q)
</Para>
<Para>
Make sure you are logged in as root.
</Para>
<Para>
Fire up you communications software, (such as minicom), dial into the PPP
server and log in as normal. If you need to issue a command to start up
PPP on the server, do so. You will now see the garbage you saw before.
</Para>
<Para>
If you are using pap or chap, then merely connecting to the remote system
should start ppp on the remote and you will see the garbage without
logging in, (although this may not happen for some servers - try pressing
<Emphasis>Enter</Emphasis> and see if the garbage starts up).
</Para>
<Para>
Now quit the communications software <Emphasis>without resetting the modem</Emphasis> (ALT Q
or CTL A Q in minicom) and at the Linux prompt (as root) type...
</Para>
<Para>
<ProgramListing>
pppd -d -detach /dev/ttySx 38400 &#38;
</ProgramListing>
</Para>
<Para>
The -d option turns on debugging - the ppp connection start up
conversation will be logged to your system log - which is useful if
you are having trouble.
</Para>
<Para>
Your modem lights should now flash as the PPP connection is established.
It will take a short while for the PPP connection to be made.
</Para>
<Para>
At this point you can look at the PPP interface, by issuing the command:-
</Para>
<Para>
<ProgramListing>
ifconfig
</ProgramListing>
</Para>
<Para>
In addition to any Ethernet and loop back devices you have, you
should see something like :-
</Para>
<Para>
<ProgramListing>
ppp0 Link encap:Point-Point Protocol
inet addr:10.144.153.104 P-t-P:10.144.153.51 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:552 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
</ProgramListing>
</Para>
<Para>
Where
<ItemizedList>
<ListItem>
<Para>
inet addr:10.144.153.10 is the IP number of your end of the link.
</Para>
</ListItem>
<ListItem>
<Para>
P-t-P:10.144.153.5 is the SERVER's IP number.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
(Naturally, ifconfig will not report these IP numbers, but the ones used
by your PPP server.)
</Para>
<Para>
Note: ifconfig also tells you that the link is UP and RUNNING!
</Para>
<Para>
If you get no ppp device listed or something like:-
</Para>
<Para>
<ProgramListing>
ppp0 Link encap:Point-Point Protocol
inet addr:0.0.0.0 P-t-P:0.0.0.0 Mask:0.0.0.0
POINTOPOINT MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
</ProgramListing>
</Para>
<Para>
Your PPP connection has not been made...see the later section on
debugging!
</Para>
<Para>
You should also be able to see a route to the remote host (and
beyond). To do this, issue the command
</Para>
<Para>
<ProgramListing>
route -n
</ProgramListing>
</Para>
<Para>
You should se something like:-
</Para>
<Para>
<ProgramListing>
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
10.144.153.3 * 255.255.255.255 UH 1500 0 1 ppp0
127.0.0.0 * 255.0.0.0 U 3584 0 11 lo
10.0.0.0 * 255.0.0.0 U 1500 0 35 eth0
default 10.144.153.3 * UG 1500 0 5 ppp0
</ProgramListing>
</Para>
<Para>
Of particular importance here, notice we have TWO entries pointing to our
ppp interface.
</Para>
<Para>
The first is a HOST route, (indicated by the H flag) and
that allows us to see the host to which we are connected to - but no
further.
</Para>
<Para>
The second is the default route, (established by giving pppd the option
<Literal remap="tt">defaultroute</Literal>. This is the route that tells our
Linux PC to send any packets NOT destined for the local Ethernet(s) - to
which we have specific network routes - to the PPP server itself. The
PPP server then is responsible for routing our packets out onto the
Internet and routing the return packets back to us.
</Para>
<Para>
If you do not see a routing table with two entries, something is wrong.
In particular if your syslog shows a message telling you pppd is not
replacing an existing default route, then you have a default route
pointing at your Ethernet interface - which <Emphasis>MUST</Emphasis> be replaced by a
specific network route: <Emphasis>YOU CAN ONLY HAVE ONE DEFAULT ROUTE!!!</Emphasis>
</Para>
<Para>
You will need to explore your system initialization files to find out
where this default route is being set up (it will use a <Literal remap="tt">route add
default...</Literal> command). Change this command to something like <Literal remap="tt">route
add net...</Literal>.
</Para>
<Para>
Now test the link by 'pinging' the server at its IP number as reported
by the ifconfig output, i.e.
</Para>
<Para>
<ProgramListing>
ping 10.144.153.51
</ProgramListing>
</Para>
<Para>
You should receive output like
</Para>
<Para>
<ProgramListing>
PING 10.144.153.51 (10.144.153.51): 56 data bytes
64 bytes from 10.144.153.51: icmp_seq=0 ttl=255 time=328.3 ms
64 bytes from 10.144.153.51: icmp_seq=1 ttl=255 time=190.5 ms
64 bytes from 10.144.153.51: icmp_seq=2 ttl=255 time=187.5 ms
64 bytes from 10.144.153.51: icmp_seq=3 ttl=255 time=170.7 ms
</ProgramListing>
</Para>
<Para>
This listing will go on for ever - to stop it press CTRL C, at which
point you will receive some more information :-
</Para>
<Para>
<ProgramListing>
--- 10.144.153.51 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 170.7/219.2/328.3 ms
</ProgramListing>
</Para>
<Para>
So far so good.
</Para>
<Para>
Now try pinging a host by name (not the name of the PPP server itself)
but a host at another site that you KNOW is probably going to be up and
running...). For example
</Para>
<Para>
<ProgramListing>
ping sunsite.unc.edu
</ProgramListing>
</Para>
<Para>
This time there will be a bit of a pause as Linux obtains the IP number
for the fully qualified host name you have 'ping'ed from the DNS you
specified in <Literal remap="tt">/etc/resolv.conf</Literal> - so don't worry (but you will
see your modem lights flash). Shortly you will receive output like
</Para>
<Para>
<ProgramListing>
PING sunsite.unc.edu (152.2.254.81): 56 data bytes
64 bytes from 152.2.254.81: icmp_seq=0 ttl=254 time=190.1 ms
64 bytes from 152.2.254.81: icmp_seq=1 ttl=254 time=180.6 ms
64 bytes from 152.2.254.81: icmp_seq=2 ttl=254 time=169.8 ms
64 bytes from 152.2.254.81: icmp_seq=3 ttl=254 time=170.6 ms
64 bytes from 152.2.254.81: icmp_seq=4 ttl=254 time=170.6 ms
</ProgramListing>
</Para>
<Para>
Again, stop the output by pressing CTRL C and get the statistics...
</Para>
<Para>
<ProgramListing>
--- sunsite.unc.edu ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 169.8/176.3/190.1 ms
</ProgramListing>
</Para>
<Para>
If you don't get any response, try pinging the IP address of the DNS
server at your ISP's site. If you get a result from this, then it looks
like you have a problem with <Literal remap="tt">/etc/resolv.conf</Literal>.
</Para>
<Para>
If this doesn't work, you have a routing problem, or your ISP has a
problem routing packets back to you. Check your routing table as shown
above and if that is OK, contact your ISP. A good test of the ISP is to
use another operating system to connect. If you can get beyond your ISP
with that, then the problem is at your end.
</Para>
<Para>
If everything works, shut down the connection by typing:-
</Para>
<Para>
<ProgramListing>
ppp-off
</ProgramListing>
</Para>
<Para>
After a short pause, the modem should hang itself up.
</Para>
<Para>
If that does not work, either turn off your modem or fire up your
communications software and interrupt the modem with +++ and then hang
up with ATH0 when you receive the modem's OK prompt.
</Para>
<Para>
You may also need to clean up the lock file created by pppd.
<ProgramListing>
rm -f /var/lock/LCK..ttySx
</ProgramListing>
</Para>
</Chapter>
<Chapter id="automate">
<Title>Automating your connections - Creating the connection scripts</Title>
<Para>
Whilst you can continue to log in by hand as shown above, it is much
neater to set up some scripts to do this automatically for you.
</Para>
<Para>
A set of scripts automates the log in and PPP start up so all you have to
do (as root or as a member of the PPP group) is issue a single command
to fire up your connection.
</Para>
<Sect1>
<Title>Connection scripts for User name/Password Authentication</Title>
<Para>
If your ISP does NOT require the use of PAP/CHAP, these are the scripts
for you!
</Para>
<Para>
If the ppp package installed correctly, you should have two example files.
For PPP 2.1.2 they are in <Literal remap="tt">/usr/sbin</Literal> and for PPP 2.2 they are in
<Literal remap="tt">/etc/ppp/scripts</Literal>. They are called
</Para>
<Para>
for PPP-2.1.2
</Para>
<Para>
<Screen>
ppp-on
ppp-off
</Screen>
</Para>
<Para>
and for PPP-2.2
</Para>
<Para>
<Screen>
ppp-off
ppp-on
ppp-on-dialer
</Screen>
</Para>
<Para>
Now, if you are using PPP 2.1.2, I strongly urge you to delete the
sample files. There are potential problems with these - and don't tell
me they work fine - I used them for ages too (and recommended them in
the first version of this HOWTO)!
</Para>
<Para>
For the benefit of PPP 2.1.2 users, here are BETTER template versions,
taken from the PPP 2.2 distribution. I suggest you copy and use these
scripts <Emphasis>instead of</Emphasis> the old PPP-2.1.2 scripts.
</Para>
</Sect1>
<Sect1>
<Title>The ppp-on script</Title>
<Para>
This is the first of a PAIR of scripts that actually fire up the
connection.
</Para>
<Para>
<ProgramListing>
#!/bin/sh
#
# Script to initiate a PPP connection. This is the first part of the
# pair of scripts. This is not a secure pair of scripts as the codes
# are visible with the 'ps' command. However, it is simple.
#
# These are the parameters. Change as needed.
TELEPHONE=555-1212 # The telephone number for the connection
ACCOUNT=george # The account name for logon (as in 'George Burns')
PASSWORD=gracie # The password for this account (and 'Gracie Allen')
LOCAL_IP=0.0.0.0 # Local IP address if known. Dynamic = 0.0.0.0
REMOTE_IP=0.0.0.0 # Remote IP address if desired. Normally 0.0.0.0
NETMASK=255.255.255.0 # The proper netmask if needed
#
# Export them so that they will be available to 'ppp-on-dialer'
export TELEPHONE ACCOUNT PASSWORD
#
# This is the location of the script which dials the phone and logs
# in. Please use the absolute file name as the $PATH variable is not
# used on the connect option. (To do so on a 'root' account would be
# a security hole so don't ask.)
#
DIALER_SCRIPT=/etc/ppp/ppp-on-dialer
#
# Initiate the connection
#
#
exec /usr/sbin/pppd debug /dev/ttySx 38400 \
$LOCAL_IP:$REMOTE_IP \
connect $DIALER_SCRIPT
</ProgramListing>
</Para>
<Para>
Here is the ppp-on-dialer script:-
</Para>
<Para>
<ProgramListing>
#!/bin/sh
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#
/usr/sbin/chat -v \
TIMEOUT 3 \
ABORT '\nBUSY\r' \
ABORT '\nNO ANSWER\r' \
ABORT '\nRINGING\r\n\r\nRINGING\r' \
'' \rAT \
'OK-+++\c-OK' ATH0 \
TIMEOUT 30 \
OK ATDT$TELEPHONE \
CONNECT '' \
ogin:--ogin: $ACCOUNT \
assword: $PASSWORD
</ProgramListing>
</Para>
<Para>
For PPP-2.2, the <Literal remap="tt">ppp-off</Literal> script looks like:-
</Para>
<Para>
<ProgramListing>
#!/bin/sh
######################################################################
#
# Determine the device to be terminated.
#
if [ "$1" = "" ]; then
DEVICE=ppp0
else
DEVICE=$1
fi
######################################################################
#
# If the ppp0 pid file is present then the program is running. Stop it.
if [ -r /var/run/$DEVICE.pid ]; then
kill -INT `cat /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
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>Editing the supplied PPP startup scripts</Title>
<Para>
As the new scripts come in two parts, we will edit them in turn.
</Para>
<Sect2>
<Title>The ppp-on script</Title>
<Para>
You will need to edit the script to reflect YOUR user name at your ISP,
YOUR password at your ISP, and the telephone number of your ISP.
</Para>
<Para>
Each of the lines like "<Literal remap="tt">TELEPHONE=</Literal>" actually set up shell variables that
contain the information to the right of the '=' (excluding the comments
of course). So edit each of these lines so it is correct for your ISP
and connection.
</Para>
<Para>
Also, as you are setting the IP number (if you need to) in the
<Literal remap="tt">/etc/ppp/options</Literal> file, DELETE the line that says
</Para>
<Para>
<ProgramListing>
$LOCAL_IP:$REMOTE_IP \
</ProgramListing>
</Para>
<Para>
Also, make sure that the shell variable DIALER&lowbar;SCRIPT points at
the full path and name of the dialer script that you are actually going
to use. So, if you have moved this or renamed the script,
make sure you edit this line correctly in the <Literal remap="tt">ppp-on</Literal> script!
</Para>
</Sect2>
<Sect2>
<Title>The ppp-on-dialer script</Title>
<Para>
This is the second of the scripts that actually brings
up our ppp link.
</Para>
<Para>
Note: a chat script is normally all on one line. the backslashes are
used to allow line continuations across several physical lines (for
human readability) and do not form part of the script itself.
</Para>
<Para>
However, it is very useful to look at it in detail so
that we understand what it is actually (supposed) to be doing!
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>What a Chat script means...</Title>
<Para>
A chat script is a sequence of expect
string, send string pairs. In particular, note that we <Emphasis>ALWAYS</Emphasis>
expect <Emphasis>something</Emphasis>
before we send something.
</Para>
<Para>
If we are to send something <Emphasis>WITHOUT</Emphasis> receiving anything first, we
must use an empty expect string (indicated by " ") and similarly for expecting something
without sending anything! Also, if a string consists of several words,
(e.g. NO CARRIER), you must quote the string so that it is seen as a
single entity by chat.
</Para>
<Para>
The chat line in our template is:-
</Para>
<Para>
<ProgramListing>
exec /usr/sbin/chat -v
</ProgramListing>
</Para>
<Para>
Invoke chat, the -v tells chat to copy ALL its I/O into the system log
(usually /var/log/messages). Once you are happy that the chat script is
working reliably, edit this line to remove the -v to save unnecessary
clutter in your syslog.
</Para>
<Para>
<ProgramListing>
TIMEOUT 3
</ProgramListing>
This sets the timeout for the receipt of expected input to three
seconds. You may need to increase this to say 5 or 10 seconds if you are
using a really slow modem!
</Para>
<Para>
<ProgramListing>
ABORT '\nBUSY\r'
</ProgramListing>
</Para>
<Para>
If the string BUSY is received, abort the operation.
</Para>
<Para>
<ProgramListing>
ABORT '\nNO ANSWER\r'
</ProgramListing>
</Para>
<Para>
If the string NO ANSWER is received, abort the operation
</Para>
<Para>
<ProgramListing>
ABORT '\nRINGING\r\n\r\nRINGING\r'
</ProgramListing>
</Para>
<Para>
If the (repeated) string RINGING is received, abort the
operation. This is because someone is ringing your phone line!
</Para>
<Para>
<ProgramListing>
\rAT
</ProgramListing>
</Para>
<Para>
Expect nothing from the modem and send the string AT.
</Para>
<Para>
<ProgramListing>
OK-+++\c-OK ATH0
</ProgramListing>
</Para>
<Para>
This one is a bit more complicated as it uses some of chat's error
recovery capabilities.
</Para>
<Para>
What is says is...Expect OK, if it is NOT received (because the modem is
not in command mode) then send +++ (the standard Hayes-compatible modem
string that returns the modem to command mode) and expect OK. Then send
ATH0 (the modem hang up string). This allows your script to
cope with the situation of your modem being stuck on-line!
</Para>
<Para>
<ProgramListing>
TIMEOUT 30
</ProgramListing>
</Para>
<Para>
Set the timeout to 30 seconds for the remainder of the script. If you
experience trouble with the chat script aborting due to timeouts,
increase this to 45 seconds or more.
</Para>
<Para>
<ProgramListing>
OK ATDT$TELEPHONE
</ProgramListing>
</Para>
<Para>
Expect OK (the modem's response to the ATH0 command) and dial the number
we want to call.
</Para>
<Para>
<ProgramListing>
CONNECT ''
</ProgramListing>
</Para>
<Para>
Expect CONNECT (which our modem sends when the remote modem answers) and
send nothing in reply.
</Para>
<Para>
<ProgramListing>
ogin:--ogin: $ACCOUNT
</ProgramListing>
</Para>
<Para>
Again, we have some error recovery built in here. Expect the login
prompt (...ogin:) but if we don't receive it by the timeout, send a
return and then look for the login prompt again. When the prompt is
received, send the username (stored in the shell variable &dollar;ACCOUNT).
</Para>
<Para>
<ProgramListing>
assword: $PASSWORD
</ProgramListing>
</Para>
<Para>
Expect the password prompt and send our password (again, stored in a
shell variable).
</Para>
<Para>
This chat script has reasonable error recovery capability. Chat has
considerably more features than demonstrated here. For more information
consult the chat manual page (<Literal remap="tt">man 8 chat</Literal>).
</Para>
<Sect2>
<Title>Starting PPP at the server end</Title>
<Para>
Whilst the ppp-on-dialer script is fine for servers that automatically
start pppd at the server end once you have logged in, some servers
require that you explicitly start PPP on the server.
</Para>
<Para>
If you need to issue a command to start up PPP on the server, you DO need
to edit the ppp-on-dialer script.
</Para>
<Para>
At the END of the script (after the password line) add an additional
<Emphasis>expect send</Emphasis> pair - this one would look for your login prompt (beware
of characters that have a special meaning in the Bourne shell - such as
&dollar; and &lsqb; or ] (open and close square brackets).
</Para>
<Para>
Once chat has found the shell prompt, chat must issue the ppp
start up command required for your ISPs PPP server.
</Para>
<Para>
In my case, my PPP server uses the standard Linux Bash prompt
<ProgramListing>
[hartr@kepler hartr]$
</ProgramListing>
</Para>
<Para>
and requires that I type
</Para>
<Para>
<ProgramListing>
ppp
</ProgramListing>
</Para>
<Para>
to start up PPP on the server.
</Para>
<Para>
It is a good idea to allow for a bit of error recovery here, so in my
case I use
<ProgramListing>
hartr--hartr ppp
</ProgramListing>
</Para>
<Para>
This says, if we don't receive the prompt within the timeout, send a
carriage return and looks for the prompt again.
</Para>
<Para>
Once the prompt is received, then send the string <Literal remap="tt">ppp</Literal>.
</Para>
<Para>
Note: don't forget to add a &bsol; to the end of the previous line so chat
still thinks the entire chat script is on one line!
</Para>
<Para>
Unfortunately, some servers produce a very variable set of prompts! You
may need to log in several times using minicom to understand what is
going on and pick the stable "expect" strings.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>A chat script for PAP/CHAP authenticated connections</Title>
<Para>
If your ISP is using PAP/CHAP, then your chat script is much simpler.
All your chat script needs to do is dial the telephone, wait for a
connect and then let pppd handle the logging in!
</Para>
<Para>
<ProgramListing>
#!/bin/sh
#
# This is part 2 of the ppp-on script. It will perform the connection
# protocol for the desired connection.
#
exec /usr/sbin/chat -v \
TIMEOUT 3 \
ABORT '\nBUSY\r' \
ABORT '\nNO ANSWER\r' \
ABORT '\nRINGING\r\n\r\nRINGING\r' \
'' \rAT \
'OK-+++\c-OK' ATH0 \
TIMEOUT 30 \
OK ATDT$TELEPHONE \
CONNECT '' \
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>The pppd <Literal remap="tt">debug</Literal> and <Literal remap="tt">file option&lowbar;file</Literal> options</Title>
<Para>
As we have already seen, you can turn on debug information logging
with the -d option to pppd. The 'debug' option is equivalent to this.
</Para>
<Para>
As we are establishing a new connection with a new script, leave in the
debug option for now. (Warning: if your disk space is tight, logging
pppd exchanges can rapidly extend your syslog file and run you into
trouble - but to do this you must fail to connect and keep on trying for
quite a few minutes).
</Para>
<Para>
Once you are happy that all is working properly, then you can remove
this option.
</Para>
<Para>
If you have called your ppp options file anything other than
<Literal remap="tt">/etc/ppp/options</Literal> or <Literal remap="tt">/etc/ppp/options.ttySx</Literal>, specify
the file name with the <Literal remap="tt">file</Literal> option to pppd - e.g.
</Para>
<Para>
<ProgramListing>
exec /usr/sbin/pppd debug file options.myserver /dev/ttyS0 38400 \
</ProgramListing>
</Para>
</Sect1>
</Chapter>
<CHAPTER>
<Title>Testing your connection script</Title>
<Para>
Open a new root Xterm (if you are in X) or open a new virtual console
and log in as root.
</Para>
<Para>
In this new session, issue the command
</Para>
<Para>
<Screen>
tail -f /var/log/messages
</Screen>
</Para>
<Para>
(or whatever your system log file is).
</Para>
<Para>
In the first window (or virtual console) issue the command
</Para>
<Para>
<Screen>
ppp-on &amp;
</Screen>
</Para>
<Para>
(or whatever name you have called your edited version of /usr/sbin/ppp-
on). If you do not put the script into the background by specifying &amp;
at the end of the command, you will not get your terminal prompt back
until ppp exits (when the link terminates).
</Para>
<Para>
Now switch back to the window that is tracking your system log.
</Para>
<Para>
You will see something like the following (provided you specified -v to
chat and -d to pppd)....this is the chat script and responses being
logged to the system log file followed by the start up information for
pppd :-
</Para>
<Para>
<ProgramListing>
Oct 21 16:09:58 hwin chat[19868]: abort on (NO CARRIER)
Oct 21 16:09:59 hwin chat[19868]: abort on (BUSY)
Oct 21 16:09:59 hwin chat[19868]: send (ATZ^M)
Oct 21 16:09:59 hwin chat[19868]: expect (OK)
Oct 21 16:10:00 hwin chat[19868]: ATZ^M^M
Oct 21 16:10:00 hwin chat[19868]: OK -- got it
Oct 21 16:10:00 hwin chat[19868]: send (ATDT722298^M)
Oct 21 16:10:00 hwin chat[19868]: expect (CONNECT)
Oct 21 16:10:00 hwin chat[19868]: ^M
Oct 21 16:10:22 hwin chat[19868]: ATDT722298^M^M
Oct 21 16:10:22 hwin chat[19868]: CONNECT -- got it
Oct 21 16:10:22 hwin chat[19868]: send (^M)
Oct 21 16:10:22 hwin chat[19868]: expect (ogin:)
Oct 21 16:10:23 hwin chat[19868]: kepler login: -- got it
Oct 21 16:10:23 hwin chat[19868]: send (hartr^M)
Oct 21 16:10:23 hwin chat[19868]: expect (ssword:)
Oct 21 16:10:23 hwin chat[19868]: hartr^M
Oct 21 16:10:23 hwin chat[19868]: Password: -- got it
Oct 21 16:10:23 hwin chat[19868]: send (??????^M)
Oct 21 16:10:23 hwin chat[19868]: expect (hartr)
Oct 21 16:10:24 hwin chat[19868]: [hartr -- got it
Oct 21 16:10:24 hwin chat[19868]: send (ppp^M)
Oct 21 16:10:27 hwin pppd[19872]: pppd 2.1.2 started by root, uid 0
Oct 21 16:10:27 hwin pppd[19873]: Using interface ppp0
Oct 21 16:10:27 hwin pppd[19873]: Connect: ppp0 &#60;--&#62; /dev/cua1
Oct 21 16:10:27 hwin pppd[19873]: fsm_sdata(LCP): Sent code 1, id 1.
Oct 21 16:10:27 hwin pppd[19873]: LCP: sending Configure-Request, id 1
Oct 21 16:10:27 hwin pppd[19873]: fsm_rconfreq(LCP): Rcvd id 1.
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: rcvd MRU
Oct 21 16:10:27 hwin pppd[19873]: (1500)
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: rcvd ASYNCMAP
Oct 21 16:10:27 hwin pppd[19873]: (0)
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: rcvd MAGICNUMBER
Oct 21 16:10:27 hwin pppd[19873]: (a098b898)
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: rcvd PCOMPRESSION
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: rcvd ACCOMPRESSION
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: lcp_reqci: returning CONFACK.
Oct 21 16:10:27 hwin pppd[19873]: fsm_sdata(LCP): Sent code 2, id 1.
Oct 21 16:10:27 hwin pppd[19873]: fsm_rconfack(LCP): Rcvd id 1.
Oct 21 16:10:27 hwin pppd[19873]: fsm_sdata(IPCP): Sent code 1, id 1.
Oct 21 16:10:27 hwin pppd[19873]: IPCP: sending Configure-Request, id 1
Oct 21 16:10:27 hwin pppd[19873]: fsm_rconfreq(IPCP): Rcvd id 1.
Oct 21 16:10:27 hwin pppd[19873]: ipcp: received ADDR
Oct 21 16:10:27 hwin pppd[19873]: (10.144.153.51)
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: ipcp: received COMPRESSTYPE
Oct 21 16:10:27 hwin pppd[19873]: (45)
Oct 21 16:10:27 hwin pppd[19873]: (ACK)
Oct 21 16:10:27 hwin pppd[19873]: ipcp: returning Configure-ACK
Oct 21 16:10:28 hwin pppd[19873]: fsm_sdata(IPCP): Sent code 2, id 1.
Oct 21 16:10:30 hwin pppd[19873]: fsm_sdata(IPCP): Sent code 1, id 1.
Oct 21 16:10:30 hwin pppd[19873]: IPCP: sending Configure-Request, id 1
Oct 21 16:10:30 hwin pppd[19873]: fsm_rconfreq(IPCP): Rcvd id 255.
Oct 21 16:10:31 hwin pppd[19873]: ipcp: received ADDR
Oct 21 16:10:31 hwin pppd[19873]: (10.144.153.51)
Oct 21 16:10:31 hwin pppd[19873]: (ACK)
Oct 21 16:10:31 hwin pppd[19873]: ipcp: received COMPRESSTYPE
Oct 21 16:10:31 hwin pppd[19873]: (45)
Oct 21 16:10:31 hwin pppd[19873]: (ACK)
Oct 21 16:10:31 hwin pppd[19873]: ipcp: returning Configure-ACK
Oct 21 16:10:31 hwin pppd[19873]: fsm_sdata(IPCP): Sent code 2, id 255.
Oct 21 16:10:31 hwin pppd[19873]: fsm_rconfack(IPCP): Rcvd id 1.
Oct 21 16:10:31 hwin pppd[19873]: ipcp: up
Oct 21 16:10:31 hwin pppd[19873]: local IP address 10.144.153.104
Oct 21 16:10:31 hwin pppd[19873]: remote IP address 10.144.153.51
</ProgramListing>
</Para>
<Para>
(Note - I am using STATIC IP numbers - hence my machine sent that to the
PPP server - you won't see this if you are using DYNAMIC IP numbers.)
Also, this server requires a specific command to start ppp at its end.
</Para>
<Para>
This looks OK - so test it out as before with pings to IP numbers and
host names.
</Para>
<Para>
Fire up you web browser or whatever and go surfing - you are connected!
</Para>
</Chapter>
<Chapter id="off">
<Title>Shutting down the PPP link</Title>
<Para>
When you have finished with the PPP link, use the standard ppp-off
command to shut it down (remember - you need to be root or a member of
the PPP group!).
</Para>
<Para>
In your system log you will see something like:-
</Para>
<Para>
<ProgramListing>
Oct 21 16:10:45 hwin pppd[19873]: Interrupt received: terminating link
Oct 21 16:10:45 hwin pppd[19873]: ipcp: down
Oct 21 16:10:45 hwin pppd[19873]: default route ioctl(SIOCDELRT): Bad address
Oct 21 16:10:45 hwin pppd[19873]: fsm_sdata(LCP): Sent code 5, id 2.
Oct 21 16:10:46 hwin pppd[19873]: fsm_rtermack(LCP).
Oct 21 16:10:46 hwin pppd[19873]: Connection terminated.
Oct 21 16:10:46 hwin pppd[19873]: Exit.
</ProgramListing>
</Para>
<Para>
Don't worry about the <Literal remap="tt">SIOCDELRT</Literal> - this is just pppd noting that it
is terminating and is nothing to worry about.
</Para>
</Chapter>
<CHAPTER>
<Title>Getting Help when totally stuck</Title>
<Para>
If you can't get your PPP link to work, go back through this document and
check everything - in conjunction with the output created by "chat-v..."
and "pppd -d" in you system log.
</Para>
<Para>
Also consult the PPP documentation and FAQ plus the other documents
mention herein!
</Para>
<Para>
If you are still stuck, try the comp.os.linux.misc and
comp.os.linux.networking newsgroups are reasonably regularly scanned by
people that can help you with PPP as is comp.protocols.ppp
</Para>
<Para>
You can try sending me personal email, but I do have a day job (and a
life) and I do not guarantee to respond quickly (if at all) as this
depends on my current work load and the state of my private life!
</Para>
<Para>
In particular - <Emphasis>DO NOT POST REAMS OF DEBUGGING OUTPUT TO THE NEWS GROUPS
NOR SEND IT TO ME BY EMAIL</Emphasis> - the former wastes huge amounts of network
bandwidth and the latter will be consigned to /dev/null (unless I have
specifically requested it).
</Para>
</Chapter>
<CHAPTER>
<Title>Common Problems once the link is working</Title>
<Para>
One problem you will find is that many service providers will only
support the connection software package that they distribute to new
accounts. This is (typically) for Microsoft Windows :-( - and many service
provider help desks seem to know nothing about Unix (or Linux). So, be
prepared for limited assistance from them!
</Para>
<Para>
You could of course do the individual a favour and educate then about
Linux (any ISP help desk person should be reasonably 'with it' in
Internet terms and that means they should have a home Linux box - of
course it does)!
</Para>
<Sect1>
<Title>I can't see beyond the PPP server I connect to</Title>
<Para>
OK - your PPP connection is up and running and you can ping the PPP
server by IP number (the second or "remote" IP number shown by <Literal remap="tt">ifconfig
ppp0</Literal>), but you can't reach anything beyond this.
</Para>
<Para>
First of all, try pinging the IP numbers you have specified in
/etc/resolv.conf as name servers. If this works, you <Emphasis>can</Emphasis> see beyond your
PPP server (unless this has the same IP number as the "remote" IP number
of your connection). So now try pinging the full Internet name of your
service provider - eg
</Para>
<Para>
<Screen>
ping my.provider.net.au
</Screen>
</Para>
<Para>
If this does NOT work, you have a problem with the name resolution. This
is probably because of a typo in your /etc/resolv.conf file. Check this
carefully against the information you acquired by ringing your service
provider. If all looks OK, ring your service provider and check that you
wrote down the IP numbers correctly.
</Para>
<Para>
If it STILL doesn't work (and your service provider confirms that his
name servers are up and running), you have a problem somewhere else -
and I suggest you check carefully through your Linux installation
(looking particularly for file permissions).
</Para>
<Para>
If you STILL can't ping your service provider's IP name servers by IP number,
either they are down (give them a voice call and check) or there is a
routing problem at your service provider's end. Again, ring them and
check this out.
</Para>
<Para>
One possibility is that the "remote end" is a Linux PPP server where the
IP forwarding option has not been specified in the kernel!
</Para>
<Para>
A good general test is to try connecting to your service provider using
the software that most supply for (gulp) Microsoft Windows. If
everything works from another operating system to exactly the same
account, then the problem is with your Linux system and NOT your service
provider.
</Para>
</Sect1>
<Sect1>
<Title>I can send email, but not receive it</Title>
<Para>
If you are using dynamic IP numbers, this is perfectly normal. See
"Setting up Services" below.
</Para>
</Sect1>
<Sect1>
<Title>Why can't people finger, WWW, gopher, talk, etc. to my machine?</Title>
<Para>
Again, if you are using dynamic IP numbers, this is perfectly normal.
See "Setting up Services" below.
</Para>
</Sect1>
</Chapter>
<Chapter id="dynamic-server">
<Title>Using Internet services with Dynamic IP numbers</Title>
<Para>
If you are using dynamic IP numbers (and many service providers will only
give you a dynamic IP number unless you pay significantly more for your
connection), then you have to recognize the limitations this imposes.
</Para>
<Para>
First of all, outbound service requests will work just fine. That is,
you can send email using sendmail (provided you have correctly set up
sendmail), ftp files from remote sites, finger users on other machines,
browse the web etc.
</Para>
<Para>
In particular, you can answer email that you have brought down to your
machine whilst you are off line. Mail will simply sit in your mail queue
until you dial back into your ISP.
</Para>
<Para>
However, your machine is NOT connected to the Internet 24 hours a day,
nor does it have the same IP number every time it is connected. So it is
impossible for you to receive email directed to your machine, and very
difficult to set up a web or ftp server that your friends can access! As
far as the Internet is concerned your machine does not exist as a
unique, permanently contactable machine as it does not have a unique IP
number (remember - other machines will be using the IP number when they
are allocated it on dial-in).
</Para>
<Para>
If you set up a WWW, (or any other server), it is totally unknown by any
user on the Internet UNLESS they know that your machine is connected AND
its actual (current) IP number. There are a number of ways they can get
this info, ranging from you ringing them, sending them email to tell
them or cunning use of ".plan" files on a shell account at your service
provider (assuming that your provider allows shell and finger access).
</Para>
<Para>
Now, for most users, this is not a problem - all that most people want
is to send and receive email (using your account on your service
provider) and make outbound connections to WWW, ftp and other servers on
the Internet. If you MUST have inbound connections to your server, you
should really get a static IP number. Alternatively you can explore the
methods hinted at above...
</Para>
<Sect1>
<Title>Setting up email</Title>
<Para>
Even for dynamic IP numbers, you can certainly configure sendmail on your
machine to send out any email that you compose locally. Configuration of
sendmail can be obscure and difficult - so this document does not
attempt to tell you how to do this. However, you should probably
configure sendmail so that your Internet service provider is designated
as your "smart relay" host (the <Literal remap="tt">sendmail.cf</Literal> <Emphasis>DS</Emphasis> option). (For more
sendmail configuration info, see the sendmail documents - and look at the
m4 configurations that come with sendmail. There is almost certain to be
one there that will meet your needs).
</Para>
<Para>
There are also excellent books on Sendmail (notably the 'bible' from
O'Reilly and Associates), but these are almost certainly overkill for
most users!
</Para>
<Para>
Once you have sendmail configured, you will probably want to have
sendmail dispatch any messages that have been sitting in the outbound
mail queue as soon as the PPP connection comes up. To do this, add the
command
</Para>
<Para>
<Screen>
sendmail -q &#38;
</Screen>
</Para>
<Para>
to your /etc/ppp/ip-up script (see below).
</Para>
<Para>
Inbound email is a problem for dynamic IP numbers. The way to handle
this is to:-
<ItemizedList>
<ListItem>
<Para>
configure your mail user agent so that all mail is sent out with a
"reply to" header giving your email address at your Internet Service
provider.
If you can, you should also set your FROM address to be your email
address at your ISP as well.
</Para>
</ListItem>
<ListItem>
<Para>
use the popclient, fetchmail programs to retrieve your email from your
service provider. Alternatively, if your ISP is using IMAP, use an IMAP
enabled mail user agent, (such as pine).
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
You can automate this process at dial up time by putting the necessary
commands in the <Literal remap="tt">/etc/ppp/ip-up</Literal> script (see below).
</Para>
</Sect1>
<Sect1>
<Title>Setting Up a local Name server</Title>
<Para>
Whilst you can quite happily use the domain name servers located at your
ISP, you can also set up a local caching only (secondary) name server
that is brought up by the ip-up script. The advantage of running a local
(caching only) name server is that it will save you time (and bandwidth)
if you frequently contact the same sites during a long on-line session.
</Para>
<Para>
DNS configuration for a caching only nameserver (that uses a
"forwarders' line in the named.boot file pointing at your ISPs DNS) is
relatively simple. The O'Reilly book (DNS and Bind) explains all you
want to know about this.
</Para>
<Para>
There is also a DNS-HOWTO available.
</Para>
<Para>
If you are running a small LAN that can access the Internet through you
Linux PC (using IP Masquerade for example), it is probably a good idea
to run a local name server (with a forwarders directive) whilst the link
is up as this will minimise the bandwidth and delays associated with
name resolution.
</Para>
<Para>
One point of Nettiquette: ask permission from your ISP before you start
using a secondary, caching only name server in your ISP's domain.
Properly configured, your DNS will not cause any problems to your ISP at
all, but if you get things wrong, it can cause problems.
</Para>
</Sect1>
</Chapter>
<Chapter id="WAN">
<Title>Linking two networks using PPP</Title>
<Para>
There is basically no difference between linking a single Linux PC to a
PPP server and linking two LANs using PPP on a machine on each LAN.
Remember, PPP is a <Emphasis>peer to peer</Emphasis> protocol.
</Para>
<Para>
However, you <Emphasis>DEFINITELY</Emphasis> need to understand about how routing is
established. Read the NET-2 howto and the Linux Network Administrator
Guide (NAG). You will also find TCP/IP Network
Administration (published by O'Reilly and Assoc - ISBN
0-937175-82-X) to be of invaluable assistance.
</Para>
<Para>
If you are going to be sub networking an IP network number on either side
of the link, you will also find the Linux (draft) sub networking
mini-howto) to be of use. This is available at <ULink
URL="http://www.interweft.com.au/other/"
>Linux Sub networking mini-HOWTO</ULink
>.
</Para>
<Para>
In order to link two LANs, you <Emphasis>must</Emphasis> be using different IP network
numbers (or subnets of the same network number) and you will need to use
static IP numbers - or use IP masquerade. If you want to use IP
masquerade, see the IP masquerade mini-howto for instructions on setting
that up.
</Para>
<Sect1>
<Title>Setting up the IP numbers</Title>
<Para>
Arrange with the network administrator of the other LAN the IP numbers
that will be used for each end of the PPP interface. If you are using
static IP numbers, this will also probably require you to dial into a
specific telephone number.
</Para>
<Para>
Now edit the appropriate <Literal remap="tt">/etc/ppp/options[.ttyXX]</Literal> file - it's a
good idea to have a specific modem and port at your end for this
connection. This may well require you to change your
<Literal remap="tt">/etc/ppp/options</Literal> file - and create appropriate
options.ttyXX files for any other connections!
</Para>
<Para>
Specify the IP numbers for your end of the PPP link in
the appropriate options file exactly as shown above for static IP
numbers.
</Para>
</Sect1>
<Sect1>
<Title>Setting up the routing</Title>
<Para>
You must arrange that packets on your local LAN are routed across the
interface that the PPP link establishes. This is a two stage process.
</Para>
<Para>
First of all, you need to establish a route from the machine running the
PPP link to the network(s) at the far end of the link. If the link is to
the Internet, this can be handled by a default route established by pppd
itself at your end of the connection using the 'defaultroute' option to pppd.
</Para>
<Para>
If however, the link is only linking two LANs, then a specific network
route must be added for each network that is accessible across the link.
This is done using a 'route' command for each network in the
/etc/ppp/ip-up script (see "After the link comes up"...) for instructions
on doing this.
</Para>
<Para>
The second thing you need to do is to tell the other computers on your
LAN that your Linux computer is actually the 'gateway' for the network(s)
at the far end of the ppp link.
</Para>
<Para>
Of course, the network administrator at the other end of the link has to
do all this too! However, as s/he will be routing packets to your specific
networks, a <Emphasis>specific network route</Emphasis> will be required, not a default
route (unless the LANs at the far and of the link are linking into you
to access the Internet across your connection).
</Para>
</Sect1>
<Sect1>
<Title>Network security</Title>
<Para>
If you are linking you LAN to the Internet using PPP - or even just to a
"foreign" LAN, you need to think about security issues. I
strongly urge you to think about setting up a firewall!
</Para>
<Para>
You should also speak to the LAN administrator at your site <Emphasis>BEFORE</Emphasis>
you start linking to foreign LANs or the Internet this way. Failure to
do so could earn you anything from no reaction to really serious trouble!
</Para>
</Sect1>
</Chapter>
<Chapter id="ip-up">
<Title>After the link comes up - the <Literal remap="tt">/etc/ppp/ip-up</Literal> script</Title>
<Para>
Once the PPP link is established, pppd looks for
<Literal remap="tt">/etc/ppp/ip-up</Literal>. If this script exists and is executable, the
PPP daemon executes the script. This allows you to automate any special
routing commands that may be necessary and any other actions that you
want to occur every time the PPP link is activated.
</Para>
<Para>
This is just a shell script and can do anything that a shell script can
do (i.e. virtually anything you want).
</Para>
<Para>
For example, you can get sendmail to dispatch any waiting outbound
messages in the mail queue.
</Para>
<Para>
Similarly, you can insert the commands into ip-up to collect (using pop)
any email waiting for you at your ISP.
</Para>
<Para>
There are restrictions on <Literal remap="tt">/etc/ppp/ip-up</Literal>:-
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
It runs in a deliberately restricted environment to enhance
security. This means you must give a full path to binaries etc.
</Para>
</ListItem>
<ListItem>
<Para>
Technically, <Literal remap="tt">/etc/ppp/ip-up</Literal> is a <Emphasis>program</Emphasis> not a
script. This means it can be directly executed - and hence it requires
the standard file magic (<Literal remap="tt">&num;!/bin/bash</Literal>) at the start of the first line and must be
readable and executable by root.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Sect1>
<Title>Special routing</Title>
<Para>
If you are linking two LANs, you will need to set up specific routes
to the 'foreign' LANs. This is easily done using the <Literal remap="tt">/etc/ppp/ip-up</Literal>
script. The only difficulty arises if your machine handles multiple PPP
links.
</Para>
<Para>
This is because the <Literal remap="tt">/etc/ppp/ip-up</Literal> is executed for EVERY ppp
connection that comes up, so you need to carefully execute the correct
routing commands for the particular link that comes up - and not when
any other link comes up!
</Para>
</Sect1>
<Sect1>
<Title>Handling email queues</Title>
<Para>
When the link between two LANs comes up, you may well want to make sure
that email that is queued at either end is <Emphasis>flushed</Emphasis> - sent out to
its destination. This is done by adding the appropriate <Literal remap="tt">sendmail</Literal>
invocation.
</Para>
<Para>
Using the bash 'case' statement on an appropriate parameter that pppd
passes into the script accomplishes this. For example, this is
the <Literal remap="tt">/etc/ppp/ip-up</Literal> script I use to handle our WAN links and the
link to my home Ethernet (also handled on the same ppp server).
</Para>
</Sect1>
<Sect1>
<Title>A sample <Literal remap="tt">/etc/ppp/ip-up</Literal> script</Title>
<Para>
The example below provides a variety of example uses.
</Para>
<Para>
<ProgramListing>
#!/bin/bash
#
# Script which handles the routing issues as necessary for pppd
# Only the link to Newman requires this handling.
#
# When the ppp link comes up, this script is called with the following
# parameters
# $1 the interface name used by pppd (e.g. ppp3)
# $2 the tty device name
# $3 the tty device speed
# $4 the local IP address for the interface
# $5 the remote IP address
# $6 the parameter specified by the 'ipparam' option to pppd
#
case "$5" in
# Handle the routing to the Newman Campus server
202.12.126.1)
/sbin/route add -net 202.12.126.0 gw 202.12.126.1
# and flush the mail queue to get their email there asap!
/usr/sbin/sendmail -q &#38;
;;
139.130.177.2)
# Our Internet link
# When the link comes up, start the time server and synchronise to the world
# provided it is not already running
if [ ! -f /var/lock/subsys/xntpd ]; then
/etc/rc.d/init.d/xntpd.init start &#38;
fi
# Start the news server (if not already running)
if [ ! -f /var/lock/subsys/news ]; then
/etc/rc.d/init.d/news start &#38;
fi
;;
203.18.8.104)
# Get the email down to my home machine as soon as the link comes up
# No routing is required as my home Ethernet is handled by IP
# masquerade and proxyarp routing.
/usr/sbin/sendmail -q &#38;
;;
*)
esac
exit 0
</ProgramListing>
</Para>
<Para>
As a result of bringing up the ppp link to our Newman campus and this
script, we end up with the following routing table entries (this machine
also is our general dial up PPP server AND handles our Internet link). I
have interspersed comments in the output to help explain what each entry
is) :-
</Para>
<Para>
<ProgramListing>
[root@kepler /root]# route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
# the HOST route to our remote internet gateway
139.130.177.2 * 255.255.255.255 UH 1500 0 134 ppp4
# the HOST route to our Newman campus server
202.12.126.1 * 255.255.255.255 UH 1500 0 82 ppp5
# the HOST route to my home ethernet
203.18.8.104 * 255.255.255.255 UH 1500 0 74 ppp3
# two of our general dial up PPP lines
203.18.8.64 * 255.255.255.255 UH 552 0 0 ppp2
203.18.8.62 * 255.255.255.255 UH 552 0 1 ppp1
# the specific network route to the Newman campus LAN
202.12.126.0 202.12.126.1 255.255.255.0 UG 1500 0 0 ppp5
# the route to our local Ethernet (super-netting two adjacent C classes)
203.18.8.0 * 255.255.254.0 U 1500 0 1683 eth0
# the route to the loop back device
127.0.0.0 * 255.0.0.0 U 3584 0 483 lo
# the default route to the Internet
default 139.130.177.2 * UG 1500 0 3633 ppp4
</ProgramListing>
</Para>
</Sect1>
<Sect1>
<Title>Handling email</Title>
<Para>
The previous section shows how to handle the outgoing mail - simply by
flushing the mail queue once the link is up.
</Para>
<Para>
If you are running a WAN link, you can arrange with the network
administrator of the remote LAN to do exactly the same thing. For
example, at the Newman Campus end of our WAN link, the
<Literal remap="tt">/etc/ppp/ip-up</Literal> script looks like :-
</Para>
<Para>
<ProgramListing>
#!/bin/bash
#
# Script which handles the routing issues as necessary for pppd
# Only the link to Hedland requires this handling.
#
# When the ppp link comes up, this script is called with the following
# parameters
# $1 the interface name used by pppd (e.g. ppp3)
# $2 the tty device name
# $3 the tty device speed
# $4 the local IP address for the interface
# $5 the remote IP address
# $6 the parameter specified by the 'ipparam' option to pppd
#
case "$5" in
203.18.8.4)
/usr/sbin/sendmail -q
;;
*)
esac
exit 0
</ProgramListing>
</Para>
<Para>
If however you have only a dynamic IP PPP link to your ISP, you need to
get your email from the account on your ISPs machine. This is usually
done using the POP (Post Office Protocol). This process can be handled
using the 'popclient' program - and the ip-up script can automate this
process for you too!
</Para>
<Para>
Simply create a <Literal remap="tt">/etc/ppp/ip-up</Literal> script that contains the
appropriate invocation of popclient. For my laptop that runs Red Hat Linux
(which I take on any travels), this is...
</Para>
<Para>
<ProgramListing>
popclient -3 -c -u hartr -p &#60;password&#62; kepler.hedland.edu.au |formail -s procmail
</ProgramListing>
</Para>
<Para>
You could use slurp or whatever to do the same for news, and so forth.
Remember, the ip-up script is just a standard bash script and so can be
used to automate ANY function that needs to be accomplished every time
the appropriate PPP link comes up.
</Para>
</Sect1>
</Chapter>
<CHAPTER>
<Title>Using <Literal remap="tt">/etc/ppp/ip-down</Literal></Title>
<Para>
You can create a script that will be executed once the
link has been terminated. This is stored in <Literal remap="tt">/etc/ppp/ip-down</Literal>. It can be
used to undo anything special that you did in the corresponding
/etc/ppp/ip-up script.
</Para>
</Chapter>
<CHAPTER>
<Title>Routing issues on a LAN</Title>
<Para>
If you are connected to a LAN but still want to use PPP on your personal
Linux machine , you need to address some issues of the routes packets
need to take from your machine to reach your LAN (through your Ethernet
interface) and also to the remote PPP server and beyond.
</Para>
<Para>
This section does NOT attempt to teach you about routing - it deals only
with a simple, special case of (static) routing!
</Para>
<Para>
I strongly urge you to read the Linux Network Administrator Guide (NAG)
if you are NOT familiar with routing. Also the O'Reilly book "TCP/IP
Network Administration" covers this topic in a very understandable form.
</Para>
<Para>
The basic rule of static routing is that the DEFAULT route should be the
one that points to the MOST number of network addresses. For other
networks, enter specific routes to the routing table.
</Para>
<Para>
The ONLY situation I am going to cover here is where your Linux box is
on a LAN that is not connected to the Internet - and you want to dial
out to the Internet for personal use whilst still connected to the LAN.
</Para>
<Para>
First of all, make sure that your Ethernet route is set up to the
specific network addresses available across your LAN - NOT set to the
default route!
</Para>
<Para>
Check this by issuing a route command, you should see something like the
following:-
</Para>
<Para>
<Screen>
[root@hwin /root]# route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
loopback * 255.255.255.0 U 1936 0 50 lo
10.0.0.0 * 255.255.255.0 U 1436 0 565 eth0
</Screen>
</Para>
<Para>
If your Ethernet interface (eth0) is pointing at the default route, (the
first column will show "default" in the eth0 line) you need to change
your Ethernet initialization scripts to make it point at the specific
network numbers rather than the default route (consult the Net2 HOWTO
and NAG).
</Para>
<Para>
This will allow pppd to set up your default route as shown below:-
</Para>
<Para>
<Screen>
[root@hwin /root]# route -n
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
10.144.153.51 * 255.255.255.255 UH 488 0 0 ppp0
127.0.0.0 * 255.255.255.0 U 1936 0 50 lo
10.1.0.0 * 255.255.255.0 U 1436 0 569 eth0
default 10.144.153.51 * UG 488 0 3 ppp0
</Screen>
</Para>
<Para>
As you can see, we have a host route to the PPP server ( 10.144.153.51)
via ppp0 and also a default network route that uses the PPP server as
its gateway.
</Para>
<Para>
If your set up needs to be more complex than this - read the routing
documents already mentioned and consult an expert at your site!
</Para>
<Para>
If your LAN already has routers on it, you will already have gateways
established to the wider networks available at your site. You should
STILL point your default route at the PPP interface - and make the other
routes specific to the networks they serve.
</Para>
<Sect1>
<Title>Note on Security</Title>
<Para>
When you set up a Linux box on an existing LAN to link into the
Internet, you are potentially opening your entire LAN to the Internet -
and the hackers that reside there. Before you do this, I strongly urge
you to consult your network administrator and site security policy. If
your PPP connection to the Internet is used to successfully attack your
site, you will at the very least earn the intense anger of your fellow
users, network and system administrators. You may also find yourself in
very much more serious trouble!
</Para>
<Para>
Before you connect a LAN to the Internet, you should consider the
security implications of even a DYNAMIC connection - hence the earlier
reference to the O'Reilly "Building Internet Firewalls"!
</Para>
</Sect1>
</Chapter>
<Chapter id="ppp-server">
<Title>Setting up a PPP server</Title>
<Para>
As already mentioned, there are many ways to do this. What I present
here is the way I do it, (using a Cyclades multi-port serial card), and a
rotary dial in set of telephone lines.
</Para>
<Para>
If you don't like the method I present here, please feel free to go your
own way. I would however, be pleased to include additional methods in
future versions of the HOWTO. So, please send me your comments and
methods!
</Para>
<Para>
Please note, this section only concerns setting up Linux as a PPP
server. I do not (ever) intend to include information on setting up
special terminal servers and such.
</Para>
<Para>
Also, I have yet to experiment with shadow passwords (but will be doing
so sometime). Information currently presented does NOT therefore include any
bells and whistles that are required by the shadow suite.
</Para>
<Sect1>
<Title>Kernel compilation</Title>
<Para>
All the earlier comments regarding kernel compilation and kernel
versions versus pppd versions apply. This section assumes that you have
read the earlier sections of this document!
</Para>
<Para>
For a PPP server, you <Emphasis>MUST</Emphasis> include IP forwarding in your kernel.
You may also wish to include other capabilities (such as IP fire walls,
accounting etc etc).
</Para>
<Para>
If you are using a multi-port serial card, then you must obviously
include the necessary drivers in your kernel too!
</Para>
</Sect1>
<Sect1>
<Title>Overview of the server system</Title>
<Para>
We offer dial up PPP (and SLIP) accounts and shell accounts using the
same user name/password pair. This has the advantages (for us) that a
user requires only one account and can use it for all types of
connectivity.
</Para>
<Para>
As we are an educational organization, we do not charge our staff and
students for access, and so do not have to worry about accounting and
charging issues.
</Para>
<Para>
We operate a firewall between our site and the Internet, and this
restricts some user access as the dial up lines are inside our
(Internet) firewall (for fairly obvious reasons, details of our other
internal fire walls are not presented here and are irrelevant in any
case).
</Para>
<Para>
The process a user goes through to establish a PPP link to our site
(once they have a valid account of course) is :-
<ItemizedList>
<ListItem>
<Para>
Dial into our rotary dialer (this is a single phone number that
connects to a bank of modems - the first free modem is then used).
</Para>
</ListItem>
<ListItem>
<Para>
Log in using a valid user name and password pair.
</Para>
</ListItem>
<ListItem>
<Para>
At the shell prompt, issue the command <Literal remap="tt">ppp</Literal> to start PPP on
the server.
</Para>
</ListItem>
<ListItem>
<Para>
Start PPP on their PC (be it running Windows, DOS, Linux MAC OS or
whatever - that is their problem).
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
The server uses individual <Literal remap="tt">/etc/ppp/options.ttyXX</Literal> files for each
dial in port that set the remote IP number for dynamic IP allocation.
The server users proxyarp routing for the remote clients (set via the
appropriate option to pppd). This obviates the need for routed or gated.
</Para>
<Para>
When the user hangs up at their end, pppd detects this and tells the modem
to hang up, bringing down the PPP link at the same time.
</Para>
</Sect1>
<Sect1>
<Title>Getting the software together</Title>
<Para>
You will need the following software:-
<ItemizedList>
<ListItem>
<Para>
Linux, properly compiled to include the necessary options.
</Para>
</ListItem>
<ListItem>
<Para>
The appropriate version of pppd for your kernel.
</Para>
</ListItem>
<ListItem>
<Para>
A 'getty' program that intelligently handles modem
communications.
We use getty&lowbar;ps2.0.7h, but mgetty is highly thought of. I understand
that mgetty can detect a call that is using pap/chap (pap is the
standard for Windows95) and invoke pppd automatically, but I have yet to
explore this.
</Para>
</ListItem>
<ListItem>
<Para>
An operational domain name server (DNS) that is accessible to your
dial up users.
You should really be running your own DNS if possible...
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect1>
<Sect1>
<Title>Setting up standard (shell access) dialup.</Title>
<Para>
Before you can set up your PPP server, your Linux box must be capable of
handling standard dial up access.
</Para>
<Para>
<Emphasis>This howto does NOT cover setting this up. Please see the
documentation of the getty of your choice and serial HOWTO for
information on this.</Emphasis>
</Para>
</Sect1>
<Sect1>
<Title>Setting up the PPP options files</Title>
<Para>
You will need to set up the overall <Literal remap="tt">/etc/ppp/options</Literal> with the
common options for all dial up ports. The options we use are:-
</Para>
<Para>
<ProgramListing>
asyncmap 0
netmask 255.255.254.0
proxyarp
lock
crtscts
modem
</ProgramListing>
</Para>
<Para>
Note - we do NOT use any (obvious) routing - and in particular there is
no defaultroute option. The reason for this is that all you (as a PPP
server) are required to do is to route packets <Emphasis>from</Emphasis> the ppp client
out across your LAN/Internet and route packets <Emphasis>to</Emphasis> the client from
your LAN and beyond.
</Para>
<Para>
All that is necessary for this is a host route to the client machine and
the use of the 'proxyarp' option to pppd.
</Para>
<Para>
The 'proxyarp' option sets up (surprise) a proxy ARP entry in the PPP
server's ARP table that basically says 'send all packets destined for
the PPP client to me'. This is the easiest way to set up routing to a
single PPP client - but you cannot use this if you are routing between
two LANs - you must add proper network routes which can't use proxy ARP.
</Para>
<Para>
You will almost certainly wish to provide dynamic IP number allocation
to your dial up users. You can accomplish this by allocating an IP
number to each dial up port. Now, create a <Literal remap="tt">/etc/ppp/options.ttyXX</Literal>
for each dial up port.
</Para>
<Para>
In this, simply put the local (server) IP number and the IP number that
is to be used for that port. For example
</Para>
<Para>
<ProgramListing>
kepler:slip01
</ProgramListing>
</Para>
<Para>
In particular, note that you can use valid host names in this file (I
find that I only remember the IP numbers of critical machines and
devices on my networks - names are more meaningful)!
</Para>
</Sect1>
<Sect1>
<Title>Setting pppd up to allow users to (successfully) run it</Title>
<Para>
As starting a ppp link implies configuring a kernel device (a network
interface) and manipulating the kernel routing tables, special
privileges are required - in fact full root privileges.
</Para>
<Para>
Fortunately, pppd has been designed to be 'safe' to run set uid to root.
So you will need to...
<ProgramListing>
chmod u+s /usr/sbin/pppd
</ProgramListing>
</Para>
<Para>
When you list the file, it should then appear as...
<ProgramListing>
-rwsr-xr-x 1 root root 74224 Apr 28 07:17 /usr/sbin/pppd
</ProgramListing>
</Para>
<Para>
If you do not do this, users will be unable to set up their ppp link.
</Para>
</Sect1>
<Sect1>
<Title>Setting up the global alias for pppd</Title>
<Para>
In order to simplify things for our dial up PPP users, we create a
global alias (in /etc/bashrc) so that one simple command will start ppp
on the server once they are logged in.
</Para>
<Para>
This looks like...
<ProgramListing>
alias ppp="exec /usr/sbin/pppd -detach"
</ProgramListing>
</Para>
<Para>
What this does is
<ItemizedList>
<ListItem>
<Para>
exec : this means replace the running program (in this case the
shell) with the program that is run.
</Para>
</ListItem>
<ListItem>
<Para>
pppd -detach : start up pppd and do NOT fork into the background.
This ensures that when pppd exits there is no process hanging around.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
When a user logs in like this, they will appear in the output of 'w' as...
<ProgramListing>
6:24pm up 3 days, 7:00, 4 users, load average: 0.05, 0.03, 0.00
User tty login@ idle JCPU PCPU what
hartr ttyC0 3:05am 9:14 -
</ProgramListing>
</Para>
<Para>
And that is it...I told you this was a simple, basic PPP server system!
</Para>
</Sect1>
</Chapter>
<Chapter id="direct">
<Title>Using PPP across a null modem (direct serial) connection</Title>
<Para>
This is very simple - there is no modem in the way so things are much
simpler.
</Para>
<Para>
First of all, choose one of the machines as a 'server', setting up a
getty on the serial port so you can test that you do have connectivity
using minicom to access the serial port on the 'client'.
</Para>
<Para>
Once you have this functioning, you can remove the getty UNLESS you want
to make sure that the connection is validated using user name/password
pairs as for a dial up connection. As you have 'physical control' of
both machines, I will presume that you do NOT want to do this.
</Para>
<Para>
Now, on the server, remove the getty and make sure that you have the serial
ports on both machines configured correctly using 'setserial'.
</Para>
<Para>
All you need to do now is to start pppd on both systems. I will assume
that the connection uses /dev/ttyS34 on both machines. So, on both
machines execute the command:-
</Para>
<Para>
<ProgramListing>
pppd -detach crtscts lock &#60;local IP&#62;:&#60;remote IP&#62; /dev/ttyS3 38400 &#38;
</ProgramListing>
</Para>
<Para>
This will bring up the link - but as yet you have no routing specified.
You can test the link by pinging to and fro to each machine. If this
works, bring down the link by killing one of the pppd processes.
</Para>
<Para>
The routing you need will of course depend on exactly what you are
trying to do. Generally, one of the machines will be connected
to an Ethernet (and beyond) and so the routing required is exactly the
same as for a PPP server and client.
</Para>
<Para>
So on the Ethernet equipped machine, the pppd command would be...
</Para>
<Para>
<ProgramListing>
pppd -detach crtscts lock proxyarp &#60;local IP&#62;:&#60;remote IP&#62; /dev/ttyS3 38400 &#38;
</ProgramListing>
</Para>
<Para>
and on the other machine
...
</Para>
<Para>
<ProgramListing>
pppd -detach crtscts lock defaultroute &#60;local IP&#62;:&#60;remote IP&#62; /dev/ttyS3 38400 &#38;
</ProgramListing>
</Para>
<Para>
If you are linking two networks (using a serial link!) or have more
complex routing requirements, you can use /etc/ppp/ip-up in exactly the
same way as mentioned earlier in this document.
</Para>
</Chapter>
<Chapter><Title>PPPoE or PPP over Ethernet</Title>
<Para>
This document does not currently cover PPoE as it appears to NOT (for Linux anyway) be under active development.
For those who have interest or need of PPPoE we do include the following links.
</Para>
<Para>
We have heard rumors that the 2.4 series of kernels will have PPoE but we are unable to confirm this
at this time. If you know differently please <Ulink URL="mailto:webmaster@linuxports.com">contact us.</Ulink>
</Para>
<ItemizedList>
<ListItem>
<ParA>
<ULink URL="http://www.ecf.toronto.edu/~stras/pppoe.html">
pppoe: a PPP-over-Ethernet redirector for pppd</Ulink>
</Para>
<Para>
This program can be used to enable PPPoE support using the pppd
daemon. PPPoE is a technique for the encapsulation of PPP streams
inside of Ethernet frames. This technology is being deployed by
high-speed Internet access providers (cable modems, xDSL, etc.) in
order to decouple the supply of bandwidth from ISP services. In
particular, in Canada, the Bell Sympatico ADSL service is moving from
DHCP-based access control to PPPoE. Further details on PPPoE can be
found in RFC2516.
</Para>
</ListItem>
<ListItem>
<Para>
<ULink URL="http://www.roaringpenguin.com/pppoe.html">Roaring Penguin PPoE Client.</Ulink>
</Para>
<Para>
The client is a user-mode program and does not require any kernel modifications. It is
fully compliant with RFC 2516, the official PPPoE specification.
</Para>
</ListItem>
<ListItem>
<Para>
<Ulink URL="http://www.carricksolutions.com/pppoe.htm">A PPoE FAQ Page.</Ulink> This
page includes comprehensive information on what PPoE is, what it is used for, and
implementations of the protocol. If you are looking for a good all around resource on
PPoE this is an excellent page to start with.
</Para>
</ListItem>
<ListItem>
<Para>
<Ulink URL="http://www.faqs.org/rfcs/rfc2516.html">The actual RFC.</Ulink> This is for
the technically minded only and usually only of help to those wishing to program with or
for the protocol.
</Para>
</ListItem>
</ItemizedList>
</Chapter>
</BOOK>
View Git Blame Copy Permalink