Problem 1: Parallel Line Internet Protocol (PLIP) Networking

Linux supports something called PLIP, which stands for Parallel Line Internet Protocol. Most modern parallel ports are capable of two-way communication. PLIP takes advantage of this fact by using this two-way capability to pass IP network packets.

In order to get PLIP going, we need to cover the following:

· Parallel port basics

· BIOS printer port setup

· Two-way printer port cables

· Compiling the Linux kernel (don't be scared!)

· Setting up the PLIP tunnel

· (Optional) Setting up masquerading

Don't be intimidated by the kernel compilation. We will hold your hand through the process, outlining how to make the selections, how to deploy the new kernel, and how to keep your old kernel around to boot from in case you make a mistake.

Before we leap into the fray, let's cover some basics of parallel ports so you are up on the terminology.

Parallel Port Basics

Most communications devices that do not plug into a bus (ISA, VLB, PCI, USB, etc.) are "serial" devices. More specifically , they are RS-232 serial devices. Without getting overly detailed, a serial device is a device where the bits of a byte are sent as separate pulses , one after another, down a single wire. A parallel device, on the other hand, is one with eight wires, one for each bit of a byte, on which all the bits of a byte are sent in a single pulse, all at the same time.

Of course, serial ports have more than one wire, and parallel ports have more than eight. There are lines in both for control signals and grounds, and serial ports have two data wires, one for input and another for output. The point is, the names serial and parallel come from the idea that a byte is presented as as series of pulses (hence serial ), or in parallel, as a group of bit pulses all sent at once.

You may have noticed that while serial devices have a line for input and a line for output, I mentioned only one set of eight lines for parallel port data. That's because the specification of the parallel interface was set almost 30 years ago by a company called Centronics for use as a printer interface only. At that time, printers were fairly dumb devices that just received and printed data. They had nothing to say back to the computer (except on those control lines I mentioned ”lines like "Out Of Paper"). The parallel port was never intended for two-way communication. Since when has that stopped anyone ?

The Four Kinds of Parallel Ports

Since PLIP is a nitty-gritty, "close to the metal" little hack to network machines that could not otherwise communicate, you are, I'm afraid, about to be confronted with a little bit of hard technical reality.

It turns out there is more than one kind of parallel port on PCs. In fact, there are four of them:

· SPP (standard)

· PS/2

· EPP

· ECP

I'll tell you a little bit about each one.

SPP: Standard Parallel Port

The SPP is a purely unidirectional interface ”or so it was intended. Remember how I said a standard parallel cable has eight bits of data and some control lines? The control lines set values in the status register of the parallel port controller. What a parallel port link cable does is to link five outbound data lines from one side of the interface to the five status lines on the other. The reverse is done in the other direction. Data is sent four bits at a time. (The fifth bit is used for handshaking ”a term that means "control signaling." The two sides must be told when a character is ready to be read and when that character has been read; otherwise, characters could be lost or duplicated .) This is the type of interface that PLIP is written to work with, for it is the lowest common denominator of parallel interfaces.

PS/2: IBM's Beloved Mutants

IBM attempted to rectify many of the design flaws in the original PC creating an entirely new set of design flaws. The result was the PS/2 family of PCs. PS/2's running IBM's powerhouse OS/2 were going to reassert IBM's dominance over the SOHO (small office/home office) PC market. Since the odds are you have neither a PS/2 nor OS/2, I think you can deduce what happened to that.

The success or failure of IBM's ambitious plans for world reconquest do not concern us here. What does concern us, however, is the PS/2 parallel port and its differences from the SPP. IBM decided that a bidirectional parallel port would be a good idea, so they added the ability to "tri-state" the drivers that put signals on the parallel data lines, allowing the computer port not only to send zeroes and ones, but also to listen.

Both the SPP and PS/2 modes transfer only unstructured byte data directly between a computer and a peripheral.

EPP: Enhanced Parallel Port

The EPP interface adds some protocol to the two-way communications channels. Four kinds of transfers are possible with EPP-capable parallel interfaces:

· Data read cycles

· Data write cycles

· Address read cycles

· Address write cycles

This ability to read and write data and to send "addresses" allows the parallel port to be used essentially like a bus, connecting multiple peripherals or complex devices with more than one "port" on them. So, in addition to being bidirectional, this specification allows you to attach devices where you can pass data and/or command and control information. This lets you control more complex devices, like disk drives and network interfaces, through your parallel port.

The EPP specification was developed by an ad hoc group of industry members , including Xircom and Zenith Data Systems. One of its important features is that each cycle can be completed in one ISA bus cycle. This allows devices connected on the EPP port to be treated in certain ways as if they were Industry Standard Architecture devices. This makes it easier both for driver programmers and for device manufacturers, who can now port ISA bus devices to EPP devices with minimal additional hardware.

ECP: Enhanced Capability Port

The ECP standard was developed jointly by Hewlett-Packard and Microsoft Corporation. It may come as a surprise to some of us more hardcore Linux folks (who tend to dislike and mistrust Microsoft), but despite Microsoft's participation, ECP is the first parallel port specification since the original SPP to go through an open standards process. Now known as the IEEE 1284 Extended Capabilities Port Protocol and ISA Interface Standard, this standard defines a fully ISA-compatible bus protocol for parallel ports. It also defines a number of performance-enhancing protocol and design improvements, including RLE compression, FIFOs for inbound and outbound channels, DMA and programmed I/O. This standard offers considerable performance improvements over the earlier standards.

So what does all of this mean? Alas, not all that much. The Linux PLIP code is written to work with all of these modes of parallel operation. It does not take advantage of the greater capabilities of the PS/2, EPP, and ECP modes. It is still valuable to know about them, however. While PLIP doesn't use them, the Parallel Port IDE driver in Linux, which allows you to connect parallel Zip drives, CD-ROM drives, external hard drives, and scanners , does use these capabilities.

Also, some ECP-capable parallel port controllers will use the FIFO buffers even in SPP mode, thus improving throughput, so it may still be an advantage to use the more advanced modes.

Two-Way Printer Port Cables

Since PLIP is written to be the lowest common denominator of SPP, to do two-way PLIP requires a custom cable. The simplest way to get going is to go to your local Super Mongo Mega Electrode Hut and buy a Laplink cable. This is a common name for these cables, since an old MS-DOS program called Laplink was the first to take advantage of this tricky way to link computers using a special parallel cable and special software.

If you are a radical do-it-yourselfer, you can make your own. You will need:

· 2 DB-25 male connectors and hoods

· 12-conductor cable (see the nearby table)

· Crimping and/or soldering tools appropriate to the DB-25 connector type you have selected

I recommend, first, that you not make your own cable and just buy the Laplink cable. It will not cost that much more. If, however, you enjoy inhaling lead from solder, then buy shielded 12-conductor cable. Use the shortest length of cable you possibly can. Longer cables are more susceptible to radio-frequency interference. After that, connect the cables as follows :

Connector 1 pin	Connects to connector 2 pin
2	15
3	13
4	12
5	10
6	11
10	5
11	6
12	4
13	3
15	2
17	17
25	25

Compiling the Linux Kernel to Support PLIP

Changes Needed for PLIP

Most optional code in the Linux kernel can be disabled, compiled into the kernel, or built as modules. Modules offer greater flexibility, but they do involve a small performance cost to get loaded. And if you wish to load and unload them, you must use a set of commands ( insmod, rmmod, etc.) to manipulate them. Personally, I find it much simpler to compile directly in everything I need and then, if I need different things, to boot between two or three different kernels . One of the great things about Linux is you can do it your own way. You can go either route.

In this case, the real problem with the PLIP driver is that it will not coexist with the parallel port printer driver. If you will often be switching between PLIP and a parallel printer, then you will probably want to use modules. This was not the case for me, so I am going to show you how to explicitly disable the parallel port and enable PLIP.

I'll show you some of the changes made with the make menuconfig interface and some with the make xconfig interface so you can get a flavor of each. No matter which tool you see used in the examples here, all of these changes must be made.

Settings I do not specifically mention should be left as they are in your present kernel. Do not change them to match the figures here. The settings you see here are from a specific installation and may not match your needs at all. If you don't know what changing an option will do, do not change it! You'd think I wouldn't need to say this, but not every reader is as bright as you.

Let's go over the changes in the order they appear. First, go to General Settings ( Figure 4-1 ). When you enter this section (by pressing Return in menuconfig or by clicking on it with your mouse in xconfig ), you will see the options shown in Figure 4-2 . The ones that concern us are " Parallel port support " and "PC-style hardware." Both of these should be compiled in.

Figure 4-1. General options.

Figure 4-2. General details.

The next section to go to is Network Options, as shown in Figure 4-3 (this time, in xconfig, just for variety).

Figure 4-3. Network options.

This is a pretty large subsection, so we will look at more than one screenshot. Figure 4-4 is the first. The item that concerns us here is "Network firewalls." This item must be compiled in.

Figure 4-4. Network options, detail 1.

Figure 4-5 shows the next part, which is just a scroll down from the screenshot of Figure 4-4 . The items that concern us here are "IP: firewalling," "IP: masquerading," and "IP: ICMP masquerading." The first two must be compiled in. The last one is optional, but if you want your PLIP client box to be able to ping hosts out on the rest of the network, you will want this compiled in.

Figure 4-5. Network options, detail 2.

You can now build and install the new kernel as described in Chapter 1 in the section Get Comfortable with Source Code.

Installing the New Kernel

Or can you? There is a wrinkle in setting up a PLIP kernel. That wrinkle is in adding an entry for the new kernel to /etc/lilo.conf. The new lines are in bold type:

  boot = /dev/hda

  vga = normal

  read-only

  linear

  prompt

  timeout = 30

  image = /boot/vmlinuz

  label = linux

  root = /dev/hda3

  image = /boot/vmlinuz.suse

  label = suse

  root = /dev/hda3

   image = /boot/vmlinuz.new

   label = new

   root = /dev/hda3

   append = "parport=0x378,7"

  other = /dev/hda1

  label = win

That last new line needs some explaining. The "append=" option of lilo allows you to specify "kernel parameters." Think of the text that follows as the kernel's "command line arguments." The Linux kernel by default uses a polling driver for the parallel ports. Polling is where the system "looks" at the port every time it gets a chance to see if it can send or receive a character. This is as opposed to interrupts, where the system ignores the port completely until the port sends an "interrupt," indicating that the status of the device has changed. The computer then drops everything to handle the event at the port.

Linux uses the polling driver by default because on many ( especially older) machines it is not possible to discover what "IRQ" (or interrupt number) the parallel port uses. The polling driver works just fine for plain old printing. (The worst thing that will ever happen is the printer will have to wait for the computer to send some data.) When doing two-way data traffic, however, the worst thing that will happen is that some data will be lost because the computer doesn't get to the port before the data is overwritten by more data. This is deadly for networking.

If you want PLIP to work at all, you need to activate the interrupt driver. You do this by telling the driver (called parport ) what the port address and IRQ number of your parallel ports are. In this case, we have one lp port and it is at the PC standard of address 0x0378, and it is on the standard IRQ of 7. Be sure to check if this is correct for your hardware. If you have more than one parallel port, you can specify them here.

Be sure to do this! If you set everything else up and nothing seems to work, check the port and IRQ settings first. PLIP simply won't work right with the polling driver.

Setting Up the PLIP Tunnel

To use PLIP, you must make those enabling modifications on two boxes. For the rest of this discussion we will refer to these two boxes as plipserver and plipclient.

First, in the /etc/hosts file of both machines, create an entry for both hosts:

  10.0.0.1 plipserver

  10.0.0.2 plipclient

I like to use the nonrouting IP subnet of 10.x.x.x. No machines on the Internet have any addresses in this range. There are other nonrouting ranges, but this one is quite easily remembered .

In this part of the discussion, we will be setting up only the connection from the client to the server. The client will not be able to reach any host other than the server. The next section will detail how to let the client through to the rest of the Internet.

Server-Side Setup

First, you must set up the interface. That is done with the ifconfig command. Here's the command to use (issue this command on plipserver):

  # ifconfig plip0 plipserver pointopoint plipclient netmask 255.255.255.0 up

Here's what ifconfig might show after issuing this command:

  eth0 Link encap:Ethernet HWaddr 00:04:AC:D9:05:7F

  inet addr:168.135.196.112 Bcast:168.135.199.255 Mask:255.255.252.0

  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

  RX packets:15357136 errors:0 dropped:0 overruns:0 frame:2

  TX packets:5981809 errors:0 dropped:0 overruns:0 carrier:17241

  collisions:2629247 txqueuelen:100

  Interrupt:10

  lo Link encap:Local Loopback

  inet addr:127.0.0.1 Mask:255.0.0.0

  UP LOOPBACK RUNNING MTU:3924 Metric:1

  RX packets:2736675 errors:0 dropped:0 overruns:0 frame:0

  TX packets:2736675 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:0

  plip0 Link encap:Ethernet HWaddr FC:FC:0A:00:00:FE

  inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.0

  UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

  RX packets:985771 errors:0 dropped:308 overruns:0 frame:0

  TX packets:942471 errors:350 dropped:0 overruns:0 carrier:350

  collisions:253 txqueuelen:10

  Interrupt:7 Base address:0x378

(Those packet counts are a bit high ”I ran this on a box that had been up for a few days!) Note that I used a class C netmask (255.255.255.0). You can use any netmask value valid for the 10.x.x.x network, such as 255.0.0.0; just be sure to use the same netmask on both sides of the interface.

Client-Side Interface

We are assuming the client side has only the loopback interface set up, so there are no entries in plipclient's routing table. To enable the plip interface and to route all network packets over the plip interface, we execute the following two commands:

  # ifconfig plip0 plipclient pointopoint plipserver netmask 255.255.255.0 up

  # route add default gw plipserver

Next, we attempt to ping the server from the client:

  # ping plipserver

  PING plipserver (10.0.0.1): 56 data bytes

  64 bytes from plipserver: icmp_seq=0 ttl=255 time=13.301 ms

  64 bytes from plipserver: icmp_seq=1 ttl=255 time=13.734 ms

  64 bytes from plipserver: icmp_seq=2 ttl=255 time=13.709 ms

  --- plipserver ping statistics ---

  3 packets transmitted, 3 packets received, 0% packet loss

  round-trip min/avg/max = 13.301/13.581/13.734 ms

You should also now be able to ping the client from the server.

Setting Up NAT (aka IP Masquerade)

If all you want is to reach the server from the client, you are done. If, however, you wish to access any and all other machines the server can reach, you need to do a little bit more on both sides.

The setup outlined here is extremely basic. We are going to show you just enough to enable your PLIP "client" machine to use the "host" machine's connection to the rest of your network and/or the Internet. We will be setting up transparent network address translation, aka IP Masquerading. We will not be setting up a true configurable firewall.

Server-Side Setup

Let's do this backwards . I'll show you all the commands you need to execute up front, then I will explain what each of them means and does. If you've been reading this book in order from cover to cover, (a) I'm impressed, and (b) this is a mere refresher on topics covered in much greater depth in Chapter 3 . If you would like, you can treat all of these commands as a magic incantation and skip the rest of this section. I recommend you read this section, but don't worry too much if you don't understand it.

These commands should be run as root on the server side:

  # modprobe ip_masq_ftp

  # echo "1" > /proc/sys/net/ipv4/ip_forward

  # echo "1" > /proc/sys/net/ipv4/ip_always_defrag

  # /sbin/ipchains -M -S 7200 10 160

  # /sbin/ipchains -P forward DENY

  # /sbin/ipchains -A forward -s 10.0.0.0/24 -j MASQ

The first command installs a module that supports masquerading of the FTP protocol. Since FTP requires that the remote end be able to open connections back to the client, this protocol requires special support to enable the return path . There are other such protocols, including cuseeme and, of course, Quake. FTP is the only one I chose to enable. I left these as modules. That's why modprobe is used to enable it.

The second command enables IP forwarding.

The third command tells the server side always to defragment fragmented IP datagrams. If you don't know what this means, don't worry ”you don't have to know. The 10-second version is that the actual low-level protocol of the Internet is called IP. IP packets are called datagrams. In theory, an IP datagram may be up to 64 kilobytes in length. Every network interface (Ethernet, token-ring, AX.25, etc.) has an MTU, or maximum transmission unit, which is the largest packet size the physical network can carry. In the case of Ethernet, this is generally set at 1500 bytes. When an IP datagram is routed over an interface, if the datagram is larger than the interface's MTU, the datagram is broken into " fragments " that are small enough to go over the interface. Generally, once fragmented, a datagram stays fragmented, since it would take more time and resources to reassemble them, only possibly to have to fragment them again at a later point in their journey. Thus, they may be made smaller and smaller on their journey, but they are never made larger again. They are only reassembled to full size at their final destination.

This is a problem, however, when the IP datagram carries TCP stream or UDP datagram data. Only the first such fragment has the information about which port is to receive the data. Subsequent fragments do not have this information. Suppose you have two FTP sessions being masqueraded and the two different clients are talking to the same server. Fragment 1 of session 1 comes in; it is sent to the correct client. Fragment 1 of session 2 comes in; it is sent to the correct client. Now fragment 2 of session 2 comes in. There is no way to tell if this fragment belongs to session 1 or session 2.

For this reason, the box that is doing the masquerading must "break with tradition" and must reassemble (defragment) all IP datagrams so that they can be routed as a unit. If you want to know more about this, read the excellent book Internetworking with TCP/IP by Douglas E. Comer.

The third command is the first of three " ipchains " commands. The ipchains command sets up "firewall rules." The first is:

  ipchains -M -S 7200 10 160

Here's what this does: The -M argument tells ipchains this is a masquerade request. The -S argument tells ipchains that we are setting masquerade parameters. Remember that in order to do masquerading, the "server" box must "remember" the host and port that actually originated a request and the port number on the server box that it used to "resend" the request from the server box (remember that masquerading hides an entire network behind the server box). The three numbers that follow the "-S" are:

· The number of seconds to "remember" a TCP connection.

· The number of seconds to "remember" a TCP connection for which an FIN has been received (see the previously cited book by Comer).

· The number of seconds to "remember" a UDP session. UDP is technically sessionless, but some request/reply protocols (like DNS) do exist.

The values shown here seem to work well. You must remember that masquerading is a "trick." It will mess you up sometimes. If you, for example, Telnet to another host while masqueraded and then you leave that socket idle for longer than the TCP timeout, you will find the connection up but frozen when you come back to it. This isn't a network failure! Your computer thinks the connection is still there. The far end thinks the connection is still there, but the proxy machine in the middle has forgotten that far end should be connected to your computer!

The next ipchains command is:

  ipchains -P forward DENY

The "-P" option specifies a policy. We are setting a policy on the "forward" chain. (This chain is "active" when we have a packet that has been accepted for input on one network interface that must be forwarded to another interface in order to reach its destination. We are here setting a policy that all such packets be silently dropped [that's what DENY means]. We could have said REJECT, which would have sent an ICMP-host or network-unreachable message back to the sender. We don't want such traffic.)

This sounds like we are disabling all routing from PLIP to eth0 and back! Well, we are. But this is just a default policy. We are about to add a specific rule to open the one and only path we want. That's the final ipchains command. Here it is:

  /sbin/ipchains -A forward -s 10.0.0.0/24 -j MASQ

So what's all this, then? The "-A" says we are going to append a rule to a chain. The "forward" argument is the chain we are appending a rule to. The "-s" specifies a source to which this rule shall be applied. In this case, it is the 10.x.x.x network with a 24-bit netmask (this is an alternate way to say a netmask of 255.255.255.0). The "-j" specifies a "jump." Any packet that matches the rule up to this point will be sent to the chain named after the "-j" parameter. The "MASQ" chain is a special "pre-existing" chain that masquerades the packet (just as DENY is a special chain that drops packets and REJECT is a special chain that drops packets with an ICMP report, and so on).

Notice we didn't really attempt to teach you the intricacies of firewalls here. You should have read all about this in Chapter 3 .

Client-Side Setup

Actually, no further configuration is required on the client side. You now have full connectivity from the client through the server to the rest of the world the server can reach.

In fact, the kernel configuration need not have been the same on both sides. The client side did not need firewalling and masquerading enabled. However, by configuring these capabilities on the client box, you can now configure the client to be a server if ever you need to do so.