If everything has gone ok so far, then you will have a Linux kernel which supports the network devices you intend to use and you also have the network tools with which to configure them. Now comes the fun part! You'll need to configure each of the devices you intend to use. This configuration generally amounts to telling each device things like what its IP address will be and what network it is connected to.
In past versions of this document I have presented near complete versions of the various configuration files and included comments to modify or delete lines from them as appropriate. From this version onwards I will take a slightly different approach which I hope will result in you having a complete set of uncluttered configuration files that you have built from scratch so you know exactly what is in them and why. I'll describe each of these files, and their function, as we come to them.
You do not need to configure any special device files in the /dev
directory for Linux Networking. Linux does not need or use them as other
operating systems might. The devices are built dynamically in memory by the
kernel and since they are only names there is no need for them to have an
appearance directly to you. The kernel provides all of the programming hooks
and interfaces that you need to utilize them effectively.
Before you can configure the networking software, you will need to know a number of pieces of information about your network connection. Your network provider or administrator will be able to provide you with most of them.
This is the unique machine address, in dotted decimal notation, that your
machine will use. An example is 128.253.153.54. Your network
administrator will provide you with this information.
If you will be using a SLIP or plip connection you may not need this information, so skip it until we get to the SLIP device.
If you're using the loopback device only, ie no ethernet, SLIP or plip support,
then you won't need an ip address as the loopback port always uses the
address 127.0.0.1.
For performance reasons it is desirable to limit the number of hosts on any particular segment of a network. For this reason it is common for network administrators to divide their network into a number of smaller networks, known as subnets, which each have a portion of the network addresses assigned to them. The network mask is a pattern of bits, which when overlayed onto an address on your network, will tell you which subnetwork it belongs to. 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 on your own network, then it is quite likely that you have specified an incorrect subnet mask.
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. Other larger networks use class-B
netmasks (255.255.0.0). The NET-2/NET-3 code will automatically
select a default mask when you assign an address to a device. The default
assumes that your network has not been subnetted.
The NET-2/NET-3 code will choose the following masks by default:
For addresses with the first byte:
1-127 255.0.0.0 (Class A)
128-191 255.255.0.0 (Class B)
192+ 255.255.255.0 (Class C)
if one of these doesn't work for you, try another. If this doesn't work ask your network administrator or local network guru (dime a dozen) for help.
You don't need to worry about a netmask for the loopback port, or if you are running SLIP/plip.
This is your IP address masked (bitwise AND) with your 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 =
`A shout is a whisper that everyone hears whether they need to or not'
This is normally your network address logically ORed with your netmask
inverted. This is simpler than it sounds. For a Class-C network, with
network mask 255.255.255.0, your Broadcast Address will
be your network address (calculated above), logically ORed with
0.0.0.255, the network mask inverted.
A worked example might look like:
If your netmask is: 255.255.255.0 !
the netmask inverted is: 0. 0. 0.255 =
If your Network address is: 128.253.154.0 ||
----------------
Your broadcast address is: 128.253.154.255 =
Note that for historical reasons some networks use the network address as the broadcast address. If you have any doubts contact your network administrator.
If you have access to a sniffer, or some other device capable of
providing you with a trace of your network traffic, then you might be able to
determine both the network and broadcast addresses by watching other traffic
on the lan. Keep an eye open for, (or filter everything except), ethernet
frames destined for the ethernet broadcast address: ff:ff:ff:ff:ff:ff.
If any of them has an IP source address of your local router and the
protocol ID is not ARP, then check the destination IP address, because this
datagram may well be a RIP routing broadcast from your router, in which case
the destination IP address will be your broadcast address.
Once again, if you're not sure, check with your network administrator, they'd rather help you, than have you connect your machine in a misconfigured way.
`There must be some way out of here.'
This is the address of the machine that connects your network to the
rest of the Internet. It is your `gateway' to the outside world. A couple
of conventions exist for allocating addresses to routers which your network
might follow, they are: The router is the lowest numbered address on the
network, the router is the highest numbered host on the network.
Probably the most common is the first, where the router will have an address
that is mostly the same as your own, except with a .1 as the last
byte. eg. if your address is 128.253.154.32, then your router might
be 128.253.154.1. The router can in fact have any address valid on
your network and function properly, the address doesn't matter at all. There
may in fact even be more than one router on your network. You will probably
need to talk to your network administrator to properly identify your router
address.
If you're using only loopback then you don't need a router address. If you're using PPP then you also don't need your router address, because PPP will automatically determine the correct address for you. If you're using SLIP, then your router address will be your SLIP server address.
Most machines on the net have access to a name server which translates
human tolerable hostnames into machine tolerable addresses and vice
versa. Your network administrators will again tell you the address
of your nearest nameserver. You can in fact run a nameserver on your own
machine by running named, in which case your nameserver
address will be 127.0.0.1, the loopback port address.
However it is not required that you run named at all; see section
`named' for more information.
If you're only using loopback then you don't need to know the nameserver address since you're only going to be talking to your own machine.
You may or may not in fact need to know any of the above information. Whether you do or not will depend on exactly how your network connection is achieved and the capabilities of the machine at the other end of the link. You'll find more detail in the section relevant to configuration of the SLIP/PLIP and PPP devices.
While the commands to configure your network devices can be typed manually each time, you will probably want to record them somewhere so that your network is configured automatically when you boot your machine.
The `rc' files are specifically designed for this purpose. For the
non-unix-wizard: `rc' file are run at bootup time by the init
program and start up all of the basic system programs such as syslog,
update and cron. They are analogous to the MS-DOS
autoexec.bat file and rc might stand for `runtime
commands'. By convention these files are kept under the /etc
directory. The Linux Filesystem Standard doesn't go so far as to describe
exactly where your rc files should go, stating that it is ok for them
to follow either the BSD (/etc/rc.*) or System-V (/etc/rc.d/rc*) conventions.
Alan, Fred and I all use the System-V convention, so that is what you will
see described here. This means that these files are found in /etc/rc.d
and are called rc.inet1 and rc.inet2. The first rc
file that gets called at bootup time is /etc/rc and it in turn calls
others, such as rc.inet1, which in turn might called rc.inet2.
It doesn't really matter where they are kept, or what they are called, so long
as init can find them.
In some distributions the rc file for the network is called
rc.net and is in the /etc subdirectory. The rc.net
file on these systems is simply the rc.inet1 and the rc.inet2
files combined into one file that gets executed.
Some equivalences:
Document Convention Slackware Debian and other newer.
=================== =========== =======================
/etc/rc.d/rc.inet1 /etc/rc.net /etc/init.d/network
/etc/rc.d/rc.inet2 /etc/rc.net /etc/init.d/netbase
/etc/init.d/netstd_init
/etc/init.d/netstd_nfs
/etc/init.d/netstd_misc
It doesn't matter where the commands appear, so long as you configure the interfaces before starting the network daemons and applications.
I will refer to these files as rc.inet1 and rc.inet2 and
I keep them in the /etc/rc.d, so if you are using one of the
distributions that uses some other convention, or you want to keep the files
somewhere else, then you will have to make appropriate adjustments as you go.
We will be building these files from scratch as we go.
The rc.inet1 file configures the basic tcp/ip interfaces for your machine using two programs: /sbin/ifconfig and /sbin/route.
/sbin/ifconfig is used for configuring your interfaces with the parameters that they require to function, such as their IP address, network mask, broadcast addresses and similar. You can use the ifconfig command with no parameters to display the configuration of all network devices. Please check the ifconfig man page for more detail on its use.
/sbin/route is used to create, modify and delete entries in a table (the routing table) that the networking code will look at when it has a datagram that it needs to transmit. The routing table lists destination address and the interface that that address is reachable via. You can use the route command with no parameters to display the contents of the routing table. Please check the route man page for more detail on its use.
The rc.inet2 file starts any network daemons such as inetd, portmapper and so on. This will be covered in more detail in section `rc.inet2', so for the moment we will concentrate on rc.inet1. I have mentioned this file here so that if you have some other configuration, such as a single rc.net file you will understand what the second half of it represents. it is important to remember that you must start your network applications and daemons after you have configured your network devices.
The loopback device isn't really a hardware device. It is a software construct that looks like a physical interface. Its function is to happily allow you to connect to yourself and to test network software without actually having to be connected to a network of any kind. This is great if you are developing network software and you have a SLIP connection. You can write and test the code locally and then when you are ready to test it on a live network, establish your SLIP connection and test it out. You won't hurt others users if your program misbehaves.
By convention, the loopback device always has an IP address of
127.0.0.1 and so you will use this address when configuring it.
The loopback device for Linux is called `lo'. You will now make the first entry into your rc.inet1 file. The following code fragment will work for you:
#!/bin/sh
#
# rc.inet1 -- configures network devices.
#
# Attach the loopback device.
/sbin/ifconfig lo 127.0.0.1
#
# Add a route to point to the loopback device.
/sbin/route add 127.0.0.1
# End loopback
#
You have used the ifconfig program to give the loopback interface
its IP address and route program to create an entry in the routing
table that will ensure that all datagrams destined for 127.0.0.1
will be sent to the loopback port.
There are two important points to note here.
Firstly, the netmask and broadcast addresses have been allowed to take the default values for the loopback device described earlier in section `Network Mask'. To see what they are, try the ifconfig program without any arguments.
# ifconfig
lo Link encap Local Loopback
inet addr 127.0.0.1 Bcast 127.255.255.255 Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 30 errors 0 dropped 0 overrun 0
#
Secondly, its not obvious how the route command chose the
loopback device as the device for the route to 127.0.0.1.
The route program is smart enough to know that 127.0.0.1
belongs to the network supported by the loopback device. It works this out
by checking the IP address and the netmask. You can use the route
command with no arguments to display the contents of the routing table:
# route
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 * 255.0.0.0 U 0 0 30 lo
#
Note: You might want to use the -n argument if your name
resolver is not yet configured properly. The -n argument tells
route to just display the numeric addresses and to not
bother looking up the name.
You'll only be interested in this section if you wish to configure an ethernet card, if not then skip on ahead to the next section.
To configure an ethernet card is only slightly more complicated than configuring the loopback device. This time you should probably specify explicitly the network mask and the broadcast address, unless you are sure that the defaults will work ok and they probably will.
For this you will need the IP address that you have been assigned, the network mask in use on your network and the broadcast address in use.
The first ethernet device for a Linux system is called `eth0', the second `eth1' and so forth. You will now add a section to your rc.inet1 file. The following code fragment will work for you if you change the addresses specified for real ones:
#
# Attach an ethernet device
#
# configure the IP address, netmask and broadcast address.
/sbin/ifconfig eth0 IPA.IPA.IPA.IPA
/sbin/ifconfig eth0 netmask NMK.NMK.NMK.NMK
/sbin/ifconfig eth0 broadcast BCA.BCA.BCA.BCA
#
# add a network route to point to it:
/sbin/route add -net NWA.NWA.NWA.NWA device eth0
#
# End ethernet
#
Where:
represents your IP Address.
represents your netmask.
represents your Broadcast address.
represents your Network Address.
Note the use of the -net argument to the route command.
This tells route that the route to be added is a route to a
network and not to a host. There is an alternative
method of achieving this, you can leave off the -net if you have
the network address listed in the /etc/networks file. This is
covered later in section `/etc/networks'.
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 line of some sort. Of course to use SLIP you need access to a SLIP-server in your area. Many universities and businesses provide SLIP access all over the world.
Slip uses the serial ports on your machine to carry IP datagrams. To do this it must take control of the serial device. Slip device names are named sl0, sl1 etc. How do these correspond to your serial devices ? The networking code uses what is called an ioctl (i/o control) call to change the serial devices into SLIP devices. There are two programs supplied that can do this, they are called dip and slattach
dip (Dialup IP) is a smart program that is able to set the speed of the serial device, command your modem to dial the remote end of the link, automatically log you into the remote server, search for messages sent to you by the server and extract information for them such as your IP address and perform the ioctl necessary to switch your serial port into SLIP mode. dip has a powerful scripting ability and it is this that you can exploit to automate your logon procedure.
dip used to be supplied with the net-tools, but since
development of dip is now seperate, you have to source it seperately.
There have been a number of other versions of dip produced which offer
a variety of new features. The dip-uri version seems to be the more
popular, but I suggest you take a close look at each to determine which offers
enhancements that you find useful. Since dip-uri is is so popular,
the examples described in this document are based on current versions of it.
You can find it at:
sunsite.unc.edu
/pub/Linux/system/Network/serial/dip337j-uri.tgz
To install it, try the following:
#
# cd /usr/src
# gzip -dc dip337j-uri.tgz | tar xvf -
# cd dip.3.3.7j
<edit Makefile>
# make install
#
The Makefile assumes the existence of a group called uucp,
but you might like to change this to either dip or SLIP
depending on your configuration.
slattach as contrasted with dip is a very simple program, that is very easy to use, but does not have the sophistication of dip. It does not have the scripting ability, all it does is configure your serial device as a SLIP device. It assumes you have all the information you need and the serial line is established before you invoke it. slattach is ideal to use where you have a permanent connection to your server, such as a physical cable, or a leased line.
You would use dip when your link to the machine that is your SLIP server is a dialup modem, or some other temporary link. You would use slattach when you have a leased line, perhaps a cable, between your machine and the server and there is no special action needed to get the link working. See section `Permanent Slip connection' for more information.
Configuring SLIP is much like configuring an Ethernet interface (read section `Configuring an ethernet device' above). However there are a few key differences.
First of all, SLIP links are unlike ethernet networks in that there is only ever two hosts on the network, one at each end of the link. Unlike an ethernet that is available for use as soon are you are cabled, with SLIP, depending on the type of link you have, you may have to initialize your network connection in some special way.
If you are using dip then this would not normally be done at boot time, but at some time later, when you were ready to use the link. It is possible to automate this procedure. If you are using slattach then you will probably want to add a section to your rc.inet1 file. This will be described soon.
There are two major types of SLIP servers: Dynamic IP address servers and static IP address servers. Almost every SLIP server will prompt you to login using a username and password when dialing in. dip can handle logging you in automatically.
A static SLIP server in one in which you have been supplied an IP address
that is exclusively yours. Each time you connect to the server, you will
configure your SLIP port with that address. The static SLIP server will
answer your modem call, possibly prompt you for a username and password,
and then route any datagrams destined for your address to you via that
connection. If you have a static server, then you may want to put entries
for your hostname and IP address (since you know what it will be) into your
/etc/hosts. You should also configure some other files such as:
rc.inet2, host.conf, resolv.conf,
/etc/HOSTNAME and rc.local. Remember that when configuring
rc.inet1, you don't need to add any special commands for your SLIP
connection since it is dip that does all of the hard work for you in
configuring your interface. You will need to give dip the appropriate
information and it will configure the interface for you after commanding the
modem to establish the call and logging you into your SLIP server.
If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure dip appropriately.
A dynamic SLIP server is one which allocates you an IP address randomly, from a pool of addresses, each time you logon. This means that there is no guarantee that you will have any particular address each time, and that address may well be used by someone else after you have logged off. The network administrator who configured the SLIP server will have assigned a pool of address for the SLIP server to use, when the server receives a new incoming call, it finds the first unused address, guides the caller through the login process and then prints a welcome message that contains the IP address it has allocated and will proceed to use that IP address for the duration of that call.
Configuring for this type of server is similar to configuring for a static server, except that you must add a step where you obtain the IP address that the server has allocated for you and configure your SLIP device with that.
Again, dip does the hard work and new versions are smart enough to not only log you in, but to also be able to automatically read the IP address printed in the welcome message and store it so that you can have it configure your SLIP device with it.
If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure dip appropriately.
As explained earlier, dip is a powerful program that can simplify and automate the process of dialing into the SLIP server, logging you in, starting the connection and configuring your SLIP devices with the appropriate ifconfig and route commands.
Essentially to use dip you'll write a `dip script', which is
basically a list of commands that dip understands that tell
dip how to perform each of the actions you want it to perform. See
sample.dip that comes supplied with dip to get an idea
of how it works. dip is quite a powerful program, with many options.
Instead of going into all of them here you should looks at the man
page, README and sample files that will have come with your version of
dip.
You may notice that the sample.dip script assumes that you're using
a static SLIP server, so you know what your IP address is beforehand. For
dynamic SLIP servers, the newer versions of dip include a command
you can use to automatically read and configure your SLIP device with the
IP address that the dynamic server allocates for you. The following sample
is a modified version of the sample.dip that came supplied with
dip337j-uri.tgz and is probably a good starting point for you.
You might like to save it as /etc/dipscript and edit it to suit your
configuration:
#
# sample.dip Dialup IP connection support program.
#
# This file (should show) shows how to use the DIP
# This file should work for Annex type dynamic servers, if you
# use a static address server then use the sample.dip file that
# comes as part of the dip337-uri.tgz package.
#
#
# Version: @(#)sample.dip 1.40 07/20/93
#
# Author: Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#
main:
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400
# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset
# Note! "Standard" pre-defined "errlevel" values:
# 0 - OK
# 1 - CONNECT
# 2 - ERROR
#
# You can change those grep'ping for "addchat()" in *.c...
# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble
# We are connected. Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:
# We are now logged in.
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error
# Command the server into SLIP mode
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error
# Get and Set your IP address from the server.
# Here we assume that after commanding the SLIP server into SLIP
# mode that it prints your IP address
get $locip remote 30
if $errlvl != 0 goto prompt_error
# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default
# Say hello and fire up!
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit
prompt_error:
print TIME-OUT waiting for sliplogin to fire up...
goto error
login_trouble:
print Trouble waiting for the Login: prompt...
goto error
password:error:
print Trouble waiting for the Password: prompt...
goto error
modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit
exit:
exit
The above example assumes you are calling a dynamic SLIP server, if
you are calling a static SLIP server, then the sample.dip
file that comes with dip337j-uri.tgz should work for you.
When dip is given the get $local command it searches the incoming text from the remote end for a string that looks like an IP address, ie strings numbers separated by `.' characters. This modification was put in place specifically for dynamic SLIP servers, so that the process of reading the IP address granted by the server could be automated.
The example above will automatically create a default route via your SLIP link, if this is not what you want, you might have an ethernet connection that should be your default route, then remove the default command from the script. After this script has finished running, if you do an ifconfig command, you will see that you have a device sl0. This is your SLIP device. Should you need to, you can modify its configuration manually, after the dip command has finished, using the ifconfig and route commands.
Please note that dip allows you to select a number of different
protocols to use with the mode command, the most common example is
cSLIP for SLIP with compression. Please note that both ends of the
link must agree, so you should ensure that whatever you select agrees with
what your server is set to.
The above example is fairly robust and should cope with most errors. Please refer to the dip man page for more information. Naturally you could, for example, code the script to do such things as redial the server if it doesn't get a connection within a prescribed period of time, or even try a series of servers if you have access to more than one.
If you have a cable between two machines, or are fortunate enough to have a leased line, or some other permanent serial connection between your machine and another, then you don't need to go to all the trouble of using dip to set up your serial link. slattach is a very simple to use utility that will allow you just enough functionality to configure your connection.
Since your connection will be a permanent one, you will want to add some
commands to your rc.inet1 file. In essence all you need to do for
a permanent connection is ensure that you configure the serial device to
the correct speed and switch the serial device into SLIP mode. slattach
allows you to do this with one command. Add the following to your
rc.inet1 file:
#
# Attach a leased line static SLIP connection
#
# configure /dev/cua0 for 19.2kbps and cslip
/sbin/slattach -p cslip -s 19200 /dev/cua0 &
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End static SLIP.
Where:
represents your IP address.
represents the IP address of the remote end.
slattach allocated the first unallocated SLIP device to the serial device specified. slattach starts with sl0. Therefore the first slattach command attaches SLIP device sl0 to the serial device specified and sl1 the next time, etc.
slattach allows you to configure a number of different protocols with
the -p argument. In your case you will use either SLIP or
cSLIP depending on whether you want to use compression or not.
Note: both ends must agree on whether you want compression or not.
plip (Parallel Line IP), is like SLIP, in that it is used for providing a point to point network connection between two machines, except that it is designed to use the parallel printer ports on your machine instead of the serial ports. Because it is possible to transfer more than one bit at a time with a parallel port, it is possible to attain higher speeds with the plip interface than with a standard serial device. In addition, even the simplest of parallel ports, printer ports, can be used, in lieu of you having to purchase comparatively expensive 16550AFN UART's for your serial ports.
Please note that some laptops use chipsets that will not work with PLIP because they do not allow some combinations of signals that PLIP relies on, that printers don't use.
The Linux plip interface is compatible with the Crynwyr Packet Driver PLIP and this will mean that you can connect your Linux machine to a DOS machine running any other sort of tcp/ip software via plip.
You have two options in using the PLIP driver. You can either compile the driver into your kernel, or use the modules package to load the module dynamically. I recommend just compiling it into your kernel as it is probably the easiest and in most circumstances you will want the driver there all the time anyway.
When compiling the kernel, there is only one file that might need to be looked
at to configure plip. That file is
/usr/src/linux/driver/net/CONFIG and it contains plip
timers in mS. The defaults are probably ok in most cases. You will probably
need to increase them if you have an especially slow computer, in which case
the timers to increase are actually on the other computer.
The driver assumes the following defaults:
device i/o addr IRQ
------ -------- -----
plip0 0x3BC 5
plip1 0x378 7
plip2 0x278 2 (9)
If your parallel ports don't match any of the above combinations then you can change the IRQ of a port using the ifconfig command using the `irq' parameter. Be sure to enable IRQ's on your printer ports in your ROM BIOS if it supports this option.
To configure a plip interface, you will need to add the
following lines to your rc.inet1 file:
#
# Attach a PLIP interface
#
# configure first parallel port as a plip device
/sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End plip
Where:
represents your IP address.
represents the IP address of the remote machine.
The pointopoint parameter has the same meaning as for SLIP, in that it specifies the address of the machine at the other end of the link.
In almost all respects you can treat a plip interface as though it were a SLIP interface, except that neither dip nor slattach need be, nor can be, used.
plip has been designed to use cables with the same pinout as those commonly used by the better known of the MS-DOS based pc-pc file transfer programs.
The pinout diagram (taken from /usr/src/linux/drivers/net/plip.c)
looks as follows:
Pin Name Connect pin - pin
--------- -------------------------------
GROUND 25 - 25
D0->ERROR 2 - 15
ERROR->D0 15 - 2
D1->SLCT 3 - 13
SLCT->D1 13 - 3
D2->PAPOUT 4 - 12
PAPOUT->D2 12 - 4
D3->ACK 5 - 10
ACK->D3 10 - 5
D4->BUSY 6 - 11
BUSY->D4 11 - 6
D5 7*
D6 8*
D7 9*
STROBE 1*
FEED 14*
INIT 16*
SLCTIN 17*
Notes: Do not connect the pins marked with an asterisk `*'. Extra grounds are 18,19,20,21,22,23 and 24.
If the cable you are using has a metallic shield, it should be connected to the metallic DB-25 shell at one end only.
Warning: A miswired PLIP cable can destroy your controller card. Be very careful and double check every connection to ensure you don't cause yourself any unnecessary work or heartache.
While you may be able to run PLIP cables for long distances, you should avoid it if you can. The specifications for the cable allow for a cable length of about 1 metre or so. Please be very careful when running long plip cables as sources of strong electromagnetic fields such as lightning, power lines and radio transmitters can interfere with and sometimes even damage your controller. If you really want to connect two of your computers over a large distance you really should be looking at obtaining a pair of thin-net ethernet cards and running some coaxial cable.