share/man/man4/plip.4

   1 .\" $NetBSD: plip.4,v 1.2 2004/12/08 18:33:32 peter 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
  47 The
  48 .Nm
  49 driver allows a PC parallel printer port to be used as a point-to-point
  50 network interface between two similarly configured systems.
  51 Data is transferred 4 bits at a time, using the printer status
  52 lines for input: hence there is no requirement for special
  53 bidirectional hardware and any standard AT-compatible printer port
  54 with working interrupts may be used.
  55 .Pp
  56 During the boot process, for each
  57 .Xr ppbus 4
  58 device which is attached and has an interrupt capability, a
  59 corresponding
  60 .Nm
  61 device is attached.
  62 The
  63 .Nm
  64 device is configured using
  65 .Xr ifconfig 8
  66 using 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
  75 Configuring a
  76 .Nm
  77 device
  78 .Dq up
  79 with
  80 .Xr ifconfig 8
  81 causes the corresponding
  82 .Xr ppbus 4
  83 to be reserved for PLIP until the network interface is configured
  84 .Dq down .
  85 .Pp
  86 The communication protocol is selected by the
  87 .Cm link0
  88 flag:
  89 .Bl -tag -width Fl
  90 .It Fl link0
  91 (default)
  92 Use
  93 .Fx
  94 mode (LPIP).
  95 This is the simpler of the two modes and therefore slightly more
  96 efficient.
  97 .It Cm link0
  98 Use Crynwr/Linux compatible mode (CLPIP).
  99 This mode has a simulated ethernet packet header, and is easier to
 100 interface to other types of equipment.
 101 .El
 102 .Pp
 103 The interface MTU defaults to 1500, but may be set to any value.
 104 Both ends of the link must be configured with the same MTU.
 105 See
 106 .Xr ifconfig 8
 107 for details on configuring network interfaces.
 108 .Ss Cable Connections
 109 The 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
 125 Cables with this wiring are widely available as
 126 .Dq Tn Laplink
 127 cables, and are often colored yellow.
 128 .Pp
 129 The connections are symmetric, and provide 5 lines in each direction
 130 (four data plus one handshake).
 131 The two modes use the same wiring, but make a
 132 different choice of which line to use as handshake.
 133 .Ss FreeBSD LPIP mode
 134 The signal lines are used as follows:
 135 .Bl -tag -width dataxxxxXPinxxX
 136 .It Em Data0 (Pin 2)
 137 Data out, bit 0.
 138 .It Em Data1 (Pin 3)
 139 Data out, bit 1.
 140 .It Em Data2 (Pin 4)
 141 Data out, bit 2.
 142 .It Em Data3 (Pin 5)
 143 Handshake out.
 144 .It Em Data4 (Pin 6)
 145 Data out, bit 3.
 146 .It Em ERROR* (pin 15)
 147 Data in, bit 0.
 148 .It Em SLCT (pin 13)
 149 Data in, bit 1.
 150 .It Em PE (pin 12)
 151 Data in, bit 2.
 152 .It Em BUSY (pin 11)
 153 Data in, bit 3.
 154 .It Em ACK* (pin 10)
 155 Handshake in.
 156 .El
 157 .Pp
 158 When idle, all data lines are at zero.
 159 Each byte is signaled in four steps:  sender writes the 4 most
 160 significant bits and raises the handshake line; receiver reads the
 161 4 bits and raises its handshake to acknowledge; sender places the
 162 4 least significant bits on the data lines and lowers the handshake;
 163 receiver reads the data and lowers its handshake.
 164 .Pp
 165 The packet format has a two-byte header, comprising the fixed values
 166 0x08, 0x00, immediately followed by the IP header and data.
 167 .Pp
 168 The start of a packet is indicated by simply signaling the first
 169 byte of the header.
 170 The end of the packet is indicated by inverting the data lines
 171 (i.e. writing the ones-complement of the previous nibble to be
 172 transmitted) without changing the state of the handshake.
 173 .Pp
 174 Note that the end-of-packet marker assumes that the handshake signal
 175 and the data-out bits can be written in a single instruction -
 176 otherwise certain byte values in the packet data would falsely be
 177 interpreted as end-of-packet.
 178 This is not a problem for the PC printer port, but requires care
 179 when implementing this protocol on other equipment.
 180 .Ss Crynwr/Linux CLPIP mode
 181 The signal lines are used as follows:
 182 .Bl -tag -width dataxxxxXPinxxX
 183 .It Em Data0 (Pin 2)
 184 Data out, bit 0.
 185 .It Em Data1 (Pin 3)
 186 Data out, bit 1.
 187 .It Em Data2 (Pin 4)
 188 Data out, bit 2.
 189 .It Em Data3 (Pin 5)
 190 Data out, bit 3.
 191 .It Em Data4 (Pin 6)
 192 Handshake out.
 193 .It Em ERROR* (pin 15)
 194 Data in, bit 0.
 195 .It Em SLCT (pin 13)
 196 Data in, bit 1.
 197 .It Em PE (pin 12)
 198 Data in, bit 2.
 199 .It Em ACK* (pin 10)
 200 Data in, bit 3.
 201 .It Em BUSY (pin 11)
 202 Handshake in.
 203 .El
 204 .Pp
 205 When idle, all data lines are at zero.
 206 Each byte is signaled in four steps:  sender writes the 4 least
 207 significant bits and raises the handshake line; receiver reads the
 208 4 bits and raises its handshake to acknowledge; sender places the
 209 4 most significant bits on the data lines and lowers the handshake;
 210 receiver reads the data and lowers its handshake.
 211 [Note that this is the opposite nibble order to LPIP mode].
 212 .Pp
 213 Packet format is:
 214 .Bd -literal
 215 Length (least significant byte)
 216 Length (most significant byte)
 217 12 bytes of supposed MAC addresses (ignored by FreeBSD).
 218 Fixed byte 0x08
 219 Fixed byte 0x00
 220 \*[Lt]IP datagram\*[Gt]
 221 Checksum byte.
 222 .Ed
 223 .Pp
 224 The length includes the 14 header bytes, but not the length bytes
 225 themselves nor the checksum byte.
 226 .Pp
 227 The checksum is a simple arithmetic sum of all the bytes (again,
 228 including the header but not checksum or length bytes).
 229 .Fx
 230 calculates outgoing checksums, but does not validate incoming ones.
 231 .Pp
 232 The start of packet has to be signaled specially, since the line
 233 chosen for handshake-in cannot be used to generate an interrupt.
 234 The sender writes the value 0x08 to the data lines, and waits for
 235 the receiver to respond by writing 0x01 to its data lines.
 236 The sender then starts signaling the first byte of the packet (the
 237 length byte).
 238 .Pp
 239 End of packet is deduced from the packet length and is not signaled
 240 specially (although the data lines are restored to the zero, idle
 241 state 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
 247 The
 248 .Nm
 249 driver was implemented for
 250 .Xr ppbus 4
 251 in
 252 .Fx
 253 and imported into
 254 .Nx .
 255 Crynwr packet drivers implemented PLIP for
 256 .Tn MS-DOS .
 257 Linux also has a PLIP driver.
 258 The protocols are know as LPIP
 259 .Pq Fx
 260 and CLPIP (Crynwr/Linux) in the documentation and code of this
 261 port.
 262 LPIP originally appeared in
 263 .Fx .
 264 .Sh AUTHORS
 265 This manual page is based on the
 266 .Fx
 267 .Nm lp
 268 manual page.
 269 The information has been updated for the
 270 .Nx
 271 port by Gary Thorpe.
 272 .Sh BUGS
 273 Busy-waiting loops are used while handshaking bytes (and worse
 274 still when waiting for the receiving system to respond to an
 275 interrupt for the start of a packet).
 276 Hence a fast system talking to a slow one will consume excessive
 277 amounts of CPU.
 278 This is unavoidable in the case of CLPIP mode due to the choice of
 279 handshake lines; it could theoretically be improved in the case of
 280 LPIP mode.
 281 .Pp
 282 Regardless of the speed difference between hosts, PLIP is CPU-intensive
 283 and its made worse by having to send nibbles (4 bits) at a time.
 284 .Pp
 285 Polling timeouts are controlled by counting loop iterations rather
 286 than timers, and so are dependent on CPU speed.
 287 This is somewhat stabilized by the need to perform (slow) ISA bus
 288 cycles to actually read the port.
 289 .Pp
 290 In the
 291 .Fx
 292 implementation, the idle state was not properly being restored on
 293 errors or when finishing transmitting/receiving.
 294 This implementation attempts to fix this problem which would result
 295 in an unresponsive interface that could no longer be used (the port
 296 bits get stuck in a state and nothing can progress) by zeroing the
 297 data register when necessary.
 298 .Pp
 299 For unknown reasons, the more complex protocol (CLPIP) yields higher
 300 data transfer rates during testing so far.
 301 This could possibly be because the other side can reliably detect
 302 when the host is transmitting in this implementation of CLPIP (this
 303 may not necessarily be true in Linux or
 304 .Tn MS-DOS
 305 packet drivers).
 306 CLPIP gets about 70 KB/sec (the best expected is about 75 KB/sec)
 307 and LPIP get about 55 KB/sec.
 308 This is despite LPIP being able to send more packets over the
 309 interface (tested with
 310 .Dq Ic ping Fl f )
 311 compared to CLPIP.