PC/IP USER'S GUIDE
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
LABORATORY FOR COMPUTER SCIENCE
NETWORK PROGRAMS BASED ON THE DOD INTERNET PROTOCOL
FOR THE IBM PERSONAL COMPUTER
PC/IP release of March, 1986; document updated February 24, 1986
by: Jerome H. Saltzer
John L. Romkey
Copyright 1984, 1985, 1986 by the Massachusetts Institute of Technology
Permission to use, copy, modify, and distribute these programs and their
documentation for any purpose and without fee is hereby granted, provided that
this copyright and permission notice appear on all copies and supporting
documentation, the name of M.I.T. not be used in advertising or publicity
pertaining to distribution of the programs without written prior permission,
and notice be given in supporting documentation that copying and distribution
is by permission of M.I.T. M.I.T. makes no representations about the
suitability of this software for any purpose. It is provided "as is" without
express or implied warranty.
The PC/IP packages are built on the work of many people in the TCP/IP
community, both at M.I.T. and elsewhere. Following are some of the people who
directly helped in the creation of the packages.
Network environment--John L. Romkey
Terminal emulator and customizer--David A. Bridgham
Initial TFTP--Karl D. Wright
Initial telnet--Louis J. Konopelski
Telnet model--David D. Clark
Tasking package--Larry W. Allen
Development system--Christopher J. Terman
Development environment--Wayne C. Gramlich
Administrative Assistant--Muriel Webber
October 3, 1985. This document is in cover.mss
1. Overview of PC/IP network programs
The PC/IP network programs are a set of commands that operate under the DOS
operating system for the IBM Personal Computer. They provide a set of
facilities that make the PC a directly attachable network host rather than a
simulated intelligent terminal.
The PC/IP programs have their origin in an M.I.T. research project on
protocol effectiveness. In consequence, they incorporate several second- and
third-generation protocol implementation techniques and algorithms. These
techniques and algorithms:
- reduce the processing load on the computer
- maximize opportunities for parallel operation of the network and the
- minimize unnecessary retransmission of data
- eliminate certain pathological situations in which two technically
compatible machines communicate very inefficiently.
One result of application of these techniques is that a complete host
implementation can operate with high effectiveness in a machine as small as the
1.1. Software environment
The PC/IP programs are a set of commands that operate under IBM PC-DOS
versions 2.0, 2.1, 3.0, or 3.1. A device driver must be installed, but no
changes are required to the operating system. Ethernet versions of the PC/IP
programs have been verified to work under TopView.
These programs all use the ARPANET standard end-to-end Internet Protocol, IP,
and can be used to communicate with any other host that also uses that
protocol. Individual commands use various higher-level ARPANET standard
protocols from the IP family, as appropriate:
TCP for reliable byte stream transmission
UDP for datagram service
Telnet for remote login
ICMP for control messages
TFTP for file transfer
name lookup service protocol
error and event logging protocol
time-of-day and calendar service protocol
Thus these programs are directly useful only in a network environment where
there are other hosts that implement one or more IP-family protocols [Thus the
programs are not useful on a network where all other hosts implement only the
SNA LU6.2, A.I. Laboratory CHAOS, DECNET, or Xerox NS protocol families.]
There is one limitation in the PC/IP protocol implementation that may affect
usage in some environments: reassembly of fragmented packets is not supported.
If one anticipates communications with a host that is accessible only via
networks that require small packets, this limitation may be a problem.
In addition to the protocols mentioned above, PC/IP network programs make
use, if available, of several network services commonly found in IP network
environments. These services include:
- name-to-host-address translation service
- IP gateways to other IP networks
- time-of-day and calendar services
- error logging service
- printer service
If any of these services is not available, it is still possible to use the
PC/IP network programs, though with loss of certain convenience features.
1.2. Hardware environment
The PC/IP programs operate on a standard IBM PC, PC/XT, or PC/AT. They have
also been reported to work on a COMPAQ IBM-compatible PC. Under DOS 2.0, they
require 128 kbytes of memory, one disk drive, 80-column display (the IBM
Monochrome display card, Color Graphics Adapter or Professional Graphics
Adapter) and any of the following kinds of hardware network attachment: RS-232
port, Interlan NI5010 Ethernet(Ethernet is a registered trademark of the Xerox
Coporation.), 3COM Etherlink[Etherlink is a registered trademark of 3COM
Corporation.] Ethernet (not the new, smart card), or Proteon proNET(proNET is a
registered trademark of Proteon, Inc.).
When an RS-232 port is used, the other end of the line can go (either by
dialup or by direct wiring) to another PC or a gateway that forwards packets to
and from a local area network. The link-level protocol used is a non-standard
one designed to allow flow control, buffer management, and packet-to-packet
redundancy compression on a full-duplex line. To simplify forwarding of
packets destined for an RS-232 attached PC, the gateway assigns the internet
host address of the PC. The PC asks the gateway for its assigned address using
another non- standard protocol. The port may be used at any standard data rate
from 300 bits/sec. to 19.2 kbits/sec. Note, however, that highly interactive
services, such as character-at-a-time remote echoing, are not every effective
at data rates below 9.6 kbits/sec. The RS-232 port does not work under TopView
at speeds of 9.6 kbits/sec. and higher.
The Ethernet versions of the PC/IP programs provide a driver for the Interlan
NI5010 interface and the 3COM Etherlink interface(The PC/IP Etherlink driver
does not use the 3COM software or device driver, and it does not require that
hardware switches be set to simulate availability of four disk drives.
However, if the environment contains the 3COM software or switch settings, the
PC/IP Ethernet driver will still operate correctly.). Since Ethernet addresses
do not map directly into internet host addresses, the Ethernet driver uses ARP,
the IP standard Ethernet-to-Internet address translation protocol. If this
protocol is not implemented by other hosts, it is possible, by use of a
customization option, to supply manually a limited number of Ethernet-to-
Internet address bindings.
The proNET versions of the PC/IP programs provide a driver for the Proteon,
Inc., proNET ring interface.
There are four versions of each PC/IP command, one version for each of kind
of network interface supported.
A customization program, named custom, sets certain parameters in a DOS
device driver that is used by each PC/IP network program. Some of these
parameters, such as serial line speed, cannot otherwise be discovered by the
software. Others, such as the preferred modes of operation of the remote login
program, depend on characteristics of the distant host most often used. Still
others, such as the internet addresses of name servers, are site-dependent.
Details of which parameters may be set for each program are found in the
descriptions of the individual programs and in the description of custom.
26 September 1985. This document is in file overview.mss
2. Technical Notes on PC/IP
This section discusses technical details about the implementation of PC/IP
and interactions between PC/IP and other TCP/IP implementations (especially
Berkeley 4.2 Unix). Casual users of PC/IP can skip this section unless
interested; people installing PC/IP at a site should definitely read this
2.1. Device Drivers
Both the Interlan and 3COM ethernet drivers use the Address Resolution
Protocol (ARP), as described in NIC RFC 826. The proNET driver does not support
Some TCP/IP implementations encapsulate IP packets in a non-standard fashion
called a trailer, as specified in NIC RFC 893. PC/IP does not support trailers
with any of its drivers; instead, it supports only the standard form of
encapsulation as specified in NIC RFC 894. The only implementations that are
known to send trailers are 4.2 UNIX(UNIX is a trademark of American Telephone
and Telegraph Co.") derivatives (Wollongong's VMS TCP/IP, for instance, is
derived from 4.2's). The 4.2 Unix command ifconfig(8) can control trailer usage
on a per-interface basis.
The maximum length packet PC/IP is prepared to send or receive is 620 bytes
long, including the local net header.
The IP layer does not implement packet fragmentation or reassembly. If a
packet fragment is received, it is discarded. Options are never sent, and
incoming options are ignored. Type of service is ignored.
Incoming destination unreachables and other errors will be printed on the
display if the NETERR or PROTERR debugging flags are turned on (see the section
on debugging). IP protocol or TCP or UDP socket, unless those packets were
broadcast. Packets are determined to be broadcast by the old convention of
having the host field be all 0's.
Routing is done according to RFC 950. The user specifies the PC's network
address and the number of bits in its subnet field with the PC/custom command.
This program computes a mask that can be used to separate the net/subnet
portion of the address from the host portion. Two machines are determined to be
on the same physical network if the net/subnet parts of both their addresses
are identical. If PC/IP tries to send to a machine that is not on the same
physical network, it routes the packet through the default gateway, also
specified with custom. If PC/IP receives an ICMP redirect from the gateway, it
records the redirect in internal routing tables, which it scans before using
the default gateway.
PC/IP has a complete UDP implementation, including checksums.
The 4.2 Unix UDP had a number of problems that have been fixed in 4.3. Among
other things, checksums were computed incorrectly, so PC's would not accept
packets from 4.2 machines.
The TCP is a single connection implementation tailored to Telnet. It sends
MAXBUFSIZE options setting the maximum buffer size to 511 bytes to defeat
trailers (discussed above; trailer packets have a multiple of 512 bytes of
data). It ignores incoming MAXBUFSIZE options.
A number of TCP problems have been fixed since the January 1985 release. One
of the most noticeable was an incompatibility between 4.2 Unix's TCP and
PC/IP's. The 4.2 TCP sent probing messages called "keepalives" when a
connection was otherwise inactive. PC/IP did not respond to these messages the
way 4.2 expected, and 4.2 would decide that the PC was down and close the
connection. PC/IP's TCP now responds as 4.2 expects.
2.5. Hostname resolution
This release has a simple domain name resolver, and all executable programs
use it in addition to the old-style hostname resolver. This domain name
resolver depends on the name server doing recursion. Recent versions of the
Bind Unix domain name system have supported this. There are not currently any
other servers to report on.
PC/IP uses the following algorithm when trying to resolve hostname foo:
If foo is a numeric address
then parse foo and return the result.
If foo is a fully qualified domain name,
then attempt a domain name resolution of foo
if the domain name resolution fails
try an old style name resolution of foo
if this resolution fails return an error
If foo is not a fully qualified domain name,
then attempt a domain name resolution of foo.my_domain
(where my_domain is the default domain specified
in configuration with the PC/custom command)
if that name resolution fails, try foo.arpa
if that fails, try foo with old name resolver
if that fails, return an error
The PC TFTP implementation includes both a TFTP user and server, and
implements both NETASCII and OCTET modes of file transfer.
The 4.2 Unix TFTP server and user were unreliable and did not implement
NETASCII mode. A completely different implementation of TFTP for Berkeley
UNIX, one that meets all the specifications of TFTP and that does not require
either Berkeley or AT&T source licenses, is available on on the PC/IP source
The 4.2 lpr daemon accepts requests only from hosts authorized to use it. A
host is authorized if it is listed in the file /etc/hosts.lpd on the server
host. Unfortunately, only hosts with names are handled, so you must assign
names to any PC's you wish to let use the line printer spooler. See 4.2BSD Line
Printer Spooler Manual, by Ralph Campbell, included in the 4.2 and 4.3 Unix
17 January 1986. This document is in file tech.mss
3. Other documentation
This section provides an annotated list of other documents that describe or
pertain to PC/IP.
1) Saltzer, J.H., et al., "The Desktop Computer as a Network Participant,"
IEEE Selected Areas in Communications, May, 1985, pp 468-478.
Discussion of the implementation may be found in:
2) Romkey, John L., "PC/IP Programmer's Manual"
The following undergraduate thesis describes the first implementation of a
file transfer protocol package. Although that package has been superseded,
there are still several points of design strategy that carry over into various
3) Wright, Karl D., "A File Transfer Program for a Personal Computer,"
S. B. Thesis, M.I.T. Department of Electrical Engineering and Computer Science,
April, 1982. Also available as M.I.T. L.C.S. Technical Memorandum TM-217.
The following undergraduate thesis describes the TCP/Telnet package. This
package is still in use, though the thesis describes an early implementation.
4) Konopelski, Louis J., "Implementing Internet Remote Login on a Personal
Computer," S. B. Thesis, M.I.T. Department of Electrical Engineering and
Computer Science, December, 1982. Also available as M.I.T. L.C.S. Technical
Much of the PC/IP implementation was influenced by the ideas of David
D. Clark documented in the "Internet Protocol Implementation Guide," August,
1982, SRI International, Menlo Park, California. Five parts of this document
are of particular interest:
5) Window and Acknowledgement Strategy in TCP (RFC 813)
6) Names, Addresses, Ports and Routes (RFC 814)
7) IP Datagram Reassembly Algorithms (RFC 815)
8) Fault Isolation and Recovery (RFC 816)
9) Modularity and Efficiency in Protocol Implementation (RFC 817)
The protocols used in the PC/IP packages are specified in the "Internet
Protocol Transition Workbook", March, 1982, available from SRI international.
The particular protocol documents are:
10) Internet Protocol (RFC-791)
11) Internet Control Message Protocol (RFC-792)
12) User Datagram Protocol (RFC-768)
13) Transmission Control Protocol (RFC-793)
14) Telnet Protocol (RFC-764)
15) Trivial File Transfer Protocol (RFC-783)
16) Name Server Protocol (IEN-116)
17) Time Server Protocol (RFC-868)
18) Nicname/Whois server (RFC-812)
19) Echo Protocol (RFC-862)
One other protocol is described in the ARPANET Protocol handbook of January,
20) Finger protocol (NIC-42758 or RFC-742)
The domain name system and name resolution protocol are described in the
21) Domain Names - Concepts and Facilities (RFC-882)
22) Domain Names - Implementation Specification (RFC-883)
The Supdup remote login protocol is described by Mark Crispin in:
23) Supdup (RFC 734)
The 4.2 Unix printer spooling protocol is described in the PC/IP Programmer's
Manual mentioned above, and is also described by Ralph Campbell in:
24) 4.2BSD Line Printer Spooler Manual (Unix documentation)
The subnet routing scheme used by PC/IP is described by Jeff Mogul and Jon
25) Internet Standard Subnetting Procedure (RFC 950)
The method for encapsulating IP packets on an ethernet is as specified by
Charles Hornig in:
26) A Standard for the Transmission of IP Datagrams over Ethernet Networks
The Address Resolution Protocol, used only by the ethernet drivers, is as
specified by David Plummer in:
27) An Ethernet Address Resolution Protocol (RFC 826)
The protocol used to send files to the Imagen print server is described in:
28) Imprint-10 Programmer's Manual, Imagen Corp. April, 1984.
The following document describes a transcription of PC/IP into Pascal, for
use on the Apple Macintosh computer and Applebus:
29) Sherman, Mark, "A Network Package for the Macintosh using DoD Internet
Protocols," Department of Mathematics and Computer Science, Dartmouth College,
29 December 1985. This document is in file otherdoc.mss
4. Changes From The Last Release
This section describes user-visible changes since the January, 1985, release
of the PC/IP packages.
A. Changes to user commands.
1. Now allows the user to select transmit and receive DMA channels.
2. Accepts interface base I/O address in hexadecimal instead of
3. A new flag was added to specify the preferred output radix for IP
addresses (decimal or octal).
4. Now recomputes the subnet mask when either the number of subnet bits
changes or the internet address changes (address could have changed
5. Permits the user to separately control debug tracing of different
6. The office and phone number fields were removed and the space
7. Added a domain name field and the addresses of up to three domain
name servers. The number of old-style name servers was reduced to
1. Can now match on several layers of types, and can match on protocol
source and destination addresses.
2. Now has an explicit pause command and also pauses when printing help
3. Packets are displayed in color when possible.
4. Records the number of packets accepted of each type.
5. Records the number of packets accepted by length (in quanta of 64
6. Records the number of broadcast packets.
7. Ethernet versions can display the manufacturer of an ethernet
interface when printing the address.
8. Can print local net addresses when printing packets symbolically.
9. Works with proNET driver.
10. Can match on source, destination or source/or/destination address
(hardware or protocol).
1. PC/setclock now automatically adjusts for daylight savings time
according to 1985 U.S. law.
1. Changed user interface to the debugging and statistics printing
commands, allowing a larger repertoire. All debugging commands now
are obtained by F10/control-something; a list of them is displayed
in response to F10/control-h.
1. Greeting message now mentions the mode of the transfer, so that
default of netascii does not trap unwitting user.
2. Packet buffer allocation now is preceded by flushing out broadcast
packets to allow TCP packet processing. Formerly, if a lot of
broadcasts or character-at-a-time messages from a hyperactive UNIX
filled up the packet buffers during initialization of tftp, it
couldn't get any free buffers and would have to give up.
3. Disk writes are now collected into a 10 KByte buffer rather than
performed once per arriving packet. Improves performance on
Ethernet transfers to floppy disks by a factor of three. A new
option ("spool") to the server turns off this buffering, so that the
tftp server can be used as an interface to a print spooler.
1. Order of opening connection, receiving data, and closing connection
modified to avoid bug in BSD 4.2 finger server, which would forget
about sending more than one packet if the connection is closed from
the originator's end.
2. All bare ASCII LF characters are changed to LF/CR, because BSD 4.2
finger server doesn't send network standard ASCII. Since a bare LF
is never legal in network standard ASCII, this change doesn't cause
trouble with servers that do netascii right.
B. Changes to protocol implementations
TCP (affects telnet, nicname, and whois)
1. Fixed error in which TCP failed to reack when rereceiving old data.
This error had two effects: First, if an ACK was lost, the
connection would hang, the other end would give up, and the next
thing to be typed would cause a foreign reset. Second, it caused
TCP to ignore UNIX "keepalives", which lead to a foreign reset if
the connection isn't used for ten minutes. TCP now responds to
2. Fixed error in TCP close/reset sequence, eliminating occasional
message "Bad TCP State" on exit.
3. Performance improvement of about 50%, accomplished by calling client
with larger blocks.
4. Implemented TCP maxsegsize option, set to 511 bytes. This feature
prevents the foreign system from sending packets larger than the PC
can handle. It also has the side effect of preventing Berkeley 4.2
systems from sending packets with trailers to the PC.
5. Changed checksum calculation to accept either FFFF or 0000, to
compensate for the ambiguous TCP specification as to which form of
one's complement zero is expected. Some implementations use one,
some the other. TCP now works with either kind of implementation.
6. Connection close sequence now acknowledges properly when the close
is initiated by the PC.
7. A deadlock in the algorithm for window opening was eliminated.
8. Closing a connection when it is only partially opened no longer
triggers an "unexpected state" error message.
1. No longer sends "destination unreachable" in response to IP
broadcast packets. Helps avoid avalanching the network.
2. Bad echo sequence number messages are now displayed only when
debugging switches are on.
1. Properly returns an error if the user tries to send a packet to an
address not on the local network, but the gateway address hasn't
been customized. (Previously, PC/IP erroneously sent the packet to
1. The name resolver has been updated to use new ARPANET standard
domain name resolution protocol.
2. Debug tracing of incoming packets now includes packet size.
C. Other changes
1. Separated debugging trace flags for the application, transport,
internet, and driver levels. This change permits user to control
the volume of debugging messages much more effectively. Any
individual debugging flag can be turned on or off, either with
PC/custom or dynamically when running PC/telnet.
Terminal emulator (affects PC/term and PC/telnet)
1. Special version created for use with IBM Professional Graphics
Display, which mis-emulates the cursor motion of the Color Graphics
Display. (used in PC/pgatn and PC/pgaterm)
2. Several bugs that produced incorrect line fill and background colors
have been fixed. These were noted mostly when using the "vi" editor
3. Hercules color card (as well as some others that have more than 2K
of display memory) now works.
1. A misdeclared variable in the timer package led to an error every
65535 times the timer was used. The most noticeable symptom of this
bug was that the line-25 clock in PC/telnet stopped ticking after 18
3COM Etherlink Ethernet driver
1. Properly initializes ARP cache to all zeros. Previous initialize
loop terminated early, left garbage, and occasionally caused
2. Driver now saves and restores state of interrupt handlers and masks,
so that it can be reused, for example, while calling a shell from
D. New Packages
1. PC/lpr allows users to send files to be printed by a 4.2 Unix
2. PC/monitor is a new command that repeatedly tests a list of network
services and keeps a display of the result.
3. New device driver for the Interlan NI5010 Ethernet card.
4. A domain name resolver was integrated with the old-style name
17 January 1986. This document is in file changes.mss
5. Changes In Prior Releases
This section describes changes between the January, 1985 and the February 1,
1984, releases of the PC/IP packages.
A major structural change in the installed device driver appeared in the
January 1985 release. As a result, a single PC must run either all 1984
release programs or else all 1985 release programs. Users of the 1984 release
who want to switch to the 1985 release must perform the installation and
customization procedures just as if they had never before used these programs.
Note, however, that if one PC runs the 1984 release and another PC runs the
1985 release on the same network they can communicate.
I. Changes that affect all packages
1) Name user upgraded to check responses to make sure they are for the
current request rather than for an earlier one.
2) Improved error messages throughout system.
3) The sources of PCIP were modified to compile and assemble with the latest
release of the microcomputer development C compiler, which now handles
identifiers of longer than 8 characters correctly. In addition, a new C
library is now is use. (Neither of these changes should cause any user-visible
4) An error in initialization that caused some programs to crash when run on
machines with more than 512K of memory was fixed.
5) Class B and Class C internet addresses now print properly.
6) All commands now return an error code to DOS as they terminate, so that
the DOS ERRORLEVEL feature can be used.
7) An error in the NETDEV device driver that prevented operation under
TopView was fixed.
8) The Ethernet device driver is now substantially more reliable, and it
works with the PC/AT.
II. Changes to protocol implementations
1) Time-exceeded debugging messages now include information about the packet
that got in trouble.
1) A bug in interpretation of bit fields in the IP header that caused the
"do-not-fragment" bit to act as the "this is a fragment" bit was fixed.
1) An error in length interpretation was fixed, which eliminates some bogus
1) TCP now provides an entry that allows an aborting command to reset a
connection before exiting.
2) Characters received over a TCP connection that have the high-order (meta-
or parity- bit) set to one are now properly discarded as the TCP specification
requires. Formerly, they were accepted, and the high-order bit set to zero.
(Discarding illegal characters has the effect, when talking to a TCP host that
mistakenly sets parity bits, of making about half the characters sent by that
III. Changes in specific packages
1) The escape sequences F10-u and F10-U enable and disable the 25th line
2) A new feature allows the user to specify that the tftp server of telnet
should not ask the user for permission to do file transfers.
3) The escape sequence F10-A (which turned on tracing of TCP activity) is now
invoked by F10-P.
4) An experimental feature allows the user to call a command interpreter
while running telnet.
B) Terminal emulator (used in PC/term and PC/telnet)
1) Certain escape sequences are not emulated; the emulator simply discards
them. Formerly, the emulator discarded only the escape sequence but not its
following arguments. Now, the arguments are discarded also.
2) In certain scrolling situations, the wrong attribute byte was used at the
end of newly scrolled lines. The bug affected only color displays, where text
near the bottom of the screen was filled to the right with light blue
background. Screen filling is now done correctly.
1) Replaced messages using the old command name finger with the name whois.
2) The user can now abort the command by typing "q".
1) An error in PC/tftp sometimes caused outgoing packets to contain a header
with a zero-length field. Although the resulting packet was, according to
protocol, strictly legal, a bug in BSD4.2 UNIX caused UNIX to go into a loop in
the kernel whenever it received such a packet. The error in PC/tftp was fixed.
2) An error in server tftp caused one packet buffer to be lost each time it
was used to send a file from the PC. In addition, the error caused the wrong
data packet to be resent when a timeout occurred, thereby assuring failure of
that transfer. The error was fixed. (This error affects both PC/tftp and
3) A bug in calculating the length of error packets was fixed. Other hosts
should no longer receive error packets with extraneous junk at the end.
E) Ethernet driver
1) The 3COM Etherlink card for the PC locks up when it receives successive
runt packets. It remains locked up until either the card is reset or the PC
tries to send a packet. The effect is to disable any program (such as ping,
tftp, or netwatch) that acts as a server. The Ethernet driver program was
modified to watch for this condition and reset the Etherlink card if necessary.
2) An (apparently) hardware bug causes the 3COM Etherlink card to
occasionally fail to respond to DMA requests on the PC/AT. The Ethernet driver
program now loops in a busy wait to insure that DMA is completed, rather than
depending on an interrupt. It now initiates DMA with a sequence that works on
PC's with an expansion chassis.
3) Zero-length packets (a common occurrence) are no longer reported as
4) The software can now be configured to use any DMA channel and I/O base
address that the 3COM Etherlink card can be configured to use. (But PC/custom
does not yet allow setting DMA channel.)
5) Lost interrupts are now picked up by a timer. This addition improves
reliability on Ethernets that have a large traffic load.
1) Upgraded to allow flexible choice of I/O base address for Ethernet
interface. Also allows setting of user name, office location, telephone
number, and printer service address. Ability to set inverse video mode in
1) A new "symbolic" format option displays IP, CHAOS, and Ethernet ARP
interpretation of received packets, as an alternative to simple hexadecimal
2) Packet buffer area reduced from 1000 to 512 undisplayed packets.
1) Built-in table of name servers brought up to date.
1) Ethernet version now gives intelligible error messages when pinging a
non-responding host on the same local net.
H) New packages
1) PC/nicname: A command to send requests to the ARPANET Network Information
Center name server.
2) PC/iprint: A command to send files to an Imagen printer service.
18 January 1985. This document is in file oldchanges.mss
6. Software Installation
This section describes how to install the PC/IP commands and how to do
The first step is to determine whether a serial line, an Ethernet, or a
Pronet interface will be used for network attachment. One should obtain a
diskette containing the proper versions of the set of PC/IP commands.
The distribution diskette is designed to be a read-only master copy, and it
does not contain any parts of DOS. Thus you should start by copying the files
you intend to use from the distribution diskette onto a formatted,
DOS-containing working diskette or hard disk. You can then put the
distribution diskette away in a safe place.
The next step is customization of the PCIP system for your environment. To
do customization a few key facts about the environment must be collected for
input to the customizer. If you are using an Ethernet or Pronet attachment:
1. Someone must assign an internet address for this PC.
2. If you plan to communicate with hosts not directly attached to the
same physical net, you must know the internet address of a gateway
that is attached to the Ethernet or Pronet.
3. If you are using an Ethernet and other hosts on your Ethernet do not
use the proposed standard Ethernet-to-Internet address translation
protocol, you must obtain a list of Ethernet-to-Internet address
translations for the other hosts on your Ethernet.
4. Figure out which DMA channel and which interrupt vector will be used
by your network interface. (See the hardware installation section
If you are using a serial line attachment, you do not need any of the above
pieces of information. Instead, you must know the data rate of the serial line
you plan to use.
That is the minimum repertoire of information needed for customization. In
addition, you will probably want to make use of time, name, and printer
services, so you should also obtain a list of names of up to five name servers
and time servers, and one print server. The names are all you need if your
local net is linked to the ARPANET; you will be able to use the PC/hostname
command to discover the internet addresses of those services.
The next step is to customize the network device, a file named netdev.sys on
the working diskette or hard disk, using the minimum set of facts collected
above. See the writeup of command PC/custom for details on how to customize
The customization of netdev.sys does not take effect until you install it as
a DOS device driver. The reason is that netdev.sys is a file that describes a
device driver rather than the device driver itself. Installation is automatic
when DOS is bootloaded, that is either when the PC power is turned on or when
control-alt-delete is typed. However, there is one detail: In order for the
device driver to be installed automatically, the bootload diskette or disk must
also contain a file named config.sys and that file must contain a line such as:
that names the file containing the device driver. If you already use a
config.sys file you should make a copy of it and add this line, using a text
editor. If you do not already have a config.sys file, you can use the one
found on the distribution diskette. The DOS reference manual provides more
information about the DEVICE command and about the file config.sys.
You should now have a config.sys file containing a "device" command that
names netdev.sys, you should have customized netdev.sys with the minimum
information, and after you bootload DOS (type control-alt-delete) you will be
ready to try a PC/IP command.
Try, for example, PC/ping, specifying the IP address of some host that you
should be able to address, to see what happens. If customization is not
correct, some error message should appear that may give a clue as to what is
The next step is to use PC/hostname to obtain the internet addresses of some
time and name servers, add them to the customization, and reboot to check them
out. PC/setclock can be used to verify that both time service and name service
customization are working: if PC/setclock succeeds when invoked with no
argument, at least one time service address is correct; if it can obtain the
time from a named time service, at least one name service address is correct.
8 April 1985. This document is in file soft-inst.mss
7. Hardware Installation
This section describes the installation procedures for network interface
hardware supported by PC/IP, and also notes a problem found with some old
Before you install your network interface, you need to select a DMA channel
(note that the proNET card can use two separate DMA channels, one for
transmitting packets and one for receiving them) for it and an interrupt
vector. The board may need to be reconfigured to use your selections, and you
also have to inform the software via the PC/custom command. It is important
that the DMA channel and interrupt vector you select are not being used by any
other hardware in the machine. Below is a chart showing what channels and
vectors the network interfaces supported by PC/IP can use, and what channels
and vectors are already in use in a PC, PC/XT and PC/AT.
Network Interfaces Interrupts Dma Channels
proNET 2, 3, or 4 1, 2, or 3
3COM Etherlink (old revs) 3 or 5 1 or 3
3COM Etherlink (newer) 2, 3, 4, 5, 6, or 7 1, 2, or 3
Interlan NI5010 3 or 5 1 or 3
COM1 (same for AT) 4 none
COM2 (same for AT) 3 none
Printer 1 (same for AT) 7 none
Printer 2 (same for AT) 5 none
Floppy disk 6 3
PC/XT hard disk 5 2
Floppy and hard disk 6 2
If you cannot, or choose not to, use a DMA channel, you should set the DMA
channel (via PC/custom) to 0. The driver will then use a tight loop to transfer
data from the card. We recommend using DMA, however.
If you install more than one network interface in your machine, or have some
other unusual hardware, it is also important to make sure that the base I/O
address of the interface does not conflict with any other hardware. Refer to
the documentation for the appropriate interface for details on setting the base
7.1. Pronet jumper selection
There are both switch-settable and jumper-selectable options on the proNet
p1300 ring interface. See the p1300 "User's Guide" that came with the
interface for more details.
The node address switch (S39) must be set to an address different from every
other station on your ring network, and that address is the same as the value
in the last field of the internet address that your machine has been assigned
(see step one under software installation.) Note that the node address switch
uses the "on" position to denote the binary value "0" and the "off" position to
denote the binary value "1". The board/rom address switch (S22) should be set
to all zeros (all "on".)
The interrupt vector jumper and the two DMA jumpers (one for input, one for
output) must agree with the configuration that the software will assume, and
must not conflict with other installed I/O devices. The card can be set to use
any of interrupt vector positions 2, 3, or 4, and any of DMA channels 1, 2, and
3. The PC/IP software requires that the two DMA jumpers be configured to use
the same DMA channel. The card is usually shipped with the jumpers set for a
configuration that will work with a standard PC or PC/XT, using interrupt
vector 2 and DMA channel 1 for both input and output.
7.2. Interlan NI5010 jumper selection
All options on the Interlan NI5010 interface are jumper selectable. For more
information, refer to the "NI5010 Installation and Programming Guide", supplied
with the card by Micom-Interlan.
The NI5010 card can be configured to use interrupt 3 or interrupt 5,
controlled by jumper W7. The B position of the jumper selects interrupt 3; the
A position selects interrupt 5.
The NI5010 card can be configured to use DMA channel 1 or 3, or no DMA at
all, depending on the positions of jumpers W8 and W14.
channel W8 W14
none remove remove
1 A B
3 B A
7.3. 3COM Etherlink interface
There are several jumper-selectable hardware options on the 3COM Etherlink
Ethernet card. The cards come in two forms. The first, older form, is
identifiable by the label "Rev. A" or "Rev. x.y" where x and y are integers;
the card is usually green in color. The second, newer form, is identifiable by
its blue color and by the presence of a humongous, 64-pin chip in the upper
left corner of the card (when held with the chips visible and the bus connector
pointing down.) The two kinds of cards have completely different labels for
their option setting jumpers, and the newer cards have a few additional
settings. The option set shown below is known to work with the PC/IP Ethernet
The choice of which DMA channel and which interrupt vector to use depends on
what other I/O equipment is attached to the PC. For example, on an IBM PC/XT
the hard disk, floppy disk, and printer are configured to use interrupt vector
positions five, six, and seven, leaving two, three, and four for other attached
devices. The Ethernet commonly uses interrupt vector position three.
3COM Etherlink card option settings:
Rev. B Rev. A
label label suggested jumper position
DMA REQ jp1 channel 1 (must match software)
DMA ACK jp2 Must match DMA REQ or jp1
Interrupt jp3 vector 3 (must match software)
I/O address bit 9 n/a right (1)
I/O address bit 8 jp4 right (1)
I/O address bit 7 jp5 left (0)
I/O address bit 6 jp6 left (0)
I/O address bit 5 jp7 left (0)
I/O address bit 4 jp8 left (0)
Memory address bit 19 n/a right (1)
Memory address bit 18 jp9 right (1)
Memory address bit 17 jp10 right (1)
Memory address bit 16 n/a left (0)
Memory address bit 15 n/a right (1)
Memory address bit 14 jp11 right (1)
Memory address bit 13 jp12 left (0)
Memory address bit 12 jp13 left (0)
Memory enable jp14 right (disable)
n/a sw1 Left for onboard transceiver,
right for external transceiver
U11/U10 n/a Plug goes in socket U10 for onboard,
socket U11 for external transceiver
Older Etherlink cards can be set only to interrupt vector positions three and
five, and therefore must use position three in an XT. Similarly, the PC/XT
uses DMA channel three for the hard disk and DMA channel two for its floppy
disk, so the Ethernet must use DMA channel one. In recent shipments the 3COM
Ethernet card has been configured at the factory with exactly these two
3COM Ethernet external transceiver incompatibility
Certain combinations of 3COM Etherlink cards that are labeled "Revision B"
with external transceivers generate improper Ethernet waveforms. These
improper waveforms can be decoded without trouble by any 3COM interface, but
some Ethernet interfaces from other manufacturers cannot decode these improper
signals. This problem may be the cause when a PC can communicate with some,
but not other, hosts on the same Ethernet. If switching the 3COM Etherlink card
to use the internal transceiver clears up the difficulty, then the transceiver
incompatibility problem is almost certainly the cause. Contact a 3COM sales
representative for information on an engineering change that corrects the
7.4. Memory expansion card flaw
Some IBM 64K/256K memory expansion cards have a design flaw that causes
trouble when an I/O device uses DMA channel 1. (The PC/IP software usually
uses DMA channel 1 for the Ethernet or the Pronet.) The symptom of this design
flaw when running PC/IP software is a catastrophic crash with the screen
displaying the message PARITY CHECK 2. The crash usually occurs within the
first hundred or so packets transmitted to or from the network.
If this problem appears, one should check the memory expansion card to see
whether or not it has this design flaw, and whether or not it has been
field-upgraded. Flawed cards have a connection between pins nine and ten of
chip U49. (The connection is a very small printed circuit stripe on the
underside of the card.) Repaired cards have had that connection severed, and
two new wires added, from chip U33 pin eight to chip U33 pin eleven, and from
chip U33 pin ten to chip U49 pin nine. Note that making changes such as these
must be done with care to avoid damaging the card, and may void any warranties.
If you have a flawed card it may be appropriate to inquire of your dealer what
action should be taken. Alternatively, the network can be operated using DMA
channel 3 if that channel is not already in use for some other device such as a
hard disk, or can operate without DMA by selecting channel 0.
23 January 1986. This document is in file hard-inst.mss
8. Ethernet Etiquette
The Ethernet is a shared communication system, and certain actions can
unintentionally disrupt it. This section describes practices and procedures
that can minimize troubles seen by other users of the same Ethernet.
1. Most PC's are attached using "thin Ethernet," which means that the
Ethernet wire comes down to the back of the PC where it connects to
the PC with a T-connector. The continuity of the Ethernet (and of
service to other users) depends on the integrity of the connection
through the T-connector. If you disconnect your PC from the
Ethernet, you should:
a. make certain that the continuity of the thin Ethernet through
the T-connector is maintained.
b. Make certain that the T-connector is not touching anything
metallic or conductive.
c. If the disconnection will be for more than a few minutes,
replace the T-connector with a barrel connector.
(Unterminated T-connectors provide an opportunity for noise,
radiation, and echoes; one such opportunity won't necessarily
bring down an Ethernet, but a large number of them can.)
If you are at one end of an Ethernet segment, you will find
that one side of your T-connector has the Ethernet coming in,
while the other side has a terminator attached. Continuity
from the Ethernet to the terminator is just as important as
continuity from one section of cable to the next, so if you
disconnect your PC from the Ethernet, you should make certain
that the Ethernet continues to be terminated, using either the
T-connector or a barrel connector.
2. The Internet address used for your PC when it is attached to the
Ethernet must be unique, and it must be manually assigned. Thus
some care is needed to insure that two PC's don't accidentally try
to operate using the same Internet address. Each PC/IP command has
this Internet address embedded in it (as part of customization).
You should not change the internet address that your PC uses without
coordinating the change with the central registry of addresses of
other PC's. Also, if you exchange diskettes containing network
programs with other PC/IP users be sure that you recustomize the
internet address before using the programs.
23 October 1983. This document is in file ethernet.mss
9. Host Names and Internet Addresses
A brief description of the syntax of host names and internet addresses, and
the method by which host names are resolved.
When PC/IP network programs accept a hostname argument it may be in either of
two standard forms:
An internet address is four octal integers separated by commas,
or four decimal integers separated by periods, for example:
Each integer represents one byte of a 32-bit standard internet
address, in the order "network," "subnet," etc. When the user
supplies an internet address the PC/IP network program uses it
as is, depending on nothing else for name resolution.
Host name When a PC/IP network program encounters a string that does not
appear to be an internet address, it interprets the string as a
host name and it attempts to resolve the name by appeal to one
or more name servers via the network. The program sends
inquiries to as many as three domain name servers and two
old-style name servers whose internet addresses are embedded in
the netdev.sys file. (The user may change the number of name
servers and their internet addresses by use of the PC/IP
If a text name is given, first up to three domain name servers are polled in
succession. If the name is a fully qualified domain name then it is passed
intact to the domain name servers; otherwise the domain specified with
PC/custom is appended to the end of the name. If none of the domain name
servers can resolve the name (or if no domain server addresses are specified)
the old-style name resolver is used.
The old-style name resolve can produce three outcomes, since name servers may
reply with an internet address, reply with a "host name unknown" response, or
may not reply at all. To increase availability several name servers are
polled, and the following rules merge the resulting replies:
1. If one or more name servers respond with an internet address, the
program uses the first such response received and ignores all later
2. If one or more name servers respond, but all the responses are "host
name unknown," the program displays that error message and exits.
3. If no response arrives from any name server within five seconds, the
program gives up, displays the error message "name servers not
responding," and exits.
Note that if different name servers give different responses to the same
inquiry, the user may see erratic results depending on which name servers are
up and which respond more quickly. If one suspects that name servers are not
responding or are not in agreement, the commands netname and onetname may help
isolate the trouble.
17 January 1986. This document is in file nameres.mss
10. Debugging options
This section explains the operation and usefulness of the debugging option
switches that can be set using the customizer.
The PC/IP packages have built in as part of their design a large number of
error and progress report messages, but these messages do not appear on the
display screen unless specifically requested. The debugging option switches
control which messages the packages display. When troubles appear in the use
of network programs, it is often not immediately apparent whether the cause is
a problem in the local computer system, in some distant server, or in some
network in between. The tracing that is controlled by the debugging switches
has as its primary value that it can allow fairly rapid trouble isolation in
The arrangement of the debugging option switches in the PC/IP packages has
evolved as the requirements for tracing have become better understood; this
evolution is incomplete and there are quite a number of cases where different
packages and different levels of network protocol do not yet follow consistent
The debugging switches can be set ON or OFF as customization options. The
usual technique is to customize the debugging options to the ON position in the
netcust: device so that they apply only to the current session. However, as is
described below some users may find it helpful or interesting to customize the
first few of the switches permanently ON (in the file netdev.sys) to allow
monitoring of network status and problems. Each debugging option switch is
described here and in the customizer by a symbolic name.
Here are the message categories controlled by each debugging switch:
NETERR Reports all recoverable errors detected by the local network
(Ethernet, proNET, or serial line) driver. Can be left ON
during normal operation to monitor appearance of network
PROTERR Reports all packets received that seem to be inappropriate for
the protocol being used, or that represent some other trouble
at the protocol level. Primarily useful for debugging other
implementations or discovering incompatibilities between
implementations on different computer systems. Can be left ON
during normal operation to serve as a warning that one has
contacted a host that isn't following protocol in the expected
TIMEOUT Reports all timeouts waiting for the other end of a connection
to respond. Can be left ON during normal operation to monitor
frequency of timeout-triggered retries.
APTRACE Provides a trace of the activities of the application level
protocol. For example, in PC/tftp, APTRACE produces a one-line
message for each file block that is sent or received. Can be
left on during normal operation if progress reports are
important or useful, but tends to fill the screen with tracing
The following debugging options are primarily useful for finding problems in
the interactions between the PC network protocol implementation and those of
other machines. They generally produce so much output that they are best left
off unless they are really needed.
TCTRACE Provides a trace of the activities of the transport level
protocol, such as UDP or TCP. Produces a one-line message for
each packet that is sent or received at the transport level.
INTRACE Provides a trace of the activities of the internet protocol
level, IP or ICMP. Produces a one-line message for each packet
that is sent or received by the internet level.
NETRACE Provides a trace of the activities of the local network driver.
Produces a one-line message for each packet that is sent or
received on the local network.
DUMP Whenever an incoming packet seems to have something wrong with
it, this switch causes its contents to be displayed in
hexadecimal format. In conjunction with NETRACE, INTRACE, or
TCTRACE, will produce a symbolic dump at the appropriate level.
(Note that the time required to display a complete packet
contents may exceed the timeout/retransmit time of some hosts,
so setting this switch ON can significantly alter the sequence
of packets received and sent.)
INFOMSG Triggers a long list of informational and progress report
messages. Used primarily to find out how far a PC/IP package
got before it crashed.
BUGHLT Displays a message whenever the network level code of PC/IP
detects a gross application error of some kind. (Not actually
used very much.)
The PC/telnet command has a special tracing feature that is useful for
tracking interactions with a remote time-sharing host. The PC/telnet escape
F10/control-A toggles the APTRACE debugging switch described above. When
APTRACE is ON, PC/telnet displays on line 25 a cryptic progress report (updated
once per second) on the connection to the other host. This report appears as
Sent: N1(N2)N3 Rcvd: N4(N5)N6 Window: N7
with the following interpretation:
N1 Number of bytes sent by the PC to the other host.
N2 Number of sent bytes not yet acknowledged by the other host.
N3 Number of packets resent to the other host in hope of eliciting
N4 Number of bytes received from the other host.
N5 Number of received bytes not yet acknowledged to the other
N6 Number of packets rereceived (that is, duplicates) from the
N7 Number of bytes that PC/IP has authorized the other host to
send. (TCP window size.)
Note that while ON, APTRACE also triggers a one-line-per-block message from
the tftp server if it used from within PC/telnet.
PC/telnet can be asked to toggle any debugging switch at any time, using F10
followed by the appropriate control- character. Several other debugging and
maintenance toggles and displays are also available. F10/control-H displays a
list of possibilities.
16 September 1985. This document is in file debugging.mss.
11. Dialup line file transfer
One use of the PC/IP commands is to transfer files to and from some
network-attached system over a dial-in line. Two scenarios for that use are
described here. For either scenario, the description of commands PC/onhook and
PC/tftp should be read before proceeding. These scenarios require that the
serial line version of PC/tftp be used.
- Scenario with manually-controlled dialling:
1. Type the command offhook.
2. Dial the telephone number of the PC concentrator. When it
answers, switch the modem to data.
3. (Optional, but recommended) Type the command setclock to verify
that the network connection is operational and also to set the
PC clock so that the date and time attached to newly
transferred files will be correct.
4. Issue the tftp command to get or put the file wanted.
5. Repeat the previous step until all files are transferred.
6. Type the command onhook.
7. Switch the modem to voice and disconnect it from the telephone
- Scenario for use with a terminal-controlled dialling modem:
1. Type the command term.
2. Using the terminal emulator, instruct the modem to dial as
3. Continue with step three, above.
27 November 1983. This document is in file dialup.mss
PC/custom, version 2.2
A command to customize the PC/IP environment, allowing setting of parameters
that describe the network environment and preferred option settings.
custom netdev [model]
begins customization of the device description found in the file named
netdev.sys. When finished customizing, custom rewrites the file netdev.sys
with the new parameters in place. The customizer is menu-driven and
self-explanatory. If a second argument is given, custom reads the values of
the customization parameters of the command found in the file model.sys and
uses them as initial values. It then enters the usual starting menu so that
the user can review the result.
For simplicity and uniformity, the one device driver contains the
customization parameters for all network levels and all commands. For example,
one can set serial line parameters even though the PC/IP commands to be used
contain an Ethernet driver. It is not necessary to specify values for
customization parameters that will not be used. For example, if the command
PC/setclock will not be used, one need not specify the internet addresses of
Note that customizing the file netdev.sys will have no effect until the next
time DOS is bootloaded. See the writeup entitled "software installation" for
12.1. Standard customization parameters
There are several customization parameters that are applicable to all or
several different PCIP commands. Customization parameters that apply to just
one command are described in the writeup of that command.
Site customization to match network hardware options, switch settings, and
- Serial line speed. Can be set to any baud rate from 110 to 19,200.
(Needs to be set only for serial line use.)
- Interrupt vector for network interface. Should be set to correspond
to the interrupt vector number that the hardware interface will use.
The PC/IP serial line driver ignores this entry.
- Receive and transmit DMA channels for network interface. Should be
set to correspond to the DMA channel that the hardware interface will
use. Most hardware only supports a single DMA channel for both
receive and transmit; if that is the case, both should be set to the
same value. The proNET interface does support separate channels. The
DMA channel can also be set to 0 if no DMA should be used; a tight
loop will be used instead to copy data to or from the interface. (The
serial line driver does not use DMA at all). Under some
circumstances, using a copy loop can be faster than using DMA (for
instance, on the PC/AT).
- Network interface I/O address. Should be set to match the I/O base
address used by the network hardware. Default is 0300 (Hex).
- Ethernet address. One can set the Ethernet address in one of three
1. to the Ethernet address found on the network interface card,
2. to an Ethernet address derived from the internet address by
concatenating 16 leading zero bits,
3. to an arbitrary Ethernet address specified to the customizer.
One should normally use the first option; the others are available to
deal with non-standard Ethernet environments.
- Number of network interfaces. This parameter is currently not used;
it is provided for future implementation of multi-network attachment.
12.2. Site customization of network level parameters
- Internet address of this computer. (Not needed for serial line use.)
- Internet address of default IP gateway. (Not needed for serial line
- Internet addresses of up to two IP non-domain name servers. These are
old-style, IEN-116 name servers.
- Internet addresses of up to three IP domain name servers.
- The text name of the machine's domain. This name is used by the
domain name resolver. When asked to resolve a name that is not fully
qualified (no domain is specified), the resolver will append this
name to given name.
- Internet addresses of up to five time servers. The servers are
polled at two second intervals in the order they were set by the
customizer, so one may place preferred services nearer the head of
the list. (Needed only by PC/setclock.)
- Internet address of a print server. (Needed only by PC/iprint and
- Internet address of an IP log server. If this address is non-zero,
some PC/IP commands send error-logging or statistics-gathering
packets to this address. For privacy, the address may be set to
0,0,0,0, in which case all logging is suppressed.
- Up to three initial values for Ethernet-to-Internet address cache.
(Needs to be set only for Ethernet use and when the environment does
not provide the proper protocol.) IP addresses are entered in
standard octal or decimal form. Ethernet addresses are entered as 6
octal byte values (each between 0 and 377) separated by commas.
- TCP window size and low window level. These two parameters affect
the performance and smoothness of flow of data in commands such as
Telnet. The window size is the count, in bytes, of the maximum
amount of data that another host should send to the PC without
waiting for authorization to send more. If not customized, its
default value is 450 bytes. One might make this value smaller if
there is a gateway with limited buffering ability in the pathway
between the PC and a commonly-used host, or if talking to a host on
the same local area network. The low window level is the trigger
point at which the PC sends authorization to send more data to the
other host. If not customized, its default value is 200 bytes. If
there is a long round-trip delay to a commonly-used host, one might
adjust this value so as to just fill up the pipeline from that host.
The low window level must be less than the window size, and the
window size must be less than 2000 bytes.
- Telnet transmission trigger. Can be set to send every character as
it is typed (necessary if using a character-based remote echo system)
or to send a batch of typed characters only when a newline character
is typed (less demanding on the remote system.)
- First RVD drive. This parameter is provided for a future feature.
- Number of subnet bits. This parameter determines how many bits,
following the network part of an IP address, are used to identify the
attached subnetwork. PC/custom displays on octal "subnet mask" that
is derived from the IP address and the number of subnet bits. This
feature is used in a simple way, as follows: when an IP packet is to
be sent from the PC, its IP destination address is masked with the
subnet mask. The part of the destination address that is revealed by
the subnet mask is then compared with the corresponding part of the
PC's own IP address. If the revealed sections of the two addresses
are different, the destination is assumed to be on another
subnetwork, and the routing layer sends the packet to the default
gateway. If the revealed sections are the same, the destination is
assumed to be on the same local area network as the PC itself, and
the concealed portion of the destination address is used by the
network layer to construct the proper physical address (perhaps using
an Address Resolution Protocol). If subnetwork routing is not in
use, an extent of zero is appropriate. At M.I.T. the subnetwork
routing scheme uses 8 bits for subnetwork identification.
12.3. Personal customization of terminal emulation options
- Action on lines too long to fit on screen. Discard mode places all
excess characters in column 80. Wraparound mode places excess
characters on next line.
- Swap interpretation of backspace with control-backspace. (See telnet
description of emulation conventions for further information.)
12.4. Other parameters
- User's name. This is a character string that is included in error
logging messages and is placed in headers of files sent to a print
server. May be set to (or left) blank.
- Internet address output radix. This parameter controls whether
numeric internet addresses are printed in decimal (for instance,
220.127.116.11) or octal (22,32,0,101). Numeric addresses can always be
input in either radix.
- Debug options. There are several options that turn on various
degrees of progress reports, tracing, and otherwise suppressed error
messages. These options are of interest primarily to system
programmers. One normally sets them to "all off". (See the section
Debugging Options for more details.)
- Local standard time offset, in minutes before GMT. West of GMT the
value is positive, east of GMT the value is negative. For EST the
value is +300. For SET the value is -60 in the winter.
- Local standard time designation string. Three letters, such as EST,
EDT, or SET. (Note that if the middle letter of the time zone
designation string is "s" or "S" PC/setclock will automatically do
12.5. On-the-fly error correction
Errors in typing names and addresses can be corrected with the following
common editing conventions: The backspace key discards the last character
typed, while Control-U discards the entire name or address typed so far,
allowing one to start over.
12.6. Temporary customization
will recustomize the currently active device driver, which is named netcust:.
Customization of netcust takes effect immediately, rather than at next
bootload, and is lost when the next bootload takes place. Temporary
customization of the active device driver is sometimes useful in debugging, for
example to turn on a tracing option for a while. Note that for temporary
customization to work there must be an already-present active device driver,
previously loaded by DOS.
17 January 1986. This document is in file custom.mss
PC/iprint, version 1.1
A program to send a text file to an Imagen print server.
iprint -n filename
iprint -q filename
sends the file filename to the default print server, using the standard
protocol for the Imagen family of print servers. PC/iprint specifies a default
format that simulates an 80-character, 10-pitch line printer. It arranges for
a header line containing the name of the file and the current date and time to
appear at the top of each page, and it attaches a cover sheet containing the
user's name. If the option "-n" is given, the header line is omitted. If the
option "-q" is given, the iprint command displays no messages unless it
encounters an error.
The following parameters of iprint can be customized with the PC/custom
1. Internet address of the print server. Note that lpr also uses the
print server address when connecting to a Unix printer spooler. The
print server address cannot be customized separately for iprint and
2. Name of the user, for the cover sheet.
All PCIP packages follow the DOS convention of returning an ERRORLEVEL value
when they exit. For use in batch files, PC/iprint returns ERRORLEVEL=0 if the
printer service accepts the file, and ERRORLEVEL=1 otherwise.
23 January 1986. This document is in file iprint.mss
PC/lpr, version 3.0
A program to send a text or graphics file to a local or remote printer.
Emulates the Unix lpr command to a limited extent.
lpr [ -Pprinter] [ -Sserver] [-pgvqw] filename
causes the file filename to be spooled to a printer. The -P option may be
used to force output to a specific printer, and the -S option may be used to
specify a print server.
If the option "-P" is given, the word following the "-P" is taken as the name
of the printer to be used. If the "-P" option is missing, the name of the
printer to be used is taken from the PRT environment variable. If this
variable has not been set, the name of the printer is taken to be lp. (Note
that the option may be written "-P printer" OR "-Pprinter", as in the UNIX
convention for the lpr command.)
The name of the printer, whether taken from the "-P" option, the environment
variable, or defaulted, is significant. The following names have special
local If the printer name is "local", the file is printed with the
DOS "PRINT" command. There must be a printer attached to the
PC issuing the command, and the normal messages issued by
"PRINT" will be displayed and should be responded to.
If the printer name is any of these names, which have special
meaning to DOS, PC/lpr assumes that the print server is another
PC on the network that is running a PC/tftp print server and
possibly a spooler. PC/lpr will send the file to that PC by
means of the tftp protocol, using the given printer name as the
target device. If the server PC has a printer attached under
that device name, it will print the file there.
all other names If the printer name is any other value, PC/lpr assumes it to be
the name of a UNIX printer controlled by a UNIX/lpd daemon,
running the 4.2bsd printer protocol. In these cases, PC/lpr
creates a cover sheet with the user's name (taken from the USER
environment variable), the name of the file, and the office
number (taken from PC/IP customization information). It then
sends the file to the UNIX/lpd daemon for printing.
If the option "-S" is given, the word following the "-S" is taken as the
internet name or address of the print server to be used. If the "-S" option is
missing, the identity of the print server to be used is taken from an
environment variable named "SERVER" or if there is no environment variable,
from the customization parameter "default print server". (Note that the option
may be written "-S server" OR "-Sserver".)
If the option "-q" is given, PC/lpr displays no messages unless it encounters
If the option "-w" is given, and the file was sent to a UNIX print server,
PC/lpr will wait until the server closes the network connection before exiting.
If the printer is directly attached to the server, this is a way to wait until
the file has started printing.
The following single letter options are used to specify that a filter is to
be used on the file before printing it. In all cases, a temporary file will be
created, modified by the filter, spooled to the printer, and then erased:
-p pr is used to format the file. If the print server is running
Unix, it will process the file with the normal Unix pr command.
If the print server is running DOS, PC/lpr will run the file
through a DOS pr filter before printing. In either case, the
file is printed in pages with a five-line margin at the top and
bottom, and a header line consisting of the date, time, name of
file, and page number, on the third line of each page.
-g prntmeta is used to format the file. This is a DOS-only
graphics filter which translates GKS meta files for printing on
the IBM Graphics Printer.
-v this option is reserved for future use for files in
printer-specific formats. There is currently no support for
The following parameters of PC/lpr can be customized with the PC/custom
1. Internet address of a remote print server.
2. Name of the user, for the cover sheet.
The following parameters of PC/lpr can be customized by setting DOS
1. printer name, set with "set prt=name"
2. user name, set with "set user=name"
3. server name, set with "set server=name"
All PC/IP packages follow the DOS convention of returning an ERRORLEVEL value
when they exit. For use in batch files, PC/lpr returns ERRORLEVEL=0 if the
printer service accepts the file, and ERRORLEVEL=1 otherwise.
26 February 1986. This document is in file lpr.mss
PC/monitor, version 1.4
A program that monitors availability of network services, keeping a display
that shows which are currently responding and which are not.
PC/monitor reads the control file filename to determine the list of services
to be monitored. It then tests each service in the list. Following each such
test it displays the name of the host of that service in a form that indicates
the outcome of the test. After completing a round of tests, PC/monitor waits
for 60 seconds, then performs another round of tests. An asterisk on the
display indicates which service is currently being tested.
Whenever a service responds normally, PC/monitor displays the host's name
using normal display mode. If a service that responded on the previous test
fails to respond, PC/monitor displays the host's name in intensified mode. If
two or more successive tests of a service fail, PC/monitor changes the display
of that host's name to blinking intensified mode, and sounds an audible alarm
once. The user can acknowledge having seen such a warning by hitting the space
bar, which causes PC/monitor to change currently blinking names to normal
intensity on the next round of tests.
If the service responds but the response is incorrect, its host's name is
underlined (or on a color monitor, in blue).
PC/monitor switches off all debugging switches just before it starts to
display test results. If it notices some error while trying to invoke a
service, it displays the host's name in inverse video.
To stop the tests and exit from PC/monitor, type "q". To start another round
of tests without waiting for completion of the 60-second timeout , type "g".
PC/monitor can test the following kinds of services:
1. UDP time service. PC/monitor sends a standard time service request
and watches for a time response from that server. It does not check
the value of the result.
2. UDP domain name service. PC/monitor sends a domain name service
request for a name specified in the input file. It checks the
response to verify that it is the one expected.
3. UDP name service (IEN-116). PC/monitor sends an old-style name
service request for a name specified in the input file. It does not
check value of the response. (N.B. Both name service and domain
name service test results appear in the same column of the display.)
4. ICMP echo service. PC/monitor sends a standard echo request
containing 20 bytes of random data, and watches for an echo response
containing those 20 bytes of random data.
5. RVD-control service. PC/monitor sends a shutdown control request
with the password "x" (in anticipation that "x" is not the
maintenance password) and watches for a response from that server,
but does not check that response for correctness.
15.1. Control file
The format of the control file is as follows:
1. The file is ASCII, so it may be prepared with an ordinary text
2. White space (blanks, tabs, or new-lines) separates control inputs in
the control file. A control input consists of a control identifier
followed by an equal sign, followed by control parameters separated
by semicolons. (Recommendation: put one token on a line, so the
result is easy to ready and modify.)
3. Following is an example of a control input describing a service to
The first parameter, "echo" in that example, could be replaced by
"domain", "name", "rvd", "time", "time1", or "time2". (The use of
"time1" and "time2" is explained in point 4, below.) The second
parameter is the name to be displayed of the host that runs the
service to be tested. This name must be eleven or fewer characters
in length. The third parameter, containing the internet address of
that host, is optional. If absent, PC/monitor uses the customized
name services to resolve the displayed name. If present, it can be
in either octal form (with commas) or decimal form (with decimal
4. The display limits the number of services of any one type to 20; the
service types "time", "time1", and "time2" place the result of a
time test in three different columns of the display, and thus
increase the limit on the number of time services to 60.)
5. To comment out a token, insert the letter # as the first character.
6. The time between passes through the service test is normally 60
seconds. This time can be changed by a control line of the form
where the number of seconds to pause is an integer less than 65535.
7. Name service tests are performed by sending a request for the name
provided in a control line of the form
Where the name must be fewer than 30 characters in length. (But for
a domain name test, it must be a complete domain name.) For
checking the correctness of a domain name server, the corresponding
internet address may be given in either decimal form (with periods)
or octal form (with commas).
If no nametest control line is provided, PC/monitor uses the default
name "athena.athena.mit.edu" and looks for the response 18.104.22.168.
8. After processing the input file, PC/monitor pauses for five seconds,
to permit review of any non-fatal warning messages that occurred
during that processing.
15.2. User commands
Summary of user requests accepted by PC/monitor:
q ("quit") Exit to DOS
g ("go") Start another round of tests.
c ("clear") Redisplay the screen contents, in case they have been
messed up by an error message.
space ("acknowledge") Change all current blinking intense fields to
15.3. Display modes
Summary of display modes and their meanings:
normal Latest test of this service was successful.
intense Latest test of this service failed; previous one was
intense blinking Two or more tests in succession failed.
normal blinking space bar hit since two or more failed.
underlined (blue) service responded, but with wrong answer.
inverse video trouble encountered in trying to do this test.
1. RVD service availability should be tested by sending server-status-
request packets, not shutdown requests.
2. If more than 20 services of one type appear in the control file,
PC/monitor muddles the display rather than reporting an error.
3. After several hours of operation, catastrophic errors begin to
appear, first muddling the display, and then crashing the monitor.
The following parameters of PC/monitor can be customized with the custom
1. Internet addresses of up to five name servers. The name servers are
used to resolve those names found in the control file that are not
accompanied with internet addresses.
23 January 1986. This document is in file monitor.mss
PC/netname, version 1.0
A package to look up the internet address that corresponds to a character
string name, using the UDP domain name protocol.
netname [-a] [-t timeout] name [domain-name-server]
Where name is the character string host name to be resolved. If no domain
name server is specified, netname sends an inquiry to each customized domain
name server, and displays all responses. The optional argument -a causes
netname to display application trace information that may help in discovering
obscure problems in name server tables. The optional argument -t causes the
next argument to be used as the timeout, in seconds, before giving up on the
name server. The default timeout is 20 seconds.
If name contains at least one period character, netname assumes it to be a
complete domain name and sends it unchanged to the domain server. If name
contains no period characters, !b[netname] appends to it the customized default
domain name for this PC.
There are three possible results of a name inquiry:
1. An internet address.
2. The response "name not known"
3. No response.
Each network node has a primary name, and may also have any number of
secondary names. PC/netname accepts inquiries for both primary and secondary
names. If the name requested is a secondary one, netname reports the primary
name as part of the response.
In the second form, above, domain-name-server is an optional argument that
identifies a specific domain name server that is to be invoked to resolve the
name name. domain-name-server may be either a character string name (in which
case it is resolved using the customized name servers) or an internet address
in standard form.
The section on host names, domain names, and internet addresses provides more
information on the resolution of host names. This command is useful primarily
for trouble isolation when one suspects that name tables may be inconsistent or
- Default domain name. Appended to any name that contains no period
- List of domain name servers.
- Application trace. If the APTRACE debugging flag is on, PC/netname
displays details of the name server response.
22 February 1986. This document is in file netname.mss
PC/netwatch, version 7.0
A program to monitor the attached local network. It is useful primarily for
debugging network operations on a broadcast network.
No arguments are required. PC/netwatch listens to the attached local
broadcast network and displays one line of information for every packet that
goes by. This information consists of the "to" and "from" local network
addresses, the packet length, the value of the protocol type field, and 8
selected contiguous bytes of the packet contents. While netwatch is running
one may type commands to it. The commands either display collected information,
change netwatch's operating mode, or tell it to filter for specific types of
packets. The commands are:
a Match all packets. Turns off all packet filtering.
c Display packet type counts. Prints a list of all packet types
that are built in to netwatch and how many of each type it has
accepted and displayed. Some counts are misleading because some
protocols have two type indicators in their headers (TCP and
UDP packets have two socket numbers).
d Match on destination. Prompts the user to input a destination
address and only accepts packets going to that address. See the
section below on filtering for more information.
h Display packet length histogram. Displays a list of packet
lengths in 64 byte increments and a count of how many packets
of each length have been accepted and displayed by netwatch.
l Clear screen.
m Toggle using manufacturer info in hardware addresses. This
command is only useful on Ethernet netwatchs. The first three
bytes of an Ethernet address can be used to determine the
manufacturer of the Ethernet card the address is associated
with. This command toggles whether or not netwatch prints the
first three bytes as hexadecimal numbers or symbolically as the
name of the manufacturer.
n Toggle normal and symbolic modes. Switches between the mode
where netwatch simply dumps packets in hex and the mode where
netwatch unparses packet headers and displays a symbolic
representation of the contents of the packet.
p Pause. Waits for the user to type something before proceeding.
q Quit. Return to PC-DOS.
r Reset packet count. Resets the count of accepted packets to 0.
s Match on source. Prompts the user to input a source address and
only accepts packets coming from that address. See the section
below on filtering for more information.
t Match on packet type. Prompts the user to input a packet type
specification (see below on filtering) and only accepts packets
of that type.
u Match only on unknown packets. Netwatch will only accept and
display packets of types it does not know. This feature
interacts incorrectly with some of the internal counters in
netwatch; some packet counters will still increment on packets
that do not get displayed.
w Match all packets coming to or from an address. Prompts the
user to input an address and accepts and displays only packets
coming from or going to that address. See below on filtering.
A Shows more application layer information when displaying
H Display histogram of packet lengths. This command shows a bar
graph of packet lengths and counts.
I Shows more internetwork layer information when displaying
L Toggle displaying local net addresses. When displaying local
net address, netwatch will display hardware source and
destination addresses even when in symbolic mode.
N Shows more network layer information when displaying packets.
S Print statistics.
T Shows more transport layer information when displaying packets.
? Print command summary.
Netwatch allows the user to specify filters for packets. Only packets
matching those filters will be accepted and displayed. Netwatch's internal
counters (length and counts of different packet types) only count accepted
The simplest filter is on packet type. Packet types can be symbolic or
numeric. For instance, on an Ethernet, one can match on packet type "ip" or
packet type "800". Higher level protocols can be matched on as well; you can
match on "ip tcp" or "ip tcp telnet". A '?' anywhere in the type specification
will cause netwatch to respond with a list of acceptable types.
Netwatch can also filter on addresses. There are three types of address
matching: source, destination and watching (source or destination). Both
hardware and protocol addresses can be specified. On a proNET ring, you might
type "99" as a hardware address. On any hardware, you could specify "ip
22.214.171.124" as an Internet protocol address or "chaos 15101" as a Chaosnet
protocol address. You can specify the hardware broadcast address as "*" or the
17.2. Combining Filters
Filters can be combined: you can look for all "ip tcp telnet" packets coming
from host "ip 126.96.36.199", or you can combine hardware addresses and protocol
addresses. There are a few catches to be wary of.
None of the filters clear the old filters when you start. Therefore you
should normally use the 'a' command to accept all packets before you change the
type or address netwatch is matching on. Some combinations make no sense, for
instance, watching for packets coming to or from "ip 188.8.131.52" and then
watching for packets coming to or from "chaos 15101". In this case, netwatch
will probably never see any packets, because it is looking for packets with the
correct bytes in right positions for both of those addresses.
Also, watching on both hardware and protocol addresses might miss some
combinations of both.
The limitations of the monitor in high-traffic situations should be
understood. The monitor can handle a burst rate of about 200 packets per
second. Packets arriving faster than that are missed (but counted in the
statistics of the network driver). In addition, the display rate is about 25
packets per second and there is a buffer that can hold 512 undisplayed packets.
If packets arrive faster than the display rate for a long enough time to fill
up the buffer, the monitor discards overflow packets.
Note: When the proNET version of netwatch is used, a jumper must be set in
the hardware to permit the interface to accept all packets.
2 October 1985. This document is in file netwatch.mss
PC/nicname, version 2.0
A program to invoke the ARPANET Network Information Center name directory
sends a request to the ARPANET Network Information Center (assumed to be
located at IP address 12,0,0,63) name resolution service, inquiring about
"name". The NIC normally responds with a text string, which nicname then
displays on the screen of the PC.
If name is "-help" nicname displays some hints on how to use it. If name is
"help", nicname forwards the request to the NIC, which responds to that name
with a screenful of information on making more sophisticated inquiries.
If the Network Information Center is not forthcoming with a response,
PC/nicname will give up after about 20 seconds. Typing the letter "q" will
cause PC/nicname to abort the operation immediately. This feature is useful if
one discovers that the output from the NIC is more extensive than anticipated.
4 December 1984. This document is in file nicname.mss
PC/onetname, version 5.0
A package to look up the internet address that corresponds to a host's
character string name, using the (now obsolete) IEN-116 UDP/ICMP name server
protocol. (See the command PC/netname for name lookup using the newer domain
onetname name nameserver
Where name is the character string host name to be resolved. If no nameserver
is specified, onetname sends an inquiry to every known name server, and
displays all responses.
nameserver is an optional argument that, if provided, identifies a specific
name server that is to be invoked to resolve the name name. nameserver may be
either a character string name (in which case it is resolved using the
customized name servers) or an internet address in standard form.
The section on host names and internet addresses provides more information on
the resolution of host names. This command is primarily useful for trouble
isolation when one suspects that name tables may be inconsistent or incorrect.
PC/onetname has no special customization parameters of its own. The names
and internet addresses of several ARPANET IEN-116 name servers are built in to
PC/onetname, and are changeable only by recompiling or patching the program.
Name server addresses provided by customization are used only for resolution of
name server names. See the description of custom for explanation of these
9 January 1985. This document is in file onetname.mss
20. Onhook and Offhook
Programs to connect or disconnect (in telephone jargon, "place off-hook or
on-hook" and in common parlance, "pick up or hang up") the telephone line
attached to a serial port on the PC.
These commands are provided for the scenario in which several different PC/IP
commands are to be used in a single session, via a dial-up serial line. The
offhook command instructs the attached modem that the computer is prepared to
use the serial line (by turning on the signal "data terminal ready" in the
modem interface.) By convention, PC/IP commands that use the serial line
always restore the on-hook/off-hook status of that serial line as they exit.
At the completion of the session, the user may issue an onhook command to
disconnect the telephone line.
Note that the terminal emulator command, PC/term, is also useful in
management of on-hook and off-hook status, especially in the case where either
the modem or the computer at the other end of the serial line is controlled by
sending ASCII characters. Rather than starting a session with the offhook
command one starts with term, using the emulator to tell the modem and switches
how to connect things up. Then, the user exits term with F10/q, which leaves
the serial port in off-hook status. At the completion of the session, the user
issues the onhook command as usual.
The commands PC/onhook and PC/offhook operate on serial port number one,
known in PC documentation as "COM1:".
23 October 1983. This document is in file onhook.mss
PC/ping, version 5.0
A program to send an echo request to another host and watch for a response,
using the ICMP/IP protocol. It is used primarily to isolate trouble in an
Where hostname is either a character-string name of the target or an internet
address in standard form. (See the section on hostnames in the network
overview for more details.) The hostname me will send an echo request
addressed to the computer on which the command is typed.
Ping reports success with a message such as "Host x,y,z,w responding" where
x,y,z,w is the internet address of the target. It may also report one of
- Host not responding
- Host responded but the returned echo packet was defective
- The initial echo request packet could not be sent
When exiting, ping also prints an array of statistics about its operation.
These statistics are in two categories: details of local network usage and
details of packets processed. These statistics often provide clues about
network problems to a network specialist.
21.1. Optional features
ping -t hostname
will go into a loop continually sending echo requests to host hostname, each
time waiting for a response before sending the next request. To exit this
loop, type the single letter "q". When in looping mode ping reports all echo
failures, and also maintains a summary line of trials and successes.
starts an echo server, a program that will respond to echos sent to this PC
from elsewhere in the network. (Note that all PC/IP programs, including ping,
always act as echo servers whenever they are in control of the PC.)
21.2. Using ping to isolate network trouble
When a host fails to respond, it may mean either that that host is down or
that some network or gateway in the path from the user to the host is down.
(It could also mean that the host does not implement the IP/ICMP echo request
protocol.) Further ping experiments can usually determine which (and thus whom
to call for repair.) A successful ping directed to another host on the same
network as the original host usually means that the original host is down or
not listening to the network. Failure to get echos from any host on that
network means that the trouble is along the path somewhere. A ping directed to
the gateway into the network in question is the next step. One can continue to
work back from the target toward the originator until the point where
communication breaks down is found.
The echo request sent by the ping command is dispatched using a low-level
protocol that does not try to guarantee delivery. As a result, there is a
possibility that any one echo request may be accidentally lost for some reason
such as temporary overload in some gateway. Thus one cannot be confident that
a particular network or gateway has failed unless a series of ping experiments
consistently succeed in getting to the point in question and consistently fail
to get beyond that point.
21.3. Using ping to evaluate a serial line
Since ping contains a built-in echo server it can be used to test or evaluate
a serial line in two ways. If a gateway is attached at the other end of the
serial line, the command "ping me" exercises the serial line in both directions
as well as the gateway. Alternatively, if one loops back the other end of the
serial line so that all data sent down the line comes immediately back to the
PC, the command "ping me" will still work, using an internet address chosen by
ping. In both cases, the command form "ping -t me" is appropriate to start a
continual test of the line. Any packets damaged in transit will lead to error
reports; the summary of tries and successes provides a picture of the total
effect of line noise.
26 October 1984. This document is in ping.mss
PC/setclock, version 6.1
A program to obtain a clock reading from a network time service and set the
PC date and time accordingly.
where time-server is either a character-string name or an internet address of
a network host that provides an UDP time service. PC/setclock sends a request,
using the standard UDP time service protocol, to time-server. If the name
time-server is omitted, PC/setclock sends requests to a default list of
internet addresses of the known time servers. This list is stored within
PC/setclock and can be set or changed with the customizer. PC/setclock takes
the first response, converts the calendar clock reading found therein to the
local date and time and displays it. Finally, PC/setclock calls the standard
PC-DOS entry points to set the system date and time.
If the second letter of the customized time zone label is either 's' or 'S',
from the last Sunday in April to the last Sunday in October, PC/setclock
adjusts the local time one hour forward for Daylight Savings Time and changes
the 's' to 'd' or 'S' to 'D'.
If no time server responds, or the network is not operational, PC/setclock
displays a message to that effect and leaves the current date and time settings
of PC-DOS unchanged.
PC/setclock is designed for use either as a stand-alone command or as a
command invoked by an autoexec.bat batch file. There are two advantages to
using PC/setclock in an autoexec.bat batch file. First, DOS does not ask the
user to type the date and time on every bootload operation. Second, it
provides an immediate test of whether or not the network connection is
operational. If setclock receives at least one response, it returns to DOS
with the DOS variable ERRORLEVEL=0; otherwise ERRORLEVEL=1.
The following parameters of PC/setclock can be customized with the PC/custom
- Local standard time offset, in minutes before GMT. West of GMT the
value is positive, east of GMT the value is negative. For EST the
value is +300. For SET the value is -60.
- Local standard time designation string. Three letters, such as EST,
EDT, or SET. If the second letter is 's' or 'S' then PC/setclock
automatically provides Daylight Savings Time during the appropriate
part of the year.
- Internet addresses of up to five time servers. The servers are
polled at two second intervals in the order they were set by the
customizer, so one may place preferred services nearer the head of
21 May 1985. This document is in file setclock.mss
PC/telnet, Version 8.0
A remote login program for the IBM PC, using the TCP/IP protocol and
emulating a display terminal.
telnet -p portno hostname
Where hostname is either a character-string name of the target host, or an
internet address in standard form. (See the section on hostnames in the
network overview for more details.) When used with the "-p" option, the
argument portno is used as a port number at the target machine. This feature
is used to connect with certain telnet-like services available on some hosts.
From the point of view of the target host, PC/telnet emulates a standard
"network virtual terminal". From the point of view of the keyboard user,
PC/telnet emulates a Heath H19 terminal. The terminal emulation is only
approximate. A set of conventions and list of incompatibilities appears on the
Typing the command with the name or internet address of a target host causes
PC/telnet to try to establish a connection. When that connection is
successful, the target host should display its greeting banner. The following
conventions apply to the translation between H19 emulation and network virtual
1. Function key F10 is an escape used to invoke PC/telnet functions.
F10 followed by a question mark displays a list of escape sequences.
Others are F10 followed by:
a Send "Are You There?" inquiry to the target host.
b Send "break" to the target host.
c Close the connection and exit from telnet.
e Send to target on every typed character.
l Local echo. (PC/telnet echos typed input.)
E Send to target only when End-Of-Line is typed.
q exit from telnet without closing connection.
r Remote echo. (Target host echos typed input.)
x Send any outstanding data now.
U turn on the line-25 clock and status report.
(default is on)
u turn off the line-25 clock and status report.
2. Function key F10 is also used to change the mode of operation of the
terminal emulator within PC/telnet. These escapes are:
B Backspace key sends BS, control-backspace sends DEL.
D Backspace key sends DEL, control-backspace sends BS.
d If output line too long, discard extra characters.
w If output line too long, wrap around to next line.
3. The PC "Print-Screen" feature, triggered by key "PrtSc", can be used
from within PC/telnet, but immediately preceding its use one must
restore the display buffer to the format expected by PrtSc.
Function key F10 typed twice does this format adjustment.
4. F10 also provides some TFTP server commands, discussed below.
23.1. Closing connections
At the end of a login session, some hosts will close the connection, in which
case PC/telnet exits, returning to PC-DOS. Other hosts issue an invitation for
another login. In the latter case, type F10 followed by "c" to close the
connection and exit from PC/telnet. Other methods of exiting, such as F10
followed by "q", or powering down the PC, will leave a dangling TCP/Telnet
connection that some hosts may not clean up properly. A later attempt to login
to that host from the same PC may encounter interference from the unclosed
If you close a connection without logging out, most hosts will deal with the
situation in the same way they handle telephone line hangups. If you exit
telnet without either logging out or closing the connection, the host may not
realize you are gone, and there is no way to pick up the connection again.
(The host, noticing lack of activity for a long time, may eventually log you
out and close the connection.)
If you try to open a connection to a host that does not respond, PC/telnet
will try eight times, then display an error message and exit. Note that this
message may mean either that the target host is not listening to the network or
that some network or gateway in the communication path to that host has failed.
(The command PC/ping may be useful in isolating the trouble.)
Versions of PC/telnet are available for both local area networks and serial
lines. On a serial line, at speeds below 9600 baud, the combination of remote
echo and send-on-every-character modes causes display to fall far behind typed
input. Local echo and send-on-newline modes are recommended for operation at
lower line speeds.
23.2. Terminal emulation conventions and compatibility
The following conventions allow the PC keyboard to behave like that of a
1. There is no repeat key. To repeat any key, hold it down.
2. The function keys are keys F1-F5.
3. The color keys are F6(blue), F7(red) and F8(gray).
4. The H19 has separate keys for ASCII "Carriage Return" and ASCII
"Line Feed". These two functions are combined on the PC "Enter"
key. To send an ASCII CR, type "enter". To send an ASCII LF, type
5. The H19 has separate keys for ASCII "Backspace" and ASCII "Delete".
These two functions are combined on the PC "back-space" key. To
send ASCII DEL, type "backspace". To send ASCII BS, type
"control-backspace". A customization option and an F10 escape allow
interchanging backspace and control-backspace. For convenience, the
keypad key labeled "Del" also sends an ASCII DEL.
6. Note that, like it or not, the emulator exactly emulates the Heath
H19 line wraparound feature. That is, in line wraparound mode, the
emulator automatically goes to the next line after placing a
character in column 80, rather than waiting to see if the program or
typist will try to put something in column 81.
23.3. Heath H19 features not emulated
hold screen/scroll keyclick disable
graphics keyboard disable
shifted keypad block cursor
alternate keypad AutoCR
identify as VT-52 AutoLF
transmit page transmit 25th line
offline/online switch parity enable
XOFF/XON flow control most ANSI escapes
control-suppression of transmitting display mgt codes
restore power-up configuration
ESC x setting of parameters
control-space does not send null (but control-2 does)
23.4. File transfer with PC/telnet
The PC/tftp server package can be invoked while using PC/telnet. With this
feature, one can use PC/telnet to log in to a remote host, and then move files
between that host and the PC, using the other host's tftp command to control
the transfer. Compared with initiating the transfer from the PC, this method
has two advantages:
1. Because the user authenticates himself upon logging in to the
distant host he can transfer any files to which he has access, not
just publicly accessible files.
2. The user can invoke other commands on the distant host in
conjunction with the transfer. (E.g., compile and load a program
before sending it.)
Seven functions of PC/telnet support tftp service. They are invoked by
typing function key F10 followed by:
T Enable the tftp server. (This is the default mode of operation
when Telnet starts.)
t Disable the tftp server (upon completion of any transfer
currently in progress).
i Send this PC's internet address, in decimal format, as if it
had been typed on the keyboard. This function simplifies the
issuing of tftp commands on other systems.
o Same as i, but send in octal format.
I Display this PC's internet address on line 25 in octal and
decimal formats. (For use if the other system needs this
address in some odd format.)
y Accept a file transfer request.
n Refuse a file transfer request.
A Accept all file transfer requests, without asking. Typing F10/A
again returns to the normal mode of operation.
When another host requests a file transfer to or from this PC, the PC/tftp
server asks the PC/telnet user for permission to accept the request. (Type
F10/y or F10/n.) For a successful transfer, the user must accept the request
before the remote host loses patience, times out, and aborts the transfer.
Hosts commonly have a 10 to 30 second timeout.
Further information on file transfer may be found in the description of
PC/tftp service, and in the description of tftp usage for the remote host.
Some hosts have a tftp command that is similar to the PC/tftp command, so that
writeup in this manual may offer some help if no other documentation is
23.5. Nested calls to the DOS shell
The PC/telnet escape F10/! invokes a nested DOS command interpreter,
permitting the user to invoke other DOS commands locally on the PC without
shutting down the telnet connection. This feature requires a configuration of
at least 192K bytes of memory, and while running the nested command
interpreter, network commands cannot be used. One should not stay in DOS for
extended periods because while in DOS, arriving messages are ignored, and if
the host at the other end of the telnet tries to send such a message it may
become impatient with the lack of response from the PC, and close the
connection. To return to PC/telnet, issue the DOS command EXIT.
The following parameters of telnet can be customized with the PC/custom
1. The parameters for TCP window size and TCP low window are of
particular interest to PC/telnet users. If one is communicating
with a mainframe time-sharing system on the same local area network
as the PC, it is recommended that a window size no larger than 350
bytes be used, with a low window of 150 bytes. Use of larger
windows may lead to pauses when displaying large quantities of
output. See the description of PC/custom for more explanation of
2. Start in line-at-a-time mode or character-at-a-time mode.
23.7. DOS note
The DOS feature of redirecting output to a file cannot be used for PC/telnet
23.8. Debugging note
There are several debugging features built in to PC/telnet that can be useful
in tracing network problems. See the section "debugging options" for more
information. Function key F10, followed by control-H, will produce a display
of a list of those options.
16 September 1985. This document is in file telnet.mss
A terminal emulator for the IBM Personal Computer. This program is not
strictly a part of the PC/IP network software, since it makes no use of the IP
protocol family. It turns the PC into a terminal so that it may be used to log
in to hosts that provide dial-up login facilities. It is included as part of
the PC/IP package because it uses a terminal emulation package that is
identical to the one used in PC/telnet.
24.1. Operating instructions
- To run the emulator type the DOS command TERM. It will immediately
activate "data-terminal-ready", which notifies the attached modem or
host computer system of its presence. It then clears the screen and
begins emulation, without any greeting messages.
- To exit the emulator without deactivating "data-terminal- ready",
type F10, followed by "q". This method of exit leaves the modem or
attached computer system with the impression that the terminal is
still attached. (exit off-hook)
- To exit the emulator and deactivate "data-terminal-ready", type F10,
followed by "c". This method of exit tells the modem or attached
computer system that the terminal has been disconnected. (exit
- To exit the emulator with "data-terminal-ready" restored to the value
it had when the emulator command was first typed, type break
- To send a break type F9.
- To set configuration options type F10, follow instructions.
- Standard terminal configuration options:
full/half duplex line discard/wrap baud rate
Extra emulator configuration options:
reverse BS/DEL normal/inverse video select serial port
- Type F10 again to exit from the option-setting menu.
- Type F10 twice before using the PC Print-Screen feature, to restore
the screen buffer to the format expected by PrtSc.
24.2. Configuration customization
The "power-up configuration" may be customized by using the DOS DEBUG command
1. While in DOS, type the command "DEBUG TERM.COM"
2. To the debugger, type command "g" to enter the emulator.
3. Hit key F10 and set the desired power-up configuration.
4. Choose menu item "q" to return to the debugger.
5. Type command "w" to save the new configuration on the disk.
6. Type command "q" to return to DOS.
For a list of keyboard conventions and terminal emulation limitations, see
the writeup of PC/telnet, which uses the same terminal emulator.
9 June 1983. This document is in file term.mss
PC/tftp, Version 7.3
A file transfer package for the IBM PC, using the UDP/IP protocol.
tftp [ get ] local-file-name hostname foreign-file-name [octet]
[ put ]
- The first argument should be get to move a file from another machine
to the PC, or put to move a file from the PC to another machine.
- local-file-name is the name of the file in the file system of the PC.
- hostname is either a standard character-string name of the other
computer, or the internet address of that computer. See the section
on hostnames for more details on this argument.
- foreign-file-name is the name of the file in the file system of the
other computer. Note that the foreign computer may require that this
file name be "fully qualified," that is it may need to include a
directory name in idiosyncratic syntax in order that the foreign
system can identify the wanted file. If the foreign file name syntax
requires use of characters reserved by PC/DOS, then the name must be
surrounded by double- quote marks. (The PC/DOS reserved characters
are greater-than, less-than, and reverse slash.)
- The optional argument octet instructs tftp to move the file
literally, byte-by-byte, from one computer to the other. If this
argument is omitted, the file is assumed to be a text file, and tftp
automatically performs any necessary character set conversions to and
from the network standard character set representation, known as
netascii. For compatibility, PC/tftp also accepts the argument image
with the same meaning as octet.
Not all hosts implement TFTP service. It is currently available on most
Multics, PDP-11 UNIX, VAX-UNIX, Alto, IBM PC, and TOPS-20 machines attached to
TFTP does not demand a password from the user, so most foreign hosts are not
willing to let just any file be transferred. As a general rule, one can move a
file from a foreign host if that file is publicly accessible on that host. If
it is protected from public access, it is usually protected also from TFTP get
operations. Similarly, a file may be moved to directory in a foreign host only
if that host would normally permit anyone to put files in that directory. An
important restriction that most hosts enforce is that one may not put a file on
top of an already-existing file of the same name. This restriction is
especially important to understand if for some reason a put operation fails or
is aborted. Despite the failure, the foreign host may have created an empty or
partial file, with the name specified. Another attempt to put the file with
the same name will then fail because of the access-control restriction.
It is possible to send a file to a printer on a remote PC that is running the
tftp server, by giving a name such as "PRN" or "LPT1" as the foreign file name.
See the writeup of the tftp server for more details.
All PCIP packages follow the DOS convention of returning an ERRORLEVEL value
when they exit. In the case of PC/tftp, the value zero means that the file was
successfully transferred, while the value one means that some error prevented
completion of the transfer. The ERRORLEVEL feature is primarily of use if
PC/tftp is invoked as a command from a DOS batch file.
The version of TFTP distributed with Berkeley 4.2 UNIX contains two defects
that are often noticed only by PC/IP users. First, it ignores the using
computer's specification of netascii or octet mode, and performs all transfers
in octet mode. Thus when a text file is transferred to or from a PC the
resulting file is not translated, and end-of-line characters are not properly
represented. Second, if a single packet sent to the PC gets lost during the
transfer, the 4.2 UNIX TFTP never retries and it ignores retries from the PC.
Thus the loss of a single packet guarantees failure of that file transfer. A
new TFTP which does not have these problems is available on the PC/IP source
See also the writeups of PC/tftp service and dialup line file transfer.
16 September 1985. This document is in file tftp.mss
26. TFTP Server
PC/tftp server, version 7.3
An implementation of a file transfer server for the IBM PC.
tftp serve spool
The PC/tftp server package allows users at other network hosts to initiate
file transfers to and from this PC. The option spool disables write blocking,
to allow the tftp server to be used as a print spooler.
- Server tftp can also be invoked from within the telnet command, while
logged in to another host. See the writeup of PC/telnet for usage
- While server tftp is running, no other use can be made of the PC. To
turn server tftp off, type "q". If a file transfer is already in
progress, server tftp will shut down immediately, leaving the host at
the other end of the transfer wondering where it went.
- There is no access control whatever. The tftp server allows a remote
host to initiate a get or put operation for any file on any
accessible disk. (The version of the tftp server that is invoked
from PC/telnet asks the user for confirmation of each file transfer
request that it receives.)
- The PC-DOS operating system is not designed for unattended use, so
leaving a PC alone with the tftp server running does not work very
well. For example, if the distant host tries to initiate a put to a
write-protected diskette or unreadied disk drive, PC-DOS will stop in
its tracks and ask the operator of this PC what to do. Until someone
answers this query, the tftp server appears to be dead.
- In initiating file transfers from other hosts, the user at the other
host must know the IP address of the PC that is running server tftp.
This IP address may not be associated with any name table name. [In
Berkeley UNIX 4.2, one can learn the IP address of the host
originating a telnet connection by using the command "who am I".
This feature simplifies transferring files back to the PC from which
one originated a telnet connection.]
- PC-DOS will prefix any file name supplied by the foreign host with
the default drive and the default working directory for that drive.
To override these defaults, the foreign tftp initiator can supply a
full drive descriptor and path name. However, because of the special
characters (colons and back-slashes) appearing in fully qualified
PC-DOS file names, one may have to use some quoting convention on the
foreign host to type the file name at command level. [For example,
on another PC, path names should be enclosed in double quotes. On
UNIX, back-slash characters should be doubled or replaced with
forward-slash characters, which PC/tftp will accept instead.]
- The tftp server permits only one file transfer at one time. If any
host requests a transfer while one is already in operation, the tftp
server will refuse the second request.
- The tftp server can be used as a print spooler, simply by telling the
tftp user to send files to the appropriate device file name (such as
PRN or LPT1). When used this way, the usual write blocking done by
the tftp server sometimes interferes, since the tftp server
accumulates up to 10K bytes of transferred data before initiating the
first write to the device. On trying to send the next block of data,
the tftp client may then time out and give up because the server PC
will concentrate all its attention on the printer for a long time.
The server should be started with the option spool to disable write
See also the writeups of PC/tftp and PC/telnet.
16 September 1985. This document is in file tftps.mss
PC/whois, version 6.0
A program to obtain directory information about a registered user of another
network host, using the TCP/IP finger protocol.
whois [email protected]
Where name is the character string name of a registered user at the target
host, and host is either a character-string name of the target host or an
internet address in standard form. (See the section on hostnames in the
introduction for more details.) If name is omitted, some hosts will respond
with a list of currently logged-in users.
The whois command sends an inquiry, and displays the answer, if any. The form
and contents of the answer are determined entirely by the target host. Note
that some hosts do not respond to whois requests. They may either ignore the
request (in which case PC/whois displays the message "....host not responding")
or reject it (in which case PC/whois displays the message "Closed: foreign
If the target host is not forthcoming with a response, PC/whois will give up
after about 20 seconds. Typing the letter "q" will cause PC/whois to abort the
operation immediately. This feature is useful if one discovers that the
quantity of output is more extensive than anticipated.
4 December 1984. This document is in file whois.mss
This is a list of serious known bugs and features that, although described in
this manual, are not actually implemented yet.
PC/term: control-scrolllock exits on-hook, rather than with DTR restored to
its original value.
PC/term: at data rates of 4800 bits/second and below, when two-character
sequences are transmitted in response to a single keyboard key, (such as for
function keys and cursor controls) one of the characters is sometimes lost.
Internet Protocol: Because the PC implementation does not currently
reassemble fragmented packets, none of the PC/IP packages can be used with
hosts that gratuitously fragment large packets or through gateways that
fragment packets. Currently MIT-Multics is the only known ARPANET host that
gratuitously fragments large packets, making tftp service unusable for files
larger than 128 bytes. (PC/telnet is usable with MIT-Multics, because Multics
TCP never tries to send large packets.) Within the M.I.T. environment, large
packets are fragmented only when they traverse the CHAOS network.
PC/telnet: if, while using the tftp server, a disk problem occurs that leads
DOS to display a message (e.g., "Disk not ready: abort, retry or ignore?") DOS
attempts to display the message without realizing that PC/telnet is operating
the screen with offset pointers. Thus the DOS message may appear in a random
place on the screen, cut apart in two pieces, or even not appear at all. If
the user types a response to the question, the response will be accepted by DOS
and (assuming that the DOS file operation is successful) the display returns to
PC/AT: All PC/IP programs have been checked on the PC model AT using both
the Ethernet and serial line drivers. Although all appear to work correctly,
some problems that may be symptoms of lost interrupts have been noted. The
most serious symptom is that while transferring files to or from diskettes, the
diskette drive occasionally appears to fall out of the ready status. (A retry
always finds that the disk is actually ready.) Note that when this problem
occurs, the error message that DOS produces triggers an instance of the
16 September 1985. This document is in file status.mss
29. PC/IP bugs, tasks, problems, projects, and bright ideas
23 January 1986
*** means critical, needed immediately
** means important to have soon
* means would improve quality of operation significantly
(no stars) means would be nice to do when time permits
Asynchronous line driver:
1. Doesn't check size of incoming packets, can fail.
2. Exits if PC gateway doesn't respond. (Should return error.)*
3. Port number and interrupt line should be a customizable
4. Loses transmitted characters on escape sequences at low data rates.*
proNET p1300 driver: (no known problems)
Interlan NI5010 driver: (no known problems)
3COM Etherlink driver: (no known problems)
IP protocol handler:
1. Doesn't reassemble fragmented packets.*
2. Doesn't reply to time stamp or information requests.
3. Doesn't upcall on destination unreachable.*
UDP protocol handler: (no known problems)
TCP protocol handler: (no known problems)
PC/telnet version 8.0
1. F10/close doesn't work while connection is being opened. (Should
ensure that half-opened connection isn't completed, then exit.)*
2. Output buffer full condition damages multi-character sequences.
3. Should catch DOS exit call on file errors and fix screen before DOS
tries to display its error message.
PC/ping version 5.0:
In test mode, line 25 should contain
- time since test started*
- name and internet address of ping target
- identification of the program in use
- number of packets sent and number lost
PC/tftp version 7.3:
1. Shouldn't touch PC file until other site confirms willingness to try
2. Need way to shut off a transfer that isn't wanted.
PC/tftp server version 7.3:
1. Should allow multiple connections.
2. Needs graceful shutdown after current transfer is complete.
3. Crashes when aborting after a disk write protect error.
4. When responding to a get, runs at half the speed of a put.
PC/onetname version 5.0: (no known problems)
PC/netname version 5.0: (no known problems)
PC/setclock version 5.0: (no known problems)
PC/custom version 2.2: (no known problems)
1. Doesn't work on port 2.*
2. Should display modem status register contents in F10 mode.
3. full/half duplex, line discard/wrap options should be per port.
4. F10/b should send break and return to emulation, to match telnet.
5. Two-character output sequences are lost at speeds of 4800 baud and
6. Control-scroll lock should exit with DTR restored to entry value.
PC/onhook and PC/offhook commands: (no known problems)
PC/whois command version 6.0: (no known problems)
PC/nicname version 2.0: (no known problems)
PC/lpr version 4.0: (no known problems)
PC/monitor version 1.4: (no known problems)
PC/iprint version 1.1
Needs control of imagen font, etc.
PC/netwatch version 7.0
1. Should confirm source address, destination, type, length match in
Other general projects:
1. Need a canned response for "whois" requests. Need a polling "whois"
to find out who is on PC's.
2 October 1985. This document is in file tasks.mss
Table of Contents
1. Overview of PC/IP network programs 1
1.1. Software environment 1
1.2. Hardware environment 1
1.3. Customization 1
2. Technical Notes on PC/IP 3
2.1. Device Drivers 3
2.2. IP 3
2.3. UDP 3
2.4. TCP 3
2.5. Hostname resolution 3
2.6. TFTP 3
2.7. LPR 3
3. Other documentation 5
4. Changes From The Last Release 7
5. Changes In Prior Releases 9
6. Software Installation 11
7. Hardware Installation 13
7.1. Pronet jumper selection 13
7.2. Interlan NI5010 jumper selection 13
7.3. 3COM Etherlink interface 13
7.4. Memory expansion card flaw 13
8. Ethernet Etiquette 15
9. Host Names and Internet Addresses 17
10. Debugging options 19
11. Dialup line file transfer 21
12. Custom 23
12.1. Standard customization parameters 23
12.2. Site customization of network level parameters 23
12.3. Personal customization of terminal emulation options 23
12.4. Other parameters 23
12.5. On-the-fly error correction 24
12.6. Temporary customization 24
13. Iprint 25
13.1. Customization 25
13.2. Notes 25
14. Lpr 27
14.1. Customization 27
14.2. Notes 27
15. Monitor 29
15.1. Control file 29
15.2. User commands 29
15.3. Display modes 29
15.4. Bugs 29
15.5. Customization 29
16. Netname 31
16.1. Customization 31
17. Netwatch 33
17.1. Filtering 33
17.2. Combining Filters 33
17.3. Performance 33
18. Nicname 35
19. Onetname 37
19.1. Customization 37
20. Onhook and Offhook 39
21. Ping 41
21.1. Optional features 41
21.2. Using ping to isolate network trouble 41
21.3. Using ping to evaluate a serial line 41
22. Setclock 43
22.1. Customization 43
23. Telnet 45
23.1. Closing connections 45
23.2. Terminal emulation conventions and compatibility 45
23.3. Heath H19 features not emulated 45
23.4. File transfer with PC/telnet 45
23.5. Nested calls to the DOS shell 46
23.6. Customization 46
23.7. DOS note 46
23.8. Debugging note 46
24. Term 47
24.1. Operating instructions 47
24.2. Configuration customization 47
25. TFTP 49
25.1. Notes 49
26. TFTP Server 51
27. Whois 53
28. Status 55
29. PC/IP bugs, tasks, problems, projects, and bright ideas 57