1.\" $NetBSD: plip.4,v 1.3 2009/03/09 19:24:28 joerg Exp $ 2.\" 3.\" Copyright (c) 1996 A.R.Gordon, andrew.gordon@net-tel.co.uk 4.\" All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. All advertising materials mentioning features or use of this software 15.\" must display the following acknowledgement: 16.\" This product includes software developed by the University of 17.\" California, Berkeley and its contributors. 18.\" 4. Neither the name of the University nor the names of its contributors 19.\" may be used to endorse or promote products derived from this software 20.\" without specific prior written permission. 21.\" 22.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 23.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 24.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 25.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 26.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 27.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 28.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 29.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 30.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 31.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 32.\" SUCH DAMAGE. 33.\" 34.\" Id: man4.i386/lp.4,v 1.9 1999/02/14 12:06:16 nsouch Exp 35.\" $FreeBSD: src/share/man/man4/lp.4,v 1.5.2.3 2000/12/29 10:18:00 ru Exp $ 36.\" 37.Dd January 28, 2004 38.Dt PLIP 4 39.Os 40.Sh NAME 41.Nm plip 42.Nd printer port Internet Protocol driver 43.Sh SYNOPSIS 44.Cd "plip* at ppbus?" 45.Cd options PLIP_DEBUG 46.Sh DESCRIPTION 47The 48.Nm 49driver allows a PC parallel printer port to be used as a point-to-point 50network interface between two similarly configured systems. 51Data is transferred 4 bits at a time, using the printer status 52lines for input: hence there is no requirement for special 53bidirectional hardware and any standard AT-compatible printer port 54with working interrupts may be used. 55.Pp 56During the boot process, for each 57.Xr ppbus 4 58device which is attached and has an interrupt capability, a 59corresponding 60.Nm 61device is attached. 62The 63.Nm 64device is configured using 65.Xr ifconfig 8 66using the options for a point-to-point network interface: 67.Pp 68.Nm ifconfig 69.Ar plip0 70.Ar hostaddress destaddress 71.Op Fl link0|link0 72.Op up|down 73.Op ... 74.Pp 75Configuring a 76.Nm 77device 78.Dq up 79with 80.Xr ifconfig 8 81causes the corresponding 82.Xr ppbus 4 83to be reserved for PLIP until the network interface is configured 84.Dq down . 85.Pp 86The communication protocol is selected by the 87.Cm link0 88flag: 89.Bl -tag -width Fl 90.It Fl link0 91(default) 92Use 93.Fx 94mode (LPIP). 95This is the simpler of the two modes and therefore slightly more 96efficient. 97.It Cm link0 98Use Crynwr/Linux compatible mode (CLPIP). 99This mode has a simulated ethernet packet header, and is easier to 100interface to other types of equipment. 101.El 102.Pp 103The interface MTU defaults to 1500, but may be set to any value. 104Both ends of the link must be configured with the same MTU. 105See 106.Xr ifconfig 8 107for details on configuring network interfaces. 108.Ss Cable Connections 109The cable connecting the two parallel ports should be wired as follows: 110.Bd -literal 111 Pin Pin Description 112 2 15 Data0 -\*[Gt] ERROR* 113 3 13 Data1 -\*[Gt] SLCT 114 4 12 Data2 -\*[Gt] PE 115 5 10 Data3 -\*[Gt] ACK* 116 6 11 Data4 -\*[Gt] BUSY 117 15 2 ERROR* -\*[Gt] Data0 118 13 3 SLCT -\*[Gt] Data1 119 12 4 PE -\*[Gt] Data2 120 10 5 ACK* -\*[Gt] Data3 121 11 6 BUSY -\*[Gt] Data4 122 18-25 18-25 Ground 123.Ed 124.Pp 125Cables with this wiring are widely available as 126.Dq Tn Laplink 127cables, and are often colored yellow. 128.Pp 129The connections are symmetric, and provide 5 lines in each direction 130(four data plus one handshake). 131The two modes use the same wiring, but make a 132different choice of which line to use as handshake. 133.Ss FreeBSD LPIP mode 134The signal lines are used as follows: 135.Bl -tag -width dataxxxxXPinxxX 136.It Em Data0 (Pin 2) 137Data out, bit 0. 138.It Em Data1 (Pin 3) 139Data out, bit 1. 140.It Em Data2 (Pin 4) 141Data out, bit 2. 142.It Em Data3 (Pin 5) 143Handshake out. 144.It Em Data4 (Pin 6) 145Data out, bit 3. 146.It Em ERROR* (pin 15) 147Data in, bit 0. 148.It Em SLCT (pin 13) 149Data in, bit 1. 150.It Em PE (pin 12) 151Data in, bit 2. 152.It Em BUSY (pin 11) 153Data in, bit 3. 154.It Em ACK* (pin 10) 155Handshake in. 156.El 157.Pp 158When idle, all data lines are at zero. 159Each byte is signaled in four steps: sender writes the 4 most 160significant bits and raises the handshake line; receiver reads the 1614 bits and raises its handshake to acknowledge; sender places the 1624 least significant bits on the data lines and lowers the handshake; 163receiver reads the data and lowers its handshake. 164.Pp 165The packet format has a two-byte header, comprising the fixed values 1660x08, 0x00, immediately followed by the IP header and data. 167.Pp 168The start of a packet is indicated by simply signaling the first 169byte of the header. 170The end of the packet is indicated by inverting the data lines 171(i.e. writing the ones-complement of the previous nibble to be 172transmitted) without changing the state of the handshake. 173.Pp 174Note that the end-of-packet marker assumes that the handshake signal 175and the data-out bits can be written in a single instruction - 176otherwise certain byte values in the packet data would falsely be 177interpreted as end-of-packet. 178This is not a problem for the PC printer port, but requires care 179when implementing this protocol on other equipment. 180.Ss Crynwr/Linux CLPIP mode 181The signal lines are used as follows: 182.Bl -tag -width dataxxxxXPinxxX 183.It Em Data0 (Pin 2) 184Data out, bit 0. 185.It Em Data1 (Pin 3) 186Data out, bit 1. 187.It Em Data2 (Pin 4) 188Data out, bit 2. 189.It Em Data3 (Pin 5) 190Data out, bit 3. 191.It Em Data4 (Pin 6) 192Handshake out. 193.It Em ERROR* (pin 15) 194Data in, bit 0. 195.It Em SLCT (pin 13) 196Data in, bit 1. 197.It Em PE (pin 12) 198Data in, bit 2. 199.It Em ACK* (pin 10) 200Data in, bit 3. 201.It Em BUSY (pin 11) 202Handshake in. 203.El 204.Pp 205When idle, all data lines are at zero. 206Each byte is signaled in four steps: sender writes the 4 least 207significant bits and raises the handshake line; receiver reads the 2084 bits and raises its handshake to acknowledge; sender places the 2094 most significant bits on the data lines and lowers the handshake; 210receiver reads the data and lowers its handshake. 211[Note that this is the opposite nibble order to LPIP mode]. 212.Pp 213Packet format is: 214.Bd -literal 215Length (least significant byte) 216Length (most significant byte) 21712 bytes of supposed MAC addresses (ignored by FreeBSD). 218Fixed byte 0x08 219Fixed byte 0x00 220\*[Lt]IP datagram\*[Gt] 221Checksum byte. 222.Ed 223.Pp 224The length includes the 14 header bytes, but not the length bytes 225themselves nor the checksum byte. 226.Pp 227The checksum is a simple arithmetic sum of all the bytes (again, 228including the header but not checksum or length bytes). 229.Fx 230calculates outgoing checksums, but does not validate incoming ones. 231.Pp 232The start of packet has to be signaled specially, since the line 233chosen for handshake-in cannot be used to generate an interrupt. 234The sender writes the value 0x08 to the data lines, and waits for 235the receiver to respond by writing 0x01 to its data lines. 236The sender then starts signaling the first byte of the packet (the 237length byte). 238.Pp 239End of packet is deduced from the packet length and is not signaled 240specially (although the data lines are restored to the zero, idle 241state to avoid spuriously indicating the start of the next packet). 242.Sh SEE ALSO 243.Xr atppc 4 , 244.Xr ppbus 4 , 245.Xr ifconfig 8 246.Sh HISTORY 247The 248.Nm 249driver was implemented for 250.Xr ppbus 4 251in 252.Fx 253and imported into 254.Nx . 255Crynwr packet drivers implemented PLIP for 256.Tn MS-DOS . 257Linux also has a PLIP driver. 258The protocols are know as LPIP 259.Pq Fx 260and CLPIP (Crynwr/Linux) in the documentation and code of this 261port. 262LPIP originally appeared in 263.Fx . 264.Sh AUTHORS 265This manual page is based on the 266.Fx 267.Nm lp 268manual page. 269The information has been updated for the 270.Nx 271port by Gary Thorpe. 272.Sh BUGS 273Busy-waiting loops are used while handshaking bytes (and worse 274still when waiting for the receiving system to respond to an 275interrupt for the start of a packet). 276Hence a fast system talking to a slow one will consume excessive 277amounts of CPU. 278This is unavoidable in the case of CLPIP mode due to the choice of 279handshake lines; it could theoretically be improved in the case of 280LPIP mode. 281.Pp 282Regardless of the speed difference between hosts, PLIP is CPU-intensive 283and its made worse by having to send nibbles (4 bits) at a time. 284.Pp 285Polling timeouts are controlled by counting loop iterations rather 286than timers, and so are dependent on CPU speed. 287This is somewhat stabilized by the need to perform (slow) ISA bus 288cycles to actually read the port. 289.Pp 290In the 291.Fx 292implementation, the idle state was not properly being restored on 293errors or when finishing transmitting/receiving. 294This implementation attempts to fix this problem which would result 295in an unresponsive interface that could no longer be used (the port 296bits get stuck in a state and nothing can progress) by zeroing the 297data register when necessary. 298.Pp 299For unknown reasons, the more complex protocol (CLPIP) yields higher 300data transfer rates during testing so far. 301This could possibly be because the other side can reliably detect 302when the host is transmitting in this implementation of CLPIP (this 303may not necessarily be true in Linux or 304.Tn MS-DOS 305packet drivers). 306CLPIP gets about 70 KB/sec (the best expected is about 75 KB/sec) 307and LPIP get about 55 KB/sec. 308This is despite LPIP being able to send more packets over the 309interface (tested with 310.Dq Ic ping Fl f ) 311compared to CLPIP. 312