The configurations above have described how a typical Linux workstation might be configured for normal end-user operation. Some of you will have other requirements which will require slightly more advanced configurations. What follows are examples of some the more common of these.
The Point to Point Protocol is a modern and efficient protocol for conveying multiple protocols, tcp/ip for one, across serial links, that a lot of people use in place of slip. It offers enhanced functionality, error detection and security options. It corrects a number of deficiencies that are found in slip, and is suitable for both asynchronous links and synchronous links alike.
An important feature of PPP operation is dynamic address allocation, and this feature will almost certainly be exploited by your PPP server. This feature allows a PPP client, with a specially formatted frame, to request its address from the server. In this way configuration is somewhat less messy than with slip, since this ability to retrieve your address must occur outside of the protocol.
The authors of the Linux port are Michael Callahan,
<callahan@maths.ox.ac.uk>
and Al Longyear,
<longyear@netcom.com>
. Most of this information has come from
the documentation that accompanies the PPP software. The documentation
is quite complete, and will tell you much more than I present here.
The Linux PPP code has come out of Alpha testing and is now available as a public release. The 1.0.0 Linux PPP code is based on Paul Mackerras's free PPP for BSD-derivative operating systems. The 1.0.0 release is based on version 2.1.1 of the free PPP code.
The PPP code comes in two parts. The first is a kernel module which handles the assembly and disassembly of the frames, and the second is a set of protocols called LCP, IPCP, UPAP and CHAP, for negotiating link options, bringing the link into a functioning state and for authentication.
You would use PPP in place of SLIP for a few reasons. The most common are:
The most obvious reason you would use PPP in favour of SLIP is when your Internet Provider supports PPP and not SLIP. Ok, I said it was obvious.
PPP provides a frame check sequence for each and every frame transmitted, SLIP does not. If you have a noisy serial line, and you are using SLIP, your error correction will be performed end to end, that is between your machine and the destination machine, whereas with PPP the error detection occurs locally, between your machine and the PPP server. This makes for faster recovery from errors.
PPP provides a number of features that SLIP does not. You might for example want to carry not only IP, but also DECNET, or AppleTalk frames over your serial link. PPP will allow you to do this.
The ppp software is available from:
sunsite.unc.edu
/pub/Linux/system/Networking/serial/ppp-2.1.2a.tar.gz
This file contains the kernel source, and the pppd source and binary. Version 1.0.0 is meant for use with kernels 1.0.x and 1.1.x. No support is currently available for Fred's Net-2E kernel.
Installation of the PPP software is fairly straightforward.
Some support for ppp has been built into the kernel for some time. Configuring the kernel is fairly easy, the following should work ok:
# cd /usr/src
# gzip -dc ppp-2.1.2a.tar.gz | tar xvf -
# cp /usr/src/ppp-2.1.2a/linux/ppp.c /usr/src/linux/drivers/net
# cp /usr/src/ppp-2.1.2a/pppd/ppp.h /usr/src/linux/include/linux
You will then need to uncomment the CONFIG_PPP
line in
/usr/src/linux/config.in
. If you are running a version of the
kernel that is 1.1.4 or higher, then you will also need to comment out or
delete the macro definition of NET02D
in the file
/usr/src/linux/drivers/net/ppp.c
. If you are running an even more
recent version then you make not to make any changes at all.
You can then do a make config, select PPP support, and follow with a make dep;make.
When you reboot with the new kernel you should see messages at boot time that look something like these:
PPP: version 2.1.1 (4 channels)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
Now, try looking at the contents of /proc/net/dev
. It should look
something like this:
Inter-| Receive | Transmit
face |packets errs drop fifo frame|packets errs drop fifo colls carrier
lo: 0 0 0 0 0 0 0 0 0 0 0
ppp0: 0 0 0 0 0 0 0 0 0 0 0
ppp1: 0 0 0 0 0 0 0 0 0 0 0
ppp2: 0 0 0 0 0 0 0 0 0 0 0
ppp3: 0 0 0 0 0 0 0 0 0 0 0
This indicates that the kernel driver is installed correctly.
If you want to recompile pppd, type make in the pppd
subdirectory of the installation. There will be some warnings when compiling
lcp.c
, upap.c
and chap.c
but these are OK.
If you want to recompile chat, consult README.linux
in the
chat
directory.
To install, type make install in the chat
and pppd
directories. This will put chat and pppd binaries in
/usr/etc
and the pppd.8
manual page in /usr/man/man8
.
pppd
needs to be run as root
. You can either make it suid
root or just use it when you are root. make install will try to
install it suid root, so if you are root when you try to install it, it should
work ok.
Like slip, you can configure the PPP software as either a client or a server. The chat performs a similar function to the dip program in that it is used to automate the dialling and login procedure to the remote machine, unlike dip though, it does not perform the ioctl to convert the serial line into a PPP line. This is performed by the pppd program. pppd can act as either the client or the server. When used as a client, it normally invokes the chat program to perform the connection and login, and then it takes over by performing the ioctl to change the line discipline to ppp and then steps out of the way to let you operate.
Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the operation of these utilities is much more complete than I have described here.
This is perhaps what most of you will want to do, so it appears first. You would use this configuration when you have a network provider who supports ppp by dialup modem. When you want to establish your connection you simply have to invoke the pppd program with appropriate arguments.
The following example might look a little confusing at first, but it is easier to understand if you can see that all it is doing is taking a command line for the chat program as its first argument and then others for itself later.
pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: password'\
/dev/cua1 38400 debug crtscts modem defaultroute 192.1.1.17:
What this says is:
chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: password
Which says: Dial 5551212, wait for the `CONNECT' string, transmit a carriage
return, wait for the string `ogin:', transmit the string `ppp', wait for the
string `word:', transmit the string `password', and quit./dev/cua1
192.1.1.17
. This argument normally looks like x.x.x.x:y.y.y.y, where
x.x.x.x is your ip address, and y.y.y.y is the ip address of the server. If you
leave off the server's address, pppd will ask for it, and x.x.x.x will
be set to your machines ip address.Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.
Configuring a PPP client via a leased line is almost as straightforward as for configuring slip with slattach. You will still use the pppd program, but since you won't need to establish the modem link the arguments to the chat program can be much simpler.
The example I'm presenting here assumes that the ppp server doesn't require any special login procedure. I do this because every login procedure will be different, and if you are simply running a local connection then it is possible that you might have it set up this way.
pppd connect 'echo connecting...' defaultroute noipdefault debug \
kdebug 2 /dev/cua0 9600
This will echo a message to your screen, and set your default route via the
ppp interface. The noipdefault argument instructs the
pppd program to request the address to use for this device from
the server. Debug messages will go to syslog. The kdebug 2
argument causes the debug messages to be set to level 2, this will give you
slightly more information on what is going on. It will use /dev/cua0
at 9600 bps.
If your ppp server does require some sort of login procedure, you can easily use the chat program as in the example for the dialup server to perform that function for you.
Please refer to the pppd and chat man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here.
Configuring a PPP server is similar to establishing a slip server.
You can create a special `ppp' account, which uses an executable script
as its login shell. The /etc/passwd
entry might look like:
ppp:EncPasswd:102:50:PPP client login:/tmp:/etc/ppp/ppplogin
and the /etc/ppp/ppplogin
script might look like:
#!/bin/sh
exec /usr/etc/pppd passive :192.1.2.23
The address that you provide will be the address that the calling machine will be assigned.
Naturally, if you want multiple users to have simultaneous access you would have to create a number of startup scripts and individual accounts for each to use, as you can only put one ip address in each script.
Most discussion on PPP for Linux takes place on the PPP mailing list.
To join the Linux PPP channel on the mail list server, send mail to:
linux-activists@niksula.hut.fi
with the line:
X-Mn-Admin: join PPP
at the top of the message body (not the subject line).
Please remember that when you are reporting bugs or problems you should include as much information relevant to the problem as you can to assist those that will help you understand your problem.
You might also like to check out:
RFCS 1548, 1331, 1332, 1333, and 1334. These are the definitive documents for PPP.
W. Richard Stevens also describes PPP in his book `TCP/IP Illustrated Volume 1', (Addison-Wessley, 1994, ISBN 0-201-63346-9).
If you have a machine that is perhaps network connected, that you'd like other people be able to dial into, and provide network services, then you will need to configure your machine as a server. If you want to use slip as the serial line protocol, then currently you have two options as to how to configure your Linux machine as a slip server. I will present a summary of both.
sliplogin is a program that you can use in place of the normal login
shell for slip users that converts the terminal line into a slip line. The
caller will login as per the standard login process, entering their username
and password, but instead of being presented with a shell after their login,
sliplogin is executed which searches its configuration file
(/etc/slip.hosts
) for an entry with a login name that matches that of
the caller. If it locates one, it configures the line as an 8bit clean line,
and uses an ioctl call to convert the line discipline to slip. When
this process is complete, the last stage of configuration takes place, where
sliplogin invokes a shell script which configures the slip interface with the
relevant ip address, netmask and sets appropriate routing in place. This script
is usually called /etc/slip.login
, but in a similar manner to
getty, if you have certain callers that require special initialisation,
then you can create configuration scripts called
/etc/slip.login.loginname
that will be run instead of the default.
sliplogin can be obtained from:
sunsite.unc.edu
/pub/Linux/system/Network/serial/sliplogin.tar.gz
The tar file contains both source, precompiled binaries and a man page.
To install the binaries into your /sbin
directory, and the man
page into section 8, do the following:
# cd /usr/src
# gzip -dc .../sliplogin.tar.gz | tar xvf -
# cd src
# make install
If you want to recompile the binaries before installation, add a
make clean
before the make install
. If you want to install
the binaries somewhere else, you will need to edit the Makefile
install rule.
/etc/passwd
for Slip hosts. You need to create some special logins for Slip callers in your /etc/passwd
file. A convention commonly followed is to use the hostname of the
calling host with a capital `S' prefixing it. So, for example, if the calling
host is called radio
then you would create a /etc/passwd
entry that looked like:
Sradio:FvKurok73:1427:1:radio slip login:/tmp:/sbin/sliplogin
Note: the caller doesn't need any special home directory, as they will not
be presented with a shell from this machine, so /tmp
is a good choice.
Also note that sliplogin is used in place of the normal login shell.
/etc/slip.hosts
The /etc/slip.hosts
file is the file that sliplogin
searches for entries matching the login name to obtain configuration details
for this caller. It is this file where you specify the ip address and netmask
that will be assigned to the caller, and configured for their use. A sample
entry for host `radio' might look like:
Sradio `hostname` radio <netmask> <opt1> <opt2>
The /etc/slip.hosts
file entries are:
Note: You can use either hostnames or IP addresses in dotted decimal notation for fields 2 and 3. If you use hostnames then those hosts must be resolvable, that is, your machine must be able to locate an ip address for those hostnames, otherwise the script will fail when it is called. You can test this by trying trying to telnet to the hostname, if you get the `Trying nnn.nnn.nnn...' message then your machine has been able to find an ip address for that name. If you get the message `Unknown host', then it has not. If not, either use ip addresses in dotted decimal notation, or fix up your name resolver configuration.
The most commonly used optional paramaters for the opt1
and
opt2
fields are:
to enable normal uncompressed slip.
to enable van Jacobsen header compression (cslip)
Naturally these are mutually exclusive, you can use one or the other. For more information on the other options available, refer to the man pages.
/etc/slip.login
file. After sliplogin has searched the /etc/slip.hosts
and found
a matching entry, it will attempt to execute the /etc/slip.login
file
to actually configure the slip interface with its ip address and netmask.
The sample /etc/slip.login
file supplied with the sliplogin
package looks like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig $1 $4 pointopoint $5 mtu 1500 -trailers up
/sbin/route add $5
exit 0
You will note that this script simply uses the ifconfig and route commands to configure the slip device with its ipaddress, remote ip address and netmask, and creates a route for the remote address via the slip device. Just the same as you would if you were using the slattach command.
/etc/slip.logout
file. When the call drops out, you want to ensure that the serial device is restored
to its normal state so that future callers will be able to login correctly.
This is achieved with the use of the /etc/slip.logout
file. It is
quite simple, and again, I'll present the sample included in the
sliplogin package.
#!/bin/sh -
#
# slip.logout
#
/sbin/ifconfig $1 down
/sbin/route del $5
exit 0
All it does is `down' the interface and delete the manual route previously created.
Let me start by saying that some of the information below came from the dip man pages, where how to run Linux as a slip server is briefly documented.
To configure Linux as a slip server, you need to create some special slip accounts for users, where dip (in slave mode) is used as the login shell. Fred suggests that he has a convention of having all of his slip accounts begin with a capital `S', eg `Sfredm'.
Because the login program won't accept arguments to the login shell, you will need to create a small program that looks like the following:
/* dip-i.c - from a mail message of Karl kkeyte@esoc.bitnet */
int main()
{
execlp("dip", "dip", "-i", (char *) 0);
}
Compile it with: gcc -O dip-i.c -o dip-i
Give it permissions 555
. I recommend calling it /usr/bin/dip-i
as shown below.
A sample /etc/passwd
entry for a slip user looks like:
Sfredm:ij/SMxiTlGVCo:1004:10:UUNET:/tmp:/usr/bin/dip-i
^^ ^^ ^^ ^^ ^^ ^^ ^^
| | | | | | \__ shell program running
| | | | | | dip -i as login shell
| | | | | \_______ Home directory
| | | | \_____________ User Full Name
| | | \__________________ User Group ID
| | \______________________ User ID
| \________________________________ Encrypted User Password
\___________________________________________ Slip User Login Name
After the user logs in, the login(1) program, if it finds and verifies
the user ok, will execute the shell program dip-i which will execute
the dip command in input mode (-i
). dip now scans
the /etc/net/diphosts
file for an entry for the given user name.
Therefore, each slip user must also have an entry in /etc/net/diphosts
.
You will have to re-read section `Proxy Arp' to arrange for your machine to proxy arp for the slip users who will be using your system if you want them to have access to any network that your server machine might be connected to.
/etc/net/diphosts
/etc/net/diphosts
is used by dip to lookup preset
configurations for remote hosts. These remote hosts might be users
dialing into your linux machine, or they might be for machines that you dial
into with your linux machine.
The general format for /etc/net/diphosts
is as follows:
Suwalt::145.71.34.1:SLIP uwalt:CSLIP,1006
^ ^ ^ ^ ^ ^
| | | | | \___ MTU
| | | | \_________ protocol (SLIP, CSLIP,
| | | | KISS)
| | | \___________________ comment field
| | \________________________________ IP address of the other
| | side, or host.domain.name
| \___________________________________ unused (compat. with passwd)
\________________________________________ login name (as returned by
getpwuid(getuid()))
An example /etc/net/diphosts
entry for a remote slip user might be:
Sfredm::145.71.34.1:SLIP uwalt:SLIP,296
which specifies a slip link with MTU of 296, or
Sfredm::145.71.34.1:SLIP uwalt:CSLIP,1006
which specifies a cslip-capable link with MTU of 1006.
When a user logs in, they will receive a normal login, and password prompt, at
which they should enter their slip-login userid and password. If they check out
ok, then the user will see no special messages, they should just change into
slip mode at their end, and then they should be able to connect ok, and be
configured with the parameters from the diphosts
file.
This section has been supplied by Mitch DSouza
, and I've included
it with minimal editing, as he supplied it. Thanks Mitch.
An automounter provides a convenient means of mounting filesystems on demand, i.e. when requried. This will reduce both the server and the client load, and provides a great deal of flexibility even with non-NFS mounts. It also offers a redundancy mechanism whereby a mount point will automatically switch to a secondary server should a primary one be unavailable. A rather useful mount called the union mount gives the automounter the ability to merge the contents of multiple directories into a single directory. The documentation msut be read thoroughly to make full use of its extensive capabilities.
A few important points must be remembered - (in no particular order):
contrib
directory -
automount2amd.pl
.
..., opts:=type=msdos,conv=auto
/home
when some user directory is /home/fred
.
% amq -ms
reports, as it will indicate problems as they occur.
# /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net
amd can be obtained from:
sunsite.unc.edu
/pub/Linux/system/Misc/mount/amd920824upl67.tar.gz
This contains ready-to-run binaries, full sources and documentation in texinfo format.
You do not configure the automounter from the /etc/fstab
file, which you will already be using to contain information about your
fileystems, instead it is command line driven.
To mount two nfs filesystems using your /etc/fstab
file
you would use two entries that looked like:
server-1:/export/disk /nfs/server-1 nfs defaults
server-2:/export/disk /nfs/server-2 nfs defaults
i.e. you were nfs mounting server-1
and server-2
on your linux disk on the /nfs/server-1
and /nfs/server-2
directories.
After commenting out, or deleting the above lines from your /etc/fstab
file, you could amd to perform the same task with the following
syntax:
/etc/amd -x all -l syslog -a /amd -- /nfs /etc/amd.server
| | | | | | | | | | | | |
| | | | | | | | | | | | |
`------' `----' `-------' `-----' -' `--' `-------------'
| | | | | | |
(1) (2) (3) (4) (5) (6) (7)
Where:
/amd
directory as a temporary place for
automount points. This directory is created automatically by amd
and should be removed before starting amd in your
/etc/rc
scripts.
# /etc/amd.server
/defaults opts:=rw;type:=nfs
server-1 rhost:=server-1;rfs:=/export/disk
server-2 rhost:=server-2;rfs:=/export/disk
Once started and successfully running, you can query the status of the mounts with the command:
% amq -ms
Now if you say:
% ls /nfs
you should see no files. However the command:
% ls /nfs/server-1
will mount the host `server-1' automatically. voila! amd is
running. After the default timeout has expired, this will automatically be
unmounted. Your /etc/password
file could contain entries like:
...
linus:EncPass:10:0:God:/nfs/server-1/home/linus:/bin/sh
mitch:EncPass:20:10:Mitch DSouza:/nfs/server-1/home/mitch:/bin/tcsh
matt:EncPass:20:10:Matt Welsh:/nfs/server-1/home/matt:/bin/csh
which would mean that when Linus, Matt, or Mitch are logged in, their home directory will be remotely mounted from the appropriate server, and umounted when they log out.
Linux will function just fine as a router. You should run a routing daemon such as gated, or if you have simple routing requirements use hard coded routes. If you are using a late version kernel (1.1.*) then you should ensure that you have answered `y' to:
IP forwarding/gatewaying (CONFIG_IP_FORWARD) [y] y
when building your kernel.
Olaf Kirch's Network Administrators Guide discusses network design and routing issues, and you should read it for more information. A reference to it is in the "Related Documentation" section of this document.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter