312 lines
9.9 KiB
Groff
312 lines
9.9 KiB
Groff
.\" $NetBSD: plip.4,v 1.1 2004/01/28 17:21:15 jdolecek Exp $
|
|
.\"
|
|
.\" Copyright (c) 1996 A.R.Gordon, andrew.gordon@net-tel.co.uk
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
.\" must display the following acknowledgement:
|
|
.\" This product includes software developed by the University of
|
|
.\" California, Berkeley and its contributors.
|
|
.\" 4. Neither the name of the University nor the names of its contributors
|
|
.\" may be used to endorse or promote products derived from this software
|
|
.\" without specific prior written permission.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
.\" SUCH DAMAGE.
|
|
.\"
|
|
.\" Id: man4.i386/lp.4,v 1.9 1999/02/14 12:06:16 nsouch Exp
|
|
.\" $FreeBSD: src/share/man/man4/lp.4,v 1.5.2.3 2000/12/29 10:18:00 ru Exp $
|
|
.\"
|
|
.Dd January 28, 2004
|
|
.Os
|
|
.Dt PLIP 4
|
|
.Sh NAME
|
|
.Nm plip
|
|
.Nd printer port Internet Protocol driver
|
|
.Sh SYNOPSIS
|
|
.Cd "plip* at ppbus?"
|
|
.Cd options PLIP_DEBUG
|
|
.Sh DESCRIPTION
|
|
The
|
|
.Nm
|
|
driver allows a PC parallel printer port to be used as a point-to-point
|
|
network interface between two similarly configured systems.
|
|
Data is transferred 4 bits at a time, using the printer status
|
|
lines for input: hence there is no requirement for special
|
|
bidirectional hardware and any standard AT-compatible printer port
|
|
with working interrupts may be used.
|
|
.Pp
|
|
During the boot process, for each
|
|
.Xr ppbus 4
|
|
device which is attached and has an interrupt capability, a
|
|
corresponding
|
|
.Nm
|
|
device is attached.
|
|
The
|
|
.Nm
|
|
device is configured using
|
|
.Xr ifconfig 8
|
|
using the options for a point-to-point network interface:
|
|
.Pp
|
|
.Nm ifconfig
|
|
.Ar plip0
|
|
.Ar hostaddress destaddress
|
|
.Op Fl link0|link0
|
|
.Op up|down
|
|
.Op ...
|
|
.Pp
|
|
Configuring a
|
|
.Nm
|
|
device
|
|
.Dq up
|
|
with
|
|
.Xr ifconfig 8
|
|
causes the corresponding
|
|
.Xr ppbus 4
|
|
to be reserved for PLIP until the network interface is configured
|
|
.Dq down .
|
|
.Pp
|
|
The communication protocol is selected by the
|
|
.Cm link0
|
|
flag:
|
|
.Bl -tag -width Fl
|
|
.It Fl link0
|
|
(default)
|
|
Use
|
|
.Fx
|
|
mode (LPIP).
|
|
This is the simpler of the two modes and therefore slightly more
|
|
efficient.
|
|
.It Cm link0
|
|
Use Crynwr/Linux compatible mode (CLPIP).
|
|
This mode has a simulated ethernet packet header, and is easier to
|
|
interface to other types of equipment.
|
|
.El
|
|
.Pp
|
|
The interface MTU defaults to 1500, but may be set to any value.
|
|
Both ends of the link must be configured with the same MTU.
|
|
See
|
|
.Xr ifconfig 8
|
|
for details on configuring network interfaces.
|
|
.Ss Cable Connections
|
|
The cable connecting the two parallel ports should be wired as follows:
|
|
.Bd -literal
|
|
Pin Pin Description
|
|
2 15 Data0 -\*[Gt] ERROR*
|
|
3 13 Data1 -\*[Gt] SLCT
|
|
4 12 Data2 -\*[Gt] PE
|
|
5 10 Data3 -\*[Gt] ACK*
|
|
6 11 Data4 -\*[Gt] BUSY
|
|
15 2 ERROR* -\*[Gt] Data0
|
|
13 3 SLCT -\*[Gt] Data1
|
|
12 4 PE -\*[Gt] Data2
|
|
10 5 ACK* -\*[Gt] Data3
|
|
11 6 BUSY -\*[Gt] Data4
|
|
18-25 18-25 Ground
|
|
.Ed
|
|
.Pp
|
|
Cables with this wiring are widely available as
|
|
.Dq Tn Laplink
|
|
cables, and are often colored yellow.
|
|
.Pp
|
|
The connections are symmetric, and provide 5 lines in each direction
|
|
(four data plus one handshake).
|
|
The two modes use the same wiring, but make a
|
|
different choice of which line to use as handshake.
|
|
.Ss FreeBSD LPIP mode
|
|
The signal lines are used as follows:
|
|
.Bl -tag -width dataxxxxXPinxxX
|
|
.It Em Data0 (Pin 2)
|
|
Data out, bit 0.
|
|
.It Em Data1 (Pin 3)
|
|
Data out, bit 1.
|
|
.It Em Data2 (Pin 4)
|
|
Data out, bit 2.
|
|
.It Em Data3 (Pin 5)
|
|
Handshake out.
|
|
.It Em Data4 (Pin 6)
|
|
Data out, bit 3.
|
|
.It Em ERROR* (pin 15)
|
|
Data in, bit 0.
|
|
.It Em SLCT (pin 13)
|
|
Data in, bit 1.
|
|
.It Em PE (pin 12)
|
|
Data in, bit 2.
|
|
.It Em BUSY (pin 11)
|
|
Data in, bit 3.
|
|
.It Em ACK* (pin 10)
|
|
Handshake in.
|
|
.El
|
|
.Pp
|
|
When idle, all data lines are at zero.
|
|
Each byte is signaled in four steps: sender writes the 4 most
|
|
significant bits and raises the handshake line; receiver reads the
|
|
4 bits and raises its handshake to acknowledge; sender places the
|
|
4 least significant bits on the data lines and lowers the handshake;
|
|
receiver reads the data and lowers its handshake.
|
|
.Pp
|
|
The packet format has a two-byte header, comprising the fixed values
|
|
0x08, 0x00, immediately followed by the IP header and data.
|
|
.Pp
|
|
The start of a packet is indicated by simply signaling the first
|
|
byte of the header.
|
|
The end of the packet is indicated by inverting the data lines
|
|
(i.e. writing the ones-complement of the previous nibble to be
|
|
transmitted) without changing the state of the handshake.
|
|
.Pp
|
|
Note that the end-of-packet marker assumes that the handshake signal
|
|
and the data-out bits can be written in a single instruction -
|
|
otherwise certain byte values in the packet data would falsely be
|
|
interpreted as end-of-packet.
|
|
This is not a problem for the PC printer port, but requires care
|
|
when implementing this protocol on other equipment.
|
|
.Ss Crynwr/Linux CLPIP mode
|
|
The signal lines are used as follows:
|
|
.Bl -tag -width dataxxxxXPinxxX
|
|
.It Em Data0 (Pin 2)
|
|
Data out, bit 0.
|
|
.It Em Data1 (Pin 3)
|
|
Data out, bit 1.
|
|
.It Em Data2 (Pin 4)
|
|
Data out, bit 2.
|
|
.It Em Data3 (Pin 5)
|
|
Data out, bit 3.
|
|
.It Em Data4 (Pin 6)
|
|
Handshake out.
|
|
.It Em ERROR* (pin 15)
|
|
Data in, bit 0.
|
|
.It Em SLCT (pin 13)
|
|
Data in, bit 1.
|
|
.It Em PE (pin 12)
|
|
Data in, bit 2.
|
|
.It Em ACK* (pin 10)
|
|
Data in, bit 3.
|
|
.It Em BUSY (pin 11)
|
|
Handshake in.
|
|
.El
|
|
.Pp
|
|
When idle, all data lines are at zero.
|
|
Each byte is signaled in four steps: sender writes the 4 least
|
|
significant bits and raises the handshake line; receiver reads the
|
|
4 bits and raises its handshake to acknowledge; sender places the
|
|
4 most significant bits on the data lines and lowers the handshake;
|
|
receiver reads the data and lowers its handshake.
|
|
[Note that this is the opposite nibble order to LPIP mode].
|
|
.Pp
|
|
Packet format is:
|
|
.Bd -literal
|
|
Length (least significant byte)
|
|
Length (most significant byte)
|
|
12 bytes of supposed MAC addresses (ignored by FreeBSD).
|
|
Fixed byte 0x08
|
|
Fixed byte 0x00
|
|
\*[Lt]IP datagram\*[Gt]
|
|
Checksum byte.
|
|
.Ed
|
|
.Pp
|
|
The length includes the 14 header bytes, but not the length bytes
|
|
themselves nor the checksum byte.
|
|
.Pp
|
|
The checksum is a simple arithmetic sum of all the bytes (again,
|
|
including the header but not checksum or length bytes).
|
|
.Fx
|
|
calculates outgoing checksums, but does not validate incoming ones.
|
|
.Pp
|
|
The start of packet has to be signaled specially, since the line
|
|
chosen for handshake-in cannot be used to generate an interrupt.
|
|
The sender writes the value 0x08 to the data lines, and waits for
|
|
the receiver to respond by writing 0x01 to its data lines.
|
|
The sender then starts signaling the first byte of the packet (the
|
|
length byte).
|
|
.Pp
|
|
End of packet is deduced from the packet length and is not signaled
|
|
specially (although the data lines are restored to the zero, idle
|
|
state to avoid spuriously indicating the start of the next packet).
|
|
.Sh SEE ALSO
|
|
.Xr atppc 4 ,
|
|
.Xr ppbus 4 ,
|
|
.Xr ifconfig 8
|
|
.Sh HISTORY
|
|
The
|
|
.Nm
|
|
driver was implemented for
|
|
.Xr ppbus 4
|
|
in
|
|
.Fx
|
|
and imported into
|
|
.Nx .
|
|
Crynwr packet drivers implemented PLIP for
|
|
.Tn MS-DOS .
|
|
Linux also has a PLIP driver.
|
|
The protocols are know as LPIP
|
|
.Pq Fx
|
|
and CLPIP (Crynwr/Linux) in the documentation and code of this
|
|
port.
|
|
LPIP originally appeared in
|
|
.Fx .
|
|
.Sh AUTHORS
|
|
This manual page is based on the
|
|
.Fx
|
|
.Nm lp
|
|
manual page.
|
|
The information has been updated for the
|
|
.Nx
|
|
port by Gary Thorpe.
|
|
.Sh BUGS
|
|
Busy-waiting loops are used while handshaking bytes (and worse
|
|
still when waiting for the receiving system to respond to an
|
|
interrupt for the start of a packet).
|
|
Hence a fast system talking to a slow one will consume excessive
|
|
amounts of CPU.
|
|
This is unavoidable in the case of CLPIP mode due to the choice of
|
|
handshake lines; it could theoretically be improved in the case of
|
|
LPIP mode.
|
|
.Pp
|
|
Regardless of the speed difference between hosts, PLIP is CPU-intensive
|
|
and its made worse by having to send nibbles (4 bits) at a time.
|
|
.Pp
|
|
Polling timeouts are controlled by counting loop iterations rather
|
|
than timers, and so are dependent on CPU speed.
|
|
This is somewhat stabilized by the need to perform (slow) ISA bus
|
|
cycles to actually read the port.
|
|
.Pp
|
|
In the
|
|
.Fx
|
|
implementation, the idle state was not properly being restored on
|
|
errors or when finishing transmitting/receiving.
|
|
This implementation attempts to fix this problem which would result
|
|
in an unresponsive interface that could no longer be used (the port
|
|
bits get stuck in a state and nothing can progress) by zeroing the
|
|
data register when necessary.
|
|
.Pp
|
|
For unknown reasons, the more complex protocol (CLPIP) yields higher
|
|
data transfer rates during testing so far.
|
|
This could possibly be because the other side can reliably detect
|
|
when the host is transmitting in this implementation of CLPIP (this
|
|
may not necessarily be true in Linux or
|
|
.Tn MS-DOS
|
|
packet drivers).
|
|
CLPIP gets about 70 KB/sec (the best expected is about 75 KB/sec)
|
|
and LPIP get about 55 KB/sec.
|
|
This is despite LPIP being able to send more packets over the
|
|
interface (tested with
|
|
.Dq Ic ping -f )
|
|
compared to CLPIP.
|