diff options
Diffstat (limited to 'static/netbsd/man4/plip.4')
| -rw-r--r-- | static/netbsd/man4/plip.4 | 311 |
1 files changed, 311 insertions, 0 deletions
diff --git a/static/netbsd/man4/plip.4 b/static/netbsd/man4/plip.4 new file mode 100644 index 00000000..8f925162 --- /dev/null +++ b/static/netbsd/man4/plip.4 @@ -0,0 +1,311 @@ +.\" $NetBSD: plip.4,v 1.5 2018/05/09 08:04:06 wiz 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 +.Dt PLIP 4 +.Os +.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 -> ERROR* + 3 13 Data1 -> SLCT + 4 12 Data2 -> PE + 5 10 Data3 -> ACK* + 6 11 Data4 -> BUSY + 15 2 ERROR* -> Data0 + 13 3 SLCT -> Data1 + 12 4 PE -> Data2 + 10 5 ACK* -> Data3 + 11 6 BUSY -> 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 +<IP datagram> +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 Fl f ) +compared to CLPIP. |