In addition to the networking mechanisms we have already considered, there are also several other possibilities, though in general these are lesser alternatives.
SLIP is a serial line IP protocol which is being superseded by PPP. This is largely because PPP is an Internet standard whereas SLIP is not. In concept, SLIP is quite similar to PPP except that SLIP is less robust and rather more error prone.
In order for Linux to support SLIP, it needs to be configured and built into the kernel at kernel build time. As usual, this is just a case of saying yes to the appropriate option when you are setting the configuration at the start of the kernel build.
Once SLIP is built into the kernel, a program called dip can be run, which acts for SLIP much like the combination of pppd and chat act for PPP.
The way to use dip is to generate a script file which specifies the sequence of actions and operations you need dip to perform. See the dip manual page for details of generating and modifying script files.
PLIP is a parallel line IP protocol. It can be used to connect two machines over standard parallel printer ports. This arrangement might be useful where, for instance you have a notebook or laptop computer without a standard network interface and would like to be able to connect it, from time to time, to your desktop machine at home or in the office.
Once again, PLIP is an option which needs to be compiled into your kernel before be used. However, once it is available in the kernel, setting up the software is quite straightforward. The only difficulty with a PLIP setup is in getting hold a lead to connect the two machines together. In fact, you can buy the necessary cable as a parallel Laplink cable, or you may opt to build the cable yourself if you are handy with a soldering iron.
If you want to go for the DIY option you will need a pair of 25-way male D-type connectors (to plug into the printer ports of your two machines) and a suitable length of multi-core cable with at least 12 individual wires in it. Once you have assembled the bits, the necessary connections are as follows:
Plug A - Plug B 2 - 15 3 - 13 4 - 12 5 - 10 6 - 11 10 - 5 11 - 6 12 - 4 13 - 3 15 - 2 17 - 17 25 - 25
All the other pins in both plugs should remain unconnected.
In order to get a PLIP link working once the two machines are connected together all you need to do is to add the following lines to the rc.inet1 configuration files:
/sbin/ifconfig plip0 la.la.la.la pointopoint ra.ra.ra.ra up /sbim/route add -host ra.ra.ra.ra plip0
where la.la.la.la is the local machine IP address number and ra.ra.ra.ra is the remote machine IP address number.
Before the advent of the Internet the only real communication between machines was performed over serial links, typically using slow modems. Even in this situation there was still a requirement to send e-mail between users on different machines and a need to upload and download files.
UUCP was designed to fulfill these early requirements by providing a simple dial-up network over ordinary telephone lines with modems. Although UUCP has been around for many years there are still large numbers of machines that use the system.
The setup of UUCP requires the creation and configuration of several files the details of which are beyond the scope of this tutorial. There is, however, a very readable account of the basics of UUCP setup in the Linux Network Administrator's Guide, available as part of the Linux documentation project and also available with the extras in many Linux distributions.
Beyond the network interfaces for communication, there are several programs which provide you with the ability to make a connection and login to a remote machine, and which will then act as a dumb terminal emulator for the duration of your login session. As an extra feature, most of the programs of this type also allow you the facility to upload and download files. In general, uploading a file means transferring the contents of a file from your local machine to the machine at the remote end of the link. And downloading a file means transferring it the other way, from the remote machine to your local machine.
Two programs that are easy to obtain for Linux are kermit and seyon. The kermit program will operate directly on a standard terminal screen, while seyon needs to be run within an X-windows environment.
Conceptually, the two programs are very similar, though their user interfaces are very different. In order to give the flavor of the facilities available with these programs we shall look at one of them (kermit) in more detail.
The kermit program can be used in one of several different ways. To start with, kermit can be used in an interactive mode, in which it will repeatedly display a prompt, accept user commands and execute them.
For some options, kermit can also be used in a command line mode, where you run the program and specify the actions you want it to perform as a set of command line parameters. In this mode, the specified actions will be performed and then kermit will terminate and return you to a shell prompt.
When you are transferring files there will be two copies of kermit running, one on each machine. Both copies of kermit are under your control on the local machine. In order to achieve this the kermit running on the remote machine will be placed into a remote server mode, where it takes and executes its commands over the communication link between the two machines.
Whichever way kermit gets run, it can also read a command file called .kermrc in your home directory. This file will normally be used to set up any default parameters you want kermit to use in its operating environment.
A typical sequence of events for transferring a binary data file from a remote machine to your local machine via a dial-up modem connection could be:
kermitYou may need to add the directory which contains the kermit program to your PATH environment variable.
set modem hayes set line /dev/modem set speed 38400 dial 334566 connectThis sequence is pretty self-explanatory, and after the connect command you should be able to get a login prompt from the remote machine. Incidentally, when you enter the connect command, make a note of the escape sequence which will get you out of the terminal emulator and back to the kermit> prompt (typically it will be something like Ctrl-\ c).
serverThis will put the remote kermit into server mode ready for file transfer.
set file type binary get datafileThe first command in this sequence tells kermit what type of file to expect. As far as kermit is concerned there are two types of file: binary data and text. You need to make sure that kermit is set to the correct type. If in doubt then use binary though the transfer will take longer. Obviously, you should substitute the name datafile with the name of the file you want to fetch. In order for this command to work, your local kermit will pass commands to the remote kermit server, which in turn will send the required file.
finishWhen the server has shut down, you will get a kermit> prompt from the local machine. If at this point you issue a connect command then it will switch your local kermit back into being a terminal emulator and you will get another kermit> prompt, but this time from the remote machine.
quitwill now terminate the remote kermit and return you to a shell prompt from the remote machine.
There are many more options to kermit than you have seen here, but this should have given you the basic idea. For more information there is a fairly comprehensive help facility built into kermit itself, which you can access just by typing help to a kermit> prompt.