1793 lines
85 KiB
HTML
1793 lines
85 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
|
<!--Converted with LaTeX2HTML 96.1-h (September 30, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>6 Networking</TITLE>
|
|
<META NAME="description" CONTENT="6 Networking">
|
|
<META NAME="keywords" CONTENT="gs">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<LINK REL=STYLESHEET HREF="gs.css">
|
|
</HEAD>
|
|
<BODY LANG="EN" >
|
|
<A NAME="tex2html879" HREF="node9.html"><IMG WIDTH=37 HEIGHT=24 ALIGN=BOTTOM ALT="next" SRC="next_motif.gif"></A> <A NAME="tex2html877" HREF="gs.html"><IMG WIDTH=26 HEIGHT=24 ALIGN=BOTTOM ALT="up" SRC="up_motif.gif"></A> <A NAME="tex2html871" HREF="node7.html"><IMG WIDTH=63 HEIGHT=24 ALIGN=BOTTOM ALT="previous" SRC="previous_motif.gif"></A> <A NAME="tex2html881" HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A NAME="tex2html880" HREF="node9.html"> About this document </A>
|
|
<B>Up:</B> <A NAME="tex2html878" HREF="gs.html">Linux Installation and Getting </A>
|
|
<B> Previous:</B> <A NAME="tex2html872" HREF="node7.html">5 The X Window </A>
|
|
<BR> <P>
|
|
<H1><A NAME="SECTION00800000000000000000">6 Networking</A></H1>
|
|
<A NAME="chapnetworking"> </A>
|
|
<P>
|
|
In this chapter we discuss Networking--how to configure a
|
|
connection, using TCP/IP, SLIP, PPP or UUCP, and electronic mail and
|
|
news.
|
|
<P>
|
|
<H1><A NAME="SECTION00810000000000000000">6.1 Networking with TCP/IP.</A></H1>
|
|
<A NAME="sectcpip"> </A>
|
|
<P>
|
|
<A NAME="6164"> </A>
|
|
<A NAME="6165"> </A>
|
|
Linux supports a full implementation of the TCP/IP (Transport Control
|
|
Protocol/Internet Protocol) networking protocols. TCP/IP has become the
|
|
most successful mechanism for networking computers worldwide.
|
|
With Linux and an Ethernet card, you can network your machine to a local
|
|
area network, or (with the proper network connections) to the Internet--the
|
|
worldwide TCP/IP network.
|
|
<P>
|
|
Hooking up a small LAN of UNIX machines is easy. It simply requires an
|
|
Ethernet controller in each machine and the appropriate Ethernet cables
|
|
and other hardware. Or, if your business or university provides
|
|
access to the Internet, you can easily add your Linux machine to this network.
|
|
<P>
|
|
<A NAME="6166"> </A>
|
|
<A NAME="6167"> </A>
|
|
<A NAME="6168"> </A>
|
|
The current implementation of TCP/IP and related protocols for Linux
|
|
is called ``NET-3,'' and before that, ``NET-2.'' This has no
|
|
relationship to the so-called NET-2 release of BSD UNIX; instead,
|
|
``NET-3'' in this context means the second implementation of TCP/IP
|
|
for Linux.
|
|
<P>
|
|
<A NAME="6169"> </A>
|
|
<A NAME="6170"> </A>
|
|
<A NAME="6171"> </A>
|
|
<A NAME="6172"> </A>
|
|
Linux NET-3 also supports SLIP--Serial Line Internet Protocol and
|
|
PPP--Point-to-Point Protocol. SLIP and PPP
|
|
allow you to have dialup Internet access using a modem.
|
|
If your business or university provides SLIP or PPP access, you can dial in to the
|
|
SLIP or PPP server and put your machine on the Internet over the phone line.
|
|
Alternately, if your Linux machine also has Ethernet access to the Internet,
|
|
you can set up your Linux box as a SLIP or PPP server.
|
|
<P>
|
|
For complete information on setting up TCP/IP under Linux, we
|
|
encourage you to read the Linux NET-3 HOWTO, available via anonymous
|
|
FTP from <TT>sunsite.unc.edu</TT>. The NET-3 HOWTO is a complete guide to
|
|
configuring TCP/IP, including Ethernet and SLIP or PPP connections, under Linux.
|
|
The Linux Ethernet HOWTO is a related document that describes configuration
|
|
of various Ethernet card drivers for Linux.
|
|
The <EM>Linux Network Administrator's Guide</EM>, from the Linux
|
|
Documentation Project, is also available. See Appendix <A
|
|
HREF="app-sources/node1.html">A</A>
|
|
for more information on these documents.
|
|
<P>
|
|
Also of interest is the book <EM>TCP/IP Network Administration</EM>, by
|
|
Craig Hunt. It contains complete information on using and configuring
|
|
TCP/IP on UNIX systems.
|
|
<P>
|
|
<H2><A NAME="SECTION00811000000000000000">TCP/IP Hardware requirements.</A></H2>
|
|
<P>
|
|
<A NAME="6178"> </A>
|
|
You can use Linux TCP/IP without any networking hardware at all--configuring
|
|
``loopback'' mode allows you to talk to yourself. This is necessary for
|
|
some applications and games which use the ``loopback'' network device.
|
|
<P>
|
|
<A NAME="6179"> </A>
|
|
<A NAME="6180"> </A>
|
|
<A NAME="6181"> </A>
|
|
However, if you want to use Linux with an Ethernet TCP/IP network, you need
|
|
an Ethernet card. Common cards such as the
|
|
3com 3c503, HP PCLAN (27245 and 27xxx series), Western Digital WD80x3,
|
|
and Novell NE2000/NE1000 are supported, as well as many more. See the
|
|
Linux Ethernet and Hardware HOWTOs for details.
|
|
<P>
|
|
There are a few common situations that you should watch out concerning
|
|
supported cards: 1) Several cards are support but offer shoddy performance or
|
|
have other restrictions. Examples are the 3Com 3C501 which works but gives
|
|
absolutely horrible performance and the Racal-Interlan NI6510 using the am7990
|
|
lance chip which doesn't work with more than 16 megabytes of RAM. In the same
|
|
vein, many cards are NE1000/NE2000 compatible clones and can have various
|
|
problems. See the Linux Ethernet HOWTO for a more complete discussion of Linux
|
|
Ethernet hardware compatibility.
|
|
<P>
|
|
Linux also supports SLIP and PPP, which allows you to use a modem to access the
|
|
Internet over the phone line. In this case, you'll need a modem compatible
|
|
with your SLIP or PPP server--most servers require a 14.4bps V.32bis modem
|
|
at a minimum . Performance is greatly improved with a 33.6bps or higher modem.
|
|
<P>
|
|
<H2><A NAME="SECTION00812000000000000000">6.1.1 Configuring TCP/IP on your system.</A></H2>
|
|
<P>
|
|
<A NAME="6183"> </A>
|
|
In this section we're going to discuss how to configure an Ethernet
|
|
TCP/IP connection on your system. Note that this method should work for
|
|
many systems, but certainly not all. This discussion should be enough
|
|
to get you on the right path to configuring the network parameters of
|
|
your machine, but there are numerous caveats and fine details not mentioned
|
|
here. We direct you to the <EM>Linux Network Administrators' Guide</EM>
|
|
and the NET-3-HOWTO for more information.<A NAME="tex2html451" HREF="footnode.html#6185"><IMG ALIGN=BOTTOM ALT="gif" SRC="foot_motif.gif"></A>
|
|
<P>
|
|
First, we assume that you have a Linux system that has the TCP/IP
|
|
software installed. This includes basic clients such as <TT>telnet</TT>
|
|
and <TT>ftp</TT>, system administration commands such as <TT>ifconfig</TT>
|
|
and <TT>route</TT> (usually found in <TT>/etc</TT>), and networking configuration
|
|
files (such as <TT>/etc/hosts</TT>). The other Linux-related networking
|
|
documents described above explain how to go about installing the
|
|
Linux networking software if you do not have it already.
|
|
<P>
|
|
We also assume that your kernel has been configured and compiled with
|
|
TCP/IP support enabled. See Section <A HREF="node6.html#secsysadmupgrade">4.9</A> for information
|
|
on compiling your kernel. To enable networking, you must answer ``yes'' to the
|
|
appropriate questions during the <TT>make config</TT> step, and rebuild the
|
|
kernel.
|
|
<P>
|
|
Once this has been done, you must modify a number of configuration
|
|
files used by NET-3. For the most part this is a simple procedure.
|
|
Unfortunately, however, there is wide disagreement between Linux
|
|
distributions as to where the various TCP/IP configuration files
|
|
and support programs should go. Much of the time, they can be found
|
|
in <TT>/etc</TT>, but in other cases may be found in <TT>/usr/etc</TT>,
|
|
<TT>/usr/etc/inet</TT>, or other bizarre locations. In the worst case
|
|
you'll have to use the <TT>find</TT> command to locate the files on your
|
|
system. Also note that not all distributions keep the NET-3 configuration
|
|
files and software in the same location--they may be spread across
|
|
several directories.
|
|
<P>
|
|
The following information applies primarily to Ethernet connections.
|
|
If you're planning to use SLIP or PPP, read this section to understand the
|
|
concepts, and follow the more specific instructions in the following
|
|
sections.
|
|
<P>
|
|
<H5><A NAME="SECTION00812001000000000000">Your network configuration.</A></H5>
|
|
<P>
|
|
<A NAME="6199"> </A>
|
|
Before you can configure TCP/IP, you need to determine the following
|
|
information about your network setup. In most cases, your local
|
|
network administrator can provide you with this information.
|
|
<UL><A NAME="6201"> </A>
|
|
<A NAME="6202"> </A>
|
|
<LI> IP address. This is the unique machine address in dotted-decimal
|
|
format. An example is 128.253.153.54. Your network admins will
|
|
provide you with this number.
|
|
<P>
|
|
If you're only configuring loopback mode (i.e. no SLIP, no Ethernet
|
|
card, just TCP/IP connections to your own machine) then your
|
|
IP address is 127.0.0.1.
|
|
<P>
|
|
<A NAME="6203"> </A>
|
|
<A NAME="6204"> </A>
|
|
<LI> Your network mask (``netmask''). This is a dotted quad, similar
|
|
to the IP address, which determines which portion of the IP address
|
|
specifies the subnetwork number, and which portion specifies the host on
|
|
that subnet. (If you're shaky on these TCP/IP networking terms, we
|
|
suggest reading some introductory material on network administration.)
|
|
The network mask
|
|
is a pattern of bits, which when overlayed onto an address on your
|
|
network, will tell you which subnet that address lives on. This is
|
|
very important for routing, and if you find, for example, that you
|
|
can happily talk to people outside your network, but not to some
|
|
people within your network, there is a good chance that you have
|
|
an incorrect mask specified.
|
|
<P>
|
|
Your network administrators will have chosen the netmask when the
|
|
network was designed, and therefore they should be able to supply
|
|
you with the correct mask to use. Most networks are class C
|
|
subnetworks which use 255.255.255.0 as their netmask. Class B
|
|
networks use 255.255.0.0. The NET-3 code will automatically select
|
|
a mask that assumes no subnetting as a default if you do not specify one.
|
|
<P>
|
|
This applies as well to the loopback port. Since the
|
|
loopback port's address is always 127.0.0.1, the netmask for
|
|
this port is always 255.0.0.0. You can either specify this
|
|
explicitly or rely on the default mask.
|
|
<P>
|
|
<A NAME="6205"> </A>
|
|
<A NAME="6206"> </A>
|
|
<LI> Your network address. This is your IP address masked bitwise-ANDed the
|
|
netmask. For example, if your netmask is 255.255.255.0, and your IP address
|
|
is 128.253.154.32, your network address is
|
|
128.253.154.0. With a netmask of 255.255.0.0,
|
|
this would be 128.253.0.0.
|
|
<P>
|
|
If you're only using loopback, you don't have a network address.
|
|
<P>
|
|
<A NAME="6207"> </A>
|
|
<A NAME="6208"> </A>
|
|
<LI> Your broadcast address.
|
|
The broadcast address is used to broadcast packets to every machine on your
|
|
subnet. Therefore, if the host number of machines on your subnet is
|
|
given by the last byte of the IP address (netmask 255.255.255.0),
|
|
your broadcast address will be your network address ORed with 0.0.0.255.
|
|
<P>
|
|
For example, if your IP address is 128.253.154.32, and your netmask is
|
|
255.255.255.0, your broadcast address is 128.253.154.255.
|
|
<P>
|
|
Note that for historical reasons, some networks are setup to use
|
|
the network address as the broadcast address, if you have any doubt,
|
|
check with your network administrators. (In many cases, it will
|
|
suffice to duplicate the network configuration of other machines on
|
|
your subnet, substituting your own IP address, of course.)
|
|
<P>
|
|
If you're only using loopback, you don't have a broadcast address.
|
|
<P>
|
|
<A NAME="6209"> </A>
|
|
<A NAME="6210"> </A>
|
|
<LI> Your gateway address. This is the address of the machine which
|
|
is your ``gateway'' to the outside world (i.e. machines not on your
|
|
subnet). In many cases the gateway machine has an IP address
|
|
identical to yours but with a ``.1'' as its host address; e.g., if
|
|
your IP address is 128.253.154.32, your gateway might be
|
|
128.253.154.1. Your network admins will provide you with the IP
|
|
address of your gateway.
|
|
<P>
|
|
In fact, you may have multiple gateways. A <EM>gateway</EM> is
|
|
simply a machine that lives on two different networks (has
|
|
IP addresses on different subnets), and routes packets between
|
|
them. Many networks have a single gateway to ``the outside
|
|
world'' (the network directly adjacent to your own),
|
|
but in some cases you will have multiple gateways--one for
|
|
each adjacent network.
|
|
<P>
|
|
If you're only using loopback, you don't have a gateway address.
|
|
The same is true if your network is isolated from all others.
|
|
<P>
|
|
<A NAME="6212"> </A>
|
|
<A NAME="6213"> </A>
|
|
<LI> Your name server address. Most machines on the net have a name
|
|
server which translates host names into IP addresses for them.
|
|
Your network admins will tell you the address of your name server.
|
|
You can also run a server on your own machine by running
|
|
<TT>named</TT>, in which case the name server address is 127.0.0.1.
|
|
Unless you absolutely <EM>must</EM> run your own name server,
|
|
we suggest using the one provided to you on the network (if
|
|
any). Configuration of <TT>named</TT> is another issue altogether;
|
|
our priority at this point is to get you talking to the network.
|
|
You can deal with name resolution issues later.
|
|
<P>
|
|
If you're only using loopback, you don't have a name server
|
|
address.
|
|
</UL>
|
|
<P>
|
|
SLIP/PPP users: You may or may not require any of the above information,
|
|
except for a name server address. When using SLIP, your IP address is
|
|
usually determined in one of two ways: Either (a) you have a ``static''
|
|
IP address, which is the same every time you connect to the network, or
|
|
(b) you have a ``dynamic'' IP address, which is allocated from a pool
|
|
available addresses when you connect to the server. In the following
|
|
section on SLIP configuration this is covered in more detail.
|
|
<P>
|
|
NET-3 supports full routing, multiple routes, subnetworking (at
|
|
this stage on byte boundaries only), the whole nine yards. The above
|
|
describes most basic TCP/IP configurations. Yours may be quite
|
|
different: when in doubt, consult your local network gurus and check
|
|
out the man pages for <TT>route</TT> and <TT>ifconfig</TT>.
|
|
Configuring TCP/IP networks is very much beyond the scope of
|
|
this book; the above should be enough to get most people started.
|
|
<P>
|
|
<H5><A NAME="SECTION00812002000000000000">The networking <TT>rc</TT> files.</A></H5>
|
|
<P>
|
|
<A NAME="6221"> </A>
|
|
<A NAME="6222"> </A>
|
|
<A NAME="6524"> </A>
|
|
<TT>rc</TT> files are systemwide configuration scripts executed at boot
|
|
time by <TT>init</TT>, which start up all of the basic system daemons
|
|
(such as <TT>sendmail</TT>, <TT>cron</TT>, etc.) and configure things
|
|
such as the network parameters, system host name, and so on.
|
|
<TT>rc</TT> files are usually found in the directory <TT>/etc/rc.d</TT> but
|
|
on other systems may be in <TT>/etc</TT>. In general Slackware distributions
|
|
use the files <TT>rc.inet1</TT>, etc. in <TT>/etc/rc.d</TT> whereas the RedHat
|
|
distributions use a series of directories
|
|
<P>
|
|
<A NAME="6525"> </A>
|
|
<A NAME="6526"> </A>
|
|
<A NAME="6527"> </A>
|
|
<A NAME="6528"> </A>
|
|
<A NAME="6529"> </A>
|
|
Here, we're going to describe the <TT>rc</TT> files used to configure
|
|
TCP/IP. There are two of them: <TT>rc.inet1</TT> and <TT>rc.inet2</TT>.
|
|
<TT>rc.inet1</TT> is used to configure the basic network parameters
|
|
(such as IP addresses and routing information) and <TT>rc.inet2</TT>
|
|
fires up the TCP/IP daemons (<TT>telnetd</TT>, <TT>ftpd</TT>, and so forth).
|
|
<P>
|
|
<A NAME="6530"> </A>
|
|
<A NAME="6531"> </A>
|
|
<A NAME="6532"> </A>
|
|
<A NAME="6533"> </A>
|
|
Many systems combine these two files into one, usually called <TT>rc.inet</TT>
|
|
or <TT>rc.net</TT>. The names given to your <TT>rc</TT> files doesn't matter,
|
|
as long as they perform the correct functions and are executed at boot time by
|
|
<TT>init</TT>. To ensure this, you may need to edit <TT>/etc/inittab</TT>
|
|
and uncomment lines to execute the appropriate <TT>rc</TT> file(s). In the
|
|
worst case you will have to create the <TT>rc.inet1</TT> and <TT>rc.inet2</TT>
|
|
files from scratch and add entries for them to <TT>/etc/inittab</TT>.
|
|
<P>
|
|
As we said, <TT>rc.inet1</TT> configures the basic network interface.
|
|
This includes your IP and network address, and the routing table information
|
|
for your network. The routing tables are used to route outgoing (and
|
|
incoming) network datagrams to other machines. On most simple configurations,
|
|
you have three routes: One for sending packets to your own machine,
|
|
another for sending packets to other machines on your network, and
|
|
another for sending packets to machines outside of your network (through
|
|
the gateway machine). Two programs are used to configure these parameters:
|
|
<TT>ifconfig</TT> and <TT>route</TT>. Both of these are usually found in <TT>/etc</TT>.
|
|
<P>
|
|
<A NAME="6534"> </A>
|
|
<A NAME="6535"> </A>
|
|
<A NAME="6536"> </A>
|
|
<A NAME="6537"> </A>
|
|
<TT>ifconfig</TT> is used for configuring the network device interface with
|
|
the parameters that it requires to function, such as the IP address, network
|
|
mask, broadcast address and the like.
|
|
<TT>Route</TT> is used to create and modify entries in the routing table.
|
|
<P>
|
|
<A NAME="6538"> </A>
|
|
<A NAME="6539"> </A>
|
|
For most configurations, an <TT>rc.inet1</TT> file that looks like the following
|
|
should work. You will, of course, have to edit this for your own system.
|
|
Do <EM>not</EM> use the sample IP and network addresses listed here for
|
|
your own system; they correspond to an actual machine on the Internet.
|
|
<P>
|
|
<BR><IMG WIDTH=675 HEIGHT=650 ALIGN=BOTTOM ALT="tscreen6272" SRC="img371.gif"><BR>
|
|
<P>
|
|
Again, you may have to tweak this file somewhat to get it
|
|
to work. The above should be sufficient for the majority of simple
|
|
network configurations, but certainly not all.
|
|
<P>
|
|
<A NAME="6540"> </A>
|
|
<A NAME="6541"> </A>
|
|
<A NAME="6542"> </A>
|
|
<TT>rc.inet2</TT> starts up various servers used by the TCP/IP suite.
|
|
The most important of these is <TT>inetd</TT>. <TT>Inetd</TT> sits in the
|
|
background and listens to various network ports. When a machine
|
|
tries to make a connection to a certain port (for example, the
|
|
incoming <TT>telnet</TT> port), <TT>inetd</TT> forks off a copy of the
|
|
appropriate daemon for that port (in the case of the <TT>telnet</TT>
|
|
port, <TT>inetd</TT> starts <TT>in.telnetd</TT>). This is simpler than
|
|
running many separate, standalone daemons (e.g., individual copies
|
|
of <TT>telnetd</TT>, <TT>ftpd</TT>, and so forth)--<TT>inetd</TT> starts up
|
|
the daemons only when they are needed.
|
|
<P>
|
|
<A NAME="6543"> </A>
|
|
<A NAME="6544"> </A>
|
|
<A NAME="6545"> </A>
|
|
<A NAME="6546"> </A>
|
|
<TT>Syslogd</TT> is the system logging daemon--it accumulates log messages
|
|
from various applications and stores them into log files based on
|
|
the configuration information in <TT>/etc/syslogd.conf</TT>.
|
|
<TT>routed</TT> is a server used to maintain dynamic routing information.
|
|
When your system attempts to send packets to another network, it may
|
|
require additional routing table entries in order to do so.
|
|
<TT>routed</TT> takes care of manipulating the routing table without
|
|
the need for user intervention.
|
|
<P>
|
|
<A NAME="6296"> </A>
|
|
<A NAME="6297"> </A>
|
|
Our example <TT>rc.inet2</TT>, below, only starts up the bare minimum
|
|
of servers. There are many other servers as well--many of which have
|
|
to do with NFS configuration. When attempting to setup TCP/IP on your
|
|
system, it's usually best to start with a minimal configuration and
|
|
add more complex pieces (such as NFS) when you have things working.
|
|
<P>
|
|
Note that in the below file, we assume that all of the network daemons
|
|
are held in <TT>/etc</TT>. As usual, edit this for your own configuration.
|
|
<P>
|
|
<A NAME="6547"> </A>
|
|
<A NAME="6548"> </A>
|
|
<BR><IMG WIDTH=230 HEIGHT=428 ALIGN=BOTTOM ALT="tscreen6302" SRC="img372.gif"><BR>
|
|
<P>
|
|
<A NAME="6549"> </A>
|
|
<A NAME="6550"> </A>
|
|
Among the various additional servers that you may want to start in
|
|
<TT>rc.inet2</TT> is <TT>named</TT>. <TT>Named</TT> is a name server--it
|
|
is responsible for translating (local) IP addresses to names, and vice
|
|
versa. If you don't have a name server elsewhere on the network, or
|
|
want to provide local machine names to other machines in your domain,
|
|
it may be necessary to run <TT>named</TT>. (For most configurations it
|
|
is not necessary, however.) <TT>Named</TT> configuration is somewhat
|
|
complex and requires planning; we refer interested readers to a good
|
|
book on TCP/IP network administration.
|
|
<P>
|
|
<H5><A NAME="SECTION00812003000000000000">The <TT>/etc/hosts</TT> file.</A></H5>
|
|
<P>
|
|
<A NAME="6552"> </A>
|
|
<A NAME="6553"> </A>
|
|
<TT>/etc/hosts</TT> contains a list of IP addresses and the host names that
|
|
they correspond to. In general, <TT>/etc/hosts</TT> only contains entries
|
|
for your local machine, and perhaps other ``important'' machines (such
|
|
as your name server or gateway). Your local name server will provide
|
|
address-to-name mappings for other machines on the network, transparently.
|
|
<P>
|
|
For example, if your machine is <TT>loomer.vpizza.com</TT> with the IP address
|
|
128.253.154.32, your <TT>/etc/hosts</TT> would look like:
|
|
<BR><IMG WIDTH=409 HEIGHT=32 ALIGN=BOTTOM ALT="tscreen6318" SRC="img373.gif"><BR>
|
|
If you're only using
|
|
loopback, the only line in <TT>/etc/hosts</TT> should be for 127.0.0.1, with
|
|
both <TT>localhost</TT> and your host name after it.
|
|
<P>
|
|
<H5><A NAME="SECTION00812004000000000000">The <TT>/etc/networks</TT> file.</A></H5>
|
|
<P>
|
|
<A NAME="6555"> </A>
|
|
<A NAME="6556"> </A>
|
|
The <TT>/etc/networks</TT> file lists the names and addresses of your own,
|
|
and other, networks. It is used by the <TT>route</TT> command, and allows
|
|
you to specify a network by name, should you so desire.
|
|
<P>
|
|
<A NAME="6557"> </A>
|
|
Every network you wish to add a route to using the <TT>route</TT>
|
|
command (generally called from <TT>rc.inet1</TT>--see above) <EM>must</EM>
|
|
have an entry in <TT>/etc/networks</TT>.
|
|
<P>
|
|
As an example,
|
|
<BR><IMG WIDTH=488 HEIGHT=52 ALIGN=BOTTOM ALT="tscreen6333" SRC="img374.gif"><BR><H5><A NAME="SECTION00812005000000000000">The <TT>/etc/host.conf</TT> file.</A></H5>
|
|
<P>
|
|
<A NAME="6559"> </A>
|
|
<A NAME="6560"> </A>
|
|
This file is used to specify how your system will resolve host names.
|
|
It should contain the two lines:
|
|
<BR><IMG WIDTH=138 HEIGHT=29 ALIGN=BOTTOM ALT="tscreen6338" SRC="img375.gif"><BR>
|
|
These lines tell the resolve libraries to first check the
|
|
<TT>/etc/hosts</TT> file for any names to lookup, and then to ask the name server
|
|
(if one is present). The <TT>multi</TT> entry allows you to have multiple
|
|
IP addresses for a given machine name in <TT>/etc/hosts</TT>.
|
|
<P>
|
|
<H5><A NAME="SECTION00812006000000000000">The <TT>/etc/resolv.conf</TT> file.</A></H5>
|
|
<P>
|
|
<A NAME="secresolveconf"> </A>
|
|
<A NAME="6562"> </A>
|
|
<A NAME="6563"> </A>
|
|
This file configures the name resolver, specifying the
|
|
address of your name server (if any) and your domain name.
|
|
Your domain name is your fully-qualified host name (if you're a
|
|
registered machine on the Internet, for example), with the host name
|
|
chopped off. That is, if your full host name is <TT>loomer.vpizza.com</TT>,
|
|
your domain name is just <TT>vpizza.com</TT>.
|
|
<P>
|
|
For example, if your machine is <TT>goober.norelco.com</TT>, and has a
|
|
name server at the address 128.253.154.5, your <TT>/etc/resolv.conf</TT> would
|
|
look like:
|
|
<BR><IMG WIDTH=213 HEIGHT=29 ALIGN=BOTTOM ALT="tscreen6351" SRC="img376.gif"><BR>
|
|
You can specify more than one name server--each must have a
|
|
<TT>nameserver</TT> line of its own in <TT>resolv.conf</TT>.
|
|
<P>
|
|
<H5><A NAME="SECTION00812007000000000000">Setting your host name.</A></H5>
|
|
<P>
|
|
<A NAME="6356"> </A>
|
|
<A NAME="6564"> </A>
|
|
You should set your system host name with the <TT>hostname</TT> command.
|
|
This is usually called from <TT>/etc/rc</TT> or <TT>/etc/rc.local</TT>;
|
|
simply search your system <TT>rc</TT> files to determine where it is
|
|
invoked. For example, if your (full) host name is <TT>loomer.vpizza.com</TT>,
|
|
edit the appropriate <TT>rc</TT> file to execute the command:
|
|
<BR><IMG WIDTH=265 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6364" SRC="img377.gif"><BR>
|
|
Note that the <TT>hostname</TT> executable may not be found in <TT>/bin</TT>
|
|
on your system.
|
|
<P>
|
|
<H5><A NAME="SECTION00812008000000000000">Trying it out.</A></H5>
|
|
<P>
|
|
<A NAME="6369"> </A>
|
|
Once you have all of these files set up, you should be able to reboot
|
|
your new kernel and attempt to use the network. There are many places where
|
|
things can go wrong, so it's a good idea to test individual aspects of
|
|
the network configuration (e.g., it's probably not a good idea to test
|
|
your network configuration by firing up Mosaic over a network-based X
|
|
connection).
|
|
<P>
|
|
<A NAME="6565"> </A>
|
|
<A NAME="6371"> </A>
|
|
You can use the <TT>netstat</TT> command to display your routing tables;
|
|
this is usually the source of the most trouble. The <TT>netstat</TT>
|
|
man page describes the exact syntax of this command in detail.
|
|
In order to test network connectivity, we suggest using a client such
|
|
as <TT>telnet</TT> to connect to machines both on your local subnetwork
|
|
and external networks. This will help to narrow down the source
|
|
of the problem. (For example, if you're unable to connect to local machines,
|
|
but can connect to machines on other networks, more than likely there
|
|
is a problem with your netmask and routing table configuration).
|
|
You can also invoke the <TT>route</TT> command directly (as <TT>root</TT>) to
|
|
play with the entries in your routing table.
|
|
<P>
|
|
You should also test network connectivity by specifying IP addresses
|
|
directly, instead of host names. For example, if you have problems with
|
|
the command
|
|
<BR><IMG WIDTH=215 HEIGHT=13 ALIGN=BOTTOM ALT="tscreen6377" SRC="img378.gif"><BR>
|
|
the cause may be incorrect name server configuration. Try using
|
|
the actual IP address of the machine in question; if that works, then
|
|
you know your basic network setup is (more than likely) correct,
|
|
and the problem lies in your specification of the name server address.
|
|
<P>
|
|
Debugging network configurations can be a difficult task, and we can't
|
|
begin to cover it here. If you are unable to get help from a local guru
|
|
we strongly suggest reading the <EM>Linux Network Administrators' Guide</EM>
|
|
from the LDP.
|
|
<P>
|
|
<H2><A NAME="SECTION00813000000000000000">6.1.2 SLIP configuration.</A></H2>
|
|
<P>
|
|
<A NAME="6381"> </A>
|
|
<A NAME="6382"> </A>
|
|
<A NAME="6383"> </A>
|
|
<A NAME="6384"> </A>
|
|
SLIP (Serial Line Internet Protocol) allows you to use TCP/IP
|
|
over a serial line, be that a phone line, with a dialup modem, or
|
|
a leased asynchronous line of some sort. Of course, to use SLIP you'll
|
|
need access to a dial-in SLIP server in your area. Many universities
|
|
and businesses provide SLIP access for a modest fee.
|
|
<P>
|
|
<A NAME="6566"> </A>
|
|
<A NAME="6567"> </A>
|
|
There are two major SLIP-related programs available--<TT>dip</TT> and
|
|
<TT>slattach</TT>. Both of these programs are used to initiate a SLIP
|
|
connection over a serial device. It is <EM>necessary</EM> to use one
|
|
of these programs in order to enable SLIP--it will not suffice to
|
|
dial up the SLIP server (with a communications program such as
|
|
<TT>kermit</TT>) and issue <TT>ifconfig</TT> and <TT>route</TT> commands.
|
|
This is because <TT>dip</TT> and <TT>slattach</TT> issue a special
|
|
<EM>ioctl()</EM> system call to seize control of the serial device to
|
|
be used as a SLIP interface.
|
|
<P>
|
|
<TT>dip</TT> can be used to dial up a SLIP server,
|
|
do some handshaking to login to the server (exchanging your username
|
|
and password, for example) and then initiate the SLIP connection over the
|
|
open serial line. <TT>slattach</TT>, on the other hand, does very little
|
|
other than grab the serial device for use by SLIP. It is useful if you
|
|
have a permanent line to your SLIP server and no modem dialup or handshaking
|
|
is necessary to initiate the connection. Most dialup SLIP users should
|
|
use <TT>dip</TT>, on the other hand.
|
|
<P>
|
|
<TT>dip</TT> can also be used to configure your Linux system as a SLIP
|
|
server, where other machines can dial into your own and connect to the
|
|
network through a secondary Ethernet connection on your machine.
|
|
See the documentation and man pages for <TT>dip</TT> for more information
|
|
on this procedure.
|
|
<P>
|
|
<A NAME="6401"> </A>
|
|
<A NAME="6402"> </A>
|
|
<A NAME="6403"> </A>
|
|
<A NAME="6404"> </A>
|
|
SLIP is quite unlike Ethernet, in that there are only two machines
|
|
on the ``network''--the SLIP host (that's you) and the SLIP server.
|
|
For this reason, SLIP is often referred to as a ``point-to-point''
|
|
connection. A generalization of this idea, known as PPP (Point to Point
|
|
Protocol) has also been implemented for Linux.
|
|
<P>
|
|
When you initiate a connection to a SLIP server, the SLIP server will
|
|
give you an IP address based on (usually) one of two methods. Some
|
|
SLIP servers allocate ``static'' IP addresses--in which case your
|
|
IP address will be the same every time you connect to the server.
|
|
However, many SLIP servers allocate IP addresses dynamically--in which
|
|
case you receive a different IP address each time you connect.
|
|
In general, the SLIP server will print the values of your IP and
|
|
gateway addresses when you connect. <TT>dip</TT> is capable of reading
|
|
these values from the output of the SLIP server login session and
|
|
using them to configure the SLIP device.
|
|
<P>
|
|
Essentially, configuring a SLIP connection is just like configuring
|
|
for loopback or ethernet. The main differences are discussed below.
|
|
Read the previous section on configuring the basic TCP/IP files,
|
|
and apply the changes described below.
|
|
<P>
|
|
<H5><A NAME="SECTION00813001000000000000">Static IP address SLIP connections using <TT>dip</TT>.</A></H5>
|
|
<P>
|
|
<A NAME="secadvslipdip"> </A>
|
|
<A NAME="6569"> </A>
|
|
<A NAME="6570"> </A>
|
|
<A NAME="6571"> </A>
|
|
If you are using a static-allocation SLIP server, you may want to include
|
|
entries for your IP address and host name in <TT>/etc/hosts</TT>.
|
|
Also, configure these files listed in the above section:
|
|
<TT>rc.inet2</TT>, <TT>host.conf</TT>, and <TT>resolv.conf</TT>.
|
|
<P>
|
|
Also, configure <TT>rc.inet1</TT>, as described above. However, you only want to
|
|
execute <TT>ifconfig</TT> and <TT>route</TT> commands for the loopback device.
|
|
If you use <TT>dip</TT> to connect to the SLIP server, it will execute
|
|
the appropriate <TT>ifconfig</TT> and <TT>route</TT> commands for the SLIP
|
|
device for you. (If you're using <TT>slattach</TT>, on the other hand, you
|
|
<EM>will</EM> need to include <TT>ifconfig</TT>/<TT>route</TT> commands in
|
|
<TT>rc.inet1</TT> for the SLIP device--see below.)
|
|
<P>
|
|
<TT>dip</TT> <EM>should</EM> configure your routing tables appropriately
|
|
for the SLIP connection when you connect. In some cases, however, <TT>dip</TT>'s
|
|
behavior may not be correct for your configuration, and you'll have to
|
|
run <TT>ifconfig</TT> or <TT>route</TT> commands by hand after connecting
|
|
to the server with <TT>dip</TT> (this is most easily done from within
|
|
a shell script that runs <TT>dip</TT> and immediately executes the
|
|
appropriate configuration commands). Your gateway is, in most cases,
|
|
the address of the SLIP server. You may know this address before hand,
|
|
or the gateway address will be printed by the SLIP server when you
|
|
connect. Your <TT>dip</TT> chat script (described below) can obtain this
|
|
information from the SLIP server.
|
|
<P>
|
|
<TT>ifconfig</TT> may require use of the <TT>pointopoint</TT> argument, if
|
|
<TT>dip</TT> doesn't configure the interface correctly. For example,
|
|
if your SLIP server address is 128.253.154.2, and your IP address
|
|
is 128.253.154.32, you may need to run the command
|
|
<BR><IMG WIDTH=453 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6437" SRC="img379.gif"><BR>
|
|
as <TT>root</TT>, after connecting with <TT>dip</TT>. The man pages for
|
|
<TT>ifconfig</TT> will come in handy.
|
|
<P>
|
|
<A NAME="6442"> </A>
|
|
<A NAME="6443"> </A>
|
|
Note that SLIP device names used with the <TT>ifconfig</TT> and <TT>route</TT>
|
|
commands are <TT>sl0</TT>, <TT>sl1</TT> and so on (as opposed
|
|
to <TT>eth0</TT>, <TT>eth1</TT>, etc. for Ethernet devices).
|
|
<P>
|
|
In Section <A HREF="node8.html#secadvusingdip">6.1.2</A>, below, we explain how to configure
|
|
<TT>dip</TT> to connect to the SLIP server.
|
|
<P>
|
|
<H5><A NAME="SECTION00813002000000000000">Static IP address SLIP connections using <TT>slattach</TT>.</A></H5>
|
|
<P>
|
|
<A NAME="6573"> </A>
|
|
<A NAME="6574"> </A>
|
|
<A NAME="6575"> </A>
|
|
If you have a leased line or cable running directly to your SLIP
|
|
server, then there is no need to use <TT>dip</TT> to initiate a connection.
|
|
<TT>slattach</TT> can be used to configure the SLIP device instead.
|
|
<P>
|
|
In this case, your <TT>/etc/rc.inet1</TT> file should look something like
|
|
the following:
|
|
<BR><IMG WIDTH=590 HEIGHT=192 ALIGN=BOTTOM ALT="tscreen6459" SRC="img380.gif"><BR>
|
|
<P>
|
|
<TT>slattach</TT> allocates the first unallocated SLIP device (<TT>sl0</TT>,
|
|
<TT>sl1</TT>, etc.) to the serial line specified.
|
|
<P>
|
|
Note that the first parameter to <TT>slattach</TT> is the SLIP protocol to use.
|
|
At present the only valid values are <TT>slip</TT> and <TT>cslip</TT>.
|
|
<TT>Slip</TT> is regular SLIP, as you would expect, and <TT>cslip</TT> is
|
|
SLIP with datagram header compression. In most cases you should use
|
|
<TT>cslip</TT>; however, if you seem to be having problems with this,
|
|
try <TT>slip</TT>.
|
|
<P>
|
|
If you have more than one SLIP interface then you will have routing
|
|
considerations to make. You will have to decide what routes to
|
|
add, and those decisions can only be made on the basis of the
|
|
actual layout of your network connections. A book on TCP/IP network
|
|
configuration, as well as the man pages to <TT>route</TT>, will be of
|
|
use.
|
|
<P>
|
|
<H5><A NAME="SECTION00813003000000000000">Dynamic IP address SLIP connections using <TT>dip</TT>.</A></H5>
|
|
<P>
|
|
<A NAME="6577"> </A>
|
|
<A NAME="6578"> </A>
|
|
<A NAME="6579"> </A>
|
|
If your SLIP server allocates an IP address dynamically, then you
|
|
certainly don't know your address in advance--therefore, you can't
|
|
include an entry for it in <TT>/etc/hosts</TT>. (You should, however,
|
|
include an entry for your host with the loopback address, 127.0.0.1.)
|
|
<P>
|
|
Many SLIP servers print your IP address (as well as the server's address)
|
|
when you connect. For example, one type of SLIP server prints a string
|
|
such as,
|
|
<BR><IMG WIDTH=287 HEIGHT=31 ALIGN=BOTTOM ALT="tscreen6477" SRC="img381.gif"><BR>
|
|
<TT>dip</TT> can capture these numbers from the output of the server and use them
|
|
to configure the SLIP device.
|
|
<P>
|
|
See page <A HREF="node8.html#secadvslipdip"><IMG ALIGN=BOTTOM ALT="gif" SRC="cross_ref_motif.gif"></A>, above, for information on configuring
|
|
your various TCP/IP files for use with SLIP. Below, we explain how to
|
|
configure <TT>dip</TT> to connect to the SLIP server.
|
|
<P>
|
|
<H2><A NAME="SECTION00814000000000000000">Using <TT>dip</TT>.</A></H2>
|
|
<P>
|
|
<A NAME="secadvusingdip"> </A>
|
|
<P>
|
|
<A NAME="6581"> </A>
|
|
<A NAME="6582"> </A>
|
|
<TT>dip</TT> can simplify the process of connecting to a SLIP server,
|
|
logging in, and configuring the SLIP device. Unless you have a leased
|
|
line running to your SLIP server, <TT>dip</TT> is the way to go.
|
|
<P>
|
|
<A NAME="6583"> </A>
|
|
To use <TT>dip</TT>, you'll need to write a ``chat script'' which
|
|
contains a list of commands used to communicate with the SLIP server
|
|
at login time. These commands can automatically send your user name/password
|
|
to the server, as well as get information on your IP address from the server.
|
|
<P>
|
|
Here is an example <TT>dip</TT> chat script, for use with a dynamic IP address
|
|
server. For static servers, you will need to set the variables
|
|
<TT>$local</TT> and <TT>$remote</TT> to the values of your local IP address
|
|
and server IP address, respectively, at the top of the script. See the
|
|
<TT>dip</TT> man page for details.
|
|
<P>
|
|
<BR><IMG WIDTH=618 HEIGHT=888 ALIGN=BOTTOM ALT="tscreen6494" SRC="img382.gif"><BR>
|
|
<P>
|
|
<TT>dip</TT> automatically executes <TT>ifconfig</TT> and <TT>route</TT> commands
|
|
based on the values of the variables <TT>$local</TT> and <TT>$remote</TT>.
|
|
Here, those variables are assigned using the <TT>get...remote</TT>
|
|
command, which obtains text from the SLIP server and assigns it to the
|
|
named variable.
|
|
<P>
|
|
If the <TT>ifconfig</TT> and <TT>route</TT> commands that <TT>dip</TT> runs for you
|
|
don't work, you can either run the correct commands in a shell script
|
|
after executing <TT>dip</TT>, or modify the source for <TT>dip</TT> itself.
|
|
Running <TT>dip</TT> with the <TT>-v</TT> option will print debugging information
|
|
while the connection is being set up, which should help you to determine
|
|
where things might be going awry.
|
|
<P>
|
|
Now, in order to run <TT>dip</TT> and open the SLIP connection, you can use
|
|
a command such as:
|
|
<BR><IMG WIDTH=306 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6510" SRC="img383.gif"><BR>
|
|
Where the various <TT>dip</TT> files, and the chat script (<TT>mychat.dip</TT>),
|
|
are stored in <TT>/etc/dip</TT>.
|
|
<A NAME="6584"> </A>
|
|
<A NAME="6585"> </A>
|
|
<P>
|
|
The above discussion should be enough to get you well on your way to
|
|
talking to the network, either via Ethernet or SLIP. Again, we strongly
|
|
suggest looking into a book on TCP/IP network configuration, especially
|
|
if your network has any special routing considerations, other than those
|
|
mentioned here.
|
|
<A NAME="6517"> </A>
|
|
<A NAME="6518"> </A>
|
|
<A NAME="6519"> </A>
|
|
<A NAME="6520"> </A>
|
|
<A NAME="6521"> </A>
|
|
<A NAME="6522"> </A>
|
|
<P>
|
|
<H1><A NAME="SECTION00820000000000000000">Dial-up networking and PPP.</A></H1>
|
|
<A NAME="secppp"> </A>
|
|
<P>
|
|
Linux supports a full implementation of the PPP (Point-to-Point)
|
|
networking protocols. PPP is a mechanism for creating and running IP
|
|
(the Internet Protocol) and other network protocols over a 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). This section will only cover configuring
|
|
PPP as a client connecting via an analog modem to a remote machine
|
|
that provides PPP dialup service.
|
|
<P>
|
|
For complete information on setting up PPP under Linux, we
|
|
encourage you to read the Linux PPP HOWTO, available via anonymous
|
|
FTP from <TT>sunsite.unc.edu</TT>. The PPP HOWTO is a complete guide to
|
|
configuring PPP, including modem, ISDN and null-modem cables, under Linux.
|
|
Much of the information in this section was gleaned from this document.
|
|
The <EM>Linux Network Administrator's Guide</EM>, from the Linux
|
|
Documentation Project, is also available. See Appendix <A
|
|
HREF="app-sources/node1.html">A</A>
|
|
for more information on these documents.
|
|
<P>
|
|
<H2><A NAME="SECTION00821000000000000000">6.2.1 What you need to get started.</A></H2>
|
|
<P>
|
|
We assume that your kernel has been configured and compiled with
|
|
TCP/IP support enabled. See Section <A HREF="node6.html#secsysadmupgrade">4.9</A> for information
|
|
on compiling your kernel. To enable networking, you must answer ``yes'' to the
|
|
appropriate questions during the <TT>make config</TT> step, and rebuild the
|
|
kernel. We also assume that ppp has been compiled and installed on your
|
|
system as well. We assume 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.0. At the time of
|
|
writing, the latest official version of PPP available for Linux is
|
|
ppp-2.2f. Please see the kerneld mini-HOWTO if you plan to use modules to load
|
|
ppp into your kernel. <EM>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.</EM>
|
|
<P>
|
|
You should also read
|
|
<UL>
|
|
<LI> the documentation that comes with the PPP package;
|
|
<LI> the pppd and chat man pages; (use <EM>man chat</EM> and <EM>man pppd</EM> to
|
|
explore these)
|
|
<LI> the Linux Network Administration Guide (NAG);
|
|
<LI> the Net-2/3 HOWTO;
|
|
<LI> Linux kernel documentation installed in /usr/src/linux/Documentation
|
|
when you install the Linux source code;
|
|
<LI> The modem setup information page--see Modem Setup Information
|
|
(http://www.in.net/info/modems/index.html)
|
|
<LI> The excellent Unix/Linux books published by O'Reilly and
|
|
Associates. See (O'Reilly and Associates On-Line catalog
|
|
(<TT>http://www.ora.com/</TT>). If you are new to Unix/Linux, run (don't
|
|
walk) to your nearest computer book shop and invest in a number of
|
|
these immediately!
|
|
<LI> The PPP-FAQ maintained by Al Longyear, available from
|
|
(<TT>ftp://sunsite.unc.edu/pub/Linux/docs/faqs</TT>; see
|
|
Appendix <A HREF="app-ftp/node1.html">B</A>).
|
|
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).
|
|
</UL><H2><A NAME="SECTION00822000000000000000">6.2.2 An overview of the steps involved.</A></H2>
|
|
<P>
|
|
There are several steps to setting up your system to use PPP. We recommend
|
|
that you read through all of these steps thoroughly before attempting to
|
|
actually bring up a PPP connection. Each of these steps will be discussed in
|
|
detail later.
|
|
<P>
|
|
<OL>
|
|
<LI> Make sure that TCP/IP support is compiled into your kernel.
|
|
<LI> Make sure that PPP support is compiled into your kernel either
|
|
statically or as a loadable module.
|
|
<LI> Make sure that PPP software is compiled and installed on your systems.
|
|
<LI> Make sure that you have a modem configured and installed/attached to
|
|
your computer and that you know which serial port the modem is
|
|
assigned to.
|
|
<LI> Make sure you have the following information from your PPP dialup server
|
|
provider (usually an ISP)
|
|
<UL>
|
|
<LI> The phone number you will dial to connect to the remote PPP dialup
|
|
service provider.
|
|
<LI> Whether or not you are using dynamic or static IP assignment. If the
|
|
latter, you will need to know that static IP number.
|
|
<LI> The IP addresss of the DNS (Domain Name Service) server that you will
|
|
be using to resolve host names when connected
|
|
</UL></OL><H5><A NAME="SECTION00822001000000000000">Make sure that the kernel has TCP/IP support.</A></H5>
|
|
<P>
|
|
Linux PPP operations come in two parts: 1) the PPP daemon and kernel support
|
|
for PPP. Most distributions seem to provide PPP kernel support in their
|
|
default installation kernels, but others do not. You should make sure that
|
|
TCP/IP is compiled into your kernel. You can do this by issuing the following
|
|
command:
|
|
<BR><IMG WIDTH=307 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6610" SRC="img384.gif"><BR>
|
|
<P>
|
|
If you get a line similar to
|
|
<P>
|
|
<BR><IMG WIDTH=737 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6612" SRC="img385.gif"><BR>
|
|
<P>
|
|
then you have TCP/IP support compiled in. You can also look for the above
|
|
information on the console while Linux is booting. On many fast machines, this
|
|
scrolls by too quickly. You can use Shift-PageUp to scroll the
|
|
screen up and see this.
|
|
<P>
|
|
<H5><A NAME="SECTION00822002000000000000">Make sure that the kernel has PPP support.</A></H5>
|
|
<P>
|
|
If at boot your kernel reports messages like
|
|
<P>
|
|
<BR><IMG WIDTH=427 HEIGHT=56 ALIGN=BOTTOM ALT="tscreen6617" SRC="img386.gif"><BR>
|
|
then your kernel has PPP support. You can also issue the command
|
|
<BR><IMG WIDTH=298 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6619" SRC="img387.gif"><BR>
|
|
If you get a line similar to
|
|
<P>
|
|
<BR><IMG WIDTH=806 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6621" SRC="img388.gif"><BR>
|
|
<P>
|
|
that means PPP support is present.
|
|
<P>
|
|
<H5><A NAME="SECTION00822003000000000000">Make sure that you have a modem configured.</A></H5>
|
|
<P>
|
|
You should make sure that your modem is correctly set up and that you know
|
|
which serial port it is connected to.
|
|
<P>
|
|
<UL>
|
|
<LI> DOS com1: = Linux /dev/cua0 (and /dev/ttyS0)
|
|
<LI> DOS com2: = Linux /dev/cua1 (and /dev/ttyS1),
|
|
<LI> et cetera
|
|
</UL>
|
|
<P>
|
|
Historically, Linux used cua<i>x</i> devices for dial out and
|
|
ttyS<i>x</i> devices for dial in. The kernel code that required this
|
|
was changed in kernel version 2.0.<i>x</i> and you should now use
|
|
ttyS<i>x</i> for both dial in and dial out. The cua<i>x</i>
|
|
device names may well disappear in future kernel versions.
|
|
<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 16550A. 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
|
|
<BR><IMG WIDTH=212 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6631" SRC="img389.gif"><BR>
|
|
<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).
|
|
You will need to configure your modem correctly for PPP--to do this
|
|
READ YOUR MODEM MANUAL! Most modems come with a factory default
|
|
setting that selects the options required for PPP. Recommended
|
|
configuration specifies (in standard Hayes commands):
|
|
<P>
|
|
<UL>
|
|
<LI> Hardware flow control (RTS/CTS) (&K3 on many modems)
|
|
<LI> E1 Command/usr/src/linux-2.0.27/include/linux/serial.h Echo ON
|
|
(required for chat to operate)
|
|
<LI> Q0 Report result codes (required for chat to operate)
|
|
<LI> S0=0 Auto Answer OFF (unless you want your modem to answer the phone)
|
|
<LI> &C1 Carrier Detect ON only after connect
|
|
<LI> &S0 Data Set Ready (DSR) always ON
|
|
<LI> (depends) Data Terminal Ready
|
|
</UL>
|
|
<P>
|
|
There is a site offering sample configurations for a growing variety
|
|
of modem makes and models at Modem setup information
|
|
(http://www.in.net/info/modems/index.html) which may assist you in
|
|
this.
|
|
<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&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&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, your 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).
|
|
<P>
|
|
<H5><A NAME="SECTION00822004000000000000">ISP information.</A></H5>
|
|
<P>
|
|
Before you can establish your PPP connection with a remote server, you
|
|
need to obtain the following information from the system administrator
|
|
or technical support people of the ISP.
|
|
<P>
|
|
<UL>
|
|
<LI> The telephone number(s) to dial for the service
|
|
If you are behind a PABX, you also need the PABX number that gives
|
|
you an outside dial tone--this is frequently digit zero (0) or
|
|
nine (9).
|
|
<LI> Does the server use DYNAMIC or STATIC IP numbers?
|
|
If the server uses STATIC IP numbers, then you may need to know
|
|
what IP number to use for your end of the PPP connection. If your
|
|
ISP is providing you with a subnet of valid IP numbers, you will
|
|
need to know the IP numbers you can use and the network mask
|
|
(netmask).
|
|
<P>
|
|
Most Internet Service Providers use DYNAMIC IP numbers. As
|
|
mentioned above, this has some implications in terms of the
|
|
services you can use.
|
|
<P>
|
|
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 do still need to know this
|
|
information!
|
|
<LI> What are the IP numbers of the ISPs Domain Name Servers?
|
|
There should be at least two although only one is needed.
|
|
<P>
|
|
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).
|
|
<P>
|
|
For Linux, you 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.
|
|
<LI> Does the server require the use of PAP/CHAP?
|
|
If this is the case you need to know the "id" and "secret" you are
|
|
to use in connecting. (These are probably your user name and
|
|
password at your ISP).
|
|
<LI> Does the server automatically start PPP or do you need to issue any
|
|
commands to start PPP on the server once you are logged in?
|
|
If you must issue a command to start PPP, what is it?
|
|
<LI> Is the server a Microsoft Windows NT system and, if so, is it using
|
|
the MS PAP/CHAP system?
|
|
Many corporate LANs seem to use MS Windows NT this way for
|
|
increased security.
|
|
</UL>
|
|
<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. Therefore to use a PPP connection must have an IP assigned
|
|
to you. Due to the increased number of machines on the Internet (partly do
|
|
the large number of PPP users), a dynamic scheme has been developed for
|
|
PPP that provides an IP on the fly to your machine when it first establishes
|
|
the PPP connection. This means that you will have a different IP address
|
|
every time you connect to the remote PPP dialup service. This is the most
|
|
common method for most ISPs. The other method is to use a static IP. You
|
|
cannot just choose an IP to us. It must be assigned by the centralized agency
|
|
in charge of issuing IP numbers. This prevents two computers from having the
|
|
same IP address and causing problems on the Internet. The remote PPP dialup
|
|
service provider will be able to tell you if you are using a static or
|
|
dynamic IP and also provide you with the actual IP number if you are using
|
|
the static method.
|
|
<P>
|
|
It is important to note that if you are using dynamic IP assignment, it will
|
|
be very very difficult to provide any permanent Internet services such as
|
|
World Wide Web servers, gopher services, or Internet Relay Chat servers. You
|
|
can still use such services that are on other machines but cannot offer such
|
|
services on your machine without going through an extreme amount of
|
|
effort. Doing this beyond the scope of this document.
|
|
<P>
|
|
PAP and CHAP are different commonly-used authentication methods. Linux
|
|
supports both of them.
|
|
<P>
|
|
<H5><A NAME="SECTION00822005000000000000">Testing your modem and remote service.</A></H5>
|
|
<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 or seyon),
|
|
set up the modem initialization 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 NOT trying to make a PPP connection--just
|
|
establishing that we have the right phone number and also to find out
|
|
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 (very carefully) write down 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:
|
|
<UL>
|
|
<LI> 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.
|
|
<LI> some servers require you to enter some text initially and then
|
|
start a standard PAP sequence.
|
|
<LI> 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!
|
|
<LI> 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!
|
|
</UL>
|
|
<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:
|
|
<P>
|
|
<UL>
|
|
<LI> the prompt that requests you to enter your user name;
|
|
<LI> the prompt that requests you to enter your password;
|
|
</UL>
|
|
<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 :
|
|
<PRE>y}#.!}!}!} }8}!}}U}"}\&} } } } }}\& ...}'}"}(}"} .~~y}</PRE>
|
|
<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 Enter to see if this
|
|
starts the PPP server.
|
|
<P>
|
|
At this point, you can hang up your modem (usually, type +++ quickly
|
|
and then issue the ATH0 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.
|
|
<P>
|
|
<H5><A NAME="SECTION00822006000000000000">Using Internet servers with dynamic IP numbers.</A></H5>
|
|
<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>
|
|
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.
|
|
<P>
|
|
<H5><A NAME="SECTION00822007000000000000">PPP connection files.</A></H5>
|
|
<P>
|
|
You now need to be logged in as root to create the directories and
|
|
edit the files needed to set up PPP. 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:
|
|
<P>
|
|
<BR><IMG WIDTH=474 HEIGHT=102 ALIGN=BOTTOM ALT="tabular6647" SRC="img390.gif"><BR>
|
|
|
|
<P>
|
|
For PPP 2.2 the files are:
|
|
<P>
|
|
<BR><IMG WIDTH=520 HEIGHT=124 ALIGN=BOTTOM ALT="tabular6653" SRC="img391.gif"><BR>
|
|
|
|
<P>
|
|
Red Hat Linux users should note that the standard Red Hat 4.X installation
|
|
places these scripts in /usr/doc/ppp-2.2.0f-2/scripts.
|
|
<P>
|
|
In your <TT>/etc</TT> directory there should be a ppp directory:
|
|
<PRE>drwxrwxr-x 2 root root 1024 Oct 9 11:01 ppp</PRE>
|
|
<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 options.tpl. 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
|
|
/etc/ppp/options 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>
|
|
Some distributions of PPP seem to have lost the options.tpl file.
|
|
You should examine the PPP-HOWTO document for the complete version.
|
|
<P>
|
|
<H5><A NAME="SECTION00822008000000000000">What options should I use?</A></H5>
|
|
<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
|
|
(/etc/ppp/options.tpl) and the pppd man pages 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.
|
|
<P>
|
|
<BR><IMG WIDTH=601 HEIGHT=391 ALIGN=BOTTOM ALT="tscreen6660" SRC="img392.gif"><BR>
|
|
<P>
|
|
<H5><A NAME="SECTION00822009000000000000">Setting up the PPP connection manually.</A></H5>
|
|
<P>
|
|
Now that you have created your /etc/ppp/options and /etc/resolv.conf
|
|
files (and, if necessary, the /etc/ppp/pap|chap-secrets 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 with the sequence
|
|
Control-A Q
|
|
<P>
|
|
<UL>
|
|
<LI> Make sure you are logged in as root.
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
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 Enter and see if the garbage starts up).
|
|
<LI>
|
|
Now quit the communications software without resetting the modem
|
|
and at the Linux prompt (as root) type
|
|
<P>
|
|
<BR><IMG WIDTH=238 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6667" SRC="img393.gif"><BR>
|
|
Substituting the name of the device your modem is connected to, of course.
|
|
<P>
|
|
The -d option enables debugging--the PPP connection start-up conversation
|
|
will be logged to your system log--which is useful for tracing problems
|
|
later.
|
|
<LI>
|
|
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>
|
|
</UL>
|
|
<P>
|
|
At this point you can look at the PPP interface, by issuing the command
|
|
<BR><IMG WIDTH=85 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6670" SRC="img394.gif"><BR>
|
|
<P>
|
|
In addition to any Ethernet and loop back devices you have, you should see
|
|
something like :
|
|
<PRE> 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</PRE>
|
|
<P>
|
|
Where
|
|
<UL>
|
|
<LI> inet addr:10.144.153.10 is the IP number of your end of the link.
|
|
<LI> P-t-P:10.144.153.5 is the SERVER's IP number.
|
|
</UL>
|
|
<P>
|
|
(Ifconfig will not report these IP numbers, but the ones used by your PPP
|
|
server.) Note: ifconfig also tells you that the link is UP and RUNNING!
|
|
<P>
|
|
You should also be able to see a route to the the remote host (and beyond).
|
|
To do this, issue the command
|
|
<P>
|
|
<BR><IMG WIDTH=84 HEIGHT=9 ALIGN=BOTTOM ALT="tscreen6674" SRC="img395.gif"><BR>
|
|
<P>
|
|
You should see something like:
|
|
<BR><IMG WIDTH=660 HEIGHT=112 ALIGN=BOTTOM ALT="tscreen6676" SRC="img396.gif"><BR>
|
|
<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
|
|
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 MUST be replaced by
|
|
a specific network route: YOU CAN ONLY HAVE ONE DEFAULT ROUTE!!!
|
|
<P>
|
|
You will need to explore your system initialization files to find out
|
|
where this default route is being set up (it will use a route add
|
|
default... command). Change this command to something like route add
|
|
net....
|
|
<P>
|
|
Now test the link by 'pinging' the server at its IP number as reported
|
|
by the ifconfig output, i.e.
|
|
<P>
|
|
<BR><IMG WIDTH=169 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6678" SRC="img397.gif"><BR>
|
|
<P>
|
|
You should receive output like
|
|
<P>
|
|
<BR><IMG WIDTH=522 HEIGHT=92 ALIGN=BOTTOM ALT="tscreen6680" SRC="img398.gif"><BR>
|
|
<P>
|
|
This listing will go on for ever--to stop it press
|
|
Control-C, at which point
|
|
you will receive some more information:
|
|
<P>
|
|
<BR><IMG WIDTH=487 HEIGHT=52 ALIGN=BOTTOM ALT="tscreen6684" SRC="img399.gif"><BR>
|
|
<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
|
|
<P>
|
|
<BR><IMG WIDTH=188 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6686" SRC="img400.gif"><BR>
|
|
<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
|
|
/etc/resolv.conf--so don't worry (but you will see your modem lights flash).
|
|
Shortly you will receive output like
|
|
<P>
|
|
<BR><IMG WIDTH=512 HEIGHT=112 ALIGN=BOTTOM ALT="tscreen6688" SRC="img401.gif"><BR>
|
|
<P>
|
|
Again, stop the output by pressing Control-C and get the statistics...
|
|
<P>
|
|
<BR><IMG WIDTH=487 HEIGHT=52 ALIGN=BOTTOM ALT="tscreen6692" SRC="img402.gif"><BR>
|
|
<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 /etc/resolv.conf.
|
|
<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
|
|
<P>
|
|
<BR><IMG WIDTH=75 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6694" SRC="img403.gif"><BR>
|
|
<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 by typing
|
|
<BR><IMG WIDTH=239 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6696" SRC="img404.gif"><BR><H2><A NAME="SECTION00823000000000000000">6.2.3 Creating the connection scripts.</A></H2>
|
|
<P>
|
|
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.
|
|
<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 /usr/sbin and for PPP 2.2 they are in
|
|
/etc/ppp/scripts. They are called
|
|
<P>
|
|
for PPP-2.1.2
|
|
<PRE> ppp-on
|
|
ppp-off</PRE>
|
|
<P>
|
|
and for PPP-2.2
|
|
<PRE> ppp-off
|
|
ppp-on
|
|
ppp-on-dialer</PRE>
|
|
<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 instead of the old PPP-2.1.2 scripts.
|
|
<P>
|
|
15.2. The ppp-on script
|
|
<P>
|
|
This is the first of a PAIR of scripts that actually fire up the
|
|
connection.
|
|
<P>
|
|
<BR><IMG WIDTH=649 HEIGHT=590 ALIGN=BOTTOM ALT="tscreen6700" SRC="img405.gif"><BR>
|
|
<P>
|
|
Here is the ppp-on-dialer script:
|
|
<P>
|
|
<BR><IMG WIDTH=592 HEIGHT=329 ALIGN=BOTTOM ALT="tscreen6702" SRC="img406.gif"><BR>
|
|
<P>
|
|
For PPP-2.2, the ppp-off script looks like:
|
|
<P>
|
|
<BR><IMG WIDTH=605 HEIGHT=667 ALIGN=BOTTOM ALT="tscreen6704" SRC="img407.gif"><BR>
|
|
<P>
|
|
<H2><A NAME="SECTION00824000000000000000">6.2.4 Editing the supplied PPP startup scripts.</A></H2>
|
|
<P>
|
|
As the new scripts come in two parts, and we will edit them in turn.
|
|
<P>
|
|
<H5><A NAME="SECTION00824001000000000000">The <TT>ppp-on</TT> script.</A></H5>
|
|
<P>
|
|
You will need to edit the ppp-on 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 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
|
|
/etc/ppp/options file, DELETE the line that says:
|
|
<P>
|
|
<PRE>$LOCAL_IP:$REMOTE_IP \</PRE>
|
|
<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 ppp-on script!
|
|
<P>
|
|
<H5><A NAME="SECTION00824002000000000000">The <TT>ppp-on-dialer</TT> script.</A></H5>
|
|
<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!
|
|
<P>
|
|
A chat script is a sequence of "expect string" "send string" pairs. In
|
|
particular, note that we ALWAYS expect something before we send
|
|
something.
|
|
<P>
|
|
If we are to send something WITHOUT receiving anything first, we must
|
|
use an empty expect string (indicated by "") and similarly for
|
|
expecting something without sending anything! Also, if a string
|
|
consists of several words, (e.g. NO CARRIER), you must quote the
|
|
string so that it is seen as a single entity by chat.
|
|
<P>
|
|
The chat line in our template is:
|
|
<P>
|
|
<BR><IMG WIDTH=187 HEIGHT=9 ALIGN=BOTTOM ALT="tscreen6709" SRC="img408.gif"><BR>
|
|
<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.
|
|
<P>
|
|
<BR><IMG WIDTH=143 HEIGHT=9 ALIGN=BOTTOM ALT="tscreen6711" SRC="img409.gif"><BR>
|
|
<P>
|
|
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!
|
|
<P>
|
|
<BR><IMG WIDTH=220 HEIGHT=10 ALIGN=BOTTOM ALT="tscreen6713" SRC="img410.gif"><BR>
|
|
<P>
|
|
If the string BUSY is received, abort the operation.
|
|
<P>
|
|
<BR><IMG WIDTH=263 HEIGHT=10 ALIGN=BOTTOM ALT="tscreen6715" SRC="img411.gif"><BR>
|
|
<P>
|
|
If the string NO ANSWER is received, abort the operation
|
|
<P>
|
|
<BR><IMG WIDTH=579 HEIGHT=150 ALIGN=BOTTOM ALT="tscreen6717" SRC="img412.gif"><BR>
|
|
<P>
|
|
Expect nothing from the modem and send the string AT.
|
|
<P>
|
|
<BR><IMG WIDTH=152 HEIGHT=10 ALIGN=BOTTOM ALT="tscreen6719" SRC="img413.gif"><BR>
|
|
<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!
|
|
<P>
|
|
<BR><IMG WIDTH=152 HEIGHT=9 ALIGN=BOTTOM ALT="tscreen6721" SRC="img414.gif"><BR>
|
|
<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.
|
|
<P>
|
|
<BR><IMG WIDTH=256 HEIGHT=11 ALIGN=BOTTOM ALT="tscreen6723" SRC="img415.gif"><BR>
|
|
<P>
|
|
Expect OK (the modem's response to the ATH0 command) and dial the
|
|
number we want to call.
|
|
<P>
|
|
<BR><IMG WIDTH=150 HEIGHT=9 ALIGN=BOTTOM ALT="tscreen6725" SRC="img416.gif"><BR>
|
|
<P>
|
|
Expect CONNECT (which our modem sends when the remote modem answers)
|
|
and send nothing in reply.
|
|
<P>
|
|
<BR><IMG WIDTH=205 HEIGHT=13 ALIGN=BOTTOM ALT="tscreen6727" SRC="img417.gif"><BR>
|
|
<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).
|
|
<P>
|
|
<BR><IMG WIDTH=214 HEIGHT=11 ALIGN=BOTTOM ALT="tscreen6729" SRC="img418.gif"><BR>
|
|
<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 (man 8 chat).
|
|
<P>
|
|
<H2><A NAME="SECTION00825000000000000000">6.2.5 Starting PPP at the server end.</A></H2>
|
|
<P>
|
|
While the <TT>ppp-on-dialer</TT> 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
|
|
expect send pair--this one would look for your login prompt (beware
|
|
of characters that have a special meaning in the Bourne shell, like
|
|
<BR><IMG WIDTH=21 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6733" SRC="img419.gif"><BR>
|
|
<P>
|
|
Once chat has found the shell prompt, chat must issue the ppp start up
|
|
command required for your ISPs PPP server.
|
|
<P>
|
|
In one author's case, the PPP server uses the standard Linux Bash prompt
|
|
<P>
|
|
<BR><IMG WIDTH=175 HEIGHT=13 ALIGN=BOTTOM ALT="tscreen6735" SRC="img420.gif"><BR>
|
|
which requires the response
|
|
<BR><IMG WIDTH=41 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6737" SRC="img421.gif"><BR>
|
|
to start up PPP on the server.
|
|
<P>
|
|
It is a good idea to allow for a bit of error recovery here, so use
|
|
<BR><IMG WIDTH=136 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6739" SRC="img422.gif"><BR>
|
|
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 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 "expect" strings.
|
|
<P>
|
|
<H2><A NAME="SECTION00826000000000000000">6.2.6 If your PPP server uses PAP (Password Authentication Protocol).</A></H2>
|
|
<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
|
|
<P>
|
|
<BR><IMG WIDTH=642 HEIGHT=351 ALIGN=BOTTOM ALT="tscreen6742" SRC="img423.gif"><BR>
|
|
<P>
|
|
<H2><A NAME="SECTION00827000000000000000">6.2.7 Using MSCHAP.</A></H2>
|
|
<P>
|
|
Microsoft Windows NT RAS can be set up to use a variation on CHAP
|
|
(Challenge/Handshake Authentication Protocol). In your PPP sources
|
|
you will find a file called README.MSCHAP80 that discusses this.
|
|
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
|
|
<P>
|
|
<BR><IMG WIDTH=597 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6745" SRC="img424.gif"><BR>
|
|
<P>
|
|
The critical information here is <TT>auth chap 80.</TT>
|
|
<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>
|
|
If you are using pap or chap authentication, then you also need to create
|
|
the secrets file. These are 1)/etc/ppp/pap-secrets and 2)/etc/ppp/chap-secrets.
|
|
<P>
|
|
They must be owned by user root, group root and have file permissions 740 for
|
|
security. The first point to note about PAP and CHAP is that they are designed
|
|
to authenticate computer systems not users. In other words, once your
|
|
computer has made its PPP connection to the server, ANY user on your system
|
|
can use that connection--not just you.
|
|
<P>
|
|
PAP can (and for CHAP DOES) require bidirectional authentication--that is a
|
|
valid name and secret is required on each computer for the other computer
|
|
involved. However, this is 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.
|
|
This is done using the name user name option to pppd. So, if you are to use
|
|
the user name given you by your ISP, add the line
|
|
<P>
|
|
<PRE>name your_user name_at_your_ISP</PRE>
|
|
<P>
|
|
to your /etc/ppp/options file.
|
|
<P>
|
|
Technically, you should really use <TT>user our_user name_at_your_ISP</TT> for
|
|
PAP, but pppd is sufficiently intelligent to interpret name as user if it is
|
|
required to use PAP. The advantage of using the name option is that this is
|
|
also valid for CHAP.
|
|
<P>
|
|
As PAP is for authenticating 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>
|
|
The <TT>/etc/ppp/pap-secrets</TT> file looks like
|
|
<P>
|
|
<PRE>
|
|
# Secrets for authentication using PAP
|
|
# client server secret acceptable_local_IP_addresses</PRE>
|
|
<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 fred and a password of
|
|
flintstone you would set the name fred option in
|
|
<TT>/etc/ppp/options</TT> and set up your <TT>/etc/ppp/pap-secrets</TT> file as
|
|
follows
|
|
<P>
|
|
<PRE> # Secrets for authentication using PAP
|
|
# client server secret acceptable local IP addresses
|
|
fred * flintstone</PRE>
|
|
<P>
|
|
This says for the local machine name fred (which we have told pppd to
|
|
use even though it is not our local machine name) and for ANY server,
|
|
use the password (secret) of 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.
|
|
<P>
|
|
This requires that you have mutual authentication methods--that is
|
|
you must allow for both your machine to authenticate the remote server
|
|
AND the remote server to authenticate your machine.
|
|
<P>
|
|
So, if your machine is fred and the remote is barney, your machine
|
|
would set name fred remotename barney and the remote machine would set
|
|
name barney remotename fred in their respective /etc/ppp/options.ttySx
|
|
files.
|
|
<P>
|
|
The <TT>/etc/chap-secrets</TT> file for fred would look like
|
|
<P>
|
|
<PRE> # Secrets for authentication using CHAP
|
|
# client server secret acceptable local IP addresses
|
|
fred barney flintstone
|
|
barney fred wilma</PRE>
|
|
and for barney
|
|
<PRE> # Secrets for authentication using CHAP
|
|
# client server secret acceptable local IP addresses
|
|
barney fred flintstone
|
|
fred barney wilma</PRE>
|
|
<P>
|
|
Note in particular that both machines must have entries for
|
|
bidirectional authentication. This allows the local machine to
|
|
authenticate itself to the remote AND the remote machine to
|
|
authenticate itself to the local machine.
|
|
<P>
|
|
<H5><A NAME="SECTION00827001000000000000">A chat script for PAP/CHAP authenticated connections.</A></H5>
|
|
<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!
|
|
<P>
|
|
<BR><IMG WIDTH=591 HEIGHT=289 ALIGN=BOTTOM ALT="tscreen6754" SRC="img425.gif"><BR>
|
|
<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>
|
|
<BR><IMG WIDTH=565 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6756" SRC="img426.gif"><BR><H5><A NAME="SECTION00827002000000000000">Testing the connection script.</A></H5>
|
|
<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
|
|
<BR><IMG WIDTH=229 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6759" SRC="img427.gif"><BR>
|
|
Many systems log output to <TT>/var/log/messages</TT>. If it has a
|
|
different name on your system, substitute the name of your system log
|
|
file in the command above.
|
|
<P>
|
|
In the first window (or virtual console) issue the command
|
|
<P>
|
|
<BR><IMG WIDTH=83 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6762" SRC="img428.gif"><BR>
|
|
<P>
|
|
(or whatever name you have called your edited version of
|
|
<TT>/usr/sbin/ppp-on</TT>). 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>
|
|
<H2><A NAME="SECTION00828000000000000000">6.2.8 Shutting down the PPP link.</A></H2>
|
|
<P>
|
|
When you have finished with the PPP link, use the standard <TT>ppp-off</TT>
|
|
command to shut it down (remember that you must be root or a member of
|
|
the <TT>ppp</TT> group!).
|
|
<P>
|
|
<H2><A NAME="SECTION00829000000000000000">6.2.9 Troubleshooting common problems once the link is working.</A></H2>
|
|
<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)!
|
|
<P>
|
|
<H5><A NAME="SECTION00829001000000000000">Address resolution problems.</A></H5>
|
|
<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
|
|
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 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
|
|
<BR><IMG WIDTH=127 HEIGHT=12 ALIGN=BOTTOM ALT="tscreen6770" SRC="img429.gif"><BR>
|
|
Substituting, of course, the name of your actual ISP. If this does not
|
|
work, you have a problem with name resolution. This is probably
|
|
because of a typo in your <TT>/etc/resolv.conf</TT> file. Check this
|
|
file carefully against the information in the sample <TT>
|
|
/etc/resolve.conf</TT> file in section <A HREF="node8.html#secresolveconf">6.1.1</A>.
|
|
<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 check carefully through your Linux installation (looking
|
|
particularly at file permissions).
|
|
<P>
|
|
If you still can't <TT>ping</TT> 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.
|
|
<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>
|
|
<H5><A NAME="SECTION00829002000000000000">Debugging a failed attempt.</A></H5>
|
|
<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.
|
|
<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.
|
|
<P>
|
|
<UL>
|
|
<LI> You failed to boot the new kernel that you compiled with PPP support.
|
|
<LI> You failed to install the PPP module that you compiled.
|
|
<LI> You expected modules to be loaded automatically and they aren't.
|
|
<LI> You are using the incorrect version of PPP for your kernel.
|
|
<LI> You are not running pppd as root.
|
|
<LI> You mistyped something in your startup scripts.
|
|
<LI> You are not correctly logging into the server.
|
|
<LI> You are not starting PPP on the server.
|
|
<LI> The remote PPP process is slow to start.
|
|
<LI> Default route not set.
|
|
</UL>
|
|
<P>
|
|
And a host of others. 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! If the answer to your problems is not there, the problem is not
|
|
ppp's fault!
|
|
<P>
|
|
<H5><A NAME="SECTION00829003000000000000">Getting help when totally stuck.</A></H5>
|
|
<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>
|
|
If you do choose to seek help in the USENET newsgroups, please
|
|
don't post a very long message consisting of debugging output. This wastes
|
|
huge amounts of network bandwidth. It is much better to describe the problem
|
|
and perhaps include a few lines of debugging output (definitely no more
|
|
than one screenful).
|
|
<P>
|
|
<A NAME="6780"> </A>
|
|
<P>
|
|
<HR><A NAME="tex2html879" HREF="node9.html"><IMG WIDTH=37 HEIGHT=24 ALIGN=BOTTOM ALT="next" SRC="next_motif.gif"></A> <A NAME="tex2html877" HREF="gs.html"><IMG WIDTH=26 HEIGHT=24 ALIGN=BOTTOM ALT="up" SRC="up_motif.gif"></A> <A NAME="tex2html871" HREF="node7.html"><IMG WIDTH=63 HEIGHT=24 ALIGN=BOTTOM ALT="previous" SRC="previous_motif.gif"></A> <A NAME="tex2html881" HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A NAME="tex2html880" HREF="node9.html"> About this document </A>
|
|
<B>Up:</B> <A NAME="tex2html878" HREF="gs.html">Linux Installation and Getting </A>
|
|
<B> Previous:</B> <A NAME="tex2html872" HREF="node7.html">5 The X Window </A>
|
|
<P><ADDRESS>
|
|
<I>Clarica Grove <BR>
|
|
Wed Mar 4 10:46:42 PST 1998</I>
|
|
</ADDRESS>
|
|
</BODY>
|
|
</HTML>
|