mirror of https://github.com/tLDP/LDP
4113 lines
145 KiB
Plaintext
4113 lines
145 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<!-- Title information -->
|
|
|
|
<title>Linux PPP HOWTO
|
|
<author>Robert Hart, <tt/hartr@interweft.com.au/
|
|
<date>v3.0, 31 March 1997
|
|
<abstract>
|
|
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.
|
|
|
|
</abstract>
|
|
|
|
<!-- Table of contents -->
|
|
|
|
<toc>
|
|
|
|
<p>
|
|
<bf>Copyright</bf>
|
|
<p>
|
|
This document is distributed under the terms of the GPL (GNU Public
|
|
License).
|
|
|
|
<p>
|
|
<bf>Distribution</bf>
|
|
|
|
<p>
|
|
This document will be posted to comp.os.linux.answers as new versions of
|
|
the document are produced. It is also available in HTML format at:-
|
|
|
|
<itemize>
|
|
<item><url url="http://sunsite.unc.edu/mdw/linux.html#howto"
|
|
name="Linux Howto Index">
|
|
<item><url
|
|
url="http://www.interweft.com.au/other/ppp-howto/ppp-howto.html"
|
|
name="PPP-HOWTO">
|
|
</itemize>
|
|
|
|
<p>
|
|
Other formats (SGML, ASCII, postscript, DVI) are available from <url
|
|
url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/other-formats"
|
|
name="Howtos - other formats">.
|
|
|
|
<p>
|
|
As sunsite.unc.edu carries a very heavy load, please use an appropriate
|
|
mirror site close to you.
|
|
|
|
<p>
|
|
<bf>Acknowledgements</bf>
|
|
|
|
<p>
|
|
A growing number of people have provided me with assistance in preparing
|
|
this document. Special thanks go to Al Longyear for the guidance on PPP
|
|
itself (if there are mistakes here, they are mine not his), Greg Hankins
|
|
(maintainer of the Linux Howto system)and Debi Tackett
|
|
(of MaximumAccess.com) for many helpful suggestions on style, content
|
|
order, logic and clarity of explanations.
|
|
|
|
<p>
|
|
Finally, to the many people who have contacted me by email offering
|
|
comments - my thanks. As with all HOWTO authors, the satisfaction of
|
|
helping is all the payment we receive and it is enough. By writing this
|
|
HOWTO I am repaying in a small way the debt I - and all other Linux
|
|
users - owe to the people who write and maintain our OS of choice.
|
|
|
|
<sect>Introduction
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
One major difference between PPP and an Ethernet connection is of course
|
|
speed - a standard Ethernet connection operates at 10 Mbs (Mega - million bits
|
|
per second) maximum theoretical throughput, whereas an analogue modem
|
|
operates at speeds up to 56 kbps (kilo - thousand bits per second).
|
|
|
|
<p>
|
|
Also, depending on the type of PPP connection, there may be some
|
|
limitations in usage of some applications and services.
|
|
|
|
<sect1>Clients and Servers
|
|
<p>
|
|
PPP is strictly a <bf/peer to peer/ 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 <bf/servers/ and <bf/clients/.
|
|
|
|
<p>
|
|
When you dial into a site to establish a PPP connection, you are a
|
|
<bf/client/. The machine to which you connect is the <bf/server/.
|
|
|
|
<p>
|
|
When you are setting up a Linux box to receive and handle dial in PPP
|
|
connections, you are setting up a PPP <bf/server/.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
This document refers to the machine that initiates the call (that dials
|
|
in) as the <bf/CLIENT/, 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
|
|
<bf/SERVER/.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
The procedure described in this document will allow you to
|
|
establish and automate your Internet connection.
|
|
|
|
<p>
|
|
This document will also give you guidance in setting up your Linux PC as
|
|
a PPP <bf/server/ and in linking two LANs together (with full routing)
|
|
using PPP (this is frequently characterised as establishing a WAN - wide
|
|
area network - link).
|
|
|
|
<sect1>Differences between Linux distributions
|
|
<p>
|
|
There are many different Linux distributions and they all have their own
|
|
idiosyncrasies and ways of doing things.
|
|
|
|
<p>
|
|
In particular, there are two different ways a Linux (and Unix) computer
|
|
actually starts up, configures its interfaces and so forth.
|
|
|
|
<p>
|
|
These are <bf/BSD system initialisation/ and <bf/System V system
|
|
initialisation/. 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!
|
|
|
|
<p>
|
|
Possibly the most widely used distributions are
|
|
|
|
<itemize>
|
|
<item>Slackware<newline>
|
|
which uses BSD style system initialisation
|
|
<item>Red Hat (and its former associate Caldera)<newline>
|
|
which use SysV system initialisation (although in a slightly modified form)
|
|
<item>Debian<newline>
|
|
which uses SysV system initialisation
|
|
</itemize>
|
|
|
|
<p>
|
|
BSD style initialisation typically keeps its initialisation files in
|
|
<tt>/etc/...</tt> and these files are:-
|
|
|
|
<code>
|
|
/etc/rc
|
|
/etc/rc.local
|
|
/etc/rc.serial
|
|
(and possibly other files)
|
|
</code>
|
|
|
|
<p>
|
|
Of recent times, some BSD system initialisation schemes use a <tt>/etc/rc.d...</tt>
|
|
directory to hold the start up file rather than putting everything into <tt>/etc</tt>.
|
|
|
|
<p>
|
|
|
|
System V initialisation keeps its initialisation files in directories under
|
|
<tt>/etc/...</tt> or <tt>/etc/rc.d/...</tt> and a number of
|
|
subdirectories under there:-
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Distribution specific PPP configuration tools
|
|
<p>
|
|
On some installations (for example Red Hat and Caldera), there is a X
|
|
Windows configured PPP dial up system. This HOWTO does not cover these
|
|
distribution specific tools. If you are having problems with them,
|
|
contact the distributors directly!
|
|
|
|
<p>
|
|
|
|
For Red Hat 4.x users, there is now a <url url="http://www.interweft.com.au"
|
|
name="Red Hat PPP-TIP"> in the Linux resources area and also from <url
|
|
url="http://www.redhat.com" name="Red Hat Software"> in the support
|
|
area.
|
|
|
|
<sect>IP Numbers
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If you are connecting a local area network (LAN) to the Internet,
|
|
<bf/YOU MUST/ use an IP number from your own assigned network range for
|
|
all the computers and devices you have on your LAN. You <bf/MUST NOT/
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
There are IP numbers that are specifically dedicated to LANs that do not
|
|
connect to the Internet. The IP number sequences are:-
|
|
|
|
<itemize>
|
|
<item>One A Class Network Address<newline>
|
|
10.0.0.0 (netmask 255.0.0.0)
|
|
<item>16 B Class Network Addresses<newline>
|
|
172.16.0.0 - 172.31.0.0 (netmask 255.255.0.0)
|
|
<item>256 C Class Network Addresses<newline>
|
|
192.168.0.0 - 192.168.255.0 (netmask 255.255.255.0)
|
|
</itemize>
|
|
|
|
<p>
|
|
If you have a LAN for which you have <bf/not/ 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.
|
|
|
|
<p>
|
|
These numbers should <bf/never/ be used on the Internet.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
For more information on how to do this see the IP Masquerade mini-HOWTO
|
|
at <url url="http://sunsite.unc.edu/mdw/HOWTO/mini/IP-Masquerade"
|
|
name="Linux IP Masquerade mini HOWTO">
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
For users, who are connecting a single PC to the Internet via an ISP,
|
|
most providers use <bf/dynamic/ 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.
|
|
|
|
<p>
|
|
With dynamic IP numbers, you are <bf/not/ 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).
|
|
|
|
<p>
|
|
The limitations of service due to dynamic IP number assignment (and ways
|
|
to work around these, where possible) are discussed later in the
|
|
document.
|
|
|
|
<sect>Aims of this Document
|
|
<sect1>Setting up a PPP Client
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Instead, this document describes the standard Linux PPP software
|
|
(chat/pppd).
|
|
|
|
<sect1>Linking two LANs or a LAN to the Internet using PPP
|
|
<p>
|
|
This document provides (basic) information on linking two LANs or a LAN
|
|
to the Internet using PPP.
|
|
|
|
<sect1>Setting up a PPP server
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
This method is known to work well. However, it is not necessarily
|
|
the best method.
|
|
|
|
<sect1>Using PPP over a direct null modem connection
|
|
<p>
|
|
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.
|
|
|
|
<sect1>This document at present does NOT cover...
|
|
<p>
|
|
<itemize>
|
|
<item>Compiling the PPP daemon software<newline>
|
|
See the documentation that comes with the version of pppd you are using.
|
|
|
|
<item>Connecting and configuring a modem to Linux (in detail)<newline>
|
|
See the Serial-HOWTO and for modem specific initialisation, see <url
|
|
url="http://www.in.net/info/modems/index.html" name="Modem Setup
|
|
Information"> for information that may help you to configure your modem.
|
|
|
|
<item>Using DIP to make PPP connections<newline>
|
|
Use chat instead...
|
|
|
|
<item>Using socks or IP Masquerade<newline>
|
|
There are perfectly good documents already covering these two packages.
|
|
|
|
<item>Using <tt/diald/ to set up an automated connection<newline>
|
|
See the <tt/diald/ documentation for information on this.
|
|
|
|
<item>Using EQL to gang together two modems into a single PPP link.
|
|
|
|
<item>Distribution specific PPP connection methods (such as the Red Hat
|
|
4.x network configuration tool.<newline>
|
|
See the distribution for documentation on the methods used.
|
|
|
|
<item>The growing number of tools available to automate PPP set
|
|
up<newline>
|
|
See the appropriate documentation.
|
|
</itemize>
|
|
|
|
<sect>Software versions covered
|
|
<p>
|
|
This HOWTO assumes that you are using a Linux 1.2.x kernel with the PPP
|
|
2.1.2 software or Linux 1.3.X/2.0.x and PPP 2.2.
|
|
|
|
<p>
|
|
At the time of writing, the latest official version of PPP available for
|
|
Linux is ppp-2.2f. The new version (ppp-2.3) is still in beta.
|
|
|
|
<p>
|
|
It is possible to use PPP 2.2.0 with kernel 1.2.13. This requires
|
|
kernel patches. It is recommended that version 1.2.13 kernel users move
|
|
up to ppp-2.2 as it includes several bug fixes and enhancements.
|
|
|
|
<p>
|
|
<bf/Also, you should particularly note that you cannot use the PPP 2.1.2
|
|
software with Linux kernel version 2.0.X./
|
|
|
|
<p>
|
|
Please note that this document does <bf/NOT/ cover problems arising from
|
|
the use of loadable modules for Linux kernel 2.0.x. Please see the
|
|
kerneld mini-HOWTO and the kernel/module 2.0.x documentation (in the
|
|
Linux 2.0.x source tree at <tt>/usr/src/linux/Documentation/...</tt>).
|
|
|
|
<p>
|
|
<bf>As this document is designed to assist new users, it is highly
|
|
recommended that you use a version of the Linux kernel and the appropriate PPP
|
|
version that are known to be stable together.</bf>
|
|
|
|
<sect>Other Useful/Important Documents
|
|
<p>
|
|
Users are advised to read :-
|
|
<itemize>
|
|
<item>the documentation that comes with the PPP package;
|
|
<item>the pppd and chat man pages;<newline>
|
|
(use <tt/man chat/ and <tt/man pppd/ to explore these)
|
|
<item>the Linux Network Administration Guide (NAG);<newline>
|
|
see <url url="http://sunsite.unc.edu/mdw/LDP-books/nag-1.0/nag.html"
|
|
name="The Network Administrators' Guide">
|
|
<item>the Net-2/3 HOWTO;<newline>
|
|
see <url url="http://sunsite.unc.edu/mdw/HOWTO/NET-2-HOWTO.html" name="Linux
|
|
NET-2/3-HOWTO">
|
|
<item>Linux kernel documentation installed in
|
|
<tt>/usr/src/linux/Documentation</tt> when you install the Linux source
|
|
code;
|
|
<item>The modem setup information page - see <url
|
|
url="http://www.in.net/info/modems/index.html" name="Modem Setup
|
|
Information">
|
|
<item>The excellent Unix/Linux books published by O'Reilly and
|
|
Associates. See (<url url=" http://www.ora.com/" name="O'Reilly and
|
|
Associates On-Line Catalogue">). If you are new
|
|
to Unix/Linux, <bf/run/ (don't walk) to your nearest computer book shop
|
|
and invest in a number of these immediately!
|
|
<item>The PPP-FAQ maintained by Al Longyear, available from <url
|
|
url="ftp://sunsite.unc.edu/pub/Linux/docs/faqs" name="Linux
|
|
PPP-FAQ">.<newline>
|
|
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).
|
|
<item>The growing number of Linux books from various publishing houses and
|
|
authors;<newline>
|
|
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.
|
|
</itemize>
|
|
|
|
<p>
|
|
The best general starting point for Linux documentation is <url
|
|
url="http://sunsite.unc.edu/mdw/" name="The Linux Documentation Project
|
|
Home Page">. The HOWTO's tend to be revised reasonably regularly.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
These documents (as well as various others, including the relevant RFCs)
|
|
provide additional and more detailed explanation than is possible in
|
|
this HOWTO.
|
|
|
|
<p>
|
|
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 <tt>&dquot;</tt>TCP/IP
|
|
Network Administration<tt>&dquot;</tt> and <tt>&dquot;</tt>Building
|
|
Internet Firewalls<tt>&dquot;</tt> of considerable benefit!
|
|
|
|
<sect1>Useful Linux Mailing Lists
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
<bf/A word to the wise/: 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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
By all means join the lists that offer open subscription, but keep your
|
|
comments relevant to the subject of the list!
|
|
|
|
<p>
|
|
A good starting point for Linux mailing lists is
|
|
<url url="http://summer.snu.ac.kr/~djshin/linux/mail-list/index.shtml"
|
|
name="Linux Mailing List Directory">
|
|
|
|
<sect>Overview of what has to be done to get PPP working as a client
|
|
<p>
|
|
This document contains a great deal of information - and with each
|
|
version it grows!
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
<sect1>Obtaining/Installing the software
|
|
<p>
|
|
If your Linux distribution does not include the PPP software, you will
|
|
need to obtain this from <url
|
|
url="ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/ppp/ppp-2.2.0f.tar.gz"
|
|
name="the Linux PPP daemon">.
|
|
|
|
<p>
|
|
This is the latest official version at the time of writing. However,
|
|
choose the latest version available from this site (ppp-2.3 is in beta
|
|
at the time of writing and should be released soon).
|
|
|
|
<p>
|
|
The PPP package contains instructions on how to compile and install the
|
|
software <bf/so this HOWTO does not/!
|
|
|
|
<sect1>Compiling PPP support into the kernel
|
|
<p>
|
|
Linux PPP operations come in two parts
|
|
<itemize>
|
|
<item>the PPP daemon mentioned above
|
|
<item>kernel support for PPP
|
|
</itemize>
|
|
|
|
<p>
|
|
Many distributions seem to provide PPP kernel support in their default
|
|
installation kernels, but others do not.
|
|
|
|
<p>
|
|
If at boot your kernel reports messages like
|
|
|
|
<code>
|
|
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
|
|
PPP line discipline registered.
|
|
</code>
|
|
|
|
<p>
|
|
your kernel does have PPP support compiled in.
|
|
|
|
<p>
|
|
That said, you will probably 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.
|
|
|
|
<p>
|
|
This document provides minimal kernel re-compilation instructions at
|
|
section <ref id="Kernel configuration" name="Configuring your Linux Kernel">.
|
|
|
|
<p>
|
|
For greater detail, see the Kernel-HOWTO at <url
|
|
url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html" name="The Linux
|
|
Kernel HOWTO">
|
|
|
|
<sect1>Obtaining information from your ISP
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Section <ref id="Server info" name="Getting the Information you need about
|
|
the PPP server"> 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.
|
|
|
|
<sect1>Configuring your modem and serial port
|
|
<p>
|
|
In order to connect to a PPP server and to obtain the best possible
|
|
data transfer rate, your modem needs to be configured correctly.
|
|
|
|
<p>
|
|
Similarly, the serial ports on your modem and computer need to be set up
|
|
correctly.
|
|
|
|
<p>
|
|
Section <ref id="Modem" name="Configuring your modem and serial port">
|
|
provides information on this.
|
|
|
|
<sect1>Setting up Name to Address Resolution (DNS)
|
|
<p>
|
|
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
|
|
<tt/www.interweft.com.au/ to the IP address that is actually used to
|
|
contact that computer. These are:-
|
|
|
|
<itemize>
|
|
<item><tt>/etc/resolv.conf</tt>
|
|
<item><tt>/etc/host.conf</tt>
|
|
</itemize>
|
|
|
|
<p>
|
|
Section <ref id="DNS" name="Setting up Name to Address Resolution">
|
|
for details on setting this up.
|
|
|
|
<p>
|
|
In particular, you do <bf/NOT/ 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).
|
|
|
|
<sect1>PPP and root Privileges
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
For details on this, see section <ref id="root" name="Using PPP and root privileges">.
|
|
|
|
<sect1>Checking your distribution PPP Files and setting up the PPP Options
|
|
<p>
|
|
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:-
|
|
|
|
<code>
|
|
/etc/ppp/options
|
|
/etc/ppp/scripts/ppp-on
|
|
/etc/ppp/scripts/ppp-on-dialer
|
|
/etc/ppp/options.tpl
|
|
</code>
|
|
|
|
<p>
|
|
You may need to create some additional files depending on exactly what
|
|
you are aiming to achieve with PPP:-
|
|
|
|
<code>
|
|
/etc/ppp/options.ttyXX
|
|
/etc/ppp/ip-up
|
|
/etc/ppp/pap-secrets
|
|
/etc/ppp/chap-secrets
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p> For details on this, see <ref id="options" name="Setting up the PPP
|
|
connection files">.
|
|
|
|
<sect1>If your PPP server uses PAP (Password Authentication Protocol)
|
|
<p>
|
|
Many ISPs and corporate PPP servers use PAP. If your server does
|
|
<bf/not/ 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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Section <ref id="pap" name="If your PPP server uses PAP (Password Authentication
|
|
Protocol)"> provides information on the files you need to set up to
|
|
establish a PPP link using PAP.
|
|
|
|
<sect1>Connecting to the PPP server by hand
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
See Section <ref id="manual" name="Setting up the PPP connection manually"> for
|
|
full details of setting this up.
|
|
|
|
<sect1>Automating your PPP Connection
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Section <ref id="automate" name="Automating your connections - Creating the
|
|
connection scripts"> covers setting up the necessary scripts, with
|
|
considerable attention paid to <tt/chat/ and scripting the login process
|
|
to the PPP server.
|
|
|
|
<p>
|
|
This section discusses scripts for user name/password authentication as
|
|
well as scripts for PAP/CHAP authenticating servers.
|
|
|
|
<sect1>Shutting down the link
|
|
<p>
|
|
Once your link is up and working, you need to be able to deactivate the
|
|
link.
|
|
|
|
<p>
|
|
This is covered in Section <ref id="off" name="Shutting down the PPP link">.
|
|
|
|
<sect1>If you have problems
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
Section <ref id="problems" name="Fixing problems"> provides some basic
|
|
information about common errors, how to isolate these and fix them.
|
|
|
|
<p>
|
|
This is <bf/NOT/ intended to provide more than just the basics. Al
|
|
Longyear maintains the PPP-FAQ which contains much more information on
|
|
this topic!
|
|
|
|
<sect1>After the link comes up
|
|
<p>
|
|
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 <bf/any/ function you can write a script to accomplish.
|
|
|
|
<p>
|
|
Section <ref id="ip-up" name="After the link comes up"> provides information on the
|
|
<tt>/etc/ppp/ip-up</tt> 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.
|
|
|
|
<sect1>Problems with standard IP services on a Dynamic IP number PPP link
|
|
<p>
|
|
As noted in the introduction, dynamic IP numbers affect the
|
|
ability of your Linux PC to act as a server on the Internet.
|
|
|
|
<p>
|
|
Section <ref id="dynamic-server" name="Problems with standard IP services on a
|
|
Dynamic IP number PPP link"> provides information on the (main) services
|
|
affected and what you can do (if anything) to overcome this.
|
|
|
|
<sect>Configuring your Linux Kernel<label id="Kernel configuration">
|
|
<p>
|
|
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 <tt>/usr/src/linux</tt> on Linux's standard
|
|
file system.
|
|
|
|
<p>
|
|
Check out this directory - many Linux distributions install the source
|
|
tree (the files and subdirectories) as part of their installation process.
|
|
|
|
<p>
|
|
At bootup, your Linux kernel prints out a great deal of information.
|
|
Amongst this is information about PPP support if the kernel includes
|
|
this. To view this information, look at your syslog file or use <tt/dmesg |
|
|
less/ to display the information to the screen. If your kernel includes
|
|
PPP support, you will see lines like
|
|
|
|
<code>
|
|
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
|
|
PPP line discipline registered.
|
|
</code>
|
|
|
|
<p>
|
|
(this is for the Linux 2.0.x kernel series).
|
|
|
|
<p>
|
|
Linux kernel sources can be obtained by ftp from <tt/sunsite.unc.edu/ or its
|
|
mirror sites.
|
|
|
|
<sect1>Installing the Linux Kernel source
|
|
<p>
|
|
The following are brief instructions for obtaining and installing the
|
|
Linux kernel sources. Full information can be obtained from <url
|
|
url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html" name="The Linux
|
|
Kernel HOWTO">.
|
|
|
|
<p>
|
|
In order to install and compile the Linux kernel, you need to be logged
|
|
in as root.
|
|
|
|
<enum>
|
|
<item>Change directory to the <tt>/usr/src</tt> directory<newline>
|
|
<tt>cd /usr/src</tt>
|
|
<item>Check in <tt>/usr/src/linux</tt> to see if you already have the
|
|
sources installed.
|
|
<item>If you don't have the sources, get them from <url
|
|
url="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0" name="Linux kernel
|
|
source directory"> or your nearest mirror.<newline>
|
|
If you are looking for earlier versions of the kernel (such as 1.2.X),
|
|
these are kept in <url url="ftp://sunsite.unc.edu/pub/Linux/kernel/old"
|
|
name="Old Linux kernel source directory">.
|
|
<item>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 <tt>/usr/src</tt>.<newline>
|
|
<bf/Note/: 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.
|
|
|
|
<item>If you already have the Linux sources installed but are upgrading
|
|
to a new kernel, you must remove the old sources. Use the
|
|
command<newline>
|
|
<tt>rm -rf /usr/src/linux</tt>
|
|
<item>Now uncompress and extract the sources using the command<newline>
|
|
<tt>tar xzf linux-2.0.XX.tar.gz</tt>
|
|
<item>Now, <tt>cd /usr/src/linux</tt> 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).
|
|
</enum>
|
|
|
|
<sect1>Knowing your hardware
|
|
<p>
|
|
You <bf/MUST/ 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).
|
|
|
|
<sect1>Kernel compilation - the Linux 1.2.13 kernel
|
|
<p>
|
|
To start the configuration process, follow the instructions in the
|
|
README file to properly install the sources. You start the kernel
|
|
configuration process with
|
|
|
|
<tscreen><verb>make config</verb></tscreen>
|
|
|
|
<p>
|
|
In order to use PPP, you must configure the kernel to include PPP
|
|
support (PPP requires BOTH pppd AND kernel support for PPP).
|
|
|
|
<code>
|
|
PPP (point-to-point) support (CONFIG_PPP) [n] y
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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 <tt/make config/ dialogue, exit by typing CTRL C and start again.
|
|
|
|
<sect1>Kernel compilation - the Linux 1.3.x and 2.0.x kernels
|
|
<p>
|
|
For Linux 1.3.x and 2.0.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
|
|
|
|
<tscreen><verb>make config</verb></tscreen>
|
|
|
|
<p>
|
|
However, you also have the choice of
|
|
<tscreen><verb>make menuconfig</verb></tscreen>
|
|
|
|
<p>
|
|
This provides a menu based configuration system with online help that
|
|
allows you to move backwards and forwards in the configuration process.
|
|
|
|
<p>
|
|
There is also a highly recommended X windows based configuration interface
|
|
<tscreen><verb>make xconfig</verb></tscreen>
|
|
|
|
<p>
|
|
You can compile PPP support directly into your kernel or as a
|
|
loadable module.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
To do this, you need to enable loadable module support:-
|
|
<code>
|
|
Enable loadable module support (CONFIG_MODULES) [Y/n/?] y
|
|
</code>
|
|
|
|
To add PPP kernel support, answer the following question:-
|
|
<code>
|
|
PPP (point-to-point) support (CONFIG_PPP) [M/n/y/?]
|
|
</code>
|
|
|
|
<p>
|
|
For a PPP loadable module, answer <bf/M/, otherwise for PPP compiled in as
|
|
part of the kernel, answer <bf/Y/.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Note on PPP-2.2 and <tt>/proc/net/dev</tt>
|
|
<p>
|
|
If you are using PPP-2.2, 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 <tt>/proc/net</tt> file system until a device is created by
|
|
starting up pppd:-
|
|
|
|
<code>
|
|
[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
|
|
</code>
|
|
|
|
<p>
|
|
Once you have one (or more) ppp services started, you will see entries
|
|
such as this (from a ppp server):-
|
|
|
|
<code>
|
|
[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
|
|
</code>
|
|
|
|
<sect1>General kernel config considerations for PPP
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
To enable IP Masquerade and IP fire walling, you <bf/MUST/ answer yes to the
|
|
first question in the <tt/make config/ process:-
|
|
<code>
|
|
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL)?
|
|
</code>
|
|
|
|
<p>
|
|
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.XX kernel with no problems.
|
|
|
|
<p>
|
|
Once you have installed and rebooted your new kernel, you can start
|
|
configuring and testing your PPP link(s).
|
|
|
|
<sect>Getting the Information you need about the PPP server<label
|
|
id="Server info">
|
|
<p>
|
|
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):-
|
|
<itemize>
|
|
<item>The telephone number(s) to dial for the service<newline>
|
|
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).
|
|
|
|
<item> Does the server use DYNAMIC or STATIC IP numbers?<newline>
|
|
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).<newline>
|
|
|
|
Most Internet Service Providers use DYNAMIC IP numbers. As mentioned
|
|
above, this has some implications in terms of the services you can
|
|
use.<newline>
|
|
|
|
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 <bf/do/ still need to know this information!
|
|
|
|
<item>What are the IP numbers of the ISPs Domain Name Servers?<newline>
|
|
There should be at least two although only one is needed.<newline>
|
|
|
|
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 you
|
|
don't need the IP address of the DNS server(s).<newline>
|
|
|
|
For Linux, you <bf/DO/ 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.<newline>
|
|
|
|
<bf/Note/: 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 <tt/dns-addr/ pppd option.
|
|
|
|
<item>Does the server require the use of PAP/CHAP?<newline>
|
|
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).
|
|
|
|
<item>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?<newline>
|
|
If you must issue a command to start PPP, what is it?
|
|
|
|
<item>Is the server a Microsoft Windows NT system and, if so, is it
|
|
using the MS PAP/CHAP system?<newline>
|
|
Many corporate LANs seem to use MS Windows NT this way for increased security.
|
|
</itemize>
|
|
|
|
<p>
|
|
Carefully note down this information - you are going to use it!
|
|
|
|
<sect>Configuring your modem and serial port<label id="Modem">
|
|
<p>
|
|
You should make sure that your modem is correctly set up and that you
|
|
know which serial port it is connected to.
|
|
|
|
<p>
|
|
<bf>Remember</bf>:-
|
|
<itemize>
|
|
<item>DOS com1: = Linux /dev/cua0 (and /dev/ttyS0)
|
|
<item>DOS com2: = Linux /dev/cua1 (and /dev/ttyS1)<newline>
|
|
et cetera
|
|
</itemize>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If you are running Linux kernel 2, you can check the in-use IRQs using
|
|
<tt>cat /proc/interrupts</tt>, which will produce output like
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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
|
|
<tt/setserial/ and is best done as part of the boot process in
|
|
<tt/rc.local/ or <tt/rc.serial/ which is called from <tt/rc.local/ or as
|
|
part of the SysV initialisation. For the machine illustrated above, the
|
|
commands used are
|
|
<code>
|
|
/bin/setserial -b /dev/ttyS2 IRQ 11
|
|
/bin/setserial -b /dev/ttyS3 IRQ 15
|
|
</code>
|
|
|
|
<p>
|
|
However, if you are using serial modules dynamically loaded when
|
|
required by the <tt/kerneld/ process, you cannot set and forget the IRQ
|
|
etc once at boot time. This is because if the serial module is unloaded,
|
|
Linux forgets the special settings.
|
|
|
|
<p>
|
|
So, if you are loading the serial module on demand, you will need to
|
|
reconfigure the IRQs etc each time the module is loaded.
|
|
|
|
<sect1>A note about serial ports and speed capabilities
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Use the command
|
|
<tscreen><verb>setserial -a /dev/ttySx</verb></tscreen>
|
|
|
|
<p>
|
|
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 $50). When you purchase a new card, make sure you can
|
|
move the IRQs around on it!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Serial Port Names
|
|
<p>
|
|
Historically, Linux used <tt/cuaX/ devices for dial out and <tt/ttySx/
|
|
devices for dial in.
|
|
|
|
<p>
|
|
The kernel code that required this was changed in kernel version 2.0.x
|
|
and you should now use <tt/ttySx/ for both dial in and dial out. I
|
|
understand that the <tt/cuaX/ device names may well disappear in future
|
|
kernel versions.
|
|
|
|
<sect1>Configuring your modem
|
|
<p>
|
|
You will need to configure your modem correctly for PPP - to do this <bf/READ
|
|
YOUR MODEM MANUAL/! Most modems come with a <bf>factory default setting</bf>
|
|
that selects the options required for PPP. The minimum configuration
|
|
specifies:-
|
|
<itemize>
|
|
<item>Hardware flow control (RTS/CTS) (<tt>&</tt>K3 on many Hayes modems)
|
|
</itemize>
|
|
<p>
|
|
Other settings (in standard Hayes commands) you should investigate are:-
|
|
<itemize>
|
|
<item>E1 Command/usr/src/linux-2.0.27/include/linux/serial.h Echo ON (required for chat to operate)
|
|
<item>Q0 Report result codes (required for chat to operate)
|
|
<item>S0=0 Auto Answer OFF (unless you want your modem to answer the phone)
|
|
<item><tt>&</tt>C1 Carrier Detect ON only after connect
|
|
<item><tt>&</tt>S0 Data Set Ready (DSR) always ON
|
|
<item>(depends) Data Terminal Ready
|
|
</itemize>
|
|
|
|
<p>
|
|
There is a site offering modem setups for a growing variety of modem
|
|
makes and models at <url url="http://www.in.net/info/modems/index.html"
|
|
name="Modem setup information"> which may assist you in this.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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<tt>&</tt>V, but you should consult your modem manual.
|
|
|
|
<p>
|
|
If you completely mess up the settings, you can return to sanity
|
|
(usually) by issuing an AT<tt>&</tt>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).
|
|
|
|
<p>
|
|
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. Alternatively you can pass the correct settings to your
|
|
modem as part of the PPP dialing process.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<sect1>Note on Serial Flow Control
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
There are two ways of doing this on serial lines:-
|
|
<itemize>
|
|
<item>Using hardware signals (Clear To Send/Request to Send - CTS/RTS)
|
|
<item>Using software signals (control S and control Q, also known as XON/XOFF).
|
|
</itemize>
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Testing your modem for dial out
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
(Note: at this stage we are <bf/NOT/ trying to make a PPP connection
|
|
- just establishing that we have the right phone number and also to find
|
|
out <bf/exactly/ what the server sends to us in order to get logged in and
|
|
start PPP).
|
|
|
|
<p>
|
|
During this process, either capture (log to a file) the entire login
|
|
process or carefully (<em/very carefully/) write down <bf/exactly/ 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).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
A few words of warning:-
|
|
|
|
<itemize>
|
|
<item>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.
|
|
<item>some servers require you to enter some text initially and <em/then/
|
|
start a standard PAP sequence.
|
|
<item>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!
|
|
<item>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!
|
|
</itemize>
|
|
|
|
<p>
|
|
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:-
|
|
<itemize>
|
|
<item>the prompt that requests you to enter your user name;
|
|
<item>the prompt that requests you to enter your password;
|
|
</itemize>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
This should look something like this :-
|
|
|
|
<code>
|
|
~y}#.!}!}!} }8}!}$}%U}"}&} } } } }%}& ...}'}"}(}"} .~~y}
|
|
</code>
|
|
|
|
<p>
|
|
(and it just keeps on coming!)
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If you do not see this immediately after connecting (and logging in and
|
|
starting the PPP server if required), press <bf/Enter/ to see if this
|
|
starts the PPP server...
|
|
|
|
<p>
|
|
At this point, you can hang up your modem (usually, type <tt>+++</tt>
|
|
quickly and then issue the ATHO command once your modem responds with
|
|
OK).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect>Setting up Name to Address Resolution (DNS)<label id="DNS">
|
|
<p>
|
|
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 <tt>&dquot;</tt>domain<tt>&dquot;</tt>. For example, my
|
|
Linux workstation is called <bf>archenland</bf> and it resides in the
|
|
<bf>interweft.com.au</bf> domain. Its human readable address is thus
|
|
archenland.interweft.com.au (which is known as the FQDN - fully
|
|
qualified domain name).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
What happens is this:-
|
|
|
|
<itemize>
|
|
<item> 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;
|
|
|
|
<item>
|
|
the resolver queries the local host file (<tt>/etc/hosts</tt>
|
|
and/or the domain name servers it knows about (the exact behaviour of
|
|
the resolver is determined by <tt>/etc/host.conf</tt>);
|
|
|
|
<item>if the answer is found in the host file, this answer is returned;
|
|
|
|
<item>if a domain name server is specified, your PC queries this
|
|
machine;
|
|
|
|
<item>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.
|
|
</itemize>
|
|
|
|
<p>
|
|
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 <bf/you/ can use the machine names but your <bf/computer/ can
|
|
translate these to the IP numbers it needs to do its work.
|
|
|
|
<p>
|
|
One way is to enter every host that you want to talk to into the
|
|
<tt>/etc/hosts</tt> 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).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>The <tt>/etc/resolv.conf</tt> file
|
|
<p>
|
|
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).
|
|
|
|
<p>As previously mentioned, Linux cannot set its name server IP number
|
|
in the way that MS Windows 95 does. So you must <bf/insist/ (politely) that
|
|
your ISP provide you with this information!
|
|
|
|
<p>
|
|
Your <tt>/etc/resolv.conf</tt> should look something like :-
|
|
|
|
<code>
|
|
domain your.isp.domain.name
|
|
nameserver 10.25.0.1
|
|
nameserver 10.25.1.2
|
|
</code>
|
|
|
|
<p>
|
|
Edit this file (creating it if necessary) to represent the information
|
|
that your ISP has provided. It should have ownership and permissions as
|
|
follows :-
|
|
|
|
<tscreen><verb>
|
|
-rw-r--r-- 1 root root 73 Feb 19 01:46 /etc/resolv.conf
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
If you have already set up a <tt>/etc/resolv.conf</tt> because you are on a
|
|
LAN, simply add the IP numbers of the PPP DNS servers to your
|
|
existing file.
|
|
|
|
<sect1>The <tt>/etc/host.conf</tt> file
|
|
<p>
|
|
You should also check that your <tt>/etc/host.conf</tt> file is
|
|
correctly set up. This should look like
|
|
<code>
|
|
order hosts,bind
|
|
multi on
|
|
</code>
|
|
|
|
<p>
|
|
This tells the resolver to use information in the host file before it
|
|
sends queries to the DNS for resolution.
|
|
|
|
<sect>Using PPP and root privileges<label id="root">
|
|
<p>
|
|
Because PPP needs to set up networking devices, change the kernel
|
|
routing table and so forth, it requires root privileges to do this.
|
|
|
|
<p> If users other than root are to set up PPP connections, the pppd
|
|
program should be setuid root :-
|
|
|
|
<tscreen><verb>-rwsr-xr-x 1 root root 95225 Jul 11 00:27 /usr/sbin/pppd</verb></tscreen>
|
|
|
|
<p>
|
|
If /usr/sbin/pppd is not set up this way, then <bf>as root</bf> issue
|
|
the command:-
|
|
|
|
<p>
|
|
<tscreen><verb>chmod u+s /usr/sbin/pppd</verb></tscreen>
|
|
|
|
<p>
|
|
What this does is make pppd run with root privileges <bf/even/ 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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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 :-
|
|
<itemize>
|
|
|
|
<item>Make pppd suid root, owned by user root and group PPP, with the 'other'
|
|
permissions on this file empty. It should then look like
|
|
<tscreen><verb>-rwsr-x--- 1 root PPP 95225 Jul 11 00:27 /usr/sbin/pppd</verb></tscreen>
|
|
|
|
<item>Make the ppp-on/off scripts owned by user root and group PPP
|
|
|
|
<item>Make the ppp-on/off scripts read/executable by group PPP
|
|
<tscreen><verb>
|
|
-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
|
|
</verb></tscreen>
|
|
|
|
<item>Make the other access rights for ppp-on/off nill.
|
|
|
|
<item>add the users who will be firing up PPP to the PPP group in /etc/group
|
|
</itemize>
|
|
|
|
<p>
|
|
Even if you do this, ordinary users will STILL not be able to shut down
|
|
the link under software control! Running the <tt/ppp-off/ script
|
|
requires root privileges. However, any user can just turn off the modem
|
|
(or disconnect the telephone line from an internal modem).
|
|
|
|
<p>
|
|
An alternative (and better method) to this set up is to use the
|
|
<tt/sudo/ 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 <tt/sudo/ will allow an authorised user to
|
|
activate/deactivate the PPP link cleanly and securely.
|
|
|
|
<sect>Setting up the PPP connection files<label id="options">
|
|
<p>
|
|
You now need to be logged in as <bf/root/ to create the directories and
|
|
edit the files needed to set up PPP, even if you want PPP to be
|
|
accessible to all users.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
For PPP 2.1.2 the files are:-
|
|
|
|
<code>
|
|
/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
|
|
</code>
|
|
|
|
<p>
|
|
For PPP 2.2 the files are:-
|
|
|
|
<code>
|
|
/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
|
|
</code>
|
|
|
|
<p>
|
|
Red Hat Linux users should note that the standard Red Hat 4.X installation
|
|
places these scripts in <tt>/usr/doc/ppp-2.2.0f-2/scripts</tt>.
|
|
|
|
<p>
|
|
In your /etc directory there should be a ppp directory:-
|
|
|
|
<tscreen><verb>
|
|
drwxrwxr-x 2 root root 1024 Oct 9 11:01 ppp
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
If it does not exist - create it with these ownerships and permissions.
|
|
|
|
<p>
|
|
If the directory already existed, it should contain a template options
|
|
file called <bf>options.tpl</bf>. This file is included below in case it
|
|
does not.
|
|
|
|
<p>
|
|
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
|
|
<tt>/etc/ppp/options</tt> 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.
|
|
|
|
<p>
|
|
If you have multiple serial lines/modems (typically the case for PPP
|
|
servers), create a general <tt>/etc/ppp/options</tt> 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.
|
|
|
|
<p>
|
|
These port specific option files are named <tt/options.ttyx1/,
|
|
<tt/options.ttyx2/ and so forth (where x is the appropriate letter for
|
|
your serial ports).
|
|
|
|
<p>
|
|
However, for a single PPP connection, you can happily use the
|
|
<tt>/etc/ppp/options</tt> file. Alternatively, you can put all the
|
|
options as arguments in the pppd command itself.
|
|
|
|
<p>
|
|
It is easier to maintain a setup that uses
|
|
<tt>/etc/ppp/options.ttySx</tt> files. If you use PPP to connect to a
|
|
number of different sites, you can create option files for each site in
|
|
<tt>/etc/ppp/options.site</tt> and then specify the option file as a
|
|
parameter to the PPP command as you connect (using the <tt/file
|
|
option-file/ pppd option to pppd on the command line).
|
|
|
|
<sect1>The supplied options.tpl file
|
|
<p>
|
|
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 <tt>/etc/ppp/options</tt> 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.
|
|
|
|
<code>
|
|
# /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 <n> for negotiation. pppd
|
|
# will ask the peer to send packets of no more than <n> bytes. The
|
|
# minimum MRU value is 128. The default MRU value is 1500. A value of
|
|
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
|
|
# bytes of data).
|
|
#mru 542
|
|
|
|
# Set the interface netmask to <n>, 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 <d> 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 <d>
|
|
|
|
# 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 <n>. 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 <n>
|
|
|
|
# Set the name of the local system for authentication purposes to <n>.
|
|
# This will probably have to be set to your ISP user name if you are
|
|
# using PAP/CHAP.
|
|
#name <n>
|
|
|
|
# Set the user name to use for authenticating this machine with the peer
|
|
# using PAP to <u>.
|
|
# Do NOT use this if you are using 'name' above!
|
|
#user <u>
|
|
|
|
# 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 <n>.
|
|
#remotename <n>
|
|
|
|
# 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 <n>
|
|
|
|
# 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 <n>
|
|
|
|
# Set the LCP restart interval (retransmission timeout) to <n> seconds
|
|
# (default 3).
|
|
#lcp-restart <n>
|
|
|
|
# Set the maximum number of LCP terminate-request transmissions to <n>
|
|
# (default 3).
|
|
#lcp-max-terminate <n>
|
|
|
|
# Set the maximum number of LCP configure-request transmissions to <n>
|
|
# (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 <n>
|
|
|
|
# Set the maximum number of LCP configure-NAKs returned before starting
|
|
# to send configure-Rejects instead to <n> (default 10).
|
|
#lcp-max-failure <n>
|
|
|
|
# Set the IPCP restart interval (retransmission timeout) to <n>
|
|
# seconds (default 3).
|
|
#ipcp-restart <n>
|
|
|
|
# Set the maximum number of IPCP terminate-request transmissions to <n>
|
|
# (default 3).
|
|
#ipcp-max-terminate <n>
|
|
|
|
# Set the maximum number of IPCP configure-request transmissions to <n>
|
|
# (default 10).
|
|
#ipcp-max-configure <n>
|
|
|
|
# Set the maximum number of IPCP configure-NAKs returned before starting
|
|
# to send configure-Rejects instead to <n> (default 10).
|
|
#ipcp-max-failure <n>
|
|
|
|
# Set the PAP restart interval (retransmission timeout) to <n> seconds
|
|
# (default 3).
|
|
#pap-restart <n>
|
|
|
|
# Set the maximum number of PAP authenticate-request transmissions to
|
|
# <n> (default 10).
|
|
#pap-max-authreq <n>
|
|
|
|
# Set the CHAP restart interval (retransmission timeout for
|
|
# challenges) to <n> seconds (default 3).
|
|
#chap-restart <n>
|
|
|
|
# Set the maximum number of CHAP challenge transmissions to <n>
|
|
# (default 10).
|
|
#chap-max-challenge
|
|
|
|
# If this option is given, pppd will re-challenge the peer every <n>
|
|
# seconds.
|
|
#chap-interval <n>
|
|
|
|
# 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
|
|
</code>
|
|
|
|
|
|
<sect1>What options should I use? (No PAP/CHAP)
|
|
|
|
<p>
|
|
Well, as in all things that depends (sigh). The options specified here
|
|
should work with most servers.
|
|
|
|
<p>
|
|
However, if it does NOT work, READ THE TEMPLATE FILE
|
|
(<tt>/etc/ppp/options.tpl</tt>) <bf/and/ the pppd man pages <bf/and/
|
|
speak to the sysadmin/user support people who run the server to which
|
|
you are connecting.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<code>
|
|
# /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)
|
|
</code>
|
|
|
|
<sect>If your PPP server uses PAP (Password Authentication
|
|
Protocol)<label id="pap">
|
|
<p>
|
|
If the server to which you are connecting requires PAP or CHAP
|
|
authentication, you have a little bit more work.
|
|
|
|
<p>
|
|
To the above options file, add the following lines
|
|
<code>
|
|
#
|
|
# force pppd to use your ISP user name as your 'host name' during the
|
|
# authentication process
|
|
name <your ISP user name> # 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
|
|
</code>
|
|
|
|
<sect1>Using MSCHAP
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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
|
|
|
|
<code>
|
|
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap 80> <magic 0x46a3>]
|
|
</code>
|
|
|
|
<p>
|
|
The critical information here is <bf/auth chap 80/.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
You should note that at present this code supports only Linux PPP
|
|
clients connecting to an MS Windows NT server. It does <bf/NOT/ support
|
|
setting up a Linux PPP server to use MSCHAP80 authentication from clients.
|
|
|
|
<sect1>The PAP/CHAP secrets file
|
|
<p>
|
|
If you are using pap or chap authentication, then you also need to
|
|
create the secrets file. These are:
|
|
<code>
|
|
/etc/ppp/pap-secrets
|
|
/etc/ppp/chap-secrets
|
|
</code>
|
|
|
|
<p>
|
|
They must be owned by user root, group root and have file permissions
|
|
740 for security.
|
|
|
|
<p>
|
|
The first point to note about PAP and CHAP is that they are designed to
|
|
authenticate <bf/computer systems/ not <bf/users/.
|
|
|
|
<p>
|
|
&dquot;Huh? What's the difference?&dquot; I hear you ask.
|
|
|
|
<p>
|
|
Well now, once your computer has made its PPP connection to the server,
|
|
<bf/ANY/ 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.
|
|
|
|
<p>
|
|
PAP can (and for CHAP <bf/DOES/) require <bf/bidirectional/
|
|
authentication - that is a valid name and secret is required on each
|
|
computer for the other computer involved. However, this is <bf/NOT/ the
|
|
way most PPP servers offering dial up PPP PAP-authenticated connections
|
|
operate.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
This is done using the <tt/name user name/ option to pppd. So, if you are
|
|
to use the user name given you by your ISP, add the line
|
|
<code>
|
|
name your_user name_at_your_ISP
|
|
</code>
|
|
<p>
|
|
to your <tt>/etc/ppp/options</tt> file.
|
|
|
|
<p>
|
|
Technically, you should really use <tt/user our_user name_at_your_ISP/
|
|
for PAP, but pppd is sufficiently intelligent to interpret <tt/name/ as
|
|
<tt/user/ if it is required to use PAP. The advantage of using the <tt/name/
|
|
option is that this is also valid for CHAP.
|
|
|
|
<p>
|
|
As PAP is for authenticating <bf/computers/, 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.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<sect1>The PAP secrets file
|
|
<p>
|
|
The <tt>/etc/ppp/pap-secrets</tt> file looks like
|
|
<code>
|
|
# Secrets for authentication using PAP
|
|
# client server secret acceptable_local_IP_addresses
|
|
</code>
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
Suppose your ISP gave you a user name of <tt/fred/ and a password of
|
|
<tt/flintstone/ you would set the <tt/name fred/ option in
|
|
<tt>/etc/ppp/options[.ttySx]</tt> and set up your
|
|
<tt>/etc/ppp/pap-secrets</tt> file as follows
|
|
|
|
<code>
|
|
# Secrets for authentication using PAP
|
|
# client server secret acceptable local IP addresses
|
|
fred * flintstone
|
|
</code>
|
|
|
|
<p>
|
|
This says for the local machine name <tt/fred/ (which we have told pppd
|
|
to use even though it is not our local machine name) and for <bf/ANY/
|
|
server, use the password (secret) of <tt/flintstone/.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>The CHAP secrets file
|
|
<p>
|
|
This requires that you have mutual authentication
|
|
methods - that is you must allow for both your machine to authenticate
|
|
the remote server <bf/AND/ the remote server to authenticate your
|
|
machine.
|
|
|
|
<p>
|
|
So, if your machine is <tt/fred/ and the remote is <tt/barney/, your
|
|
machine would set <tt>name fred remotename barney</tt> and the remote
|
|
machine would set <tt>name barney remotename fred</tt> in their respective
|
|
<tt>/etc/ppp/options.ttySx</tt> files.
|
|
|
|
<p>
|
|
The <tt>/etc/chap-secrets</tt> file for fred would look like
|
|
<code>
|
|
# Secrets for authentication using CHAP
|
|
# client server secret acceptable local IP addresses
|
|
fred barney flintstone
|
|
barney fred wilma
|
|
</code>
|
|
|
|
<p>
|
|
and for barney
|
|
|
|
<code>
|
|
# Secrets for authentication using CHAP
|
|
# client server secret acceptable local IP addresses
|
|
barney fred flintstone
|
|
fred barney wilma
|
|
</code>
|
|
|
|
<p>
|
|
Note in particular that both machines must have entries for
|
|
bidirectional authentication. This allows the local machine to
|
|
authenticate itself to the remote <bf/AND/ the remote machine to
|
|
authenticate itself to the local machine.
|
|
|
|
<sect1>Handling multiple PAP-authenticated connections
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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 <tt>/etc/ppp/pap-secrets</tt>.
|
|
|
|
<p>
|
|
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 <bf/remotename/ option to pppd.
|
|
|
|
<p>
|
|
Let us suppose that you connect to two PPP servers using the username
|
|
fred. You set up your <tt>/etc/ppp/pap-secrets</tt> something like
|
|
|
|
<code>
|
|
fred pppserver1 barney
|
|
fred pppserver2 wilma
|
|
</code>
|
|
|
|
<p>
|
|
Now, to set connect to pppserver1 you would use <tt>name fred remotename
|
|
pppserver1</tt> in your ppp-options and for pppserver2 <tt>name fred
|
|
remotename pppserver2</tt>.
|
|
|
|
<p>
|
|
As you can select the ppp options file to use with pppd using the
|
|
<tt>file filename</tt> 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 <tt>remotename</tt> option.
|
|
|
|
<sect>Setting up the PPP connection manually<label id="manual">
|
|
<p>
|
|
Now that you have created your <tt>/etc/ppp/options</tt> and
|
|
<tt>/etc/resolv.conf</tt> files (and, if necessary, the
|
|
<tt>/etc/ppp/pap|chap-secrets</tt> file), you can test the settings by
|
|
manually establishing a PPP connection. (Once we have the manual
|
|
connection working, we will automate the process).
|
|
|
|
<p>
|
|
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)
|
|
|
|
<p>
|
|
Make sure you are logged in as root.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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
|
|
<bf/Enter/ and see if the garbage starts up).
|
|
|
|
<p>
|
|
Now quit the communications software <em/without resetting the modem/ (ALT Q
|
|
or CTL A Q in minicom) and at the Linux prompt (as root) type
|
|
|
|
<code>
|
|
pppd -d -detach /dev/ttySx 38400 &
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
At this point you can look at the PPP interface, by issuing the command
|
|
|
|
<code>
|
|
ifconfig
|
|
</code>
|
|
|
|
<p>
|
|
In addition to any Ethernet and loop back devices you have, you
|
|
should see something like :-
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
Where
|
|
<itemize>
|
|
<item>inet addr:10.144.153.10 is the IP number of your end of the link.
|
|
<item>P-t-P:10.144.153.5 is the SERVER's IP number.
|
|
</itemize>
|
|
<p>
|
|
(Naturally, ifconfig will not report these IP numbers, but the ones used
|
|
by your PPP server.)
|
|
|
|
<p>
|
|
Note: ifconfig also tells you that the link is UP and RUNNING!
|
|
|
|
<p>
|
|
If you get no ppp device listed or something like
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
Your PPP connection has not been made...see the later section on
|
|
debugging!
|
|
|
|
<p>
|
|
You should also be able to see a route to the the remote host (and
|
|
beyond). To do this, issue the command
|
|
|
|
<code>
|
|
route -n
|
|
</code>
|
|
|
|
<p>
|
|
You should se something like:-
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
Of particular importance here, notice we have TWO entries pointing to our
|
|
ppp interface.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
The second is the default route (established by giving pppd the option
|
|
<tt/defaultroute/. 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.
|
|
|
|
<p>
|
|
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 <bf/MUST/ be replaced by a
|
|
specific network route: <bf/YOU CAN ONLY HAVE ONE DEFAULT ROUTE!!!/
|
|
|
|
<p>
|
|
You will need to explore your system initialisation files to find out
|
|
where this default route is being set up (it will use a <tt/route add
|
|
default.../ command). Change this command to something like <tt/route
|
|
add net.../.
|
|
|
|
<p>
|
|
Now test the link by 'pinging' the server at its IP number as reported
|
|
by the ifconfig output, i.e.
|
|
|
|
<code>
|
|
ping 10.144.153.51
|
|
</code>
|
|
|
|
<p>
|
|
You should receive output like
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
This listing will go on for ever - to stop it press CTRL C, at which
|
|
point you will receive some more information :-
|
|
|
|
<code>
|
|
--- 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
|
|
</code>
|
|
|
|
<p>
|
|
So far so good.
|
|
|
|
<p>
|
|
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
|
|
|
|
<code>
|
|
ping sunsite.unc.edu
|
|
</code>
|
|
|
|
<p>
|
|
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 <tt>/etc/resolv.conf</tt> - so don't worry (but you will
|
|
see your modem lights flash). Shortly you will receive output like
|
|
|
|
<code>
|
|
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
|
|
</code>
|
|
|
|
<p>
|
|
Again, stop the output by pressing CTRL C and get the statistics...
|
|
|
|
<code>
|
|
--- 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
|
|
</code>
|
|
|
|
<p>
|
|
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 <tt>/etc/resolv.conf</tt>.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If everything works, shut down the connection by typing
|
|
|
|
<code>
|
|
ppp-off
|
|
</code>
|
|
|
|
<p>
|
|
After a short pause, the modem should hang itself up.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
You may also need to clean up the lock file created by pppd
|
|
<code>
|
|
rm -f /var/lock/LCK..ttySx
|
|
</code>
|
|
|
|
<sect>Automating your connections - Creating the connection scripts<label id="automate">
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Connection scripts for User name/Password Authentication
|
|
<p>
|
|
If your ISP does NOT require the use of PAP/CHAP, these are the scripts
|
|
for you!
|
|
|
|
<p>
|
|
If the ppp package installed correctly, you should have two example files.
|
|
For PPP 2.1.2 they are in <tt>/usr/sbin</tt> and for PPP 2.2 they are in
|
|
<tt>/etc/ppp/scripts</tt>. They are called
|
|
|
|
<p>
|
|
for PPP-2.1.2
|
|
|
|
<tscreen><verb>
|
|
ppp-on
|
|
ppp-off
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
and for PPP-2.2
|
|
|
|
<tscreen><verb>
|
|
ppp-off
|
|
ppp-on
|
|
ppp-on-dialer
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
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)!
|
|
|
|
<p>
|
|
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 <bf/instead of/ the old PPP-2.1.2 scripts.
|
|
|
|
<sect1>The ppp-on script
|
|
<p>
|
|
This is the first of a PAIR of scripts that actually fire up the
|
|
connection.
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<p>
|
|
Here is the ppp-on-dialer script:-
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<p>
|
|
For PPP-2.2, the <tt/ppp-off/ script looks like:-
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<sect1>Editing the supplied PPP startup scripts
|
|
<p>
|
|
As the new scripts come in two parts, we will edit them in turn.
|
|
|
|
<sect2>The ppp-on script
|
|
<p>
|
|
You will need to edit the script to reflect YOUR user name at your ISP,
|
|
YOUR password at your ISP, the telephone number of your ISP.
|
|
|
|
<p>
|
|
Each of the lines like <tt/TELEPHONE=/ 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.
|
|
|
|
<p>
|
|
Also, as you are setting the IP number (if you need to) in the
|
|
<tt>/etc/ppp/options</tt> file, DELETE the line that says
|
|
|
|
<code>
|
|
$LOCAL_IP:$REMOTE_IP \
|
|
</code>
|
|
|
|
<p>
|
|
Also, make sure that the shell variable DIALER_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 <tt/ppp-on/ script!
|
|
|
|
<sect2>The ppp-on-dialer script
|
|
<p>
|
|
This is the second of the scripts that actually brings
|
|
up our ppp link.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
However, it is very useful to look at it in detail so
|
|
that we understand what it is actually (supposed) to be doing!
|
|
|
|
<sect1>What a Chat script means...
|
|
<p>
|
|
A chat script is a sequence of <tt>&dquot;</tt>expect
|
|
string<tt>&dquot;</tt> <tt>&dquot;</tt>send string<tt>&dquot;</tt>
|
|
pairs. In particular, note that we <bf/ALWAYS/ expect <bf>something</bf>
|
|
before we send something.
|
|
|
|
<p>
|
|
If we are to send something <bf/WITHOUT/ receiving anything first, we
|
|
must use an empty expect string (indicated by
|
|
<tt>&dquot;</tt><tt>&dquot;</tt>) 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.
|
|
|
|
<p>
|
|
The chat line in our template is:-
|
|
|
|
<code>
|
|
exec /usr/sbin/chat -v
|
|
</code>
|
|
<p>
|
|
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.
|
|
|
|
<code>
|
|
TIMEOUT 3
|
|
</code>
|
|
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!
|
|
|
|
<code>
|
|
ABORT '\nBUSY\r'
|
|
</code>
|
|
<p>
|
|
If the string BUSY is received, abort the operation.
|
|
|
|
<code>
|
|
ABORT '\nNO ANSWER\r'
|
|
</code>
|
|
<p>
|
|
If the string NO ANSWER is received, abort the operation
|
|
|
|
<code>
|
|
ABORT '\nRINGING\r\n\r\nRINGING\r'
|
|
</code>
|
|
<p>
|
|
If the (repeated) string RINGING is received, abort the
|
|
operation. This is because someone is ringing your phone line!
|
|
|
|
<code>
|
|
&dquot; \rAT
|
|
</code>
|
|
<p>
|
|
Expect nothing from the modem and send the string AT.
|
|
|
|
<code>
|
|
OK-+++\c-OK ATH0
|
|
</code>
|
|
<p>
|
|
This one is a bit more complicated as it uses some of chat's error
|
|
recovery capabilities.
|
|
<p>
|
|
|
|
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!
|
|
|
|
<code>
|
|
TIMEOUT 30
|
|
</code>
|
|
<p>
|
|
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.
|
|
|
|
<code>
|
|
OK ATDT$TELEPHONE
|
|
</code>
|
|
<p>
|
|
Expect OK (the modem's response to the ATH0 command) and dial the number
|
|
we want to call.
|
|
|
|
<code>
|
|
CONNECT ''
|
|
</code>
|
|
<p>
|
|
Expect CONNECT (which our modem sends when the remote modem answers) and
|
|
send nothing in reply.
|
|
|
|
<code>
|
|
ogin:--ogin: $ACCOUNT
|
|
</code>
|
|
<p>
|
|
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 $ACCOUNT).
|
|
|
|
<code>
|
|
assword: $PASSWORD
|
|
</code>
|
|
<p>
|
|
Expect the password prompt and send our password (again, stored in a
|
|
shell variable).
|
|
|
|
<p>
|
|
This chat script has reasonable error recovery capability. Chat has
|
|
considerably more features than demonstrated here. For more information
|
|
consult the chat manual page (<tt/man 8 chat/).
|
|
|
|
<sect2>Starting PPP at the server end
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If you need to issue a command to start up PPP on the server, you DO need
|
|
to edit the ppp-on-dialer script.
|
|
|
|
<p> At the END of the script (after the password line) add an additional
|
|
<bf/expect send/ pair - this one would look for your login prompt (beware
|
|
of characters that have a special meaning in the Bourne shell - such as
|
|
$ and [ or ] (open and close square brackets).
|
|
|
|
<p>
|
|
Once chat has found the shell prompt, chat must issue the ppp
|
|
start up command required for your ISPs PPP server.
|
|
|
|
<p>
|
|
In my case, my PPP server uses the standard Linux Bash prompt
|
|
<code>
|
|
[hartr@kepler hartr]$
|
|
</code>
|
|
|
|
<p>
|
|
and requires that I type
|
|
|
|
<code>
|
|
ppp
|
|
</code>
|
|
|
|
<p>
|
|
to start up PPP on the server.
|
|
|
|
<p>
|
|
It is a good idea to allow for a bit of error recovery here, so in my
|
|
case I use
|
|
<code>
|
|
hartr--hartr ppp
|
|
</code>
|
|
|
|
<p>
|
|
This says, if we don't receive the prompt within the timeout, send a
|
|
carriage return and looks for the prompt again.
|
|
|
|
<p>
|
|
Once the prompt is received, then send the string <tt/ppp/.
|
|
|
|
<p>
|
|
Note: don't forget to add a \ to the end of the previous line so chat
|
|
still thinks the entire chat script is on one line!
|
|
|
|
<p>
|
|
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 &dquot;expect&dquot; strings.
|
|
|
|
<sect1>A chat script for PAP/CHAP authenticated connections
|
|
<p>
|
|
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!
|
|
|
|
<code>
|
|
#!/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 '' \
|
|
</code>
|
|
|
|
|
|
|
|
<sect1>The pppd <tt/debug/ and <tt/file option_file/ options
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
Once you are happy that all is working properly, then you can remove
|
|
this option.
|
|
|
|
<p>
|
|
If you have called your ppp options file anything other than
|
|
<tt>/etc/ppp/options</tt> or <tt>/etc/ppp/options.ttySx</tt>, specify
|
|
the file name with the <tt/file/ option to pppd - e.g.
|
|
|
|
<code>
|
|
exec /usr/sbin/pppd debug file options.myserver /dev/ttyS0 38400 \
|
|
</code>
|
|
|
|
<sect>Testing your connection script
|
|
<p>
|
|
Open a new root Xterm (if you are in X) or open a new virtual console
|
|
and log in as root.
|
|
|
|
<p>
|
|
In this new session, issue the command
|
|
|
|
<tscreen><verb>
|
|
tail -f /var/log/messages
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
(or whatever your system log file is).
|
|
|
|
<p>
|
|
In the first window (or virtual console) issue the command
|
|
|
|
<tscreen><verb>
|
|
ppp-on &
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
(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 &
|
|
at the end of the command, you will not get your terminal prompt back
|
|
until ppp exits (when the link terminates).
|
|
|
|
<p>
|
|
Now switch back to the window that is tracking your system log.
|
|
|
|
<p>
|
|
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 :-
|
|
|
|
<code>
|
|
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 <--> /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
|
|
</code>
|
|
|
|
<p>
|
|
(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.
|
|
|
|
<p>
|
|
This looks OK - so test it out as before with pings to IP numbers and
|
|
host names.
|
|
|
|
<p>
|
|
Fire up you web browser or whatever and go surfing - you are connected!
|
|
|
|
<sect>Shutting down the PPP link<label id="off">
|
|
<p>
|
|
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!).
|
|
|
|
<p>
|
|
In your system log you will see something like:-
|
|
|
|
<code>
|
|
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.
|
|
</code>
|
|
|
|
<p>
|
|
Don't worry about the <tt/SIOCDELRT/ - this is just pppd noting that it
|
|
is terminating and is nothing to worry about.
|
|
|
|
<sect>Debugging<label id="problems">
|
|
<p>
|
|
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.
|
|
|
|
<sect1>I have compiled PPP support into the kernel, but...
|
|
<p>
|
|
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.
|
|
|
|
<sect2>Are you booting the right kernel?
|
|
Whilst you <bf/have/ recompiled your kernel to support ppp, you
|
|
are not booting the new kernel. This can happen if you do not update
|
|
<tt>/etc/lilo.conf</tt> and rerun lilo.
|
|
|
|
<p>
|
|
A good check on the kernel can be obtained by issuing the command
|
|
<tt/uname -a/, which should produce a line like
|
|
|
|
<code>
|
|
Linux archenland 2.0.28 #2 Thu Feb 13 12:31:37 EST 1997 i586
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect2>Did you compile ppp kernel support as a module?
|
|
<p>
|
|
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 <tt>/usr/src/linux</tt>!
|
|
|
|
<p>
|
|
Another module connected possibility is that you are expecting required
|
|
modules to be automatically loaded, but are not running the <tt/kerneld/
|
|
daemon (which auto-loads and unloads modules on the fly). Check the
|
|
kerneld mini-HOWTO for information on setting up kerneld.
|
|
|
|
<sect2>Are you using the correct version of PPP for your kernel?
|
|
<p>
|
|
You <bf/must/ 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.
|
|
|
|
<sect2>Are you running pppd as root?
|
|
<p>
|
|
If you are not running pppd as the root user (and pppd is not suid to
|
|
root), you can receive this message.
|
|
|
|
<sect1>My modem connects but ppp never starts up
|
|
<p>
|
|
There are innumerable variations on this (take a look in comp.os.linux...).
|
|
|
|
<p>
|
|
A <bf/VERY/ 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 <em/line by line/ to make.
|
|
You may need to dial into the ppp server manually to check things out again.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<sect1>The syslog says &dquot;<tt/serial line is not 8 bit clean/...&dquot;
|
|
<p>
|
|
There are variations on this too - such as <tt/serial line looped back/
|
|
etc., and the cause can be one (or a sequence) of a number of things.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
There are several reasons this reflection can occur.
|
|
|
|
<sect2>You are not correctly logging into the server
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
So, the lcp packets are reflected and you receive this error.
|
|
|
|
<p>
|
|
You need to carefully check and correct (if necessary) your chat script
|
|
(see above).
|
|
|
|
<sect2>You are not starting PPP on the server
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Check your chat script (see above).
|
|
|
|
<p>
|
|
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).
|
|
|
|
<sect2>The remote PPP process is slow to start
|
|
<p>
|
|
This one is a bit tricksy!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
On your machine, pppd sees all 10 requests reflected back (with the 8th
|
|
bit stripped) and exits.
|
|
|
|
<p>
|
|
There are two ways round this:-
|
|
|
|
<p>
|
|
Add <tt/lcp-max-configure 30/ 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.
|
|
|
|
<p>
|
|
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 <bf/first/ character of the ppp garbage that appears was always the
|
|
tilde character (˜).
|
|
|
|
<p>
|
|
Using this knowledge we can add a new <tt>expect/send</tt> pair to the
|
|
end of the chat script which expects a tilde and sends nothing. This
|
|
would look like:-
|
|
|
|
<code>
|
|
\~ ''
|
|
</code>
|
|
|
|
<p>
|
|
Note: as the tilde character has a special meaning in the shell, it must
|
|
be escaped (and hence the leading backslash).
|
|
|
|
<sect1>Default route not set
|
|
<p>
|
|
If pppd refuses to set up a default route, it is because (quite
|
|
correctly) it refuses remove/replace an existing default route.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
See the Linux NAG and the Net2/3 HOWTOs for information on correctly
|
|
setting up your Ethernet card and associated routes.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<sect1>Other Problems
|
|
<p>
|
|
There are many reasons apart from these that ppp fails to connect and/or
|
|
operate properly.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<sect>Getting Help when totally stuck
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Also consult the PPP documentation and FAQ plus the other documents
|
|
mention herein!
|
|
|
|
<p>
|
|
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
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
In particular - <bf>DO NOT POST REAMS OF DEBUGGING OUTPUT TO THE NEWS GROUPS
|
|
NOR SEND IT TO ME BY EMAIL</bf> - the former wastes huge amounts of network
|
|
bandwidth and the latter will be consigned to /dev/null (unless I have
|
|
specifically requested it).
|
|
|
|
<sect>Common Problems once the link is working
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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)!
|
|
|
|
<sect1>I can't see beyond the PPP server I connect to
|
|
<p>
|
|
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 <tt/ifconfig
|
|
ppp0/), but you can't reach anything beyond this.
|
|
|
|
<p>
|
|
First of all, try pinging the IP numbers you have specified in
|
|
/etc/resolv.conf as name servers. If this works, you <bf/can/ 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
|
|
|
|
<tscreen><verb>
|
|
ping my.provider.net.au
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
One possibility is that the "remote end" is a Linux PPP server where the
|
|
IP forwarding option has not been specified in the kernel!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>I can send email, but not receive it
|
|
<p>
|
|
If you are using dynamic IP numbers, this is perfectly normal. See
|
|
"Setting up Services" below.
|
|
|
|
<sect1>Why can't people finger, WWW, gopher, talk etc to my machine?
|
|
<p>
|
|
Again, if you are using dynamic IP numbers, this is perfectly normal.
|
|
See "Setting up Services" below.
|
|
|
|
|
|
<sect>Using Internet services with Dynamic IP numbers<label id="dynamic-server">
|
|
<p>
|
|
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 recognise the limitations this imposes.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
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...
|
|
|
|
<sect1>Setting up email
|
|
<p>
|
|
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 <tt/sendmail.cf/ <bf/DS/ 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).
|
|
|
|
<p>
|
|
There are also excellent books on Sendmail (notably the 'bible' from
|
|
O'Reilly and Associates), but these are almost certainly overkill for
|
|
most users!
|
|
|
|
<p>
|
|
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
|
|
|
|
<tscreen><verb>
|
|
sendmail -q &
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
to your /etc/ppp/ip-up script (see below).
|
|
|
|
<p>
|
|
Inbound email is a problem for dynamic IP numbers. The way to handle
|
|
this is to:-
|
|
<itemize>
|
|
<item>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.<newline>
|
|
If you can, you should also set your FROM address to be your email
|
|
address at your ISP as well.
|
|
|
|
<item>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).
|
|
</itemize>
|
|
|
|
<p>
|
|
You can automate this process at dial up time by putting the necessary
|
|
commands in the <tt>/etc/ppp/ip-up</tt> script (see below).
|
|
|
|
<sect1>Setting Up a local Name server
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
There is also a DNS-HOWTO available.
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect>Linking two networks using PPP<label id="WAN">
|
|
<p>
|
|
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 <bf/peer to peer/ protocol.
|
|
|
|
<p>
|
|
However, you <bf/DEFINITELY/ need to understand about how routing is
|
|
established. Read the NET-2 howto and the Linux Network Administrator
|
|
Guide (NAG). You will also find &dquot; TCP/IP Network
|
|
Administration&dquot; (published by O'Reilly and Assoc - ISBN
|
|
0-937175-82-X) to be of invaluable assistance.
|
|
|
|
<p>
|
|
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 <url
|
|
url="http://www.interweft.com.au/other/" name="Linux
|
|
Sub networking mini-HOWTO">.
|
|
|
|
<p>
|
|
In order to link two LANs, you <bf/must/ 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.
|
|
|
|
<sect1>Setting up the IP numbers
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Now edit the appropriate <tt>/etc/ppp/options[.ttyXX]</tt> 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
|
|
<tt>/etc/ppp/options</tt> file - and create appropriate
|
|
options.ttyXX files for any other connections!
|
|
|
|
<p>
|
|
Specify the IP numbers for your end of the PPP link in
|
|
the appropriate options file exactly as shown above for static IP
|
|
numbers.
|
|
|
|
<sect1>Setting up the routing
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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 <bf/specific network route/ 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).
|
|
|
|
<sect1>Network security
|
|
<p>
|
|
If you are linking you LAN to the Internet using PPP - or even just to a
|
|
&dquot;foreign&dquot; LAN, you need to think about security issues. I
|
|
strongly urge you to think about setting up a firewall!
|
|
|
|
<p>
|
|
You should also speak to the LAN administrator at your site <bf/BEFORE/
|
|
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!
|
|
|
|
<sect>After the link comes up - the <tt>/etc/ppp/ip-up</tt> script<label id="ip-up">
|
|
<p>
|
|
Once the PPP link is established, pppd looks for
|
|
<tt>/etc/ppp/ip-up</tt>. 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.
|
|
|
|
<p>
|
|
This is just a shell script and can do anything that a shell script can
|
|
do (i.e. virtually anything you want).
|
|
|
|
<p>
|
|
For example, you can get sendmail to dispatch any waiting outbound
|
|
messages in the mail queue.
|
|
|
|
<p>
|
|
Similarly, you can insert the commands into ip-up to collect (using pop)
|
|
any email waiting for you at your ISP.
|
|
|
|
<p>
|
|
There are restrictions on <tt>/etc/ppp/ip-up</tt>:-
|
|
|
|
<itemize>
|
|
<item>It runs in a deliberately restricted environment to enhance
|
|
security. This means you must give a full path to binaries etc.
|
|
<item>Technically, <tt>/etc/ppp/ip-up</tt> is a <em/program/ not a
|
|
script. This means it can be directly executed - and hence it requires
|
|
the standard file magic (<tt>#!/bin/bash</tt>) at the start of the first line and must be
|
|
readable and executable by root.
|
|
</itemize>
|
|
|
|
<sect1>Special routing
|
|
<p>
|
|
If you are linking two LANs, you will need to set up specific routes
|
|
to the 'foreign' LANs. This is easily done using the <tt>/etc/ppp/ip-up</tt>
|
|
script. The only difficulty arises if your machine handles multiple PPP
|
|
links.
|
|
|
|
<p>
|
|
This is because the <tt>/etc/ppp/ip-up</tt> 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!
|
|
|
|
<sect1>Handling email queues
|
|
<p>
|
|
When the link between two LANs comes up, you may well want to make sure
|
|
that email that is queued at either end is <em/flushed/ - sent out to
|
|
its destination. This is done by adding the appropriate <tt/sendmail/
|
|
invocation.
|
|
|
|
<p>
|
|
Using the bash 'case' statement on an appropriate parameter that pppd
|
|
passes into the script accomplishes this. For example, this is
|
|
the <tt>/etc/ppp/ip-up</tt> script I use to handle our WAN links and the
|
|
link to my home Ethernet (also handled on the same ppp server).
|
|
|
|
<sect1>A sample <tt>/etc/ppp/ip-up</tt> script
|
|
<p>
|
|
The example below provides a variety of example uses.
|
|
|
|
<code>
|
|
#!/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 &
|
|
;;
|
|
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 &
|
|
fi
|
|
# Start the news server (if not already running)
|
|
if [ ! -f /var/lock/subsys/news ]; then
|
|
/etc/rc.d/init.d/news start &
|
|
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 &
|
|
;;
|
|
*)
|
|
esac
|
|
exit 0</code>
|
|
|
|
<p>
|
|
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) :-
|
|
|
|
<code>
|
|
[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
|
|
</code>
|
|
|
|
<sect1>Handling email
|
|
<p>
|
|
The previous section shows how to handle the outgoing mail - simply by
|
|
flushing the mail queue once the link is up.
|
|
|
|
<p>
|
|
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
|
|
<tt>/etc/ppp/ip-up</tt> script looks like :-
|
|
|
|
<code>
|
|
#!/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
|
|
</code>
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
Simply create a <tt>/etc/ppp/ip-up</tt> script that contains the
|
|
appropriate invocation of popclient. For my laptop that runs Red Hat Linux
|
|
(which I take on any travels), this is
|
|
|
|
<code>
|
|
popclient -3 -c -u hartr -p <password> kepler.hedland.edu.au |formail -s procmail
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect>Using <tt>/etc/ppp/ip-down</tt>
|
|
<p>
|
|
You can create a script that will be executed once the
|
|
link has been terminated. This is stored in <tt>/etc/ppp/ip-down</tt>. It can be
|
|
used to undo anything special that you did in the corresponding
|
|
/etc/ppp/ip-up script.
|
|
|
|
<sect>Routing issues on a LAN
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
This section does NOT attempt to teach you about routing - it deals only
|
|
with a simple, special case of (static) routing!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
Check this by issuing a route command, you should see something like the
|
|
following:-
|
|
|
|
<tscreen><verb>
|
|
[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
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
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 initialisation scripts to make it point at the specific
|
|
network numbers rather than the default route (consult the Net2 HOWTO
|
|
and NAG).
|
|
|
|
<p>
|
|
This will allow pppd to set up your default route as shown below:-
|
|
|
|
<tscreen><verb>
|
|
[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
|
|
</verb></tscreen>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
If your set up needs to be more complex than this - read the routing
|
|
documents already mentioned and consult an expert at your site!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Note on Security
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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"!
|
|
|
|
<sect>Setting up a PPP server<label id="ppp-server">
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Kernel compilation
|
|
<p>
|
|
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!
|
|
|
|
<p>
|
|
For a PPP server, you <bf/MUST/ include IP forwarding in your kernel.
|
|
You may also wish to include other capabilities (such as IP fire walls,
|
|
accounting etc etc).
|
|
|
|
<p>
|
|
If you are using a multi-port serial card, then you must obviously
|
|
include the necessary drivers in your kernel too!
|
|
|
|
<sect1>Overview of the server system
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
As we are an educational organisation, we do not charge our staff and
|
|
students for access, and so do not have to worry about accounting and
|
|
charging issues.
|
|
|
|
<p>
|
|
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).
|
|
|
|
<p>
|
|
The process a user goes through to establish a PPP link to our site
|
|
(once they have a valid account of course) is :-
|
|
<itemize>
|
|
<item>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).
|
|
<item>Log in using a valid user name and password pair.
|
|
<item>At the shell prompt, issue the command <tt/ppp/ to start PPP on
|
|
the server.
|
|
<item>Start PPP on their PC (be it running Windows, DOS, Linux MAC OS or
|
|
whatever - that is their problem).
|
|
</itemize>
|
|
|
|
<p>
|
|
The server uses individual <tt>/etc/ppp/options.ttyXX</tt> 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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Getting the software together
|
|
<p>
|
|
You will need the following software:-
|
|
<itemize>
|
|
<item>Linux, properly compiled to include the necessary options.
|
|
<item>The appropriate version of pppd for your kernel.
|
|
<item>A 'getty' program that intelligently handles modem
|
|
communications.<newline>
|
|
We use getty_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.
|
|
<item>An operational domain name server (DNS) that is accessible to your
|
|
dial up users.<newline>
|
|
You should really be running your own DNS if possible...
|
|
</itemize>
|
|
|
|
<sect1>Setting up standard (shell access) dialup.
|
|
<p>
|
|
Before you can set up your PPP server, your Linux box must be capable of
|
|
handling standard dial up access.
|
|
|
|
<p>
|
|
<bf>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.</bf>
|
|
|
|
<sect1>Setting up the PPP options files
|
|
<p>
|
|
You will need to set up the overall <tt>/etc/ppp/options</tt> with the
|
|
common options for all dial up ports. The options we use are:-
|
|
|
|
<code>
|
|
asyncmap 0
|
|
netmask 255.255.254.0
|
|
proxyarp
|
|
lock
|
|
crtscts
|
|
modem
|
|
</code>
|
|
|
|
<p>
|
|
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 <bf/from/ the ppp client
|
|
out across your LAN/Internet and route packets <bf/to/ the client from
|
|
your LAN and beyond.
|
|
|
|
<p>
|
|
All that is necessary for this is a host route to the client machine and
|
|
the use of the 'proxyarp' option to pppd.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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 <tt>/etc/ppp/options.ttyXX</tt>
|
|
for each dial up port.
|
|
|
|
<p>
|
|
In this, simply put the local (server) IP number and the IP number that
|
|
is to be used for that port. For example
|
|
|
|
<code>
|
|
kepler:slip01
|
|
</code>
|
|
|
|
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)!
|
|
|
|
<sect1>Setting pppd up to allow users to (successfully) run it
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Fortunately, pppd has been designed to be 'safe' to run set uid to root.
|
|
So you will need to
|
|
<code>
|
|
chmod u+s /usr/sbin/pppd
|
|
</code>
|
|
|
|
<p>
|
|
When you list the file, it should then appear as
|
|
<code>
|
|
-rwsr-xr-x 1 root root 74224 Apr 28 07:17 /usr/sbin/pppd
|
|
</code>
|
|
|
|
<p>
|
|
If you do not do this, users will be unable to set up their ppp link.
|
|
|
|
<sect1>Setting up the global alias for pppd
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
This looks like
|
|
<code>
|
|
alias ppp="exec /usr/sbin/pppd -detach"
|
|
</code>
|
|
|
|
<p>
|
|
What this does is
|
|
<itemize>
|
|
<item>exec : this means replace the running program (in this case the
|
|
shell) with the program that is run.
|
|
<item>pppd -detach : start up pppd and do NOT fork into the background.
|
|
This ensures that when pppd exits there is no process hanging around.
|
|
</itemize>
|
|
|
|
When a user logs in like this, they will appear in the output of 'w' as
|
|
<code>
|
|
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 -
|
|
</code>
|
|
|
|
<p>
|
|
And that is it...I told you this was a simple, basic PPP server system!
|
|
|
|
<sect>Using PPP across a null modem (direct serial) connection<label
|
|
id="direct">
|
|
<p>
|
|
This is very simple - there is no modem in the way so things are much
|
|
simpler.
|
|
|
|
<p>
|
|
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'.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
Now, on the server, remove the getty and make sure that you have the serial
|
|
ports on both machines configured correctly using 'setserial'.
|
|
|
|
<p>
|
|
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:-
|
|
|
|
<code>
|
|
pppd -detach crtscts lock <local IP>:<remote IP> /dev/ttyS3 38400 &
|
|
</code>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
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.
|
|
|
|
<p>
|
|
So on the Ethernet equipped machine, the pppd command would be
|
|
|
|
<code>
|
|
pppd -detach crtscts lock proxyarp <local IP>:<remote IP> /dev/ttyS3 38400 &
|
|
</code>
|
|
|
|
<p>
|
|
and on the other machine
|
|
|
|
<code>
|
|
pppd -detach crtscts lock defaultroute <local IP>:<remote IP> /dev/ttyS3 38400 &
|
|
</code>
|
|
|
|
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.
|
|
|
|
|
|
<p>
|
|
<p>
|
|
<bf/Robert Hart/<newline>
|
|
Port Hedland, Western Australia<newline>
|
|
Melbourne, Victoria, Australia
|
|
August/October 1996
|
|
January/March 1997
|
|
|
|
</article>
|