@Make(Manual)
@String(ETHVersion="V2.4 Beta #3")
@LibraryFile(MultiLevelIndex)
@Modify(InputExample, LongLines Wrap, Group)
@Modify(ProgramExample, LongLines Wrap, Group)
@Begin(TitlePage)
@Begin(TitleBox)
@MajorHeading(ETHERMON)
@Heading(@Value[ETHVersion])
@Center(5 July 1992)
@End(TitleBox)
@CopyrightNotice(Andrew C. Pavlin)
@Begin(ResearchCredit)
@Center(written by)
@Center(Andrew C. Pavlin)
@Center(General Electric Co.)
@Center(Aerospace Information Technology)
@Center(Syracuse, NY 13221)
@End(ResearchCredit)
@End(TitlePage)
@PageHeading(Left="@Value[SectionTitle]",Right="@Value[Page]")
@Process(PageHeadings)
@Begin(Abstract)
ETHERMON is a software implementation of an Ethernet line activity 
monitor. It permits a suitably privileged user to observe the flow of 
data across the Ethernet, as seen from any DEC-standard Ethernet adapter 
connected to a VAX/VMS system. The data can be observed statistically in 
several forms, or can be recorded to a disk file for additional off-line 
analysis. The received data can be selectively filtered to remove 
messages not of interest. When possible, Ethernet addresses are 
displayed symbolically in addition to the physical hardware 
representation.
@End(Abstract)
@Chapter(Requirements for Use)
To operate, ETHERMON requires a VAX/VMS system at version 4.x or higher, and 
at least one Ethernet or FDDI interface that uses a driver compatible with the 
Ethernet driver specifications in the @u[@i<VMS I/O User's Reference 
Manual: Part II>] (DEUNA, DELUA, DEQNA, DELQA, DEBNT, etc.). The user 
account running ETHERMON must have PHY_IO, NETMBX, and TMPMBX (or SETPRV) 
privileges, and a buffered I/O byte limit quota (BYTLM) of at least 16000 
(depending on the value of certain SYSGEN parameters; see section @Ref[quota] 
on page @PageRef[quota]). For systems running VAX/VMS V5.4-3 and above, CMKRNL 
privilege is also required; it is preferred for systems at lower versions. 
@Foot{For more information regarding this new privilege requirement for 
ETHERMON V2.4 (needed to implement the new "fast" port interface), please see 
section @Ref[CMKRNL] describing ETHERMON's @i<modus operandi> on page 
@PageRef[CMKRNL].}
@IndexSecondary(Primary="quotas",Secondary="BYTLM")
@IndexSecondary(Primary="privileges",Secondary="CMKRNL")
@IndexSecondary(Primary="privileges",Secondary="NETMBX")
@IndexSecondary(Primary="privileges",Secondary="PHY_IO")
@IndexSecondary(Primary="privileges",Secondary="SETPRV")
@IndexSecondary(Primary="privileges",Secondary="TMPMBX")
@Index(SYSGEN parameters)
@Index(Fast port interface)
@Index(FDDI)
The system must not be running any 
application using promiscuous mode on the selected Ethernet 
interface (if running in fallback Ethernet-only mode, there must be no other 
protocol type FF-FF user on the Ethernet interface; see section @Ref[V4.x] for 
more details).
@Index(promiscuous mode)
@IndexSecondary(Primary="protocol type",Secondary="FF-FF")

Note that only one copy of ETHERMON can be running on an Ethernet 
interface at a time (due to a driver limitation on the number of 
simultaneous promiscuous Ethernet users); however, any number of 
@i[other] applications (DECnet, TCP/IP, etc.) may be running on an 
Ethernet interface at the same time as ETHERMON (as long as those 
applications do not create a promiscuous user).

Note also that, if your Ethernet has any kind of serious load on it, 
ETHERMON will tend to be a CPU hog. The program has been tuned, but the 
vast majority of its CPU time is spent in the VMS I/O executive and the 
Ethernet interface I/O driver (per VAX SPM analyses), which can't be 
"tweaked" for better performance. It is therefore recommended that you 
use ETHERMON on the most powerful CPU you have available, in order to 
prevent data loss in ETHERMON's analysis. Work is being done to attempt 
to correct this problem, but the work has not been completed as of this 
release.

One final limitation is that ETHERMON cannot see any messages being transmitted 
by the local system through the selected Ethernet interface (the 
loopback buffer isn't big enough for ETHERMON to bother turning it on, and 
most interfaces can't run in loopback or echo without also turning off real 
transmissions to and receptions from the actual cable). Bear this in mind 
when you interpret the received data.

@Section(Statement of Liability)
As usual, you use this program @b[at your own risk]; neither the author, 
the author's employer, DECUS, or anybody 
but yourself is liable for any problems caused by this program. The 
information used to construct this program was culled from many sources, 
not all of which could be considered to be 100% reliable; the author has 
tried for the best accuracy and reliability possible, but some of the data 
and logic in this program is based on conjecture. If you have any comments 
or suggestions as to improvements, corrections, etc., please contact me 
regarding them. As of 6 March 1992, I can be reached at:
@Begin(Verbatim, Group, LeftMargin +1 inch)
General Electric Company
Electronics Park, Bldg. 7, Room C67
Syracuse, NY 13221 U.S.A.
telephone: (315) 456-6212
           8*256-6212 (GE/RCA DIALCOMM)
fax: (315) 456-0956
GE DECnet: C5VR::PAVLIN
Internet: PAVLIN@@syr.ge.com
          PAVLIN@@c5vr.dnet.ge.com
@Label[author]
@End(Verbatim)
@Section(Acknowledgements)
DEC, DECnet, DECbridge, DECserver, LAT, UCX, Ultrix, VAX, 
VAXcluster, and VMS are trademarks of Digital Equipment Corporation.

ARPANET, Internet, and TCP/IP are trademarks of the U.S. Government 
Department of Defense.

MultiNet is a trademark of SRI International and TGV, Inc.

MULTIBUS II is a trademark of Intel Corporation.

Scribe is a trademark of Scribe Systems Inc.

SUN and NFS are trademarks of Sun Microsystems Inc.

U-B, NIU, and Access/One are registered trademarks of Ungermann-Bass, Inc.

AT&T and Unix are trademarks of American Telephone & Telegraph Co.

Xerox, XNS, and PUP are trademarks of Xerox Corporation.

HIU, CC, and Xyplex are trademarks of Xyplex Corporation.

Macintosh, AppleTalk, and EtherTalk are trademarks of Apple Computer, Inc.

PostScript is a registered trademark of Adobe Systems Incorporated.

HP is a trademark of Hewlett-Packard.

All other manufacturer names are those manufacturers' trademarks.
@Chapter(Installing the Program)
@Section(Manifest)
ETHERMON consists of several FORTRAN subroutines, a set of MACRO 
routines and a syntax table, a file of error message definitions, a 
VAX/VMS help library, and documentation files. The complete set of files
composing ETHERMON contains:
@Begin(Enumerate)
the FORTRAN source files and INCLUDE files defining COMMON blocks:
@Begin(Itemize)
ETHERMON.FOR - initialization and support routines source file

ETHERMON_ETHREAD.FOR - Ethernet read routines source file

ETHERMON_CMD_AL.FOR - commands (from @@ to L) source file

ETHERMON_CMD_MR.FOR - commands (from M to R) source file

ETHERMON_CMD_S.FOR - commands (S) source file

ETHERMON_CMD_TZ.FOR - commands (from T to Z) source file

ETHERMON_ADDR.INC - Ethernet address table

ETHERMON_BRIDGES.INC - bridge table and bridge interconnection map

ETHERMON_DEV.INC - device and system names

ETHERMON_ETH.INC - raw Ethernet data buffers and port parameters

ETHERMON_FILTER.INC - data filtering table

ETHERMON_MANUF.INC - manufacturer prefix numbers and names table

ETHERMON_PING.INC - PING command flags and data buffer

ETHERMON_PROT.INC - protocol type numbers and names table

ETHERMON_PRS.INC - parameters from command line parsing

ETHERMON_SMG.INC - pointers and control information for use of the Screen 
Management Facility (SMG)

ETHERMON_STATS.INC - counters for message statistics

ETHERMON_TCPIP.INC - protocol numbers and names for the DoD Internet 
protocol suite

ETHERMON_TRACE.INC - control flags and RMS blocks for TRACE command
@End(Itemize)

ETHERMON_PARSE.MAR - the MACRO source file containing the LIB$TPARSE 
state table and assorted support action routines.

ETHERMON_FASTCALL.MAR - the MACRO source file providing the run-time 
link access to the "fast" port interface.

ETHERMON_FASTSHR.MAR - the MACRO source file containing the kernel-mode 
access routines used to implement the "fast" port interface.
@Index(Fast port interface)

ETHERMON_MSG.MSG - the MESSAGE source file (containing the error message 
definitions).

ETHERMON.COM - a command prcedure which compiles and links the ETHERMON
program, creates the ETHERMON help library, and attempts to build the 
unsupported utilities (see section @Ref[Utilities] and the list of 
unsupported off-line utility files below).

On-line documentation:
@Begin(Itemize)
ETHERMON.HLP - the HELP command source text (used to build the VMS help 
library file).

ETHERMON.HLB - the VMS help library file for ETHERMON.
@End(Itemize)

Off-line documentation:
@Begin(Itemize)
ETHERMON.MSS - the user's guide (this document) in Scribe manuscript 
source format.

ETHERMON.LN0 - the user's guide in DEC LN03 laser printer output format.

ETHERMON.LPT - the user's guide in "dumb" line printer output format.

ETHERMON.PS - the user's guide in PostScript output format.
@End(Itemize)

Distribution tools:
@Begin(Itemize)
ETHERMON_SEND.COM - a command procedure to help in distributing ETHERMON by 
electronic mail (e-mail); currently, it only supports DECnet mail and 
Internet mail using the TGV MultiNet product's foreign mail interface.

AAAREADME.TXT - the introductory file for the ETHERMON package.
@End(Itemize)

Off-line unsupported utilities:
@Begin(Itemize)
ETHTRSTRUC.INC - FORTRAN include file describing the structure of a binary 
TRACE file's records

ETHERPARSE.FOR - FORTRAN source file of basic ASCII formatter for binary 
TRACE files

ETHERPARSE2.FOR - FORTRAN source file of enhanced ASCII formatter for binary 
TRACE files

ETHERPARSE2_CRF.MAR - MACRO source file of support code and data for 
ETHERPARSE2

ETHERPARSE_TCP.FOR - FORTRAN source file of alternate ASCII formatter

ETHERPARSE_XREF.FOR - FORTRAN source file of alternate ASCII formatter

ETHFILT_ETHADDR.FOR - FORTRAN source file for post-filter

ETHFILT_IPADDR_TGV.FOR - FORTRAN source file for post-filter

ETHFILT_IPADDR_UCX.FOR - FORTRAN source file for post-filter

ETHFILT_NFS.FOR - FORTRAN source file for post-filter

ETH_CHECK_SUBPROC.FOR - FORTRAN source file for support subroutine: verifying 
if a process is a TRACE/ANALYZER subprocess

ETH_MAP_ADDRTBL.FOR - FORTRAN source file for support subroutine: connecting a 
TRACE/ANALYZER subprocess to ETHERMON's address table global section

ETHFILT_IPADDR_TGV.OPT - linker options file for post-filter

ETHFILT_IPADDR_UCX.OPT - linker options file for post-filter

ETHERMON_ALL.COM - sample command procedure for batch-mode data collection
@End(Itemize)
@End(Enumerate)

@Section(Installation Procedure)
To prepare ETHERMON for use, the program must be compiled and linked, 
and its associated help library must be built; optionally, the program can 
be defined as a DCL foreign command.

Building the program means, first of all, all the source files must be in 
the same directory, and that directory must be the current default 
directory. Then issue the following commands:
@Begin(InputExample)
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON]
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON_ETHREAD]
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON_CMD_AL]
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON_CMD_MR]
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON_CMD_S]
   $ @b[FORTRAN/OPTIMIZE/CONTINUATIONS=99 ETHERMON_CMD_TZ]
   $ @b[MACRO ETHERMON_PARSE]
   $ @b[MACRO ETHERMON_FASTCALL]
   $ @b[MESSAGE ETHERMON_MSG]
   $ @b[LINK ETHERMON,-]
   $_     @b[ETHERMON_ETHREAD,-]
   $_     @b[ETHERMON_CMD_AL,-]
   $_     @b[ETHERMON_CMD_MR,-]
   $_     @b[ETHERMON_CMD_S,-]
   $_     @b[ETHERMON_CMD_TZ,-]
   $_     @b[ETHERMON_PARSE,-]
   $_     @b[ETHERMON_FASTCALL,-]
   $_     @b[ETHERMON_MSG]
   $ @b[MACRO ETHERMON_FASTSHR]
   $ @b[LINK/SHARE/PROTECT ETHERMON_FASTSHR,-]
   $_                   @b[SYS$SYSTEM:SYS.STB/SELECTIVE_SEARCH,-]
   $_                   @b[SYS$INPUT:/OPTIONS]
   @b[UNIVERSAL=FASTSHR_VERSION]
   @b[UNIVERSAL=P_INIT_FAST_$QIO]
   @b[UNIVERSAL=P_FAST_BUFIO_READ_$QIO]
   @b[UNIVERSAL=P_FAST_$QIO_D_LINE]
@End(InputExample)
which produces several .OBJ files, ETHERMON.EXE, and ETHERMON_FASTSHR.EXE. 
Alternatively, do
@Begin(InputExample)
   $ @b[@@ETHERMON]
@End(InputExample)
which does the same thing (and additional compiles for other programs) 
with less typing.

The shareable image ETHERMON_FASTSHR.EXE must be located in the same directory 
as the copy of the ETHERMON.EXE file that will be run, or the shareable 
image's location must identified by an executive-mode system-wide logical 
name. The shareable image must also be installed as a shared, protected image 
with the INSTALL utility, using commands like the following:
@Label[INSTALL]
@Begin(ProgramExample)
$ @b{ASSIGN/SYSTEM/EXECUTIVE_MODE -}
$_@b{     dev:[dir]ETHERMON_FASTSHR.EXE -}
$_@b{     ETHERMON_FASTSHR}
$ @b{INSTALL :== $INSTALL/COMMAND_MODE}
$ @b{INSTALL}
INSTALL> @b{ADD dev:[dir]ETHERMON_FASTSHR.EXE/SHARE/OPEN/HEAD/PROT}
INSTALL> @b{EXIT}
@End(ProgramExample)
@Index(INSTALL utility)
@Index(logical name)
@Index(SYSTARTUP_V5.COM)
It is suggested that these commands be placed in your system startup 
command procedure (SYS$MANAGER:SYSTARTUP_V5.COM) if you plan on using 
ETHERMON regularly.

Building the help library means:
@Begin(InputExample)
   $ @b[LIBRARY/CREATE/HELP ETHERMON ETHERMON]
@End(InputExample)
which produces ETHERMON.HLB. The program expects to find the .HLB file 
in the same directory as the .EXE files; it cannot be redirected by use 
of logical names. If you wish to change this behavior, the subroutine 
HELP in ETHERMON.FOR must be edited appropriately.
@Index(help library)

ETHERMON can be invoked either with the RUN command or as a foreign 
command. To define ETHERMON as a foreign command, the following line of
DCL must be executed before ETHERMON is used:
@Begin(InputExample)
     $ @b<ETHER*MON :== $@i{disk}:[@i{dir}]ETHERMON>
@End(InputExample)
where @i[disk] and @i[dir] specify the location of the ETHERMON*.EXE and 
ETHERMON.HLB files (a good place to put this line is in your LOGIN.COM 
file; although it can be done in SYLOGIN.COM, it is not recommended to 
encourage general users to try to use ETHERMON). Once that is done, ETHERMON 
can be invoked with the command line:
@Index(LOGIN.COM)
@Index(SYLOGIN.COM)
@Begin(InputExample)
     $ @b<ETHERMON> @i<@u[interface]>
@End(InputExample)
where @i<@u[interface]> is the name of the Ethernet interface to use. Only 
the device and controller letters need be specified; the unit number 
will always be discarded and replaced by a zero (to ensure that the 
program gets a unique device unit for its work). Optionally, you can 
specify an initial command to ETHERMON as well by using the command 
form:
@Begin(InputExample)
     $ @b<ETHERMON> @i<@u[interface]>@b<,>@i<@u[command]>
@End(InputExample)
where @i<@u[command]> is any legal ETHERMON command as defined later in 
this manual (including an Indirect file using the @b<@@@i[filename]> 
command form). This command will be executed immediately upon completing 
initialization of the Ethernet interface. You must specify an interface 
name if you also wish to specify a command. Remember also, if you are 
going to use a command with embedded quotes ("), that DCL preparses the 
command line before passing it to the application, possibly removing 
your quote marks before ETHERMON gets to look at the command.

When invoking ETHERMON with a RUN command, the start-up command looks 
like this:
@Begin(InputExample)
     $ @b<RUN ETHERMON>
@End(InputExample)
If you do not specify your Ethernet port name, or if you invoke 
ETHERMON with a RUN command, ETHERMON will search for all recognized
interface devices on your system, and will display a list of 
acceptable device names for your system on your terminal and query you for
a device name; if only one standard Ethernet interface exists on your system, 
ETHERMON will not query but will automatically select that one device and 
inform you of that action. For example, using the RUN command on a 
system with two Ethernet adapters (underlined text is user-entered):

@Begin(InputExample)
$ @u<run ethermon>
%ETHERMON-I-PORT, enter VMS device name of the Ethernet interface to use
_ETA0:   DEBNA      1: 60-07 DEC: LAVC
                    2: 60-03 DEC: DECnet Phase 4
                    3: 60-01 DEC: MOP Dump/Load
                    4: 90-00 Loopback
                    7: 08-00 Internet IP (DoD)
                    8: 08-06 Internet ARP
_ETB0:   DEBNA      1: 06-00 XEROX: NS IDP
Ethernet_port_: @u<eta0>
ETHERMON @Value[ETHVersion], 5-Jul-1992
ETHERMON>
@End(InputExample)

A single Ethernet adapter system's session (using the foreign command 
method without specifying an interface name):

@Begin(InputExample)
$ @u<ethermon>
%ETHERMON-I-ONEPORT, implicitly using the one Ethernet interface _XEA0:
ETHERMON @Value[ETHVersion], 5-Jul-1992
ETHERMON>
@End(InputExample)
@Chapter(Operation)
@Section(Theory of Operation)
ETHERMON operates by using the most basic property of the Ethernet 
promiscuous mode: that @b[ALL] Ethernet messages are received by the 
promiscuous user. 
@Index(promiscuous mode)
ETHERMON begins by connecting to the specified 
Ethernet interface and enabling the necessary privileges needed to 
perform the privileged I/O operations. The interface is started 
in promiscuous mode as a IEEE 802.3 mode receiver (Ethernet mode is a subset 
thereof; if Ethernet mode is used because you are running under VAX/VMS V4.x, 
the program uses protocol type FF-FF). 
It then posts an asynchronous read to the device; the read completion AST 
analyzes a received message and queues up another read, forever (or until the 
program is terminated).
@Index(IEEE 802.3)
@IndexSecondary(Primary="protocol type",Secondary="FF-FF")
@IndexSecondary(Primary="VAX/VMS",Secondary="V4.x")

As of version V2.4 of ETHERMON, certain enhancements were needed to work around 
a bug/"feature" in VAX/VMS V5.4-3 and above. These required directly accessing 
the raw Ethernet packet buffers in non-paged pool to ensure that the 
Ethernet MAC-level header was returned to ETHERMON correctly. This was 
implemented by writing a customized, streamlined version of the $QIO system 
service that is optimized for issuing asynchronous reads to an already 
assigned and protection-checked Ethernet port channel. This special version 
also adds an "intercept" routine to catch the completed read requests as 
they are sent to VMS I/O postprocessing; the intercept routine corrects the 
system buffer pointers to account for the MAC-level headers, thereby allowing 
the headers to be returned untouched by the Ethernet driver code. This allows 
for more accurate interpretation of the MAC headers, but requires that:
@Index(Fast port interface)
@IndexSecondary(Primary="VAX/VMS",Secondary="V5.4-3 and up")
@Index($QIO)
@Index(QIO)
@Label[CMKRNL]
@Begin(Itemize)
the user must hold the CMKRNL privilege, in addition to the 
other privileges required to use ETHERMON.
@IndexSecondary(Primary="privileges",Secondary="CMKRNL")

the shareable image ETHERMON_FASTSHR.EXE must be located in the same directory 
as the ETHERMON.EXE file (or its location identified by an executive-mode 
logical name), and must be installed as a shared, protected image 
with the INSTALL utility (see section @Ref[INSTALL] on page 
@PageRef[INSTALL] for details).
@End(Itemize)

All the fancy features of ETHERMON are based on how the received 
messages are analyzed. Normally, received messages are analyzed to see 
if the sending nodes have been listed in the table of known addresses 
kept by ETHERMON (this is only done for messages with protocol types 
where ETHERMON knows how to interpret the message body). If a sending 
node (and, in some cases, the destination node) are not found in the 
addresses table, the addresses are added to the table with appropriate 
identification; i.e., for Internet IP messages, the Internet physical IP 
address is stored in the table with the Ethernet address. An Ethernet 
address may have more than one equivalence name in the address table 
(since a node may be used for more than one purpose on the Ethernet). 
This table of equivalence names is used by the DISPLAY and SUMMARIZE 
commands to supply more meaningful identifications with the Ethernet 
addresses reported to the user.

The combinations of addresses and protocol types that can be recognized 
and decoded by ETHERMON are as follows:
@Begin(Enumerate)
any single-node (not multicast) address under protocol type 60-03 
(DECnet Phase IV) (symbolic names obtained from the local system's 
NETACP process)
@Index(DECnet)
@IndexSecondary(Primary="protocol type",Secondary="DECnet (60-03)")
@Index(NETACP)

any single-node address transmitting DEC MOP System ID packets (type 7) 
under the DEC MOP Remote Console protocol (60-02, either Ethernet or IEEE 
802.3 SNAP protocol subtype)
@Index(MOP)
@IndexSecondary(Primary="protocol type",Secondary="MOP (60-02)")

any single-node address under protocol type 08-00 (DoD Internet IP) 
(assuming the IP message header is valid)
@Index(Internet)
@IndexSecondary(Primary="protocol type",Secondary="IP (08-00)")

any source address under protocol type 08-06 (Internet ARP) (assuming the 
ARP header is correct; in ARP reply cases, the destination address can 
be deciphered as well) (proxy ARP is not processed because it is not 
trusted)
@Index(ARP)
@IndexSecondary(Primary="Internet",Secondary="ARP")
@IndexSecondary(Primary="protocol type",Secondary="ARP (08-06)")

source and multicast destination addresses for messages under protocol 
type 60-07 (DEC Local Area VAXcluster) that are sending to LAVC Node 
ID multicast addresses (AB-00-04-01-@i<xx-yy>), where @i<yyxx> is the 
hexadecimal cluster group ID plus 256 (decimal)
@Index(LAVC)
@Index(VAXcluster)
@IndexSecondary(Primary="protocol type",Secondary="LAVC (60-07)")
@Index(multicast address)

any address under protocol type 80-35 (Internet reverse ARP) (RARP response 
packet types only)
@Index(RARP)
@IndexSecondary(Primary="Internet",Secondary="RARP")
@IndexSecondary(Primary="protocol type",Secondary="RARP (80-35)")

any single-node source or destination address under protocol type 
08-88 (Xyplex terminal network)
@Index(Xyplex)
@IndexSecondary(Primary="protocol type",Secondary="Xyplex (08-88)")

addresses assigned to Ungermann-Bass, Inc., under protocol type 
06-00 (Xerox NS IDP) (prefixes 00-DD-00, 00-DD-01, and 00-DD-0F only),
including NIU's and XNS-based Access/One equipment
@Index(XNS)
@IndexSecondary(Primary="protocol type",Secondary="XNS (06-00)")

all addresses assigned to DEC hardware under protocol type 80-38 
(DEC Bridge management)
@Index(bridge)
@Index(DEC LAN Bridge)
@IndexSecondary(Primary="protocol type",Secondary="LAN Bridge (80-38)")

all addresses assigned to DEC hardware under protocol type 60-04 (DEC LAT)
@Index(LAT)
@IndexSecondary(Primary="protocol type",Secondary="LAT (60-04)")

certain source and destination addresses under protocol type 80-9B 
(AppleTalk, either Ethernet or IEEE 802.3 SNAP protocol subtype)
@Index(AppleTalk)
@IndexSecondary(Primary="protocol type",Secondary="AppleTalk (80-9B)")

all source addresses under protocol type 80-F3 (AppleTalk ARP, either 
Ethernet or IEEE 802.3 SNAP protocol subtype)
@Index(AARP)
@IndexSecondary(Primary="AppleTalk",Secondary="ARP")
@IndexSecondary(Primary="protocol type",Secondary="AARP (80-F3)")

all source addresses under protocol type 80-80 (Vitalink TransLAN III) 
sending to destination addresses 09-00-02-04-00-01 or 09-00-7C-04-00-01
(3Com/Bridge or Vitalink bridge logging multicast)
@Index(bridge)
@IndexSecondary(Primary="protocol type",Secondary="TransLAN III (80-80)")
@Index(multicast address)
@End(Enumerate)

When a DISPLAY or SUMMARIZE command is in progress, messages are counted 
up in categories corresponding to the search scheme selected (by source 
address, destination address, message body size, or protocol type). The 
resulting summations are reported as the output data from these 
commands. In a TRACE command, the messages are passed directly to the 
specified output file.
@Newpage
@Section(Commands)
Once ETHERMON is running, initially nothing will be going on (except for 
automatic address/name data collecting); the utility will prompt the user 
for command input. ETHERMON will continue to execute until the EXIT 
command or a control-Z is typed to terminate the program.

The defined commands are listed below; explanations of their functions 
and detailed syntax are given in the following sections.
@Begin(Verbatim)
       @@indirect-command-file
       ADD FILTER
       CLEAR FILTER
       CLEAR FLAGS
       DEFINE/KEY
       DELETE/KEY
       DISPLAY DESTINATIONS
       DISPLAY PROTOCOLS
       DISPLAY SIZES
       DISPLAY SOURCES
       DISPLAY STATISTICS
       EXIT
       HELP
       LOAD
       MAP
       MONITOR
       PING
       QUERY
       SAVE
       SET ADDRESS_NAME
       SET FILTER
       SET INTERVAL
       SET KEYPAD
       SET MANUFACTURER
       SET MESSAGES
       SET PROTOCOL_NAME
       SHOW ADDRESS_NAMES
       SHOW BRIDGES
       SHOW FILTERS
       SHOW KEY
       SHOW MANUFACTURERS
       SHOW MESSAGES
       SHOW PORT_STATUS
       SHOW PROTOCOL_NAMES
       SPAWN
       SUMMARIZE DESTINATION
       SUMMARIZE INTERNET
       SUMMARIZE PROTOCOL
       SUMMARIZE SIZE
       SUMMARIZE SOURCE
       SUMMARIZE STATISTICS
       TRACE
       WAIT
@End(Verbatim)
@Newpage
@SubSection(Command Parameters)
Certain command parameters have a constant format throughout ETHERMON. To 
simplify this user's manual, these formats are described here, rather than 
individually for each command.
@SubSubSection(Ethernet addresses)
@Label[address]
Ethernet addresses are 6-byte addresses. Users can specify them as command 
parameter and qualifier values in any of the following formats:
@Begin(Enumerate)
a physical Ethernet address in standard Xerox notation of the form 
@i<aa-bb-cc-dd-ee-ff>, where each letter group is a one- or two-digit 
hexadecimal number.

a physical manufacturer prefix code in standard Xerox notation of the form 
@i<aa-bb-cc>, where each letter group is a one- or two-digit hexadecimal 
number. You should always enter this as a even address (LSB of first number 
even), as the multicast bit is always cleared before doing manufacturer 
comparisons. Note that this is only legal for the ADD/SET FILTER command, 
the SHOW ADDRESS_NAMES command, and the SET MANUFACTURER command; other 
commands require a full node address.

a DECnet node number in the form @i<aa.bbb>, where @i<aa> is the decimal 
DECnet area number (in the range 1 to 63) and @i<bbb> is the decimal DECnet 
node number within the area (in the range 1 to 1023); the DECnet address 
translates directly to an Ethernet address of the form 
AA-00-04-00-@i<xx-yy>, where @i<yyxx> is the hexadecimal composite 
DECnet address ((area * 1024) + number).

a DECnet node name (a 1- to 6-character alphanumeric string); the node 
name must already be listed in the address table (so that the 
command can look up the equivalent Ethernet address).

an Internet physical IP address (four decimal numbers separated by 
periods, each ranging from 0 to 255, in the format @i<a.b.c.d>); the 
Internet address must already be listed in the address table (so that 
the command can look up the equivalent Ethernet address).

an Ungermann-Bass device serial number in the format UB#@i<nnnnn>, where 
@i<nnnnn> is the serial number of the device; ETHERMON will automatically 
determine which manufacturer prefix the device uses from the serial number 
range, and compute an address of the form 00-DD-00-@i<aa-bb>-00 or 
00-DD-01-@i<aa-bb-cc>.
@End(Enumerate)

Some commands can accept wildcards; in these cases, wildcards may only be 
used in the physical hexadecimal Ethernet and Internet physical address 
formats, and is done by replacing a number in a field with an asterisk ('*').
@SubSubSection(Protocol types)
@Label[protocol]
Ethernet protocols are 2-byte code numbers. Users can specify them as command 
parameter and qualifier values in either of the following formats:
@Begin(Enumerate)
a physical Ethernet protocol number in standard Xerox notation of the form 
@i<aa-bb>, where each letter group is a one- or two-digit hexadecimal number.

for certain commonly used protocol types, a symbolic name may also be used.  
The defined symbolic names are:
@Begin(Itemize)
AARP - AppleTalk Address Resolution Protocol (80-F3)

APPLETALK - AppleTalk Phase I or Phase II EtherTalk (80-9B)

ARP - DoD Internet Address Resolution Protocol (08-06)

DECNET - Digital Equipment Corporation's DECnet Phase IV protocol (60-03)

DOMAIN - Apollo DOMAIN protocol (80-19)

IP - DoD Internet Protocol (08-00)

LAT - Digital Equipment Corporation's Local Area Terminal service protocol 
(60-04)

LAVC - Digital Equipment Corporation's Local Area VAXcluster protocol 
(60-07)

LOOPBACK - the Ethernet-specification loopback test protocol (90-00)

MOP_DLA - Digital Equipment Corporation's Maintenance Operations Protocol 
for Dump/Load Assistance (60-01)

MOP_RC - Digital Equipment Corporation's Maintenance Operations Protocol 
for Remote Console operations (60-02)

RARP - DoD Internet Reverse Address Resolution Protocol (80-35)

XNS - Xerox Network Services: Internet Datagram Protocol (06-00)
@End(Itemize)
@End(Enumerate)

Protocol type numbers may not be wild-carded.

A list of protocol types known to ETHERMON can be obtained by issuing the 
SHOW PROTOCOL_NAMES/ALL command.
@IndexSecondary(Primary="commands",Secondary="SHOW PROTOCOL_NAMES")
@Index(SHOW PROTOCOL_NAMES)
@Newpage
@SubSection(@@indirect-command-file)
The @@@i<file> command causes a file of ETHERMON commands to be executed. 
Only one level of input indirection is allowed, and parameters may not 
be passed to the command file. It is not recommended to put an EXIT command 
into the indirect file, as it will cause the program to terminate (unless, 
of course, that is what you want to happen). The file is assumed to 
have a default filetype of .COM.
@Index(@@filespec)
@IndexSecondary(Primary="commands",Secondary="@@filespec")

Command format:
@Begin(InputExample)

@@@i<filename>
@End(InputExample)
@SubSection(ADD FILTER)
The ADD FILTER command adds a new filter definition to the filter table, 
optionally (and defaultly) enabling the filter for use in restricting 
data collection. No check is performed to test if this filter duplicates 
an existing definition. The filter can accept either matches or 
mismatches independently on source and/or destination address, and/or 
protocol type, in any combination.

During message reception for any DISPLAY, SUMMARIZE, or TRACE command, 
only those messages which can pass all of the enabled exclusion filters 
(if any) and at least one of each enabled address and protocol type 
inclusion filter (if any) will be processed.

Command format:
@IndexSecondary(Primary="commands",Secondary="ADD FILTER")
@Index(ADD FILTER)
@Index(filter)
@Begin(InputExample)

ADD FILTER /ENABLE (default)
           /DISABLE
           /ONLY=([PROTOCOL=@i<protocik>],[SOURCE=@i<address>],
                  [DESTINATION=@i<address>],[ADDRESS=@i<address>],
                  [MULTICAST])
           /EXCLUDE=([PROTOCOL=@i<protocol>],[SOURCE=@i<address>],
                     [DESTINATION=@i<address>],[ADDRESS=@i<address>],
                     [MULTICAST])

@End(InputExample)
where @i<protocol> is a Ethernet protocol type code, expressed as described 
in section @Ref[protocol], and @i<address> is a node address, expressed as 
described in section @Ref[address].

The use of SOURCE= specifies that the @i<address> is only treated as a 
source address; DESTINATION= specifies a destination address only;
ADDRESS= implies the address regardless of whether it was a source or 
destination; and MULTICAST specifies any multicast destination (including 
the Broadcast address).
@Index(multicast address)
@SubSection(CLEAR FILTER)
The CLEAR FILTER command removes one or all filter definitions from the 
filter table. The definition(s) are completely erased (not merely 
disabled); to disable a filter without deleting it, use the SET 
FILTER/DISABLE command.
@IndexSecondary(Primary="commands",Secondary="SET FILTER")
@Index(SET FILTER)
@Index(filter)

Command format:
@IndexSecondary(Primary="commands",Secondary="CLEAR FILTER")
@Index(CLEAR FILTER)
@Begin(InputExample)

CLEAR FILTER @i<filternumber>

CLEAR FILTER /ALL

@End(InputExample)
where @i<filternumber> specifies the number of the filter to delete 
(displayed by the ADD FILTER and SHOW FILTER commands), and /ALL 
specifies clearing all filters from the table.
@SubSection(CLEAR FLAGS)
The CLEAR FLAGS command clears the Internet (IP) flag bits for all 
address table entries (see the SHOW ADDRESS_NAMES command for the /TYPE 
qualifier). This is primarily available to allow re-deriving of IP 
addresses for nodes when some of the addresses are garbled (generally due 
to glitchy RIP-type IP routing messages detected on the Ethernet). After 
entering the command, automatic IP address derivation will start over 
from scratch (although the Ethernet address entries themselves will not 
be deleted).
@IndexSecondary(Primary="commands",Secondary="SHOW ADDRESS_NAMES")
@Index(SHOW ADDRESS_NAMES)
@IndexSecondary(Primary="protocol type",Secondary="RIP")

Command format:
@IndexSecondary(Primary="commands",Secondary="CLEAR FLAGS")
@Index(CLEAR FLAGS)
@Begin(InputExample)

CLEAR FLAGS

@End(InputExample)
@SubSection(DEFINE/KEY)
The DEFINE/KEY command associates an equivalence string and a set of 
attributes with a key on the terminal keyboard. The /KEY qualifier is 
required.

Command format:
@IndexSecondary(Primary="commands",Secondary="DEFINE/KEY")
@Index(DEFINE/KEY)
@Begin(InputExample)

DEFINE/KEY [/@i<qualifiers>] @i<key-name> @i<equivalence-string>

@End(InputExample)
where @i<key-name> specifies the name of the key that you are defining,
and @i<equivalence-string> specifies the string which is to be processed 
when you press the key. The entire remaining portion of the line after 
the key name is accepted as the equivalence string, as-is, so all 
qualifiers for the DEFINE/KEY command (as opposed to the equivalence 
string) must appear before the key-name.

The defined command qualifiers for DEFINE/KEY are:
@Begin(Itemize)
/NOECHO - determines whether the equivalence string is displayed on your
screen after the key has been pressed. By default, the equivalence
string is echoed to the screen when it is pressed.

/IF_STATE=state-name - specifies a state which must be in effect for the key
definition to be in effect. If you omit the /IF_STATE qualifier, the 
default state is used. The state name is an alphanumeric string. States are 
established with the /SET_STATE qualifier. The states already known to 
ETHERMON are DEFAULT (implied if /IF_STATE is not used) and GOLD (keypress 
immediately following pressing the PF1 key).

/LOCK_STATE - specifies that the state set by the /SET_STATE qualifier 
remain in effect until explicitly changed. If you do not use the /LOCK_STATE
qualifier, the state set by /SET_STATE is in effect only for the next 
defineable key that you press or for the next read terminating character
that you type. The /LOCK_STATE qualifier can only be specified with the 
/SET_STATE qualifier.

/SET_STATE=state-name - causes the specified state-name to be set when the 
key is pressed. The state name can be any alphanumeric string. If you omit 
the /SET_STATE qualifier, the current state that was locked remains in effect.

/TERMINATE - specifies whether the current equivalence string is to be 
terminated (that is, processed) when the key is pressed. Pressing RETURN 
after pressing the defined key has the same effect as using /TERMINATE.
@End(Itemize)

The following table lists the key names in column one. The remaining three
columns indicate the key designations on the keyboards for the three
different types of terminals that allow key definitions. All
definable keys on VT52 terminals are located on the numeric keypad.
On VT100-type terminals, you can define the LEFT and RIGHT arrow
keys as well as all the keys on the numeric keypad (although re-defining 
the arrow keys is not recommended). There are three
types of keys that can be defined on terminals with LK201 keyboards:
(1) keys on the numeric keypad, (2) keys on the editing keypad
(except the UP and DOWN arrow keys), and (3) keys on the function
key row across the top of the terminal.  (Note that you cannot
define function keys F1 through F5.)

@Begin(Verbatim)
      Key-name         LK201            VT100-type     VT52

      PF1              PF1              PF1            [blue]
      PF2              PF2              PF2            [red]
      PF3              PF3              PF3            [gray]
      PF4              PF4              PF4            - -
      KP0,KP1,...,KP9  0,1,...,9        0,1,...,9      0,1,...,9
      PERIOD           .                .              .
      COMMA            ,                ,              n/a
      MINUS            -                -              n/a
      ENTER            Enter            ENTER          ENTER
      Find (E1)        Find             - -            - -
      Insert Here (E2) Insert Here      - -            - -
      Remove (E3)      Remove           - -            - -
      Select (E4)      Select           - -            - -
      Prev Screen (E5) Prev Screen      - -            - -
      Next Screen (E6) Next Screen      - -            - -
      HELP             Help             - -            - -
      DO               Do               - -            - -
      F6, F7, ..., F20 F6, F7, ..., F20 - -            - -
@End(Verbatim)

Some defineable keys are enabled for definition all the time.
Others, including KP0 through KP9, PERIOD, COMMA, and MINUS, need to
be enabled for definition purposes. You must issue the SET
KEYPAD APPLICATION command before using these keys (by default, ETHERMON 
implicitly issues this command, but its effect may be cancelled with the
SET KEYPAD NUMERIC command).
@Index(SET KEYPAD)
@IndexSecondary(Primary="commands",Secondary="SET KEYPAD")

The LEFT and RIGHT arrow keys and the F6 through F14 VT200 keys are
reserved for command line editing.  You must issue the SET 
TERMINAL/NOLINE_EDITING command from the DCL level before defining these 
keys. You can also press control-V to enable keys F7 through F14.  Note that 
control-V will not enable the F6 key.
@Index(control-V)

Following is a sample of how to use defineable keys. The user wanted a 
method of typing a long, complicated TRACE command in as soon as a certain 
event occurred. A key definition was made to define the keypad ENTER key as 
translating to the command. When the event alert message occurred, the user 
merely had to press a single key to begin recording.

@Begin(InputExample)
ETHERMON> @i<@u[DEFINE/KEY/TERM/NOECHO ENTER TRACE/BIN/PARA/INT=:5/OUT=GRABIT]>
ETHERMON> 
    .
    .
    .
%ETHERMON-I-MOPMSG, 11:22:33 08-00-2B-12-34-56 sent MOP DLA msg, t=0508 ln=8
ETHERMON> @i{@u[<press keypad ENTER key>]}
%ETHERMON-I-ASYNTRCBEG, asynchronous TRACE command started...
@End(InputExample)
@SubSection(DELETE/KEY)
The DELETE/KEY command deletes key definitions that have been established by 
the DEFINE/KEY command.  The /KEY qualifier is required.

Command Format:
@IndexSecondary(Primary="commands",Secondary="DELETE/KEY")
@Index(DELETE/KEY)
@Begin(InputExample)

DELETE/KEY [/@i<qualifier>] @i<key-name>

@End(InputExample)
where @i<key-name> specifies the name of the key whose definition you want to 
delete, and the optional qualifier is /STATE=state-name, which specifies the 
names of states for which the specified key definitions are to be deleted. 
State names can be any appropriate alphanumeric string. If you omit the /STATE 
qualifier, key definitions in the DEFAULT state are deleted.

@SubSection(DISPLAY DESTINATIONS)
The DISPLAY DESTINATIONS command brings up a continuously updating 
screen (similar to the VMS MONITOR utility) reporting on the current top 
@i<N> destination addresses that Ethernet messages are being sent to. The 
screen is updated at the rate specified by the SET INTERVAL command.
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

Command format:
@IndexSecondary(Primary="commands",Secondary="DISPLAY DESTINATIONS")
@Index(DISPLAY DESTINATIONS)
@Begin(InputExample)

DISPLAY DESTINATIONS [/NOFILTER]

@End(InputExample)

The upper part of the screen reports the display type and the system 
name and interface port used for collecting the data. Below that is the 
report of messages lost (generally because the program could not read 
and process them as fast as they were coming in), and the number of 
messages and bytes of data received before and after filtering. The 
remainder of the screen is a bar graph, displaying the number of 
post-filter messages received for the top @i<N> destination addresses, 
where the addresses are displayed as physical Ethernet addresses and the 
first few characters of their combined equivalence names (if any, as many
as will fit for the available screen size). After 
the physical address is the message count in messages per second 
(averaged over the sampling interval) and the bar graph line for that 
value.

The /NOFILTER qualifier specifies that the DISPLAY will not use the 
currently active filters to restrict displayed data; this is useful when you 
have a background TRACE command running and still want to use the 
displays.
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@SubSection(DISPLAY PROTOCOLS)
The DISPLAY PROTOCOLS command brings up a continuously updating 
screen (similar to the VMS MONITOR utility) reporting on the current top 
@i<N> protocol types that Ethernet messages are being sent under. The 
screen is updated at the rate specified by the SET INTERVAL command.
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

Command format:
@IndexSecondary(Primary="commands",Secondary="DISPLAY PROTOCOLS")
@Index(DISPLAY PROTOCOLS)
@Begin(InputExample)

DISPLAY PROTOCOLS [/NOFILTER]

@End(InputExample)

The upper part of the screen reports the display type and the system 
name and interface port used for collecting the data. Below that is the 
report of messages lost (generally because the program could not read 
and process them as fast as they were coming in), and the number of 
messages and bytes of data received before and after filtering. The 
remainder of the screen is a bar graph, displaying the number of 
post-filter messages received for the top @i<N> protocol types,
where the protocol types are displayed as physical Ethernet type codes and the 
first few characters of their equivalence name (if any, as many
as will fit for the available screen size); if an 'i' appears after the 
physical protocol type number, this is an IEEE 802.3 extended (SNAP) 
protocol rather than an Ethernet protocol. After 
the physical type code is the message count in messages per second 
(averaged over the sampling interval) and the bar graph line for that 
value.

The /NOFILTER qualifier specifies that the DISPLAY will not use the 
currently active filters to restrict displayed data; this is useful when you 
have a background TRACE command running and still want to use the 
displays.
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@SubSection(DISPLAY SIZES)
The DISPLAY SIZES command brings up a continuously updating 
screen (similar to the VMS MONITOR utility) reporting on the current 
number of Ethernet messages in each of 15 size categories. The 
screen is updated at the rate specified by the SET INTERVAL command.
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

Command format:
@IndexSecondary(Primary="commands",Secondary="DISPLAY SIZES")
@Index(DISPLAY SIZES)
@Begin(InputExample)

DISPLAY SIZES [/NOFILTER]

@End(InputExample)

The upper part of the screen reports the display type and the system 
name and interface port used for collecting the data. Below that is the 
report of messages lost (generally because the program could not read 
and process them as fast as they were coming in), and the number of 
messages and bytes of data received before and after filtering. The 
remainder of the screen is a bar graph, displaying the number of 
post-filter messages received for the 15 size categories, ranging from 1 
to 100 bytes, to 1401 to 1500 bytes, in size partitions of 100 bytes.
After the size range on the display is the message count in messages per second 
(averaged over the sampling interval) and the bar graph line for that 
range.

The /NOFILTER qualifier specifies that the DISPLAY will not use the 
currently active filters to restrict displayed data; this is useful when you 
have a background TRACE command running and still want to use the 
displays.
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@SubSection(DISPLAY SOURCES)
The DISPLAY SOURCES command brings up a continuously updating 
screen (similar to the VMS MONITOR utility) reporting on the current top 
@i<N> source addresses that Ethernet messages are being sent to. The 
screen is updated at the rate specified by the SET INTERVAL command.
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

Command format:
@IndexSecondary(Primary="commands",Secondary="DISPLAY SOURCES")
@Index(DISPLAY SOURCES)
@Begin(InputExample)

DISPLAY SOURCES [/NOFILTER]

@End(InputExample)

The upper part of the screen reports the display type and the system 
name and interface port used for collecting the data. Below that is the 
report of messages lost (generally because the program could not read 
and process them as fast as they were coming in), and the number of 
messages and bytes of data received before and after filtering. The 
remainder of the screen is a bar graph, displaying the number of 
post-filter messages received for the top @i<N> source addresses, 
where the addresses are displayed as physical Ethernet addresses and the 
first few characters of their combined equivalence names (if any, as many
as will fit for the available screen size). After 
the physical address is the message count in messages per second 
(averaged over the sampling interval) and the bar graph line for that 
value.

The /NOFILTER qualifier specifies that the DISPLAY will not use the 
currently active filters to restrict displayed data; this is useful when you 
have a background TRACE command running and still want to use the 
displays.
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@SubSection(DISPLAY STATISTICS)
The DISPLAY STATISTICS command brings up a continuously updating 
screen (similar to the VMS MONITOR utility's unsupported ETHERNET class 
display) reporting on the current Ethernet port statistics (or counters, to 
use DECnet NCP terminology). The 
screen is updated at the rate specified by the SET INTERVAL command.
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
@Index(NCP)

Command format:
@IndexSecondary(Primary="commands",Secondary="DISPLAY STATISTICS")
@Index(DISPLAY STATISTICS)
@Begin(InputExample)

DISPLAY STATISTICS

@End(InputExample)

The upper part of the screen reports the display type and the system 
name and interface port used for collecting the data. Below that is the 
report of messages lost (generally because the program could not read 
and process them as fast as they were coming in), and the number of 
messages and bytes of data received before and after filtering. The 
remainder of the screen is a display of current, average, minimum, and 
maximum counts (averaged over the sampling interval) for data bytes 
received, data messages received, multicast bytes received, multicast 
messages received, single and multiple collisions, transmission delays 
due to potential collision, and assorted buffer errors.

There are two points to keep in mind regarding this command:
@Begin(Enumerate)
The data displayed by this command is from the raw counters in the Ethernet 
interface itself; no filtering can be applied to this data, so the 
/NOFILTER qualifier is meaningless (the results will be the same whether or 
not filtering is applied).

Because some of the data counters saturate or "wrap around" if the 
interface has been running for a while since it was last zeroed, some of 
the fields in this display may be zero or out of range when they should not 
be. To correct this, use the SHOW PORT_STATUS/ZERO command to zero the 
counters; this should correct any such display errors. Conversely, if 
another user issues the DECnet NCP command ZERO LINE COUNTERS, it may cause 
the display to briefly show erroneous data. This can be corrected by 
re-issuing the DISPLAY STATISTICS command, so that it starts with a fresh 
set of data.
@Index(SHOW PORT_STATUS)
@IndexSecondary(Primary="commands",Secondary="SHOW PORT_STATUS")
@Index(NCP)
@End(Enumerate)
@SubSection(EXIT)
The EXIT command terminates execution of the ETHERMON utility. This 
function is also performed by typing control-Z. The special promiscuous 
Ethernet port is shut down and deleted, any active TRACE/PARALLEL or 
TRACE/REPEAT command is terminated as if a TRACE/ABORT command was typed, 
and all information collected by 
ETHERMON (except that previously stored with the SAVE command) is discarded.

Command format:
@IndexSecondary(Primary="commands",Secondary="EXIT")
@Index(EXIT)
@Index(control-Z)
@Index(TRACE)
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Begin(InputExample)

EXIT

@End(InputExample)
@SubSection(HELP)
The HELP command obtains helpful information on the formats and usages 
of the ETHERMON commands. It functions similarly to standard VMS HELP.

Command format:
@IndexSecondary(Primary="commands",Secondary="HELP")
@Index(HELP)
@Begin(InputExample)

HELP [topic ...]

@End(InputExample)
@SubSection(LOAD)
The LOAD command reads a saved file of ETHERMON table information into 
the run-time database of the program. Four tables of dynamically 
updated name equivalences are maintained by the utility: the address 
table (storing equivalences to Ethernet physical addresses), the filter 
table (storing message filtering definitions), the manufacturer prefix
table (storing three-byte Ethernet address prefixes), and the protocol type 
table (storing equivalence names for Ethernet protocol types). LOAD will 
read a file and merge the file contents into one of these tables (append 
to table end for the filters table). The input file format is rather 
inflexible and defined to match the files generated by the SAVE command.

Command format:
@Index(LOAD)
@IndexSecondary(Primary="commands",Secondary="LOAD")
@Index(SAVE)
@IndexSecondary(Primary="commands",Secondary="SAVE")
@Index(address)
@Index(filter)
@Index(Internet)
@Index(manufacturer prefix)
@Index(protocol type)
@Begin(InputExample)

LOAD /ADDRESSES     [@i<inputfile>]
     /FILTERS       [@i<inputfile>]
     /INTERNET
     /MANUFACTURERS [@i<inputfile>]
     /PROTOCOLS     [@i<inputfile>]

@End(InputExample)
where /ADDRESSES if the default if no qualifier is specified, and 
@i<inputfile> is the optional specification of the file to read; if 
@i<inputfile> is missing or incomplete, the file specification is filled 
in from the default of SYS$DISK:[]ETHERMON.ETH_@i<qualifier>, where 
@i<qualifier> is the name of the qualifier currently in effect.

Upon LOADing an address, manufacturer prefix, or protocol type file, the 
file entries are merged with any existing entries in the table; duplicate 
fields are overwritten, but fields not specified in the file for a particular 
Ethernet address are not changed. 

Upon LOADing a filter 
file, all file entries are added as new entries; no match-ups between 
existing filter table entries and the new ones are made. Also, since the 
filter table is rather small (only 25 entries), it is very possible for 
the file read to prematurely terminate with a "table full" error; this 
will not abort ETHERMON, but will merely stop reading any more entries 
from the file. Also note that all filters LOADed from a file are 
initially disabled and, to be used, must be turned on with the SET 
FILTER/ENABLE command.
@IndexSecondary(Primary="commands",Secondary="SET FILTER")
@Index(SET FILTER)
@Index(filter)

If /INTERNET is specified, ETHERMON attempts to connect to the local 
Internet software running on the local system; currently, only TGV 
MultiNet, DEC VMS/Ultrix Connection (UCX, now called TCP/IP Services for VMS), 
Carnegie-Mellon University TCP/IP (CMU TCP/IP), and Network Research 
Corporation's Fusion (NRC Fusion) are supported. 
@IndexSecondary(Primary="Internet software",Secondary="CMU TCP/IP")
@IndexSecondary(Primary="Internet software",Secondary="DEC UCX")
@IndexSecondary(Primary="Internet software",Secondary="DEC TCP/IP Services for VMS")
@IndexSecondary(Primary="Internet software",Secondary="TGV MultiNet")
@IndexSecondary(Primary="Internet software",Secondary="NRC Fusion")
If the connection succeeds, ETHERMON will 
query the Internet software for any entries that match detected Internet 
addresses seen on the cable which have not received "real" name strings (as 
opposed to ASCII representations of the physical address). Any match-ups 
have their Internet name strings replaced with the name supplied by the 
Internet software. Note that the results of this command will be no better 
than the local Internet software can supply, so if your local node doesn't 
know much and does not have access to Domain Name Service, don't expect 
much from this command.
@Index(Domain Name Service)
@SubSection(MAP)
The MAP command attempts to query each Ethernet bridge currently known 
to the program for its packet forwarding tables, in order to attempt to 
build a interconnection "map" of the Ethernet segments visible from the 
current monitoring point.

Command format:
@IndexSecondary(Primary="commands",Secondary="MAP")
@Index(MAP)
@Index(bridge)
@Begin(InputExample)

MAP

@End(InputExample)

Note that the MAP command only works for bridges speaking DEC LAN Bridge 
protocol (80-38) or Ungermann-Bass's spanning tree protocol run over XNS, 
@Index(DEC LAN Bridge)
@IndexSecondary(Primary="protocol type",Secondary="LAN Bridge (80-38)")
@Index(XNS)
@IndexSecondary(Primary="protocol type",Secondary="XNS (06-00)")
and is not guaranteed to work for those (depending on 
filtering, passwords, etc.); however, references to any recognized 
bridge (whether or not it speaks a bridge protocol that the MAP command 
knows how to use) will be listed in the 
overall bridge routing map constructed by ETHERMON. To see the 
computed map, issue the SHOW BRIDGES/FULL command; to plot the map as a 
PostScript graphic image, issue the SHOW BRIDGES/MAP command.
@IndexSecondary(Primary="commands",Secondary="SHOW BRIDGES")
@Index(SHOW BRIDGES)
@SubSection(MONITOR)
The MONITOR command is a synonym for the DISPLAY command, for ease of 
use for heavy VMS MONITOR users. Any of the DISPLAY keywords and 
qualifiers may be used with MONITOR.

Command format:
@IndexSecondary(Primary="commands",Secondary="MONITOR")
@Index(MONITOR)
@Begin(InputExample)

MONITOR DESTINATIONS

MONITOR PROTOCOLS

MONITOR SIZES

MONITOR SOURCES

MONITOR STATISTICS

@End(InputExample)
@SubSection(PING)
The PING command attempts to "ping" a message off a remote node on the 
Ethernet, similar to the Unix "ping" utility, and reports the turnaround 
time if successful; however, the ETHERMON PING command can "ping" using 
multiple protocols.

Command format:
@IndexSecondary(Primary="commands",Secondary="PING")
@Index(PING)
@Begin(InputExample)

PING [/IEEE_LOOPBACK] [@i<address>]
PING /IEEE_MOP [@i<address>]
PING /INTERNET [@i<address>]
PING /LOOPBACK [@i<address>]
PING /MOP [@i<address>]

@End(InputExample)
where the address of the remote node is expressed as described in section 
@Ref[address]; note that a full, non-wildcarded address must be used. If no 
address is specified, the Ethernet Broadcast address 
(FF-FF-FF-FF-FF-FF) will be used. This is useful when you wish to test 
for the existence of a certain group of nodes, or just to help fill the 
address names table (by causing relatively idle nodes to generate 
traffic that ETHERMON can detect).

The qualifiers specify which format of "ping" message to use. The 
default is /IEEE_LOOPBACK if no qualifier is given. The message 
formats available are:
@Begin(Enumerate)
/IEEE_LOOPBACK: using IEEE 802.3 SNAP protocols for the general 
loopback protocol type (90-00).
@IndexSecondary(Primary="protocol type",Secondary="loopback (90-00)")
@Index(IEEE 802.3)

/IEEE_MOP: using IEEE 802.3 SNAP protocols using the DEC MOP Remote 
Console protocol (60-02) type's Request ID and System ID response 
message types.
@IndexSecondary(Primary="protocol type",Secondary="MOP (60-02)")
@Index(IEEE 802.3)

/INTERNET: using DoD Internet IP (08-00) datagrams using the ICMP 
Echo Request and Echo Reply message formats. Note that the target node 
must have an IP address stored for it in the address table.
@IndexSecondary(Primary="protocol type",Secondary="IP (08-00)")

/LOOPBACK: using Ethernet protocols for the general loopback protocol 
type (90-00).
@IndexSecondary(Primary="protocol type",Secondary="loopback (90-00)")

/MOP: using Ethernet protocols using the DEC MOP Remote Console protocol 
(60-02) type's Request ID and System ID response message types.
@IndexSecondary(Primary="protocol type",Secondary="MOP (60-02)")
@End(Enumerate)

@b<Note that, on a busy Ethernet, the PING command may fail because the 
reply packet was discarded by the Ethernet I/O driver when ETHERMON 
couldn't keep up with the incoming data flow. This does not necessatily 
mean that the target node does not exist.>
@SubSection(QUERY)
The QUERY command issues various types of queries to ranges of Ethernet 
addresses; it assumes that the automatic address recognition logic in 
ETHERMON will do something useful with the reply messages (if any). This 
allows searching for various types of remote devices by forcing them to 
respond to a direct status poll.

Command format:
@Index(QUERY)
@IndexSecondary(Primary="commands",Secondary="QUERY")
@Begin(InputExample)

QUERY/@i<querytype> [/@i<qualifier>] @i<address> [@i<endaddress>]

@End(InputExample)
where @i<address> is the first address to query, expressed as described in 
section @Ref[address]; @i<endaddress> is an optional last address to query 
(all Ethernet addresses between the first address and the last address 
inclusive will be queried); and @i<querytype> is the type of query to 
issue.

Legal query types include:
@Begin(Itemize)
/DECBRIDGE - issues a DEC "dump bridge statistics" query using DEC Lan Bridge 
protocol (80-38).

/DECMOP - issues a DEC MOP "Request ID" query using DEC Maintenance Operations
Protocols' Remote Console protocol (60-02).

/UB_BRIDGE - issues an Ungermann-Bass 'dump bridge forwarding table B' query 
using the XNS protocol (as would be done by an Ungermann-Bass Network 
Management Console).
@End(Itemize)

Additional @i<qualifiers> that may be specified are /LITTLE2_ENDIAN and 
/LITTLE3_ENDIAN, which control the sequence in which the span of addresses 
is traversed. By default, Ethernet addresses are assumed to be big-end 
first, so one will be added to the last byte, with carries trickling to the 
left as each byte overflows. However, some address sequences are different
(DECnet addresses are little-endian over the last two bytes, for example); 
to traverse these in a rational order, either of the above two qualifiers 
may be used to indicate how many of the last bytes of the address should be 
treated as little-endian order; bytes to the left of the little-endian 
group are treated as big-endian order and of larger magnitude than the 
little-endian block.

Note that this command can cause large amounts of network traffic, which 
may be particularly damaging to your network if you use remote bridges with 
sub-Ethernet line speeds between the Ethernet segments. ETHERMON has been 
measured to spew out approximately 200 messages/second on a VAX 6440, each 
of which has a different destination address, which will massively strain 
bridges trying to locate all the addresses that do not actually exist. Bear 
this in mind before using this command. To prevent accidental overloading 
of the Ethernet, a sanity check is applied to limit the number of addresses 
that will be queried; if more than 1000 addresses could be queried, the 
user is asked to confirm the address range before proceeding. If more than 
16777215 addresses are in the range, the command is unconditionally 
rejected.
@SubSection(SAVE)
The SAVE command writes the current contents of the ETHERMON utility's 
address, filter, manufacturer prefix, and protocol type tables to disk files, 
where they may be archived for later use with the LOAD command. These tables 
are built from a combination of pre-defined "hardwired" entries, entries 
manually entered by the user, and entries automatically made by the automatic 
address recognition and interpretation logic. However, their contents 
are lost when ETHERMON is exited.

Command format:
@Index(LOAD)
@IndexSecondary(Primary="commands",Secondary="LOAD")
@Index(SAVE)
@IndexSecondary(Primary="commands",Secondary="SAVE")
@Index(address)
@Index(filter)
@Index(manufacturer prefix)
@Index(protocol type)
@Begin(InputExample)

SAVE /ADDRESSES     [@i<outputfile>]
     /FILTERS       [@i<outputfile>]
     /MANUFACTURERS [@i<outputfile>]
     /PROTOCOLS     [@i<outputfile>]

@End(InputExample)
where /ADDRESSES if the default if no qualifier is specified, and 
@i<outputfile> is the optional specification of the file to write; if 
@i<outputfile> is missing or incomplete, the file specification is filled 
in from the default of SYS$DISK:[]ETHERMON.ETH_@i<qualifier>, where 
@i<qualifier> is the name of the qualifier currently in effect.

For the /ADDRESSES qualifier, the output file is an ASCII file where one 
record corresponds to one entry in the address table. Each line begins 
with the Ethernet address expressed as a single 48-bit (12-digit) 
hexadecimal number, last byte (not first) first. After the address, 
delimited by spaces are the equivalences for the other fields, if 
those fields are not empty (it is possible to have a record with only an 
Ethernet address and no equivalences whatsoever, if that node sent or received
messages only on protocols that ETHERMON cannot decipher). The second Ethernet 
address field is of the form
@Begin(ProgramExample)
A:ffeeddccbbaa
@End(ProgramExample)
where @i<ffeeddccbbaa> is the alternate Ethernet address stored in the same 
form as the primary Ethernet address. The DECnet field is of the form
@Begin(ProgramExample)
D:nn.mmm
@End(ProgramExample)
or
@Begin(ProgramExample)
D:name
@End(ProgramExample)
where @i<name> is the DECnet node name (as recognized by your local 
node's DECnet NETACP volatile database), or @i<nn.mmm> is the area and 
@Index(NETACP)
node number representation if the node name was not known. The preceding 
'D:' is required and must be in upper case. The Internet field is of the 
form
@Begin(ProgramExample)
I:a.b.c.d'domain-name'
@End(ProgramExample)
where @i<a.b.c.d> is the decimal Internet IP physical address for the node and 
@i<domain-name> is the symbolic equivalence name string (surrounded by 
single quotes). Currently, ETHERMON has no way to translate an IP 
address to a domain-name (other than the LOAD/INTERNET command), so the 
@i<domain-name> field is usually a duplicate of 
the IP address; the user may change this by editing the SAVE file 
manually and LOADing the modified file back into ETHERMON. The serial 
number field is of the form
@Begin(ProgramExample)
S:nnnn
@End(ProgramExample)
where @i<nnnn> is the variable-length decimal serial number in the 
manufacturer's numbering scheme. The XNS network number field is of the 
form
@Begin(ProgramExample)
X:ddccbbaa
@End(ProgramExample)
where @i<ddccbbaa> is a 4-byte hexadecimal number (last byte first) of the 
XNS network number field. The miscellaneous field is of the form
@Begin(ProgramExample)
Mxxxx:text optionally containing blanks
@End(ProgramExample)
where @i<xxxx> is a hexadecimal mask indicating what types of names have 
been stored in the miscellaneous name string, and the @i<text> can be of 
any length (not more than 80 characters, 
currently) and may contain embedded blanks or any other printable 
characters; because of this, the miscellaneous field must be the last 
field on the line, and all of the line after the 'M@i<xxxx>:' is assumed to be 
part of the miscellaneous name. Other fields stored in the address table are 
currently not stored in the SAVE file.

For the /FILTERS qualifier, the output file is an ASCII file where one 
record corresponds to one entry in the filter table. Each line may 
contain one or more definitions, delimited by spaces, which, combined, 
make up that filter. The definitions are of the form
@Begin(ProgramExample)
@i[<mode>]S:address
@i[<mode>]D:address
@i[<mode>]A:address
@i[<mode>]M
@i[<mode>]P:typecode
@End(ProgramExample)
where @i[<mode>] is one of the letters @b[O] (for Only) or @b[E] (for 
Exclude), @b[S], @b[D], @b[A], and @b[P] indicate source address, destination 
address, any address, or protocol type, @b[M] indicates any mulitcast 
destination address, @i<address> is either a 48-bit, 12-digit, 
high-byte-first physical Ethernet address (as used in the address SAVE 
file) or a 24-bit, 6-digit, high-byte first physical manufacturer prefix 
code, and @i<typecode> is a 16-bit, 4-digit, high-byte-first physical 
Ethernet protocol type code (as used in the protocol SAVE file).

For the /MANUFACTURERS qualifier, the output file is an ASCII file where one 
record corresponds to one entry in the manufacturer prefix table. Each line 
starts with a 24-bit, 6-digit hexadecimal number (high byte first) which 
is the manufacturer prefix code, followed by a space, an 8-character 
blank-padded field for the short version of the prefix name, a space, and 
arbitrary text (to the end of line) for the long form of the 
manufacturer name. 

For the /PROTOCOLS qualifier, the output file is an ASCII file where one 
record corresponds to one entry in the protocol type table. Each line 
starts with a 16-bit, 4-digit hexadecimal number (high byte first) which 
is the protocol type code, followed by a space and arbitrary text (to 
the end of line) which is the equivalence name. Note that the IEEE flag 
(indicating that the protocol is an IEEE 802.3 SNAP subtype or not) is 
not stored in a SAVE file. This limitation will be removed in a future 
release.
@SubSection(SET ADDRESS_NAME)
The SET ADDRESS_NAME command manually adds a new entry to the address 
name table with an equivalence name in the miscellaneous field, or 
overwrites the miscellaneous field of an existing entry. Hence, Ethernet 
addresses that cannot be recognized by the automatic interpretation 
logic can be manually named.

Command format:
@Index(SET ADDRESS_NAME)
@IndexSecondary(Primary="commands",Secondary="SET ADDRESS_NAME")
@Begin(InputExample)

SET ADDRESS_NAME aa-bb-cc-dd-ee-ff name

SET ADDRESS_NAME aa-bb-cc-dd-ee-ff "quoted string"

@End(InputExample)
where @i<aa-bb-cc-dd-ee-ff> is the standard format physical Ethernet 
address specification (low byte first, hexadecimal numbers); symbolic 
address formats cannot be used here. @i<name> is 
a text string without embedded blanks or punctuation marks (other than _
or $), and @i<"quoted string"> is a string enclosed in double quotes 
(not considered part of the string) which may contain any printable 
character other than a double quote. Only the first 80 characters of the 
supplied equivalence name will be stored in the table; if a matching 
entry already exists in the address table and its miscellaneous field is 
not empty, ETHERMON will prompt to verify that you wish to overwrite the 
existing field contents. Note that some pieces of address information 
automatically computed by ETHERMON are stored in the miscellaneous field;
these will be destroyed by using this command, but will be regenerated by 
ETHERMON when it sees new packets containing the information that derived 
the name data the previous time.
@SubSection(SET FILTER)
The SET FILTER command modifies the configuration of a pre-defined 
filter, enables or disables a filter, or modifies the message size 
filter settings. Filters can accept either matches or 
mismatches independently on source and/or destination address, and/or 
protocol type, in any combination.

During message reception for any DISPLAY, SUMMARIZE, or TRACE command, 
only those messages which can pass all of the enabled exclusion filters 
(if any) and at least one of each enabled address and protocol type 
inclusion filter (if any) will be processed.

Command format:
@IndexSecondary(Primary="commands",Secondary="SET FILTER")
@Index(SET FILTER)
@Index(filter)
@Begin(InputExample)

SET FILTER filternum /ENABLE
                     /DISABLE
                     /ONLY=([PROTOCOL=@i<ab-cd>],[SOURCE=@i<address>],
                            [DESTINATION=@i<address>],[ADDRESS=@i<address>],
                            [MULTICAST])
                     /EXCLUDE=([PROTOCOL=@i<ab-cd>],[SOURCE=@i<address>],
                               [DESTINATION=@i<address>],
                               [ADDRESS=@i<address>],[MULTICAST])
                     /NODESTINATION
                     /NOPROTOCOL
                     /NOSOURCE

SET FILTER /SIZE=(ENABLE,
                  DISABLE,
                  MAXIMUM=nnn,
                  MINIMUM=nnn)

@End(InputExample)
For the first form of the command, @i<filternum> is the index number of a 
pre-existing filter definition (as reported by ADD FILTER and SHOW FILTER), 
@i<protocol> is a protocol type code as described in section @Ref[protocol], 
and @i<address> is a node address as described in section @Ref[address].
Wildcards are permitted in the address, as are manufacturer-prefix-only 
values. The use of SOURCE= specifies that the @i<address> is only treated as 
a source address; DESTINATION= specifies a destination address only; 
ADDRESS= implies the address regardless of whether it was a source or 
destination; and MULTICAST specifies any multicast destination (including 
the Broadcast address).
@Index(multicast address)

For the second form of the command, only one of ENABLE or DISABLE may be 
specified for the /SIZE qualifier, and these may be specified with or 
without the MAXIMUM and MINIMUM options; these options take a decimal byte 
count @i<nnn> as the minimum and maximum message sizes that may pass through 
the filter. There is no safety check on minimum and maximum sizes to 
ensure that the maximum is greater than the minimum, so the size filter 
could be set to exclude all messages; be careful of this.
@SubSection(SET INTERVAL)
The SET INTERVAL command sets the number of seconds between screen 
updates for the DISPLAY commands, and the default period of data 
collection for the SUMMARIZE and TRACE commands.

Command format:
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
@Begin(InputExample)

SET INTERVAL nn

@End(InputExample)
where @i<nn> is the decimal integer number of seconds to be used, in 
the range of 2 to 59 seconds. The initial default is 4 seconds.
@SubSection(SET KEYPAD)
The SET KEYPAD command switches the state of the terminal's numeric keypad 
to numeric or applications mode. By default, ETHERMON will switch the 
keypad to applications mode upon start-up, and restore the terminal to 
whatever state it was in before ETHERMON was invoked when ETHERMON 
terminates.

Command format:
@IndexSecondary(Primary="commands",Secondary="SET KEYPAD")
@Index(SET KEYPAD)
@Begin(InputExample)

SET KEYPAD APPLICATIONS
SET KEYPAD NUMERIC

@End(InputExample)
@SubSection(SET MANUFACTURER)
The SET MANUFACTURER command manually adds a new entry to the 
manufacturer prefix name table with an equivalence name, or 
overwrites the equivalence name of an existing entry. Hence, Ethernet 
interface manufacturers not already known to ETHERMON can be manually named.

Command format:
@IndexSecondary(Primary="commands",Secondary="SET MANUFACTURER")
@Index(SET MANUFACTURER)
@Index(manufacturer prefix)
@Begin(InputExample)

SET MANUFACTURER aa-bb-cc short-name long-name

SET MANUFACTURER aa-bb-cc short-name "quoted long name"

@End(InputExample)
where @i<aa-bb-cc> is the first three bytes of the standard format physical 
Ethernet address specification (low byte first, hexadecimal numbers), 
@i<short-name> is a text string without embedded blanks or punctuation marks 
(other than _ or $) which is used to prefix node name information on the
DISPLAY screens, and @i<long-name> and @i<"quoted long name"> are 
strings (optionally enclosed in double quotes, may contain any printable 
character other than a double quote), which is a more descriptive
name for the manufacturer. Only the first 8 characters of the 
supplied short-name and first 24 characters of the long-name will be stored 
in the table; if a matching entry already exists in the manufacturer table, 
ETHERMON will prompt to verify that you wish to overwrite the existing 
names.
@SubSection(SET MESSAGES)
The SET MESSAGES command enables or disables display of asynchronous 
"significant event" messages on the user terminal. By default, 
asynchronous event messages can interrupt any output on your screen any time 
while ETHERMON is running; however, when executing a DISPLAY command, such 
messages are displayed in a separate scrolling window, and the messages 
are not written to any SHOW or SUMMARIZE command's output when the 
/OUTPUT qualifier is used.

Command format:
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@IndexSecondary(Primary="messages",Secondary="asynchronous event")
@Begin(InputExample)

SET MESSAGES ON

SET MESSAGES OFF

SET MESSAGES DEBUG

@End(InputExample)
where ON specifies that significant messages should be displayed (the 
default), OFF specifies 
that messages should not be displayed, and DEBUG not only enables 
display, but turns on additional event messages not normally 
considered significant. Note that the default changes to DEBUG if you 
compile ETHERMON_CMD_S.FOR with the /D_LINES compiler option.
@Index[/D_LINES (FORTRAN qualifier)]

Other flavors of the SET MESSAGE command allow enabling and disabling 
optional sanity checks. The first of these checks is
@Begin(InputExample)

SET MESSAGE DUPIP

SET MESSAGE NODUPIP

@End(InputExample)
@IndexSecondary(Primary="messages",Secondary="duplicate IP addresses")
where, if DUPIP checking is enabled, ETHERMON will check for any new node 
addresses that claim the same IP address as a node already existing in the 
address table.

Another check available is
@Begin(InputExample)

SET MESSAGE NEWNODE

SET MESSAGE NONEWNODE

@End(InputExample)
@IndexSecondary(Primary="messages",Secondary="new node detected")
where, if NEWNODE checking is enabled, ETHERMON will report each time a new 
entry is added to the address table (entries loaded by the LOAD/ADDRESSES 
command but not previously seen by the current ETHERMON session will not be 
reported, as they are assumed to already be known).
@SubSection(SET PROTOCOL_NAME)
The SET PROTOCOL_NAME command manually adds a new entry to the protocol 
name table with an equivalence name, or 
overwrites the equivalence name of an existing entry. Hence, Ethernet 
protocols not already known to ETHERMON can be manually named.

Command format:
@Index(SET PROTOCOL_NAME)
@IndexSecondary(Primary="commands",Secondary="SET PROTOCOL_NAME")
@Begin(InputExample)

SET PROTOCOL_NAME aa-bb name

SET PROTOCOL_NAME aa-bb "quoted string"

@End(InputExample)
where @i<aa-bb> is the standard format physical Ethernet 
protocol type specification (low byte first, hexadecimal numbers), @i<name> is 
a text string without embedded blanks or punctuation marks (other than _
or $), and @i<"quoted string"> is a string enclosed in double quotes 
(not considered part of the string) which may contain any printable 
character other than a double quote. Only the first 24 characters of the 
supplied equivalence name will be stored in the table; if a matching 
entry already exists in the protocol table, ETHERMON will prompt to verify 
that you wish to overwrite the existing equivalence name.

@Begin(Description)
@b[@i<WARNING !!!!>]@\At present, the SET PROTOCOL_NAME command cannot tell 
the difference between an IEEE 802.3 extended protocol and an Ethernet 
protocol in the table, so if you have a protocol used in both modes, the SET 
PROTOCOL_NAME command will affect the first occurrence located in the 
protocol name table (not necessarily the displayed order, as the table is 
sorted by the SHOW PROTOCOL_NAMES command for display).
@End(Description)
@SubSection(SHOW ADDRESS_NAMES)
The SHOW ADDRESS_NAMES command displays the current contents of the address 
table on the user terminal, preceded and followed by the current table 
size. This includes all pre-defined "hardwired" names, all names 
extracted from the local node or VAXcluster, all names manually entered with 
the SET ADDRESS_NAME command, and all names automatically derived by the 
address recognition logic and the LOAD/INTERNET command. 
@Index(SET ADDRESS_NAME)
@IndexSecondary(Primary="commands",Secondary="SET ADDRESS_NAME")
@Index(LOAD)
@IndexSecondary(Primary="commands",Secondary="LOAD")
Any address which has been seen on your Ethernet 
since ETHERMON was started will have a letter displayed before the 
hexadecimal address string; the letter will be a "s" (for source only),
"d" (for destination only), "m" (for multicast destination only), or 
"b" (used both as source and destination).
@Index(multicast address)

Command format:
@Index(SHOW ADDRESS_NAMES)
@IndexSecondary(Primary="commands",Secondary="SHOW ADDRESS_NAMES")
@Begin(InputExample)

SHOW ADDRESS_NAMES [wildcard-address]
                   [/ALL]
                   [/FULL]
                   [/OUTPUT=filespec]
                   [/PROTOCOL=protocol]
                   [/TYPE=%Xnnnn]
                   [/TYPE=(typename[,typename...])]

@End(InputExample)

Note that the name count at the end of a display may be larger than at 
the beginning, due to automatic name insertion while the command is in 
progress. Also note that, unless the /ALL qualifier is specified, only 
addresses that have actually been seen on the Ethernet since the current 
ETHERMON session was started will actually be displayed; alternate 
addresses and addresses predefined by ETHERMON (but not active) will not be 
displayed.

The @i[wildcard-address] parameter allows you to restrict address display 
to a subset of known addresses, where the parameter is expressed in one of 
the formats described in section @Ref[address].
The address can be specified as just a manufacturer prefix, where the 
missing terms are assumed to be wildcarded. If no address is given, the 
address @i[*-*-*-*-*-*] is assumed. The Internet physical address form 
@i[a.b.c.d], where each number is a legal (0 to 255) decimal byte value 
or the '*' wildcard symbol, may also be used, providing at least one of the 
octets is not a wildcard. Specifying both an Ethernet address and an Internet 
address will cause only addresses meeting @i<both> criteria to be 
displayed (if any meet the criteria).

The /ALL qualifier specifies that all addresses, not just active ones, will 
be displayed (subject to other restrictions).

The /FULL qualifier specifies that the protocol types used by each address 
are displayed after that address when the table is displayed. Currently, 
ETHERMON can save up to 10 protocol types (Ethernet or IEEE 802.3 SNAP) per 
Ethernet address. The protocol type names (if any) from the protocol names 
table will be displayed after the physical numbers; preceding each 
protocol type number will be letters indicating direction of use ('s', 
'd', or 'b') and IEEE mode ('i' for IEEE 802.3 SNAP, '@ ' for Ethernet).
@Index(IEEE 802.3)

The /OUTPUT=filespec qualifier allows you to redirect the SHOW command's
display to a file instead of the user terminal. If the file specification 
is missing or incomplete, the name SYS$DISK:[]ETHERMON_ADDRESSES.LIS is 
used to supply any missing components.

The /PROTOCOL=@i<protocol> qualifier allows you to restrict address display to 
only those addresses that have used the protocol specified (using one of the
formats described in section @Ref[protocol]). By default, all addresses 
(subject to other restrictions) are displayed, regardless of protocol used. 
Note that there is no way to specify that the protocol is IEEE 
802.3 SNAP or plain-vanilla Ethernet; both kinds will be displayed if 
both kinds exist for a specified value.

The /TYPE=@i<value> qualifier allows you to specify that the listing 
should only include address table entries which have the specified 
attributes.The value can be:
@Begin(Enumerate)
a hexadecimal number in the form %X@i<nnnn>, where the numeric values 
correspond to the internal binary flag codes used in the address 
table (and seen as the M@i<xxxx>: number in SAVE/ADDRESS files);
@Index(SAVE)
@IndexSecondary(Primary="commands",Secondary="SAVE")

one or more symbolic names of the flag bits. if more than one name
is specified, the names must be separated by commas "," and the
entire list enclosed in parenthesis "()". The symbolic type names are 
(with their associated binary hex values):
@Begin(Itemize)
DECBRIDGE    (%X00080): identified as DEC LAN Bridge

DECNET       (%X00008): running DECnet protocols

DECSERVER    (%X00100): identified as DEC LAT terminal server

DESTINATION  (%X00004): node has been a destination

DNSSERVER    (%X10000): node is an Internet DNS server

IARP         (%X20000): node's IP address confirmed by ARP

INETGATEWAY  (%X08000): node is an Internet IP gateway/router

INETNAME     (%X00800): node has a symbolic Internet name defined

INTERNET     (%X00010): running DoD Internet IP protocols

LAVC         (%X00200): running DEC Local Area VAXcluster protocols

LINE2ADDR    (%X80000): displayed address is for 2nd port of two-port device

MACNUM       (%X02000): running AppleTalk protocols

MACZONE      (%X01000): identified as AppleTalk zone router

MOP          (%X04000): running DEC MOP protocols

OTHERADDR    (%X40000): node has two addresses because it is a two-port device

SOURCE       (%X00002): node has been a source

UB           (%X00020): node is running Ungermann-Bass protocols

VITALINK     (%X00400): identified as Vitalink bridge

XYPLEX       (%X00040): running Xyplex terminal net protocols
@End(Itemize)
@End(Enumerate)

Additional information will be displayed after the Ethernet physical address 
if such information has been collected on the node. Such information can 
include (depending on the protocols used by the node):
@Begin(Itemize)
the DECnet node name (as understood by the local VAX's DECnet volatile 
database); if the specified node number is not listed in the local DECnet 
volatile database, the node address in DECnet area.node format will be 
displayed instead.

the DoD Internet protocol address, in dotted numeric notation. If the 
LOAD/INTERNET command has been used, the node may also have a host name 
displayed in the format known to the local TCP/IP software (assuming that 
the IP address was added to the address table before the LOAD/INTERNET 
command was issued and that the local node has access to a name/address 
pair for the specified IP address). If the node also speaks the Routing 
Information Protocol or RIP (documented in NIC.DDN.MIL Request For Comments 
RFC:RFC1058.TXT), an asterisk (*) will be displayed before the host name or 
address to indicate that the node is apparently a router.
@Index(NIC.DDN.MIL)
@Index(RFC1058)
@IndexSecondary(Primary="protocol type",Secondary="RIP")

DEC interface characteristics (if the interface is of Digital Equipment 
Corporation manufacture or emulates such); this information is collected from 
the DEC MOP Remote Console protocol broadcasts (the System ID messages) made 
periodically by all DEC-compatible interfaces which announce the interface 
characteristics. Such entries are of the form 
@u[device-type:attribute;attribute...], where the @u[device-type] is either a 
DEC interface type (DEUNA, DEBNA, etc.) or @u[t=@i{xx}], where @i{xx} is a 
one-byte hexadecimal number representing a type code unknown to ETHERMON. 
The known type codes include:
@Begin(Enumerate)
'01'X: deuna (UNIBUS interface card)

'05'X: deqna (Q-BUS interface card)

'0B'X: delua (UNIBUS interface card)

'15'X: debet (DEC LAN Bridge 100)

'17'X: debna (BI interface card)

'21'X: lat?? (LAT terminal server)

'25'X: delqa (Q-BUS interface card)

'27'X: desva (VAXstation built-in interface)

'2B'X: PC??1

'2D'X: TrfMn (DECbridge running LAN Traffic Monitor??)

'35'X: NCDxt (X-terminal manufactured by NCD)

'3F'X: vx??1

'40'X: vx??2

'41'X: debni (BI interface card)

'42'X: demna

'4B'X: deqta (Q-BUS interface card)

'4C'X: db150 (DEC LAN Bridge 150, improved DEBET)

'72'X: vt1200 (DEC X-terminal)

'75'X: MacII (certain brand of Apple Macintosh Ethernet interface)

'79'X: CSrtr (multi-protocol bridge/router manufactured by cisco Systems, 
Inc.)
@End(Enumerate)
The attributes reported by a given node vary, but can include any of the 
following:
@IndexSecondary(Primary="protocol type",Secondary="MOP (60-02)")
@Begin(Enumerate)
f=@i{xx} - hexadecimal flags byte for the functions this interface can 
perform; bit values are:
@Begin(Enumerate)
bit 0: loop

bit 1: dump

bit 2: primary loader (can only load secondary loader)

bit 3: multi-block loader (can load tertiary loader or system)

bit 4: boot

bit 5: console carrier

bit 6: data link counters

bit 7: console carrier reservation
@End(Enumerate)

s=@i{x} - system processor type code

hw@i{aabbccddeeff} - hardware (ROM) Ethernet address of interface (if 
address has been changed by node's local software)

log@i{aabbccddeeff} - logical Ethernet address of interface (for 
interface's listing under ROM address)
@End(Enumerate)

the AppleTalk node number in the form @u[Mac@i{network}.@i{node}], where 
@i{network} is the AppleTalk Phase II network number (or zero if a Phase I 
node), and @i{node} is the node number within the logical network. If the 
node is also an AppleTalk router, the node's routing zone is appended after 
the network address in the form @u[rt@ @i{zone-name}].
@IndexSecondary(Primary="protocol type",Secondary="AppleTalk (80-9B)")

the Ungermann-Bass host serial number if the node speaks XNS and has an 
Ungermann-Bass manufacturer's prefix, in the form @u[#@i{nnnnn}], where 
@i{nnnnn} is the decimal serial number of the U-B device. The '#' may be 
prefixed by 'BRG' (if this node is the root bridge of the spanning tree) 
or 'tr' (if the node is on a Token Ring).
@Index(XNS)
@IndexSecondary(Primary="protocol type",Secondary="XNS (06-00)")

the Xyplex host serial number if the node speaks the Xyplex proprietary 
terminal network protocol and has a Xyplex manufacturer's prefix, in the 
form @u[unit@i{nnnnn}], where @i{nnnnn} is the decimal serial number of 
the Xyplex device.
@Index(Xyplex)
@IndexSecondary(Primary="protocol type",Secondary="Xyplex (08-88)")
@End(Itemize)
@SubSection(SHOW BRIDGES)
The SHOW BRIDGES command displays the addresses and symbolic 
identifications of all Ethernet devices tentatively identified as 
bridges. Optionally, it also displays a "best-approximation" 
overall bridge routing "map" as created by the MAP command.

Command format:
@IndexSecondary(Primary="commands",Secondary="SHOW BRIDGES")
@Index(SHOW BRIDGES)
@Index(bridge)
@Begin(InputExample)

SHOW BRIDGES [/FULL]
             [/MAP[=filespec]]
             [/OUTPUT[=filespec]]

@End(InputExample)

The /FULL qualifier specifies that the protocol types used by each bridge 
are displayed after that address when the table is displayed (currently, 
ETHERMON can save up to 10 protocol types {Ethernet or IEEE 802.3} per 
Ethernet address; the protocol type names {if any} from the protocol names 
table will be displayed after the physical numbers), along with any 
routing "map" information for each bridge that was computed by the last 
MAP command's execution.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")

The /OUTPUT=filespec qualifier allows you to redirect the SHOW command's
display to a file instead of the user terminal. If the file specification 
is missing or incomplete, the name SYS$DISK:[]ETHERMON_BRIDGES.LIS is 
used to supply any missing components.

The /MAP=filespec qualifier tells ETHERMON to generate a graphical sketch of 
the bridged Ethernet, instead of a tabular report. The plot is generated as a 
stand-alone portable Level 1 PostScript document. Due to limited information 
available from the bridges, the map is not guaranteed to be totally accurate; 
however, it is a good attempt. If the file specification is missing or 
incomplete, the name SYS$DISK:[]BRIDGE_MAP.PS is used to supply any missing 
components.
@Index(PostScript)
@SubSection(SHOW FILTERS)
The SHOW FILTERS command displays the current contents of the filter 
table, listing first the size filter thresholds and its enable/disable 
status. This is followed by all the currently defined filters, where 
each filter displays its index number, current enable/disable status, 
and the attributes it filters on, where Ethernet addresses and protocol 
types may be followed by their equivalence names (if any) from the 
address, manufacturer, and protocol tables.

Command format:
@Index(SHOW FILTERS)
@IndexSecondary(Primary="commands",Secondary="SHOW FILTERS")
@Index(filter)
@Begin(InputExample)

SHOW FILTERS

@End(InputExample)
@SubSection(SHOW KEY)
The SHOW KEY command displays the current key definitions as set up by the 
DEFINE/KEY command. All key definitions are displayed in the form of the 
DEFINE/KEY commands needed to re-create the definitions. Definitions that 
are "hard-wired" into ETHERMON have an asterisk (*) displayed before their 
DEFINE/KEY commands to indicate that these are non-redefineable keys.

Command format:
@Index(SHOW KEY)
@IndexSecondary(Primary="commands",Secondary="SHOW KEY")
@Begin(InputExample)

SHOW KEY

@End(InputExample)
@SubSection(SHOW MANUFACTUTERS)
The SHOW MANUFACTURERS command displays the current contents of the 
manufacturers' address prefix table on the user terminal, followed by 
the current table size. This includes all pre-defined "hardwired" names 
and all prefix codes automatically entered by the message analyzing logic. 
Manufacturer address prefixes which have been seen on the local Ethernet 
since starting ETHERMON will have a letter displayed in front of the address 
prefix; the letter will be a "s" (for source only),
"d" (for destination only), or "b" (used both as source and destination).

Command format:
@IndexSecondary(Primary="commands",Secondary="SHOW MANUFACTURERS")
@Index(SHOW MANUFACTURERS)
@Index(manufacturer prefix)
@Begin(InputExample)

SHOW MANUFACTURERS [/ALL]
                   [/OUTPUT=filespec]

@End(InputExample)
Note that, unless the /ALL qualifier is specified, only manufacturer prefix 
codes that have actually been seen on the Ethernet since ETHERMON 
was started will actually be displayed.

The /ALL qualifier specifies that all manufacturer codes, not just active 
ones, will be displayed.

The /OUTPUT=filespec qualifier allows you to redirect the SHOW command's
display to a file instead of the user terminal. If the file specification 
is missing or incomplete, the name SYS$DISK:[]ETHERMON_MANUFACTURERS.LIS is 
used to supply any missing components.
@SubSection(SHOW MESSAGES)
The SHOW MESSAGES command displays the current settings of the SET MESSAGES 
command for enabling or disabling output of asynchronous "significant event" 
messages to the user terminal.

Command format:
@Index(SHOW MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SHOW MESSAGES")
@Begin(InputExample)

SHOW MESSAGES

@End(InputExample)
@SubSection(SHOW PORT_STATUS)
The SHOW PORT_STATUS command displays the current Ethernet port's 
current status. Some of the status is global for the entire interface, 
where other status is peculiar to ETHERMON's connection to the 
interface. For more information, see the @i<@u[VMS I/O User's 
Reference Manual: Part II]> (the chapter on Ethernet interfaces) for 
information about the IO$_SENSEMODE function's extended characteristics 
buffer, and the @i<@u[VMS Network Control Program Manual]> for 
information about line counters.

Command format:
@Index(SHOW PORT_STATUS)
@IndexSecondary(Primary="commands",Secondary="SHOW PORT_STATUS")
@Index(NCP)
@Begin(InputExample)

SHOW PORT_STATUS [/ZERO]

@End(InputExample)
where /ZERO can be optionally specified to zero the interface's counters 
after displaying the old data (similar to the DECnet NCP command ZERO 
LINE COUNTERS). Note that some port parameters may show up as question 
marks, i.e. @i[???]; this implies that those parameters are not returned by 
the type of interface being used.
@SubSection(SHOW PROTOCOL_NAMES)
The SHOW PROTOCOL_NAMES command displays the current contents of the 
protocol table on the user terminal, followed by the current table 
size. This includes all pre-defined "hardwired" names, all names 
manually entered with the SET PROTOCOL_NAME command, and all protocol
types actually seen on the Ethernet since ETHERMON was started. Protocol types 
which have been seen on the local Ethernet since ETHERMON was started will have 
an asterisk (*) displayed in front of the protocol type number.

Command format:
@Index(SHOW PROTOCOL_NAMES)
@IndexSecondary(Primary="commands",Secondary="SHOW PROTOCOL_NAMES")
@Begin(InputExample)

SHOW PROTOCOL_NAMES [/ALL]
                    [/OUTPUT=filespec]

@End(InputExample)
Note that, unless the /ALL qualifier is specified, only 
protocol types that have actually been seen on the Ethernet since ETHERMON 
was started will actually be displayed.

The /ALL qualifier specifies that all protocol types, not just active 
ones, will be displayed.

The /OUTPUT=filespec qualifier allows you to redirect the SHOW command's
display to a file instead of the user terminal. If the file specification 
is missing or incomplete, the name SYS$DISK:[]ETHERMON_PROTOCOLS.LIS is 
used to supply any missing components.
@SubSection(SPAWN)
The SPAWN command spins off a DCL subprocess, either executing a single 
command or beginning DCL prompting. While the subprocess is SPAWN'ed, 
ETHERMON continues to record address, manufacturer, and protocol type 
information in its tables, and any active asynchronous TRACE command continues 
to collect data.
@Index(TRACE)
@IndexSecondary(Primary="commands",Secondary="TRACE")

Command format:
@Index(SPAWN)
@IndexSecondary(Primary="commands",Secondary="SPAWN")
@Begin(InputExample)

SPAWN [@i<DCL-command-string>]

@End(InputExample)
Note that this command functions similarly to the DCL SPAWN command, but 
with fewer options. Also, you must have sufficient PRCLM and other 
quotas to SPAWN a subprocess while ETHERMON is consuming most of your 
available BYTLM resources; ETHERMON computes how much BYTLM it must leave 
unused to guarantee that one minimal-quota SPAWNed subprocess and one 
TRACE/ANALYZER command may be succesfully created, but it does not check 
other quotas.
@IndexSecondary(Primary="quotas",Secondary="BYTLM")
@IndexSecondary(Primary="quotas",Secondary="PRCLM")
@SubSection(SUMMARIZE DESTINATIONS)
The SUMMARIZE DESTINATIONS command collects data over a specified time 
period, then generates a report of counts of messages sent to 
destinations, sorted by descending quantity of messages.

Command format:
@Index(SUMMARIZE DESTINATIONS)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE DESTINATIONS")
@Begin(InputExample)

SUMMARIZE DESTINATIONS [/INTERVAL=deltatime]
                       [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.

Only messages passing the currently enabled filters are counted in the 
summation. The output report is printed to the user terminal; after the 
report header, each line of data gives the number of messages received, 
the physical Ethernet address they were sent to, and any equivalence 
names known for the address.
@SubSection(SUMMARIZE INTERNET)
The SUMMARIZE INTERNET command collects data over a specified time 
period, then generates a report of counts of Internet messages sent 
under different second level Internet protocols (such as TCP, UDP, 
etc.), sorted by descending quantity of messages.

Command format:
@Index(SUMMARIZE INTERNET)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE INTERNET")
@Index(Internet)
@Begin(InputExample)

SUMMARIZE INTERNET [/INTERVAL=deltatime]
                   [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.

Only messages passing the currently enabled filters are counted in the 
summation; an additional filter is automatically defined and enabled for 
the duration of the command to ensure that only messages under 
protocol type 08-00 (DoD Internet IP) are processed. The output report is 
printed to the user terminal; after the 
report header, each line of data gives the number of messages received, 
the second level protocol number, and the mnemonic name of the second 
level protocol (per NIC.DDN.MIL Request For Comments RFC:RFC1060.TXT).
For the TCP (6) and UDP (17) second-level protocols, counts on a 
per-port basis are also kept.
@Index(NIC.DDN.MIL)
@Index(RFC1060)
@IndexSecondary(Primary="protocol type",Secondary="TCP")
@IndexSecondary(Primary="protocol type",Secondary="UDP")
@SubSection(SUMMARIZE PROTOCOLS)
The SUMMARIZE PROTOCOLS command collects data over a specified time 
period, then generates a report of counts of messages sent under 
different protocol types, sorted by descending quantity of messages.

Command format:
@Index(SUMMARIZE PROTOCOLS)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE PROTOCOLS")
@Begin(InputExample)

SUMMARIZE PROTOCOLS [/INTERVAL=deltatime]
                    [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.

Only messages passing the currently enabled filters are counted in the 
summation. The output report is printed to the user terminal; after the 
report header, each line of data gives the number of messages received, 
the physical Ethernet protocol type code they were sent under, and any 
equivalence name known for the protocol type.
@SubSection(SUMMARIZE SIZES)
The SUMMARIZE SIZES command collects data over a specified time 
period, then generates a report of counts of messages of various size 
categories, sorted by descending quantity of messages.

Command format:
@Index(SUMMARIZE SIZES)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE SIZES")
@Begin(InputExample)

SUMMARIZE SIZES [/INTERVAL=deltatime]
                [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.

Only messages passing the currently enabled filters are counted in the 
summation. The output report is printed to the user terminal; after the 
report header, each line of data gives the number of messages received 
and the message size range the messages were in.
@SubSection(SUMMARIZE SOURCES)
The SUMMARIZE SOURCES command collects data over a specified time 
period, then generates a report of counts of messages sent from
sources, sorted by descending quantity of messages.

Command format:
@Index(SUMMARIZE SOURCES)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE SOURCES")
@Begin(InputExample)

SUMMARIZE SOURCES [/INTERVAL=deltatime]
                  [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.

Only messages passing the currently enabled filters are counted in the 
summation. The output report is printed to the user terminal; after the 
report header, each line of data gives the number of messages received, 
the physical Ethernet address they were sent from, and any equivalence 
names known for the address.
@SubSection(SUMMARIZE STATISTICS)
The SUMMARIZE STATISTICS command collects data over a specified time 
period, then generates a report of Ethernet port counter value changes.

Command format:
@Index(SUMMARIZE STATISTICS)
@IndexSecondary(Primary="commands",Secondary="SUMMARIZE STATISTICS")
@Begin(InputExample)

SUMMARIZE STATISTICS [/INTERVAL=deltatime]
                     [/OUTPUT[=file]]

@End(InputExample)
where /INTERVAL specifies a standard VMS @i<deltatime> value (without 
enclosing double quotes, and without a day count); if /INTERVAL is not 
specified, the current SET INTERVAL value is used as the sample period 
length. @IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)

The /OUTPUT=filespec qualifier allows you to redirect the 
SUMMARIZE command's display to a file instead of the user terminal. 
If the file specification is missing or incomplete, the name 
SYS$DISK:[]ETHERMON.SUM is used to supply any missing components.
@SubSection(TRACE)
The TRACE command collects Ethernet messages after filtering and writes them 
to a disk file for offline processing by another program. The messages 
can be recorded in either ASCII or binary form.

Command format:
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@Begin(InputExample)

TRACE [/ASCII] [/BINARY] [/SNIFFER] [/ANALYZER=imagename]
      [/INTERVAL=deltatime]
      [/OUTPUT=outfilespec]
      [/PARALLEL]
      [/REPEAT[=@i<n>]]
      [/[NO]STATISTICS]
      [/TRUNCATE=@i<m>]

TRACE /ABORT

@End(InputExample)
where only one of /ASCII, /BINARY, /SNIFFER, or /ANALYZER may be specified (if 
none of them is specified, /BINARY is the default). /INTERVAL specifies a 
standard VMS @i<deltatime> value (without enclosing double quotes, and without 
a day count); if /INTERVAL is not specified, the current SET INTERVAL 
value is used as the sample period length. 
@IndexSecondary(Primary="commands",Secondary="SET INTERVAL")
@Index(SET INTERVAL)
/OUTPUT specifies the 
output file name (if file specification is incomplete or qualifier is 
missing, the default is SYS$DISK:[]ETHERMON.DAT for binary mode,
SYS$DISK:[]ETHERMON.LIS for ASCII mode, SYS$DISK:[]ETHERMON.SNIFFER for 
Sniffer mode, and SYS$OUTPUT: for analyzer mode). The /PARALLEL qualifier 
specifies that recording should go on in the background, leaving the 
terminal free to execute other ETHERMON commands. The /REPEAT[=n] 
qualifier also specifies background recording, but specifies that after 
each interval, the recording file should be closed and a new version 
opened, keeping the recording running forever or until aborted 
(whichever comes first); to prevent running out of disk space, the 
optional @i<n> is used to specify a maximum version count allowed for 
the recording files (automatic file purging is done when more than @i<n> 
files are collected). Note that the /REPEAT qualifier is ignored if 
/ANALYZER is specified (only one analyzer session will be done). The 
/[NO]STATISTICS qualifier is used to override the 
default choice of reporting TRACEd packet statistics; by default, 
statistics are reported at the end of a synchronous (non-/PARALLEL) TRACE 
command, and are not at the end of a /PARALLEL or /REPEAT command's 
background execution. /TRUNCATE=@i<m> allows recording only the first @i<m> 
bytes of each packet in a binary or Sniffer-format recording file; by 
default, all bytes are recorded, and there is no choice for ASCII files 
(the 40 bytes that are reported are fewer than the minimum physical packet 
length anyway). It is strongly recommended that records not be truncated to 
shorter than the length of an IEEE 802.3 SNAP header (22 bytes), as there 
would not be enough information left in the file's records to be able to 
decipher the data.

The TRACE/ABORT command is used to cleanly shut down a TRACE/PARALLEL or 
TRACE/REPEAT command; it specifies that the currently open file should 
be closed immediately and all tracing should cease. Note that an asynchronous 
TRACE will also be terminated if ETHERMON is exited; parallel TRACEing 
does NOT spin off a background batch job or subprocess to do the parallel 
monitoring, but just saves the data directly from the data collection AST.
Also, you cannot perform a foreground TRACE and a background TRACE at the 
same time. The /[NO]STATISTICS qualifier may be used on the TRACE/ABORT 
command to override the reporting choice made when the asynchronous TRACE 
session was started.

Several unsupported utilities are supplied to help analyze binary TRACE 
file recordings, and may be used as a template for your own expanded 
offline message analysis tools. Some of these may also be used as analyzer 
modules with the /ANALYZER qualifier. For more information on these 
utilities, see section @Ref[Utilities] of this document.

For ASCII mode, the output file contains three lines for each received 
and filter-passed Ethernet message. The first line contains the VMS timestamp 
when the message was received, the source and destination addresses in standard
Xerox ASCII-hexadecimal format, the protocol type (also ASCII-hex), and the
message body's length in bytes. The second line is a hexadecimal dump of
the first 40 bytes of the received message; the third line is the same
40 bytes dumped in ASCII (with a space before each actual character, such
that the ASCII characters line up under their hexadecimal bytes; periods
are displayed for unprintable characters). Preceding the dump lines is a 
single line reporting when the dump began; following the dump lines are 
three lines reporting when the dump was completed, and the quantity of data 
bytes and messages processed from the Ethernet before and after filtering.
The file has carriage-return carriage control and variable-length records. 
A typical ASCII recording file looks like this:
@Begin(OutputExample)
  Ethernet TRACE: starting data collection at 21-JUN-1991 09:28:54.22
21-JUN-1991 09:28:54.29 s:AA-00-04-00-CA-28 d:AA-00-04-00-D1-28 p:60-07    46
1400AA000400D1280500AA000400CA280800AA340000000000000000000000000000000000000000
 . . * . . . Q ( . . * . . . J ( . . * 4 . . . . . . . . . . . . . . . . . . . .
21-JUN-1991 09:28:54.40 s:08-00-7C-00-30-26 d:09-00-2B-01-00-01 p:80-38    46
E1190100003108007C003B7101DE007F08007C0030260101050F1E0F3004000081000100000D7465
 a . . . . 1 . . | . ; q . ^ . . . . | . 0 & . . . . . . 0 . . . . . . . . . t e
21-JUN-1991 09:28:54.43 s:00-DD-01-02-96-2C d:08-00-2B-10-1A-E5 p:06-00    46
FFFF002A00050000000108002B101AE5872C0000000100DD0102962C8713C000075EC05F0039010F
 . . . * . . . . . . . . + . . e . , . . . . . ] . . . , . . @ . . ^ @ _ . 9 . .
21-JUN-1991 09:28:54.44 s:00-DD-01-0A-12-A8 d:FF-FF-FF-FF-FF-FF p:06-00    70
FFFF0046000400000000FFFFFFFFFFFF80010000000100DD010A12A8802000000000000100000000
 . . . F . . . . . . . . . . . . . . . . . . . ] . . . ( .   . . . . . . . . . .
21-JUN-1991 09:28:54.47 s:AA-00-04-00-D8-28 d:AB-00-00-03-00-00 p:60-03    46
22000D020000AA000400D82803DA05000000000000000000AA00040063280F000002AAAA00000000
 " . . . . . * . . . X ( . Z . . . . . . . . . . * . . . c ( . . . . * * . . . .
21-JUN-1991 09:28:54.48 s:00-DD-01-08-50-A2 d:AA-00-04-00-3D-30 p:80-9Bi   17
0011000013601360C7A60606060101835B
 . . . . . ` . ` G & . . . . . . [
21-JUN-1991 09:28:54.48 s:00-DD-01-08-50-A2 d:AA-00-04-00-3D-30 p:80-9Bi   17
0011000013601360C7A60606060101EB62
 . . . . . ` . ` G & . . . . . k b

                            .
                            .
                            .

21-JUN-1991 09:28:57.26 s:AA-00-04-00-F5-28 d:AA-00-04-00-CE-28 p:60-07    87
5500AA000400CE280500AA000400F5280B00D2BDF3BD023E0004000A0001003000966A0900D3670E
 U . * . . . N ( . . * . . . u ( . . R = s = . > . . . . . . . 0 . . j . . S g .
  Ethernet TRACE: ending data collection at 21-JUN-1991 09:28:57.27
         15805 bytes,  234 messages analyzed
         15805 bytes,  234 messages received before filtering
@End(OutputExample)

For binary mode, the file contains one variable-length record per received and
filter-passed Ethernet message. A set of structure definitions of the 
records for various programming languages are listed below. The FORTRAN 
version of this structure definition is supplied in the file ETHTRSTRUC.INC.

FORTRAN:
@Begin(OutputExample)
      STRUCTURE /BIN_REC/
	INTEGER*4 VMS_DATETIME(2) ! quadword system timestamp
        UNION
	  MAP
	    BYTE      DSTADDR(0:5) ! beginning of XEDRIVER P5 buffer: dest addr
	    BYTE      SRCADDR(0:5) ! source Ethernet address
	  END MAP
	  MAP
	    INTEGER*2 W_DSTADDR(0:2)
	    INTEGER*2 W_SRCADDR(0:2)
	  END MAP
	  MAP
	    INTEGER*4 L_DSTADDR
	    INTEGER*2 W_DSTADDR4
	    INTEGER*4 L_SRCADDR
	    INTEGER*2 W_SRCADDR4
	  END MAP
	END UNION
	UNION
	  MAP
	    CHARACTER*8 PROTBUF
	  END MAP
	  MAP
	    BYTE    PROTOCOL(0:1) ! Ethernet protocol type
	  END MAP
	  MAP
	    INTEGER*2 W_PROTOCOL
	  END MAP
	  MAP
	    BYTE    DSAP        ! IEEE 802 destination SAP
	    BYTE    SSAP        ! IEEE 802 source SAP
	    UNION
	      MAP
		BYTE  CTL(0:1)  ! IEEE 802 CTL byte(s)
	      END MAP
	      MAP
		BYTE  ECTL      ! IEEE extended 802 CTL byte
		BYTE  PID(0:4)  ! IEEE extended 802 Protocol IDentification
	      END MAP
	    END UNION
	  END MAP
	END UNION               ! end of XEDRIVER P5 buffer (20 bytes)
	INTEGER*2 LENGTH        ! length of message body
	UNION
	  MAP
	    BYTE      BODY(4470)! not all of this array may be sent; only
          END MAP               ! part actually used is written to file
	  MAP
	    CHARACTER*4470 CBODY
	  END MAP
	END UNION
      END STRUCTURE ! /BIN_REC/
@End(OutputExample)

MACRO:
@Begin(OutputExample)
        $DEFINI REC
$EQU    REC$Q_TIME      0    ; VAX/VMS binary timestamp
$EQU    REC$B_DESTADDR  8    ; 6-byte destination address
$EQU    REC$B_SRCADDR   14   ; 6-byte source address
$EQU    REC$B_PROTOCOL  20   ; 2-byte Ethernet protocol type
$EQU    REC$B_DSAP      20   ; 1-byte IEEE 802 DSAP
$EQU    REC$B_SSAP      21   ; 1-byte IEEE 802 SSAP
$EQU    REC$B_CTL       22   ; 1- or 2-byte IEEE 802 CTL field
$EQU    REC$B_ECTL      22   ; 1-byte IEEE extended 802 CTL field
$EQU    REC$B_PID       23   ; 5-byte IEEE extended 802 protocol ID
$EQU    REC$W_LENGTH    28   ; word length of message body
$EQU    REC$T_BODY      30   ; body of message
$EQU    REC$K_MAXLEN    4500 ; maximum length of file record
        $DEFEND REC
@End(OutputExample)

Note that the above file record format definitions assume a fixed size of 
the protocol type field; if the protocol field of a particular Ethernet 
packet is shorter than the maximum size, the field is padded out with zero 
bytes. Also, the network CRC field is not recorded, nor is the length field 
in the header of an IEEE 802.3 packet, nor the padding to minimum legal 
packet length of an IEEE 802.3 packet with less than the minimum number of 
actual data body bytes. Therefore, the records in a binary-format file are NOT 
in the same format as they were as network packets.

To get a closer approximation of the actual network packet format, the 
Sniffer format can be used. It is also a binary file format, but contains 
ONLY the used header fields (including length if IEEE 802.3, unlike the 
binary format) and the message body; unused header fields, the CRC, and 
IEEE 802.3 padding are not stored in the file's records. No timestamps are 
recorded in a Sniffer-format file.

All the unsupported utilities delivered with ETHERMON (described in section 
@Ref[Utilities]) expect to read binary format files (not Sniffer format).

To analyze data in real-time in greater detail than TRACE/ASCII is capable 
of doing, or to provide additional filtering capabilities beyond the 
existing filtering logic in ETHERMON, the /ANALYZER qualifier may be used 
to spin off a subprocess that will be fed the recorded data in real-time. 
The subprocess is created with the following environment:
@Begin(Itemize)
SYS$INPUT is a VMS temporary mailbox with no logical name, specified by 
physical device name; this mailbox is written with network packet 
data in the binary file format, and is written with an end-of-file when the 
TRACE terminates (either due to timeout or a TRACE/ABORT command); the 
mailbox is written with resource wait mode disabled, so if the mailbox 
overflows, the main ETHERMON process will not be suspended, but some data 
will be lost (a count will be kept of SS$_MBFULL errors)
@Index(mailbox)

SYS$OUTPUT defaults to the SYS$OUTPUT file of the process running ETHERMON, 
but may be redirected with the /OUTPUT qualifier on the TRACE command; 
interpretation of this file specification is done by the selected analyzer 
module

SYS$ERROR is the ETHERMON process's SYS$ERROR

default disk and directory is the same as the process running ETHERMON

base priority is the base priority of the ETHERMON process

privileges are those of the ETHERMON process (including those automatically 
enabled by ETHERMON)

no CLI is present; the subprocess is created by SYS$CREPRC, not by 
LIB$SPAWN

all quotas are set to system defaults (see the @i<@u[VMS System Services 
Reference Manual]> for details on subprocess quota allocations)

process name is the ETHERMON process's process name, prefixed with the 
string 'Eanl_' (truncated to fit in 15 characters)

a termination mailbox is defined, and will be used to keep track of the 
subprocess even after the SYS$INPUT mailbox is closed and deleted

image dumping is enabled

the image file being run must be a .EXE file in the ETHERMON executable 
image's directory, with the filename being the name specified on the 
/ANALYZER=@i<imagefile> qualifier
@End(Itemize)

You must have sufficient PRCLM and other 
quotas to create a subprocess while ETHERMON is consuming most of your 
available BYTLM resources; ETHERMON computes how much BYTLM it must leave 
unused to guarantee that one minimal-quota SPAWNed subprocess and one 
TRACE/ANALYZER command may be succesfully created, but it does not check 
other quotas.
@IndexSecondary(Primary="quotas",Secondary="BYTLM")
@IndexSecondary(Primary="quotas",Secondary="PRCLM")

No additional parameters may be passed to the subprocess by this command 
(although the analyzer module could examine shareable logical name tables 
for information). The analyzer module may do anything it wishes with the 
data it receives from the mailbox.

Only one analyzer module may execute at a time; even if an analyzer module 
has had its input data stream terminated, the image will be allowed to run 
to its chosen completion (allowing post-processing of the data as it sees 
fit). As such, another TRACE/ANALYZER command may not be issued until the 
previous subprocess has terminated; if the previous 
subprocess is still running, the TRACE/ANALYZER command 
will be rejected. If an analyzer module terminates 
pre-maturely, the TRACE command (synchronous or asynchronous) will be 
aborted with a message reporting that the analyzer image died.
@SubSection(WAIT)
The WAIT command allows suspending command execution of ETHERMON while 
maintaining data collection. This is primarily useful for batch 
monitoring jobs which want to use the TRACE/REPEAT command, but don't 
want ETHERMON to exit after initiating data collection.
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)

Command format:
@IndexSecondary(Primary="commands",Secondary="WAIT")
@Index(WAIT)
@Index(batch mode)
@Begin(InputExample)

WAIT hh:mm:ss.cc [message]

WAIT FOREVER [message]

@End(InputExample)
where @i<hh:mm:ss.cc> is a standard VMS delta time (without a days 
value), and FOREVER means wait until external events continue execution 
(no timer is started to end a FOREVER wait). The optional @i<message>
is a string of text which will be displayed on the
standard output device (terminal or batch log file) before the WAIT
begins. This is useful for ETHERMON indirect command files, where the commands
being executed cannot be seen by the user.

Since the WAIT command suspends execution in a main-level user-mode 
$HIBERnate, data collection continues.
The WAIT can be terminated before its specified end time by entering
any keyboard character (for interactive mode use) or by issuing
a $WAKE service request at the process running ETHERMON (given appropriate
access privileges). A message will be output indicating how the WAIT 
was aborted.

A sample DCL command procedure, ETHERMON_ALL.COM, is supplied as an 
example of how to use the WAIT and TRACE/REPEAT commands to create a 
24-hour-a-day network monitor. The sanple looks like this:
@Begin(ProgramExample)
$ ETHERMON :== $'F$ENV("DEFAULT")'ETHERMON
$ ETHERMON ETA		! assuming a DEBNA or DEBNI on the system
SET MESSAGES OFF
WAIT 00:00:10 "Wait for address table to fill"
ADD FILTER/ONLY=(ADDRESS=C5VR,PROTOCOL=08-00)
TRACE/REPEAT=20/INTERVAL=00:05:00/BINARY/OUTPUT=C5VR
WAIT FOREVER "Now collecting IP data from NFS Server node..."
@End(ProgramExample)
@Label[WAITdemo]
where this particular application first waits for the address table to 
be populated (the first WAIT command), then defines a filter to monitor 
the Internet IP traffic in and out of the DECnet node named C5VR, then 
starts a repeating asynchronous TRACE command that collects a series of 
files (each covering a 5 minute interval) for a total holding period of 
1 hour 40 minutes. It then WAITs FOREVER (so as to maintain the 100 
minute sliding window of collected data indefinitely).
@Chapter(Utilities)
@Label(Utilities)
Seven offline analysis utilities are supplied with ETHERMON for use in 
deciphering binary TRACE files. These are:
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(TRACE)
@IndexSecondary(Primary="TRACE",Secondary="file")
@Begin(Enumerate)
ETHERPARSE - the first attempt at an analysis tool

ETHERPARSE2 - a fancier version of ETHERPARSE; it can decipher 
AppleTalk packet headers, Internet IP, TCP, UDP, RIP, RPC, NFS, RPC 
portmapper, and SNMP headers,
XNS packet headers, DEC LAN Bridge packets, and ARP/RARP packets. This 
program may be used for a TRACE/ANALYZER subprocess.

ETHERPARSE_TCP - a specialized parser, it matches up packets from TCP 
sessions, using remote/local host-address/port-number to uniquely identify 
sessions, and reports on the status of the session flow control counters
(SEQ and ACK, from the RFC793 specification of the TCP protocol) for each 
session.

ETHERPARSE_XREF - a specialized parser, it matches up source and 
destination hosts, and counts the number of packets sent by each 
combination, then reports a list of such pairs sorted as to most active 
pairs. Very slow program!

ETHFILT_ETHADDR - a secondary filter to help fine-tune the results of a 
SET FILTER command in ETHERMON; it selects only records from a recording 
file that contain the user-supplied Ethernet address and copies 
them to another file.

ETHFILT_IPADDR - another secondary filter to help fine-tune the results of a 
SET FILTER command in ETHERMON; it selects only records from a recording 
file that contain the user-supplied DoD Internet IP address and copies 
them to another file.

ETHFILT_NFS - yet another secondary filter; it passes only records that 
are speaking DoD Internet IP, and furthermore are speaking Sun 
Microsystems' Network File System (NFS) protocol.
@End(Enumerate)

There are also two support subroutines which are available to help programs 
connect up with ETHERMON as TRACE/ANALYZER subprocesses. These are:
@Begin(Enumerate)
ETH_CHECK_SUBPROC - this subroutine accepts a dummy argument (it ignores 
it, but the variable is required for FORTRAN syntax), and returns a 
LOGICAL*1 value indicating whether or not the calling program is in a 
CLI-less subprocess (.TRUE. if environment appears to be a TRACE/ANALYZER 
subprocess).
@IndexSecondary(Primary="TRACE",Secondary="/ANALYZER")

ETH_MAP_ADDRTBL - this subroutine does everything that ETH_CHECK_SUBPROC 
does, but then attempts to map the enclosing ETHERMON's address table 
COMMON global section into this process's address space; the procedure accepts 
a LOGICAL*1 argument that is .TRUE. if the subprocess wants read/write 
access to the table, and .FALSE. if read-only access is desired. The 
procedure returns a LOGICAL*1 value indicating whether or not the calling 
program is in a CLI-less subprocess (.TRUE. if environment appears to be a 
TRACE/ANALYZER subprocess). It signals a fatal error if everything was OK 
except that the global section was not properly aligned in memory (a 
COLLECT= linker option was not used to put the /ADDRESS_NAMES/ COMMON in a 
separate cluster of linker-allocated address space).
@IndexSecondary(Primary="TRACE",Secondary="/ANALYZER")
@End(Enumerate)

@Section(ETHERPARSE)
ETHERPARSE's source files consist of a single FORTRAN file 
ETHERPARSE.FOR. This program will prompt for the name of a TRACE binary 
recording file (default file type .DAT), the name of an output listing 
file (default file type .LIS), and the optional start and end times of 
the data to select (if not supplied, all data in the file is accepted; 
if supplied, they must be valid VAX/VMS absolute times). Very little 
error checking is done; if an invalid input file is supplied, the 
program will crash sloppily.
@Index(ETHERPARSE)
@IndexSecondary(Primary="Utilities",Secondary="ETHERPARSE")

The output file contains a series of formatted packets, where each 
packet is begun with a blank line and a line containing the packet 
time, source address, destination address, protocol type (with an 'i' 
suffix if IEEE 802.3 SNAP protocol), and the packet length in bytes.
After this, there are lines of hexadecimal and ASCII representation of 
the packet data (16 bytes per line), with the hex data going 
right-to-left, and the ASCII data going left-to-right (with periods 
representing unprintable characters); each line is ended with a 
four-hex-digit number giving the offset of this line from the 
beginning of the data link's data field of the packet. At the end of 
the report is a list of packet counts for source addresses, 
destination addresses, and protocol types; the left count is the total 
for the entire file, and second column is the count within the 
specified time window (identical if no time limits were given).

@Section(ETHERPARSE2)
ETHERPARSE2's source files consist of a FORTRAN file 
ETHERPARSE2.FOR, and a MACRO source file ETHERPARSE2_CRF.MAR. Its user 
interface is identical to ETHERPARSE, with the exception of one 
additional query: does the user want all of each packet dumped in 
ASCII and hexadecimal, even if part of the packet was also dumped 
symbolically (by default, any data dumped symbolically is skipped over 
in generating the ASCII/hex dump).
@Index(ETHERPARSE2)
@IndexSecondary(Primary="Utilities",Secondary="ETHERPARSE2")
Note that, to link ETHERPARSE2, you must use a LINK command of the form:
@Begin(InputExample)

$ @b<LINK ETHERPARSE2,ETHERPARSE2_CRF,ETH_MAP_ADDRTBL,SYS$INPUT:/OPT>
@b<COLLECT=ADDRESS_NAMES,ADDRESS_NAMES>
@i[<ctl-Z>]

@End(InputExample)

The additional processing that ETHERPARSE2 supplies consists of:
@Begin(Enumerate)
decoding the LLP prefixes of AppleTalk packets, the DDP packet header, 
and (when valid) the NBP packet body.
@IndexSecondary(Primary="protocol type",Secondary="AppleTalk (80-9B)")
@IndexSecondary(Primary="AppleTalk",Secondary="DDP")
@IndexSecondary(Primary="AppleTalk",Secondary="NBP")

decoding ARP messages (IP ARP, IP RARP, and AppleTalk ARP)
@IndexSecondary(Primary="protocol type",Secondary="ARP (08-06)")
@IndexSecondary(Primary="protocol type",Secondary="RARP (80-35)")
@IndexSecondary(Primary="protocol type",Secondary="AARP (80-F3)")

decoding some forms of DEC LAN Bridge control messages
@IndexSecondary(Primary="protocol type",Secondary="LAN Bridge (80-38)")

decoding XNS network level packet headers
@Index(XNS)
@IndexSecondary(Primary="protocol type",Secondary="XNS (06-00)")

decoding DoD Internet message headers: IP (RFC 791, always), TCP and UDP 
(RFC's 793 and 768, when protocol type is one of these and not a 
continuation IP packet), ICMP (RFC 792, when protocol type is this), RIP 
(Routing Information Protocol, RFC 1058, when valid UDP and port number is 
520), RPC (Sun Remote Procedure Call, RFC 1057; when valid after either 
a TCP or UDP header), Sun NFS (Network File System, RFC 1094, after valid 
UDP and RPC headers that specify NFS), RPC portmapper (RFC 1057, after 
valid TCP or UDP headers), and SNMP (Simple Network Management Protocol, 
RFC 1157, after valid UDP header)
@IndexSecondary(Primary="protocol type",Secondary="IP (08-00)")
@IndexSecondary(Primary="protocol type",Secondary="ICMP")
@Index(NFS)
@IndexSecondary(Primary="protocol type",Secondary="NFS")
@IndexSecondary(Primary="protocol type",Secondary="RIP")
@IndexSecondary(Primary="protocol type",Secondary="RPC")
@IndexSecondary(Primary="protocol type",Secondary="RPC portmapper")
@IndexSecondary(Primary="protocol type",Secondary="SNMP")
@IndexSecondary(Primary="protocol type",Secondary="TCP")
@IndexSecondary(Primary="protocol type",Secondary="UDP")
@Index(RFC768)
@Index(RFC791)
@Index(RFC792)
@Index(RFC793)
@Index(RFC1057)
@Index(RFC1058)
@Index(RFC1094)
@Index(RFC1157)
@End(Enumerate)

Additional reports generated at the end of the formatted listing 
include any of the following items that had their type of data 
collected in the data file:
@Begin(Enumerate)
cross-reference of XNS socket usage by Ethernet addresses (flagged as 
source or destination users)
@Index(XNS)
@IndexSecondary(Primary="protocol type",Secondary="XNS (06-00)")

per-Ethernet address client usage of NFS service calls, listing the names of 
the procedures called, and counts for each procedure for number of 
calls, number of identified successful replies, and number of identified 
erroneous replies.
@Index(NFS)
@IndexSecondary(Primary="protocol type",Secondary="NFS")
@End(Enumerate)

ETHERPARSE2 may be used as a TRACE/ANALYZER subprocess.
@IndexSecondary(Primary="TRACE",Secondary="/ANALYZER")

@Section(ETHERPARSE_TCP)
ETHERPARSE_TCP's source files consist of a single FORTRAN file 
ETHERPARSE_TCP.FOR. This program will prompt for the name of a TRACE binary 
recording file (default file type .DAT) and the name of an output listing 
file (default file type .LIS). Very little 
error checking is done; if an invalid input file is supplied, the 
program will crash sloppily.
@Index(ETHERPARSE_TCP)
@IndexSecondary(Primary="Utilities",Secondary="ETHERPARSE_TCP")

The output file contains a series of formatted packets, where each 
packet is displayed on a single line containing the packet 
time, source IP address and TCP port, destination IP address and TCP port, 
sequence number (with computed error flags), acknowledge number (with 
computed error flags), window size value, and any additional flags from the 
TCP header (URG, FIN, PSH, etc.). This processes the TCP header according 
to the documentation in RFC793. At the end of the report, a summary of 
packets processed and packets discarded as not being TCP/IP is printed.
@IndexSecondary(Primary="protocol type",Secondary="TCP")
@Index(RFC793)

@Section(ETHERPARSE_XREF)
ETHERPARSE_XREF's source files consist of a single FORTRAN file 
ETHERPARSE_XREF.FOR. This program will prompt for the name of a TRACE binary 
recording file (default file type .DAT), the name of an output listing 
file (default file type .LIS). Very little 
error checking is done; if an invalid input file is supplied, the 
program will crash sloppily.
@Index(ETHERPARSE_XREF)
@IndexSecondary(Primary="Utilities",Secondary="ETHERPARSE_XREF")

The output file contains a list of packet counts for source addresses, 
destination addresses, and protocol types. Following this list is one more 
list of matched pairs of source and destination addresses (displayed in 
Ethernet physical format and Internet IP [if valid] with packet counts.
All lists (except the protocol list) are sorted in descending order of 
number of packets.

This program was written rather inefficiently with regard to both CPU time 
and virtual memory consumption; do not expect quick response from it if a 
large number of different combinations are present in your data sample.

@Section(ETHFILT_ETHADDR)
ETHFILT_ETHADDR's source files consist of a single FORTRAN file 
ETHFILT_ETHADDR.FOR. Its user 
interface is similar to ETHERPARSE; it prompts for an input TRACE 
binary recrding file (default file type .DAT), and a name for the 
to-be-created output binary recording file (default file type .DAT). 
It then prompts for the Ethernet physical address of the packets 
(using the fixed format @i<@u[aa-bb-cc-dd-ee-ff]>, where the hyphens are 
required and each byte must be specified by two hexadecimal digits) to 
filter for. Any packets which do not contain the specified Ethernet 
address in either the source or 
destination address fields of the data link layer header are discarded; the 
remaining packets are copied to the output file, and a 
statistical summary of packets processed is printed on the user 
terminal.
@Index(filter)
@Index(ETHFILT_ETHADDR)
@IndexSecondary(Primary="Utilities",Secondary="ETHFILT_ETHADDR")

@Section(ETHFILT_IPADDR)
ETHFILT_IPADDR's source files consist of two versions of a FORTRAN file,
ETHFILT_IPADDR_TGV.FOR and ETHFILT_IPADDR_UCX.FOR, and corresponding 
linker options files ETHFILT_IPADDR_TGV.OPT and ETHFILT_IPADDR_UCX.OPT. 
Its user interface is similar to ETHERPARSE; it prompts for an input TRACE 
binary recording file (default file type .DAT), and a name for the 
to-be-created output binary recording file (default file type .DAT). 
It then prompts for the Internet IP physical (numeric, not symbolic) 
address of the packets to filter for. Any packets which are not IP or 
do not contain the specified IP address in either the source or 
destination address fields of the IP header are discarded; the 
remaining packets are copied to the output file, and a 
statistical summary of packets processed is printed on the user 
terminal.
@Index(filter)
@Index(ETHFILT_IPADDR)
@IndexSecondary(Primary="Utilities",Secondary="ETHFILT_IPADDR")
@IndexSecondary(Primary="protocol type",Secondary="IP (08-00)")

The linker options file is used to specify the object files to be 
linked. The two versions assume that either TGV MultiNet or DEC 
VMS/Ultrix Connection (UCX, now called TCP/IP Services for VMS) is the Internet 
software running 
on the local system; as such, they specify the appropriate socket library 
shareable image as a place to get the Internet address format 
conversion routines (either MULTINET:MULTINET_SOCKET_LIBRARY or 
SYS$SHARE:VAXCRTL). To link either image, a LINK command of the form
@Begin(InputExample)

$ @b<LINK/EXE=ETHFILT_IPADDR ETHFILT_IPADDR_>@i<@u[version]>@b</OPTION>

@End(InputExample)
should be used, where @i<@u[version]> is either TGV or UCX.
@IndexSecondary(Primary="Internet software",Secondary="TGV MultiNet")
@IndexSecondary(Primary="Internet software",Secondary="DEC UCX")
@IndexSecondary(Primary="Internet software",Secondary="DEC TCP/IP Services for VMS")

@Section(ETHFILT_NFS)
ETHFILT_NFS's source files consist of a single FORTRAN file ETHFILT_NFS.FOR. 
Its user interface is similar to ETHERPARSE; it prompts for an input TRACE 
binary recrding file (default file type .DAT), and a name for the 
to-be-created output binary recording file (default file type .DAT). 
Any packets which are not IP/UDP or do not contain RPC/NFS data are 
discarded; the remaining packets are copied to the output file, and a 
statistical summary of packets processed is printed on the user 
terminal.
@Index(filter)
@Index(ETHFILT_NFS)
@IndexSecondary(Primary="Utilities",Secondary="ETHFILT_NFS")
@IndexSecondary(Primary="protocol type",Secondary="IP (08-00)")
@IndexSecondary(Primary="protocol type",Secondary="UDP")
@IndexSecondary(Primary="protocol type",Secondary="RPC")
@Index(NFS)
@IndexSecondary(Primary="protocol type",Secondary="NFS")

Note that, to link ETHFILT_NFS, you must use a LINK command of the form:
@Begin(InputExample)

$ @b<LINK ETHFILT_NFS,ETH_CHECK_SUBPROC>

@End(InputExample)

ETHFILT_NFS may be used as a TRACE/ANALYZER subprocess.
@IndexSecondary(Primary="TRACE",Secondary="/ANALYZER")
@Chapter(Security Considerations)
For system and network administrators who are concerned about illicit 
monitoring of their networks: ETHERMON does that sort of thing just dandy! 
Seriously, network monitoring is the whole purpose of ETHERMON; ETHERMON is 
supposed to be able to see all traffic that passes by on your network. 
However, there are constraints to help prevent @u<@i{illicit}> monitoring 
of the network with ETHERMON:
@Begin(Enumerate)
ETHERMON requires a fair number of sensitive user privileges to be able to run: 
PHY_IO, NETMBX, and CMKRNL, to be precise (or SETPRV, which allows all the 
others to be enabled). Similarly, it requires rather large user quotas 
(BYTLM). All of these can only be granted by a user with system 
administrator privileges. As such, it is highly recommended NOT to install 
ETHERMON.EXE with privilege.
@IndexSecondary(Primary="privileges",Secondary="CMKRNL")
@IndexSecondary(Primary="privileges",Secondary="NETMBX")
@IndexSecondary(Primary="privileges",Secondary="PHY_IO")
@IndexSecondary(Primary="privileges",Secondary="SETPRV")
@IndexSecondary(Primary="quotas",Secondary="BYTLM")

VAX/VMS V5.4-3 and higher @i<require> the use of an installed protected 
shareable image, which requires even more privileges to set up. Changes to 
the installed image list can be easily audited for, and the essential 
shareable image (ETHERMON_FASTSHR) can be placed under VMS file protections 
to control access to it.
@Index(INSTALL)

The main executable image file of ETHERMON depends on its location to 
locate other files. Therefore, illicit copies of the executable file would 
not be able to access the installed official copy of the shareable image file 
(unless a system-wide executive-mode logical name was defined @i<and 
visible> to the account being used).
@Index(logical name)
@End(Enumerate)

This is as opposed to PC and Macintosh-based monitoring tools, such as 
NetMinder, where simple physical access to the software package and the 
computer in question is enough to guarantee the ability to run a monitor. 
Even if a VAX/VMS user was to "roll their own" monitoring software (as 
ETHERMON V1.0 was originally created), a minimum of PHY_IO privilege would 
still be required to enable the promiscuous monitoring mode on the Ethernet 
interface device.
@Index(promiscuous mode)

For system administrators who are concerned about un-trusted kernel-mode 
code (the V2.4 enhancements involving ETHERMON_FASTSHR.EXE) running on their 
systems, there are four safety checks in place:
@Begin(Enumerate)
As with the rest of ETHERMON, complete commented source code is provided 
for the program, allowing you to study what ETHERMON would be doing to your 
system. This source code is located in the file ETHERMON_FASTSHR.MAR.

Random users cannot take advantage of the kernel mode hooks because the 
shareable image does not implement a user-written system service; it is 
implemented as a shareable image only to keep the necessary system version 
dependencies out of the main ETHERMON code, and to allow a non-defeatable 
image rundown routine to be executed. Therefore, users of the shareable 
image still require all the privileges needed to run ETHERMON and the 
shareable image's extensions (i.e., users could link their own code to the 
shareable image, but they would not gain any privilege from it).

ETHERMON is capable of functioning without the "fast" port interface for 
VAX/VMS versions V5.4-2 and below (it requires it for VAX/VMS V5.4-3 and 
above). To disable ETHERMON's attempts to use the "fast" interface, simply 
do not keep a copy of ETHERMON_FASTSHR.EXE in the same directory as 
ETHERMON.EXE, and/or do not install the image appropriately (as described 
in section @Ref[INSTALL] on page @PageRef[INSTALL]). ETHERMON 
@b[cannot] use the shareable image unless it is installed as described above.
On a failed attempt to use the shareable image, ETHERMON will print out an 
appropriate error message describing why it could not activate the "fast" 
interface, and then either continue using the old interface scheme or 
terminate (depending on the operating system version).
@IndexSecondary(Primary="VAX/VMS",Secondary="V5.4-3 and up")

Because the shareable image is activated using the standard services of the 
VAX/VMS Image Activator, an image that was linked under an incompatible 
operating system version cannot be activated; however, do not just relink 
ETHERMON_FASTSHR if this happens, but re-compile it as well (to ensure that 
any system macro changes will be accounted for). Note that there should never 
be any link-time errors from linking the shareable image; if there are, the 
image is suspect and should not be used. Also, a linker options file (as 
embedded in the file ETHERMON.COM) must be used to guarantee the proper 
structure of the shareable image.
@End(Enumerate)
@Appendix(Messages)
@Section(ETHERMON Messages)
@Begin(Enumerate)
@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ADRPROTOVF, no room to store @i<@u[aa-bb]> for @i<@u[aa-bb-cc-dd-ee-ff]>
@End(ProgramExample)
While automatically updating the address table during a message read, 
ETHERMON ran out of protocol type slots for a single address entry in the 
address table, and could not store an additional new protocol type for that 
address. Verify that the specified address on the Ethernet is supposed to 
be servicing that many protocol types simultaneously; if this is normal, 
edit the file ETHERMON_ADDR.INC to increase the value of the parameter 
ICPADR_MAXPROTS and recompile and relink ETHERMON. This 
message will only be displayed with the SET MESSAGES DEBUG command active.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-ADRTBLFUL, address table full - new address/name pair not added
@End(ProgramExample)
A SET ADDRESS_NAME or LOAD command attempted to add a new Ethernet 
address to the address table, but there was no more room for it. This 
requires a rather complicated procedure to enlarge the size of the 
address table in the source code (file ETHERMON_ADDR.INC, and scattered 
changes to address insertion logic throughout ETHERMON.FOR), then 
rebuilding the program.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-ADRTBLOVF, Ethernet address buffer table overflow - PROGRAM ABORT
@End(ProgramExample)
During a DISPLAY or SUMMARIZE command, there was no longer room in the 
address table to add a new entry that was being counted up. The program 
has crashed. To correct this, the address table must be enlarged. However, 
this also implies that you have an exceedingly busy Ethernet, which you may 
wish to correct.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ALLFLTDEL, all defined filters deleted
@End(ProgramExample)
A CLEAR FILTERS/ALL command has been executed successfully. No action 
is required.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-ALRDYPRMUSR, promiscuous user already active on this interface
@End(ProgramExample)
This error is caused by the fact that there is already a promiscuous user on 
the Ethernet interface you are attempting to use. Try another interface, 
or get rid of the existing promiscuous user (it could be another 
invocation of this program).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ANLRPT, TRACE/ANALYZER PID=@i<@u[xxxxxxxx]> elapsed=@i<@u[hh:mm:ss.cc]>
                        CPU=@i<@u[hh:mm:ss.cc]> pf=@i<@u[nn]> bio=@i<@u[nn]>(@i<@u[nn]> extra) dio=@i<@u[nn]>
@End(ProgramExample)
The subprocess created by a TRACE/ANALYZER command completed with the 
specified accounting statistics. An additional message will follow, giving the 
final completion status of the subprocess. No action is necessary (unless 
you wish to troubleshoot a non-success completion status).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ASYNTRCBEG, asynchronous TRACE command started...
@End(ProgramExample)
A TRACE command was entered with the /PARALLEL or /REPEAT qualifier, 
and is now running in the background while another ETHERMON command 
prompt is issued. No action is required.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ASYNTRCDON, asynchronous TRACE command completed.
@End(ProgramExample)
A TRACE command with /PARALLEL completed its time interval, or the 
TRACE/ABORT command was entered to shut down a TRACE/PARALLEL or 
TRACE/REPEAT command, or ETHERMON was exited while a TRACE/PARALLEL or 
TRACE/REPEAT was active. No action is required.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-BADADDRNUM, invalid octet in Ethernet address number
@End(ProgramExample)
A standard format physical Ethernet address was specified where one of 
the octets was outside the range 00 to FF. Re-enter the command with a 
valid address.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BADAPPLE, @i<@u[aa-bb-cc-dd-ee-ff]> sent unknown AppleTalk layer
@End(ProgramExample)
The specified node transmitted an AppleTalk/EtherTalk packet where the 
higher-level protocol type was not recognized (not DDP). Find why the 
node is sending invalid packets; if the packets turn out to be valid, 
please send a bug report to the author of ETHERMON, reporting what 
type of traffic is being mislabeled as invalid. This 
message can be suppressed with the SET MESSAGES OFF command.
@IndexSecondary(Primary="AppleTalk",Secondary="DDP")
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-BADFIL, invalid record in file
@End(ProgramExample)
While reading a SAVE'd address or filter file, an invalid record in the 
file was found; the record was ignored. If the file was manually edited, 
use an un-edited version of the file or correct the record's syntax.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BADPNGADR, can't ping to a multicast address (except Broadcast)
@End(ProgramExample)
The PING command was entered with a multicast address as a target. Use 
a valid physical (not multicast) Ethernet address when entering the 
PING command.
@Index(multicast address)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-BADPROTNUM, invalid octet in Ethernet protocol number
@End(ProgramExample)
A standard format Ethernet protocol type code was specified where one of 
the octets was outside the range 00 to FF. Re-enter the command with the 
correct protocol type code.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BRGMAPOLD, bridge map is out of date - use MAP command again
@End(ProgramExample)
A new Ethernet bridge made itself known after the last time the MAP 
command was executed, thereby probably obsoleting the bridge 
interconnection map computed by the MAP command. This message will 
appear when using the SHOW BRIDGES/FULL command to display the bridge 
map. Enter the MAP command again to recompute the map with the 
additional data.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")
@Index(SHOW BRIDGES)
@IndexSecondary(Primary="commands",Secondary="SHOW BRIDGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BRGPRTINF, vague remote line data obtained; bridge map unreliable
@End(ProgramExample)
While executing a MAP command, bridge port data was not complete for the remote 
side of some bridge map entries. This is a frequent occurrence if bridges 
using the DEC LAN Bridge protocol appear on the network, as they do not 
specify which Ethernet address corresponds to which side of the bridge. No 
action is required, but it does imply possible errors that might appear in 
the output of a SHOW BRIDGES/MAP command.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")
@Index(SHOW BRIDGES)
@IndexSecondary(Primary="commands",Secondary="SHOW BRIDGES")
@IndexSecondary(Primary="protocol type",Secondary="LAN Bridge (80-38)")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-BRGROUTOVF, routing table overflow for bridge #@u<n>
@End(ProgramExample)
While executing a MAP command, the bridge being queried returned more 
valid bridge addresses than the bridge mapping table could hold. Note 
that this can only happen when:
@Begin(Enumerate)
executing the MAP command on a large Ethernet with many bridges, and

in the file ETHERMON_BRIDGES.INC file, the parameter 
ICPBRG_MAXBRGROUT is smaller than the parameter ICPBRG_MAXBRIDGES.
@End(Enumerate)
To correct the problem, edit ETHERMON_BRIDGES.INC to set ICPBRG_MAXBRGROUT 
equal to ICPBRG_MAXBRIDGES (you may also wish to enlarge ICPBRG_MAXBRIDGES if 
you find that the SHOW BRIDGES command shows you exactly as many 
bridges as the current table size); then re-compile and re-link ETHERMON.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BRGTMO, @u<n> timeouts while querying bridges - use MAP command again
@End(ProgramExample)
While executing a MAP command, responses were not received the specified 
number of times, either due to packet drops by ETHERMON, the bridge 
ignoring the request, or some other network glitch that would cause packets 
to be dropped before they reached the monitoring system. It is suggested 
that you repeat the MAP command to ensure that data is received from all 
the bridges.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-BRGTMO2, bridge #@u<n> timed out
@End(ProgramExample)
While executing a MAP command with SET MESSAGES DEBUG, a response was not 
received from the specified bridge, either due to a packet drop by ETHERMON, 
the bridge ignored the request, or some other network glitch that would cause 
a packet to be dropped before they reached the monitoring system. It is 
suggested that you repeat the MAP command to ensure that data is received from 
all the bridges.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-CANTDOIEEE, this VAX can't support IEEE 802 mode
@End(ProgramExample)
A command was entered that requires the Ethernet interface to be 
running in IEEE 802.3 extended mode, but ETHERMON was started in Ethernet mode 
instead because the interface or the VAX system, for some reason, 
could not operate in IEEE 802.3 mode. Find why the VAX cannot support 
IEEE 802.3 extended mode on the selected Ethernet interface (typically, 
this is because you are using a VAX running VMS V4.7 or earlier).
@IndexSecondary(Primary="VAX/VMS",Secondary="V4.x")
@Index(IEEE 802.3)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-CANTSTART, can't start Ethernet port, devchar=@u<xxxxxxxx>
@End(ProgramExample)
Some sort of VMS I/O driver error occurred while trying to start the 
Ethernet interface for promiscuous monitoring. An accompanying system 
message will give additional details as to the cause of the error.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-CMPETHRD, error completing Ethernet read
@End(ProgramExample)
Some sort of VMS I/O driver error occurred during completion of an 
asynchronous read of the Ethernet interface. An accompanying system 
message will give additional details as to the cause of the error.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-CMPNETACP, error completing status query to DECnet NETACP
@End(ProgramExample)
A request was sent to the DECnet NETACP process to translate a DECnet 
node number to a node name, and the request completed in error. An 
accompanying system message will give additional details as to the cause 
of the error. This message can be suppressed with the SET MESSAGES OFF 
command.
@Index(DECnet)
@Index(NETACP)
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-CRASHDUMP, crash dump of ETHERMON from ETHER_READ
@End(ProgramExample)
This prefixes a fatal error report from within the per-message read and 
analysis code in ETHERMON. The following lines will give context of the 
error. This information (other than the traceback) will also be recorded 
in a disk file named ETHERMON.CRASH_DUMP in the current directory. If this 
should happen, please contact the author and send him a copy of the crash 
dump file's contents (the file is ASCII and easily mailed); please 
include the version of ETHERMON you were running and the version of 
VAX/VMS you were running under.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-DISPJAMMD, screen stalled for > 7 minutes; data munched
@End(ProgramExample)
Either the user accidentally pressed the NO SCROLL key (control-S) on 
his/her keyboard for too long during a DISPLAY command, or ETHERMON was 
over-saturated with network messages continuously for too long. The 
DISPLAY command is terminated. Re-enter the DISPLAY command and don't 
leave NO SCROLL active for such a long time period.
@Index(control-S)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-DUPIPADR, @i<@u[aa-bb-cc-dd-ee-ff]> has same IP adr @i<@u[a.b.c.d]> as @i<@u[aa-bb-cc-dd-ee-ff]> 
@End(ProgramExample)
The SET MESSAGES DUPIP command has been entered, and ETHERMON detected a node  
claiming the same IP source address as an existing node (the first Ethernet 
address displayed in the message is the new node, and the second Ethernet 
address is the older entry in the address table). Determine why two 
different IP hosts are using the same IP address.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-ERRGETSYI, error issuing $GETSYI service call
@End(ProgramExample)
During ETHERMON initialization, an attempt to query VAX/VMS for system
identification or configuration data failed. Use the associated VAX/VMS 
error message to determine why the $GETSYI service call failed.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-ERROPNIND, can't open specified indirect command file
@End(ProgramExample)
For some reason, ETHERMON cannot open the indirect command file 
specified with the last @@@i<filespec> command.
@Index(@@filespec)
@IndexSecondary(Primary="commands",Secondary="@@filespec")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-FILOPNERR, FORTRAN I/O error #@u<nn> trying to open LOAD file
@End(ProgramExample)
ETHERMON could not open the specified file during a LOAD command. Look 
up the FORTRAN IOSTAT error message number and correct the corresponding 
problem.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FLTADDDIS, filter #@u<nn> added and disabled
@End(ProgramExample)
The ADD FILTER command successfully defined a new filter and disabled it. 
No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FLTADDENA, filter #@u<nn> added and enabled
@End(ProgramExample)
The ADD FILTER command successfully defined a new filter and enabled it.
No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FLTDEL, filter #@u<nn> deleted
@End(ProgramExample)
The CLEAR FILTER command successfully deleted a filter definition. No 
action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FLTMODDIS, filter #@u<nn> modified and disabled
@End(ProgramExample)
The SET FILTER command successfully modified a filter definition, 
leaving it in the disabled state. No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FLTMODENA, filter #@u<nn> modified and enabled
@End(ProgramExample)
The SET FILTER command successfully modified a filter definition, 
leaving it in the enabled state. No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-FLTTBLFUL, filter table full - new filter not added
@End(ProgramExample)
An ADD FILTER or LOAD command failed because there was not enough space 
in the filter table. Remove some unused filter definitions with the 
CLEAR FILTER command and try the ADD FILTER or LOAD command again.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FNDINETGW, @i<@u[aa-bb-cc-dd-ee-ff]> is an Internet IP gateway
@End(ProgramExample)
Sufficient data has been received to determine that the specified node 
is an Internet IP gateway, or router. No action is necessary. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-FNDMLTIPA, @i<@u[aa-bb-cc-dd-ee-ff]> has multiple Internet IP addresses
                first is @i<@u[a.b.c.d]>, second is @i<@u[e.f.g.h]>
@End(ProgramExample)
During the monitoring, messages specifying more than one legal 
non-broadcast DoD Internet IP 
address was detected being sent to or received by a single Ethernet 
node; this may imply that the node is an Internet IP gateway (but not 
yet confirmed as such), or that the node is misconfigured. The first address 
displayed is the one the node originally appeared as, and the second 
is the second address listed. Note that third, fourth, etc., addresses 
will not be displayed; only enough addresses to determine the 
multi-address characteristics of the node will be reported. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-INCBRGDAT, incomplete data used for map - use MAP command again
@End(ProgramExample)
While the MAP command was being executed, it discovered that incomplete 
infomation was stored for some of the bridges known to ETHERMON. The 
additional information was automatically filled in, but not necessarily in 
time for previous queries to other bridges to take advantage of the new 
information. The MAP command should be re-executed to re-run the data 
collection with the new information available.
@Index(MAP)
@IndexSecondary(Primary="commands",Secondary="MAP")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-INCONSIST, internal inconsistency in command parser - submit PR
@End(ProgramExample)
While parsing a command entered by the user, the parser disconvered an 
internal inconsistency in the parsing logic. If this message occurs, please 
submit a problem report to the author, giving the exact command line you 
entered (character for character). Also please 
include the version of ETHERMON you were running and the version of 
VAX/VMS you were running under.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-IMOPMSG, @i<@u[hh:mm:ss aa-bb-cc-dd-ee-ff]> sent iMOP @i<@u[prot]> msg, t=@i<@u[xxxx]> ln=@i<@u[nn]>
@End(ProgramExample)
The specified node transmitted a DEC MOP (Maintenance Operations 
Protocol) message (using IEEE 802.3 SNAP formatting) of a significant 
type. @i<@u[prot]> specified whether the message was a Dump/Load 
Assistance (60-01) or Remote Console (60-02) protocol type, the 
"t=@i<@u[xxxx]>' specifies the first word of the message in 
hexadecimal (high byte first), and "ln=@i<@u[nn]>" gives the length of the 
message in bytes. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@Index(IEEE 802.3)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-INVDSPINT, invalid display interval of @u<nn> sec; not changed
@End(ProgramExample)
The SET INTERVAL command specified an invalid or out-of-range number of 
seconds for the display update interval; the old setting was not 
changed. Re-enter the command with a valid number between 2 and 59.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-INVFLTNUM, specified filter is undefined or out of range
@End(ProgramExample)
In a SET FILTER or CLEAR FILTER command, there is no filter 
corresponding to the specified filter index number. Re-enter the command 
with a valid filter index (use the SHOW FILTER command to check what 
filter numbers are defined).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-INVNODSPC, invalid network node specification
@End(ProgramExample)
An ADD FILTER or SET FILTER command specified an Ethernet address 
symbolically by DECnet node number, DECnet node name, or Internet IP 
address, but there was a syntax error in the specification. Re-enter the 
command with a valid-syntax address.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-INVTRCTYP, only 1 file format qualifier may be given on TRACE
@End(ProgramExample)
A TRACE command was entered with more than one of the qualifiers /ASCII, 
/BINARY, /SNIFFER, or /ANALYZER. Only one of these qualifiers may be used at 
a time. Re-enter the TRACE command with only one of the file format qualifiers.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-LOWBYTLM, current BYTLM=@i<@u[nnnn]> lower than recommended minimum @i<@u[mmmm]>
@End(ProgramExample)
This message will appear during ETHERMON start-up if your process does not 
have sufficient BYTLM quota left to allow ETHERMON to execute. It may appear 
as an informational message (ETHERMON will run anyway, with possible degraded 
performance) or as a fatal error (ETHERMON cannot run and will terminate). 
Get your BYTLM quota raised, or don't run as many other applications that 
consume BYTLM quota from your process. Note that the recommended minimum for 
efficient operation is at least 10000 bytes higher than the absolute minimum 
required for the program to run at all. Note that the recommended 
minimum may seem rather large if other layered products have modified 
the SYSGEN parameters DEFMBXBUFQUO or PQL_MBYTLM. The absolute minimum 
is determined by the formula
@Begin(ProgramExample)
value = MIN(PQL_MBYTLM,PQL_DBYTLM) 
        + DEFMBXBUFQUO
        + @i<buffer_size_of_port> + 50
        + 1100
        + @i<buffer_size_of_port> + 50
        + 4 * (@i<buffer_size_of_port> + 50)
        + 4 * 512
        + 252
@End(ProgramExample)
where the SYSGEN parameters are used to reserve enough quota for the 
SPAWN command to work, the first @i<buffer_size_of_port>+50 is for the normal 
$QIO read buffer needed by ETHERMON, the 1100 is for other I/O buffers 
(terminal I/O, etc.) needed by ETHERMON, and the second 
@i<buffer_size_of_port>+50 is to account for at least one 
pre-allocated receive buffer for the Ethernet I/O driver (the 
NMA$C_PCLI_BFN extended characteristic), the 4*(@i<buffer_size_of_port>+50)
is for two maximum-size messages in a mailbox for the TRACE/ANALYZER command 
and the write by ETHERMON and the read by the subprocess, the 4*512 is for 
standard output and standard error output by the TRACE/ANALYZER command, 
and the 252 is for TRACE/ANALYZER termination handling; for each additional 
@i<buffer_size_of_port>+50 bytes available above this minimum, the 
NMA$C_PCLI_BFN value used is incremented by 1, to a maximum value of 127. The 
value of @i<buffer_size_of_port> is 1492 for Ethernet devices, and 4468 for 
FDDI devices (the NMA$C_PCLI_MBS extended characteristic). Note also that 
these calculations are performed after some BYTLM quota has
already been consumed to create the cloned device units for the Ethernet 
interface and the DECnet network mailbox.
@Label[quota]
@Index(FDDI)
@Index(SYSGEN parameters)
@IndexSecondary(Primary="quotas",Secondary="BYTLM")
@Index(SPAWN)
@IndexSecondary(Primary="commands",Secondary="SPAWN")
@Index(TRACE)
@IndexSecondary(Primary="commands",Secondary="TRACE")
@Index(DECnet)
@Index(mailbox)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-MDUPIP, @i<@u[aa-bb-cc-dd-ee-ff]> (@i<@u[name]>) claims @i<@u[aa-bb-cc-dd-ee-ff]> has
                   same IP adr @i<@u[a.b.c.d]> as @i<@u[aa-bb-cc-dd-ee-ff]> 
@End(ProgramExample)
The SET MESSAGES DUPIP command has been entered, and ETHERMON detected a node  
claiming the same IP source address as an existing node (the first Ethernet 
address displayed in the message is the new node, and the second Ethernet 
address is the older entry in the address table). Determine why two 
different IP hosts are using the same IP address.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-MNFTBLFUL, manufacturer table full - new code/name pair not added
@End(ProgramExample)
A SET MANUFACTURER command attempted to add a new Ethernet manufacturer 
prefix to the manufacturer table, but there was no more room for it. 
Increase the value of the manufacturer name table size parameter 
ICPMNF_MAXNAMES in ETHERMON_MANUF.INC, then rebuild the ETHERMON program.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-MOPMSG, @i<@u[hh:mm:ss aa-bb-cc-dd-ee-ff]> sent MOP @i<@u[prot]> msg, t=@i<@u[xxxx]> ln=@i<@u[nn]>
@End(ProgramExample)
The specified node transmitted a DEC MOP (Maintenance Operations 
Protocol) message (using Ethernet formatting) of a significant 
type. @i<@u[prot]> specified whether the message was a Dump/Load 
Assistance (60-01) or Remote Console (60-02) protocol type, the 
"t=@i<@u[xxxx]>' specifies the first word of the message in 
hexadecimal (high byte first), and "ln=@i<@u[nn]>" gives the length of the 
message in bytes. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-MSGLEN, specified message buffer length out of range
@End(ProgramExample)
A SET FILTER/SIZE command was entered with the MAXIMUM or MINIMUM 
option, but the numeric size was outside the range of 46 to 4470. 
Re-enter the command with a valid message size.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-NETACPDAT, insufficient data returned by NETACP
@End(ProgramExample)
A query was sent to the DECnet NETACP process, but the returned data was 
too short to be intelligible. Contact your local DEC software support 
center, as this implies a weird fault within DECnet; however, please notify 
the author as well.
@Index(DECnet)
@Index(NETACP)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-NEWNODE, new Ethernet sender @i<@u[aa-bb-cc-dd-ee-ff]> detected
@End(ProgramExample)
The SET MESSAGES NEWNODE command has been entered, and a new sending node has 
just been added to the address table. No action is required (except 
possibly to enter the SET MESSAGES NONEWNODE command if you do not wish to 
see these messages).
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-NOASYNTRC, no asynchronous TRACE active to abort - command ignored
@End(ProgramExample)
The TRACE/ABORT command was entered when there was no active 
TRACE/PARALLEL or TRACE/REPEAT background command in progress. No 
action is required (except possibly to determine why there was no 
active TRACE command when you expected one to be active).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-NODECNET, can't access DECnet services
@End(ProgramExample)
At ETHERMON start-up, a connection to a DECnet network mailbox could not 
be made, preventing ETHERMON from translating DECnet addresses with the help of 
NETACP. DECnet may not be running on your system, or you may not have
NETMBX (or SETPRV) privilege. If DECnet is supposed to be on your system 
but isn't, contact your system manager to find why it is not currently 
running.
@Index(DECnet)
@Index(NETACP)
@IndexSecondary(Primary="privileges",Secondary="NETMBX")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-NOFASTFB, can't activate ETHERMON_FASTSHR.EXE; using unsupported interface
@End(ProgramExample)
The "fast" $QIO interface for ETHERMON could not be started. However, you are 
using a sufficiently old version of VAX/VMS for the old "plain" $QIO 
interface to still function. Unless you wish to use the "fast" interface, 
no action is required; if you do wish to use the "fast" interface, see the 
actions described for the %ETHERMON-F-NOFASTSHR message.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-NOFASTSHR, can't activate ETHERMON_FASTSHR.EXE - PROGRAM ABORT
@End(ProgramExample)
The "fast" $QIO interface for ETHERMON could not be started for some 
reason, and, because you are using a version of VAX/VMS later than V5.4-2, 
the old-style $QIO interface could not be used successfully. A VMS system 
error message should accompany this message, explaining why the "fast" 
interface could not be activated.
@IndexSecondary(Primary="VAX/VMS",Secondary="V5.4-3 and up")
The expected VMS error message (and corresponding action) should be 
one of the following:
@Begin(Itemize)
@Begin(Group)
@Begin(ProgramExample)
-RMS-F-FNF
@End(ProgramExample)
The shareable image file ETHERMON_FASTSHR.EXE could not be found, either by 
executive-mode logical name translation, or by looking in the directory where 
the ETHERMON.EXE file being executed was located. Define the logical name or
move the file to the same directory as the ETHERMON executable image.
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-SHRIDMISMAT
-LIB-F-KEYNOTFOU
@End(ProgramExample)
The installed shareable image file ETHERMON_FASTSHR.EXE is of an incompatible 
patch level for the current version of ETHERMON. Re-compile and re-link 
both ETHERMON and ETHERMON_FASTSHR under the current operating system with 
current source files, then re-install ETHERMON_FASTSHR.
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-EXQUOTA
@End(ProgramExample)
You do not have enough BYTLM quota left to create the non-paged pool data 
structures needed to support the "fast" interface. This error should never 
occur (ETHERMON should have reserved enough BYTLM when it saved quota for 
spawning subprocesses); if it does, please 
submit a problem report to the author, giving the exact command line you 
entered (character for character). Also please 
include the version of ETHERMON you were running and the version of 
VAX/VMS you were running under.
@IndexSecondary(Primary="quotas",Secondary="BYTLM")
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-INSFMEM
@End(ProgramExample)
Your system does not have enough non-paged pool left to allocate space for 
the data structures needed by the "fast" interface. Exit ETHERMON and 
re-SYSGEN your system (if you get this error, your system is far too 
tight on non-paged pool to consider running ETHERMON in any mode).
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-LKWSETFUL
@End(ProgramExample)
Your process's working set is too small to be able to lock down the 
additional memory pages required for the "fast" interface to run 
successfully. In this case, you definitely do not have a large enough 
working set for ETHERMON to be able to run adequately. Enlarge your working 
set limit and/or quota (or have your system administrator grant your 
account more quota), then try again.
@IndexSecondary(Primary="quotas",Secondary="WSDEFAULT")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-NOPRIV
-SYSTEM-F-NOTALLPRIV
@End(ProgramExample)
The user has all the privileges necessary to run ETHERMON in the old mode, 
but does not have the CMKRNL (or SETPRV) privilege necessary to use the 
"fast" mode interface. Have your system administrator grant your account 
the necessary privileges.
@IndexSecondary(Primary="privileges",Secondary="CMKRNL")
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-PROTINSTALL
@End(ProgramExample)
The shareable image file ETHERMON_FASTSHR.EXE was not installed as a 
protected shareable image with the INSTALL utility. Install the image as 
described in section @Ref[CMKRNL].
@Index(INSTALL utility)
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-SYSVERDIF
@End(ProgramExample)
The shareable image file ETHERMON_FASTSHR.EXE was compiled and linked under 
an incompatible version of VAX/VMS. Re-compile and re-link ETHERMON_FASTSHR 
under the current operating system, then re-install it.
@End(Group)
@Hinge

@Begin(Group)
@Begin(ProgramExample)
-SYSTEM-F-VECFULL
@End(ProgramExample)
For some strange reason, your account environment has so many privileged 
images using the kernel-mode user-rundown facility that there are no vector 
entries left in the rundown vector table. If this message occurs, please 
submit a problem report to the author, giving the exact command line you 
entered (character for character). Also please 
include the version of ETHERMON you were running, the version of 
VAX/VMS you were running under, and the names and descriptions of any 
privileged layered products that are installed on your system.
@End(Group)
@End(Itemize)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-NOFILE, can't find specified LOAD file
@End(ProgramExample)
The file specified on a LOAD command cannot be found. Re-enter the LOAD 
command with the correct file specification (watch the defaults).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-NOGBLSEC, couldn't create address table global section
@End(ProgramExample)
During start-up of ETHERMON, an attempt was made to create a temporary 
group global section containing the address table, such that the table 
might be shared with TRACE/ANALYZER subprocesses. However, the section 
creation failed. An accompanying system error message from the $CRMPSC 
system service should explain why the section could not be created. 
ETHERMON will function without the section; however, address table data 
cannot be shared in real-time with subprocesses unless the section is 
created. As of ETHERMON V2.4, creating the global section requires 2009 
contiguous free global pages, and the same number of free global page-file 
pages; these pages will be released when ETHERMON is exited.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-NOINET, can't find known Internet software to query
@End(ProgramExample)
Upon receiving a LOAD/INTERNET command, ETHERMON could not find a 
recognized type of Internet software to query for name information. The 
LOAD/INTERNET command only works with the products DEC VMS/Ultrix Connection 
(UCX, now called TCP/IP Services for VMS), TGV MultiNet, NRC Fusion, and 
CMU TCP/IP; if you have no Internet software, or something 
other than these, the command probably will not work.
@IndexSecondary(Primary="Internet software",Secondary="DEC UCX")
@IndexSecondary(Primary="Internet software",Secondary="DEC TCP/IP Services for VMS")
@IndexSecondary(Primary="Internet software",Secondary="TGV MultiNet")
@IndexSecondary(Primary="Internet software",Secondary="NRC Fusion")
@IndexSecondary(Primary="Internet software",Secondary="CMU TCP/IP")

Should you have another manufacturer's Internet software and know how 
to query it to translate Internet physical addresses to @i[host.network] name 
format, please contact the author so I can add support for your 
configuration to ETHERMON.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-NOINETDST, specified destination hasn't spoken Internet yet
@End(ProgramExample)
A PING/INTERNET command was issued to a node which does not have an IP 
address assigned to it yet. Verify that the correct Ethernet address 
was given on the PING command, or determine why the specified node has 
not yet been seen to speak DoD Internet IP protocol (08-00).
@Index(PING)
@IndexSecondary(Primary="commands",Secondary="PING")
@Index(Internet)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-NONSTDMOP, @i<@u[aa-bb-cc-dd-ee-ff]> had non-std MOP type @i<@u[xxxx]>, len=@i<@u[nn]>
@End(ProgramExample)
A DEC MOP (Maintenance Operations Protocol) message with an 
undocumented message type was sent by the specified node. You may wish 
to investigate why the non-standard message packet was sent. This 
message will only be displayed with the SET MESSAGES DEBUG command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-ONEPORT, implicitly using the one Ethernet interface @i<@u[_ddc0:]>
@End(ProgramExample)
ETHERMON was invoked with a RUN command, or as a foreign command but without 
an Ethernet device name, and it has searched for the expected types of 
Ethernet devices on the system, and found only one such device, which it 
automatically selected for use. No action is required (unless you wanted to 
use some non-standard third-party interface; in that case, you must specify 
its device name on the foreign command line).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-PNGNOTSENT, PING message was not transmitted during wait interval
@End(ProgramExample)
For some reason, during the period that ETHERMON waits for a PING to 
be acknowledged, the Ethernet device driver did not even finish 
sending the PING request. Please notify the author if this message 
appears, and describe what type of Ethernet interface hardware and 
device driver software you were using. Note that this message was reported 
falsely in versions V2.2 to V2.3-1 of ETHERMON when PINGing to the 
Broadcast address; the error has been corrected as of V2.3-2.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-PORT, enter VMS device name of the Ethernet interface to use
@End(ProgramExample)
ETHERMON was invoked with a RUN command, or as a foreign command but without 
an Ethernet device name, and it has searched for the expected types of 
Ethernet devices on the system, and found more than one such device. 
Following this message will be a list of VMS device names and a prompt to 
enter a device name. Enter one of the displayed device names to continue 
execution.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-PORTASNFAI, error assigning channel to Ethernet interface
@End(ProgramExample)
During ETHERMON initialization, an I/O channel could not be assigned 
to the specified or defaulted Ethernet interface device. Check that 
your account is permitted access to the Ethernet device, and verify 
that the device name was typed in properly and any logical name used 
translates properly to a valid Ethernet interface device name. The 
associated VMS error message will help describe why the $ASSIGN system 
service failed.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-F-PROTBLOVF, Ethernet protocol buffer table overflow - PROGRAM ABORT
@End(ProgramExample)
During a DISPLAY or SUMMARIZE command, the protocol type counter table 
did not have any more free space. This requires a rather difficult fix to 
enlarge the table and rebuild the ETHERMON program. However, this also 
implies that you have an exceedingly busy Ethernet, which you may wish 
to correct.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-PROXYARP, @i<@u[aa-bb-cc-dd-ee-ff]> is proxy-ARPing for @i<@u[aa-bb-cc-dd-ee-ff]>
@End(ProgramExample)
A node on the Ethernet was detected sending an Internet ARP message for 
another node (not for itself). You may wish to verify that proxy-ARP 
is supposed to be enabled for the selected node. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@Index(ARP)
@IndexSecondary(Primary="Internet",Secondary="ARP")
@IndexSecondary(Primary="protocol type",Secondary="ARP (08-06)")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-PRTTBLFUL, protocol table full - new protocol/name pair not added
@End(ProgramExample)
A SET PROTOCOL_NAME or LOAD command was entered, but there was no room 
in the protocol name table to add another new entry. Increase the value of 
the protocol name table size parameter ICPPRT_MAXNAMES in ETHERMON_PROT.INC, 
then rebuild the ETHERMON program.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-QIONETACP, error queuing status query to DECnet NETACP
@End(ProgramExample)
An attempt to send a query to the DECnet NETACP process to translate a 
DECnet node number was made, but the query could not be queued. An 
accompanying system message will give more details about the error. This 
message can be suppressed with the SET MESSAGES OFF command.
@Index(DECnet)
@Index(NETACP)
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-STRTANLZ, couldn't start TRACE/ANALYZER command
@End(ProgramExample)
A TRACE/ANALYZER command was entered; however, for some system reason, the 
environment for the analyzer subprocess could not be created. The command 
was not processed. An accompanying system error message should explain why 
the command could not be processed (usually indicating some system resource 
or quota limitation).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-W-TOOMANYADR, too many addresses for QUERY command; command ignored
@End(ProgramExample)
The QUERY command was issued with a range of addresses that was too large 
to practically deal with, so the command was ignored. Use a smaller range 
of addresses if you are going to use the QUERY command (less than one whole 
manufacturer's prefix worth is the absolute limit).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-TOOMANYIND, can't nest indirect command files
@End(ProgramExample)
An indirect command file was invoked, which in turn attempted to invoke 
another file. Only one level of indirection is permitted; remove the 
indirect file reference from the first indirect file.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-TRACERPT, post-filter: @u<nn> bytes, @u<nn> messages recorded to file
@End(ProgramExample)
The specified number of messages and bytes of data were recorded in a 
TRACE command's output file. No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-TRACERPT2, pre-filter: @u<nn> bytes, @u<nn> messages received on net
@End(ProgramExample)
The specified number of messages and bytes of data were received from 
the Ethernet during a TRACE command. No action is necessary.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-TRACERPT3, pre-ETHERMON: @u<nn> messages lost before analysis
@End(ProgramExample)
The specified number of network packets were dropped by the Ethernet 
interface device driver during a TRACE command, because ETHERMON couldn't 
keep up with the data rate. No action is necessary (except possibly to use 
a more powerful VAX in future network monitoring).
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-TRACERPTA, pre-analyzer: @u<nn> messages lost due to mailbox full
@End(ProgramExample)
The specified number of network packets were dropped by ETHERMON during a 
TRACE command, because the analyzer module subprocess couldn't keep up with 
the data rate and let its input mailbox overflow. No action is necessary 
(except possibly to use a more powerful VAX in future network monitoring, 
and/or to tune the execution of the analyzer module).
@Index(mailbox)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-E-TRCBSY, couldn't start TRACE command; previous TRACE still busy
@End(ProgramExample)
A TRACE command was entered; however, a previous asynchronous TRACE
command is still running. Abort the running TRACE with TRACE/ABORT, or wait 
for it to finish executing. If there is no active TRACE running, please send 
a problem report to the author, and describe your system's VAX/VMS version 
and ETHERMON version.
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-UNDDECNOD, node @u<nn>.@u<nn> seen on Ethernet; not in DECnet database
@End(ProgramExample)
ETHERMON requested the local DECnet NETACP to translate a DECnet node 
number to a node name, but NETACP did not have a corresponding name in 
its database. Check with your system or network manager as to why 
the specified DECnet node is appearing on your Ethernet but is 
not listed in the local system's DECnet node database. This message will 
only be displayed if you have entered the SET MESSAGES DEBUG command.
@Index(DECnet)
@Index(NETACP)
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-UNKARPOPC, @i<@u[aa-bb-cc-dd-ee-ff]> sent unknown ARP opcode: prot=@i<@u[pp-pp]> opc=@i<@u[pp-pp]>
@End(ProgramExample)
An Internet ARP or RARP message was received, but the ar$op field (see 
NIC.DDN.MIL Request For Comments RFC826.TXT) 
@Index(NIC.DDN.MIL)
@Index(RFC826)
for details of ARP message formats) was not one of the values 01-00, 
02-00, 03-00, 04-00 (the legal values for ARP and RARP), or 05-00, 06-00, 
or 07-00 (dynamic RARP). You may wish 
to determine if there is a node transmitting erroneous packets on your 
Ethernet; if not, please inform the author of your discoveries so that a 
future version of ETHERMON can properly deal with the extensions to the 
ARP protocol. This message can be suppressed with the SET MESSAGES OFF 
command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@Index(ARP)
@Index(RARP)
@IndexSecondary(Primary="protocol type",Secondary="ARP (08-06)")
@IndexSecondary(Primary="protocol type",Secondary="RARP (80-35)")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-UNKETHCHR, unknown Ethernet port characteristic code=@u<xxxx>, @u<xxxx>
@End(ProgramExample)
An undeciphered port characteristics code was received while performing 
an IO$_SENSEMODE operation on the interface. This message can only appear if 
you have compiled ETHERMON with the /D_LINES option on the FORTRAN 
compiler. Check for compatability of your Ethernet interface's I/O 
driver with the standard DEC driver, as documented in the @i<@u[VMS 
I/O User's Reference Manual: Part II]>.
@Index[/D_LINES (FORTRAN qualifier)]
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-UNKETHCNT, unknown Ethernet port counter code=@u<xxxx>, @u<xxxx>
@End(ProgramExample)
An undeciphered port counter ID code was received while performing 
an IO$_SENSEMODE with IO$M_RD_COUNT operation on the interface. This message 
can only appear if you have compiled ETHERMON with the /D_LINES option on the 
FORTRAN compiler. Check for compatability of your Ethernet interface's I/O 
driver with the standard DEC driver, as documented in the @i<@u[VMS 
I/O User's Reference Manual: Part II]>.
@Index[/D_LINES (FORTRAN qualifier)]
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%ETHERMON-I-UNKIPARP, @i<@u[aa-bb-cc-dd-ee-ff]> sent unknown ARP pkt: prot=@i<@u[pp-pp]> Hlen=@i<@u[n]> Plen=@i<@u[n]>
@End(ProgramExample)
An Internet ARP or RARP message was received, but the values of the ar$hrd, 
ar$hln, and/or ar$pln fields (see NIC.DDN.MIL Request For Comments 
RFC:RFC826.TXT) 
@Index(NIC.DDN.MIL)
@Index(RFC826)
for details of ARP message formats) were not legal for IP and/or 
Ethernet addresses. You may wish 
to determine if there is a node transmitting erroneous packets on your 
Ethernet; if not, please inform the author of your discoveries so that a 
future version of ETHERMON can properly deal with the extensions to the 
ARP protocol. This message can be suppressed with the SET MESSAGES OFF 
command.
@Index(SET MESSAGES)
@IndexSecondary(Primary="commands",Secondary="SET MESSAGES")
@Index(ARP)
@Index(RARP)
@IndexSecondary(Primary="protocol type",Secondary="ARP (08-06)")
@IndexSecondary(Primary="protocol type",Secondary="RARP (80-35)")
@End(Group)

@End(Enumerate)
@Section(System Messages Frequently Seen)
@Begin(Enumerate)
@Begin(Group)
@Begin(ProgramExample)
%SMG-E-KEYDEFPRO, key definition is protected - cannot be changed or deleted
@End(ProgramExample)
You attempted to re-define a key (using the DEFINE/KEY command) or delete a 
key definition (using DELETE/KEY) for a key with a permanently defined 
function. The attempt has failed, and the key definition has not changed. 
Use a different key for your local definition.
@Index(DEFINE/KEY)
@IndexSecondary(Primary="commands",Secondary="DEFINE/KEY")
@Index(DELETE/KEY)
@IndexSecondary(Primary="commands",Secondary="DELETE/KEY")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%SYSTEM-F-BADPARAM, bad parameter
@End(ProgramExample)
This error is caused by one of two reasons:
@Begin(Enumerate)
There is already a promiscuous user on the Ethernet interface you are 
attempting to use. Try another interface, or get rid of the existing 
promiscuous user (it could be another invocation of this program).

@Label[V4.x]
You are attempting to run under Version V4.x of VAX/VMS, which does not 
recognize IEEE 802.3 mode operation of the Ethernet interface. ETHERMON can 
be retrofitted to run in Ethernet mode; however, all IEEE 802.3 extended 
messages seen on the cable will be discarded (data that would appear as
Ethernet protocol type AA-AA). To make the change, uncomment all lines in 
ETHERMON.FOR that begin 
with the comment string "C4.x", and recompile and relink ETHERMON. You may 
also need to comment out the lines ending in "! V5.x". Note that these 
edits should not need to be done; ETHERMON should work under either V4.x 
or V5,x after re-compiling and re-linking. Note also that, if you are using 
the "fast" $QIO interface, you should be able to successfully interpret 
IEEE 802.3 messages even if you are using VAX/VMS V4.x. This configuration, 
although theoretically workable, is not supported.
@IndexSecondary(Primary="VAX/VMS",Secondary="V4.x")
@Index(IEEE 802.3)
@End(Enumerate)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%SYSTEM-F-EXBYTLM, exceeded byte count quota
@End(ProgramExample)
Under some installations of VAX/VMS with some homebrew and/or third-party 
software installed, sometimes the SPAWN command will fail with this error. You 
will also find on these systems that VAX DEBUG cannot run in subprocess mode. 
The reason for this is improper values of the SYSGEN parameters 
controlling default mailbox parameters (DEFMBXBUFQUO and MAXBUF); MAXBUF 
should always be larger than DEFMBXBUFQUO, and the user BYTLM quota 
must be at least 10000 bytes larger than DEFMBXBUFQUO for ETHERMON to operate 
(assuming the DEC default value for PQL_MBYTLM; preferably, your user BYTLM 
quota should be considerably larger).
@Index(SPAWN)
@IndexSecondary(Primary="commands",Secondary="SPAWN")
@Index(SYSGEN parameters)
@IndexSecondary(Primary="quotas","Secondary="BYTLM")
@Index(mailbox)
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%RMS-F-EXT, ACP file extend failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded
@End(ProgramExample)
While writing an output disk file (a SHOW, SUMMARIZE, or TRACE command, 
typically), your process exceeded your allowed disk quota. Free up some 
disk space and try again.
@IndexSecondary(Primary="quotas","Secondary="disk")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%SYSTEM-F-EXQUOTA, exceeded quota
@End(ProgramExample)
Typically, this will occur when issuing a SPAWN or TRACE/ANALYZER command, 
because the user account will not have enough BYTLM or PRCLM quota 
(although other quotas may be exceeded) left to create the subprocess. Get 
your quotas raised by your system administrator or reduce the number of 
active subprocesses you are running.
@Index(SPAWN)
@IndexSecondary(Primary="commands",Secondary="SPAWN")
@IndexSecondary(Primary="quotas","Secondary="BYTLM")
@IndexSecondary(Primary="quotas","Secondary="PRCLM")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%SYSTEM-F-NOSUCHNODE, remote node is unknown
@End(ProgramExample)
A symbolic node address was specified on an ADD FILTER or SET FILTER 
command, but the specified DECnet node name or Internet IP address could 
not be found in the address name table. Either specify the address 
correctly, or add the address specification to the address table. This 
message may appear when using the ADD or SET FILTER commands immediately 
after starting ETHERMON, before ETHERMON has seen the node speak the 
corresponding protocol; in that case, just wait a little while until the 
remote node speaks the appropriate protocol (in batch jobs, use the WAIT 
command to stall a few seconds; an example is given on page 
@PageRef[WAITdemo]).
@Index(WAIT)
@IndexSecondary(Primary="commands",Secondary="WAIT")
@End(Group)

@Begin(Group)
@Begin(ProgramExample)
%HELP-E-OPENIN, error opening @i<@u{disk:[dir]}>ETHERMON.HLB; as input
-RMS-E-FNF, file not found
@End(ProgramExample)
Upon issuing the HELP command, the help library file ETHERMON.HLB could 
not be found. This is generally due to placing the .HLB file in a 
different directory from the ETHERMON.EXE file; all ETHERMON run-time 
files expect to be in the same directory (location of source files is 
irrelevant, except that they all must be in the current default 
directory at build time). Either move the help library file to the 
directory containing the .EXE file, or edit appropriately the subroutine 
HELP in the file ETHERMON.FOR and rebuild ETHERMON.
@Index(help library)
@IndexSecondary(Primary="HELP",Secondary="errors")
@End(Group)
@End(Enumerate)
@Appendix(Known Ethernet Data)
There are a great deal of numbers associated with the Ethernet. Some 
of these numbers are in the DEC/Xerox/Intel and/or IEEE 
specifications. Some of them were assigned by various authoritative 
bodies. Some of them were just claimed by squatter's rights 
(thankfully very few of these). The information used to pre-load 
ETHERMON's protocol type and manufacturer prefix tables, and, in general, 
analyze the data packets (both in ETHERMON and the unsupported 
utilities), came from many sources:
@Begin(Itemize)
@i<@u[VMS I/O User's Reference Manual: Part II]>, Version 5.0, Digital 
Equipment Corporation, April 1988, order number AA-LA85A-TE, in the chapter on 
Ethernet interfaces (previous editions also used)

@i<@u[VMS Network Control Program Manual]>, Version 5.0, Digital 
Equipment Corporation, April 1988, order number AA-LA50A-TE, in the sections 
on the SHOW LINE command and on line counters (previous editions also used)

@i<@u[VMS System Services Reference Manual: Part II]>, Version 5.0, Digital 
Equipment Corporation, April 1988, order number AA-LA69A-TE (previous editions 
also used)

@i<@u[DECnet Digital Network Architecture Phase IV: Maintenance Operations 
Functional Specification]>, MOP Version 3.0.0, Digital Equipment 
Corporation, December 1983, order number AA-X436A-TK.

DoD Internet Requests For Comments (RFC's), as obtained from the 
Network Information Center (the NIC, with Internet address NIC.DDN.MIL) 
via anonymous FTP:
@Index(NIC.DDN.MIL)
@Begin(Enumerate)
RFC 768, @u[User Datagram Protocol], Postel, J.B., August 1980
@Index(RFC768)

RFC 791, @u[Internet Protocol], Postel, J.B., September 1981
@Index(RFC791)

RFC 792, @u[Internet Control Message Protocol], Postel, J.B., September 1981
@Index(RFC792)

RFC 793, @u[Transmission Control Protocol], Postel, J.B., September 1981
@Index(RFC793)

RFC 826, @u[Ethernet Address Resolution Protocol: Or converting 
network protocol addresses to 48.bit Ethernet address for transmission 
on Ethernet hardware], Plummer, D.C., November 1982
@Index(RFC826)

RFC 1057, @u[RPC: Remote Procedure Call Protocol specification: Version 
2], Sun Microsystems, Inc., June 1988
@Index(RFC1057)

RFC 1058, @u[Routing Information Protocol], Hedrick, C.L., June 1988
@Index(RFC1058)

RFC 1060, @u[Assigned Numbers], Reynolds, J.K.; Postel, J.B., March 1990 (the 
now-obsoleted RFC 1010, May 1987, was also used in earlier versions of ETHERMON)
@Index(RFC1060)

RFC 1094, @u[NFS: Network File System Protocol specification], Sun 
Microsystems, Inc., March 1989
@Index(RFC1094)

RFC 1157, @u[Simple Network Management Protocol (SNMP)], Case, J.D.; Fedor, 
M.; Schoffstall, M.L.; Davin, C., May 1990
@Index(RFC1157)
@End(Enumerate)

@i<@u[Inside AppleTalk]>, 2nd ed., Sidhu, G., Andrews, R.F., and 
Oppenheimer, A.B., 1990.

other obscure vendor documents whose titles have been lost in the 
mists of time

sheer trial and error by many parties ("Ah hah! Another unknown manufacturer 
prefix... but it speaks IP. What happens if I Telnet to it? Ahhh... an 
operating system signon message, so now I know what it is 
{@i<@b[maybe...]>}.")
@End(Itemize)

As none of these sources is either complete or infallible, the data 
known by ETHERMON is necessarily incomplete and prone to errors. All 
the information the author was able to obtain is embedded in this 
program (with the exception of non-SNAP IEEE 802.3 data; that is not 
yet properly supported by ETHERMON). If you find any errors or 
determine any new manufacturer prefixes or protocol types, please let 
the author know, so that the information can be shared with all in a 
new release of ETHERMON. The author's address (electronic and 
real-world) is given in section @Ref[author] on page @PageRef[author].

@Section(Manufacturer Prefixes)
These are the manufacturer prefixes currently known to ETHERMON, as 
displayed by the SHOW MANUFACTURERS/ALL command. Note that this only 
shows the physical prefix assignments. As far as the author knows, the 
corresponding multicast address blocks (same prefix except the LSB of 
the first byte is set) are also assigned to the same party. Generally, 
the name displayed is of the Ethernet @i<@u[interface]> manufacturer, 
which is not necessarily the same as the whole computer's 
manufacturer; in cases where two names are displayed, separated by a 
slash "/", this generally implies that either two manufacturers were 
merged on the corporate level, or that the second manufacturer is 
(apparently) the exclusive user of the first manufacturer's Ethernet 
boards in the specified address block. None of this, however, is 
confirmed.
@Index(manufacturer prefix)

@Begin(OutputExample)
00-00-0C Cisco[Cisco]                 00-DD-0F Ungermann-Bass[U-B]
00-00-0F NeXT[NeXT]                   02-04-06 BBN internal[BBN]
00-00-10 Sytek[Sytek]                 02-07-01 MICOM/InterLAN[InterLAN]
00-00-1B Novell[Novell]               02-60-86 Satelcom MegaPac (UK)[Satelco
00-00-1D Cabletron[Cabltron]          02-60-8C 3Com (IBM PC)[3Com]
00-00-20 Data Industrier AB[DIAB]     02-CF-1F CMC[CMC]
00-00-22 Visual Technology[VisTec]    08-00-02 3Com/Bridge[Bridge]
00-00-2A TRW[TRW]                     08-00-03 Adv. Computer Communic.[ACC]
00-00-3D AT&T[AT&T]                   08-00-05 Symbolics LISP machine[Symbol
00-00-55 AT&T[AT&T]                   08-00-07 Apple Computer[Apple]
00-00-5A S & Koch[S&K]                08-00-08 BBN[BBN]
00-00-5E I-net Asnd.Num.Authority[IAN 08-00-09 Hewlett-Packard[H-P]
00-00-65 Network General[N-G]         08-00-0A Nestar Systems[Nestar]
00-00-6B MIPS[MIPS]                   08-00-0B Unisys[Unisys]
00-00-77 MIPS[MIPS]                   08-00-10 AT&T[AT&T]
00-00-7A Ardent[Ardent]               08-00-11 Tektronix, Inc.[Tektr]
00-00-89 Cayman Systems[Cayman]       08-00-14 Excelan[Excelan]
00-00-8E Solburne (Sun clone)[Solburn 08-00-17 Network System Corp.[NSC]
00-00-93 Proteon 802.3/802.4[Proteon] 08-00-1A Data General[DG]
00-00-94 Asante (Macintosh)[Asante]   08-00-1B Data General[DG]
00-00-9F Ameristar Technology[Amersta 08-00-1E Apollo[Apollo]
00-00-A2 Wellfleet[Wellflt]           08-00-20 Sun Microsystems[Sun]
00-00-A3 Network Appl. Technology[N-A 08-00-22 NBI[NBI]
00-00-A6 Network General[N-G]         08-00-25 CDC[CDC]
00-00-A7 NCD[NCD]                     08-00-26 Norsk Data[Norsk]
00-00-A9 Network System Corp.[N-S]    08-00-27 PCS Computer System GmbH[PCS]
00-00-AA Xerox[Xerox]                 08-00-28 Texas Instruments[TI]
00-00-AB Logic Modeling Systems[LMS]  08-00-2B DEC[DEC]
00-00-B0 RAD Network Devices Ltd.[RND 08-00-2E Metaphor[Metaphor]
00-00-B3 CIMLinc[CIMLinc]             08-00-2F Prime Computer[Prime]
00-00-B5 Vista[Vista]                 08-00-36 Intergraph[Intrgrph]
00-00-B7 Dove[Dove]                   08-00-37 Fujitsu-Xerox[Fujitsu]
00-00-BB Tri-Data Systems, Inc.[TriDa 08-00-38 Bull[Bull]
00-00-BC Allen-Bradley[A-B]           08-00-39 Spider Systems[Spider]
00-00-C0 Western Digital[W-D]         08-00-3E Motorola ?[Mot?]
00-00-C6 Hewlett-Packard INO(Eon)[HP  08-00-41 DCA Digital Comm. Assoc.[DCA]
00-00-C8 Altos[Altos]                 08-00-45 ???? (Xylogics?)[????]
00-00-C9 Emulex (term.servers)[Emulex 08-00-46 Sony[Sony]
00-00-D7 Dartmouth College[Dartmth]   08-00-47 Sequential[Sequent]
00-00-D8 3Com/Novell ?? PS/2[? PS/2]  08-00-49 Univation[Univatn]
00-00-DD Gould[Gould]                 08-00-4C Encore[Encore]
00-00-DE Unigraph[Unigraph]           08-00-4E BICC[BICC]
00-00-E2 Acer Counterpoint[Acer C]    08-00-56 Stanford University[Stanford]
00-00-EF Alantec[Alantec]             08-00-58 ??? (DECsystem-20)[?DEC20]
00-00-FD High Level Hardware[HLH]     08-00-5A IBM[IBM]
00-01-02 BBN internal[BBN]            08-00-67 Comdesign[Comdesgn]
00-01-1B Network Peripherals Inc.[NPI 08-00-68 Ridge[Ridge]
00-17-00 Kabel[Kabel]                 08-00-69 Silicon Graphics/Iris[Iris]
00-80-19 Dayna Etherprint[Dayna]      08-00-6A AT&T[AT&T]
00-80-2D Xylogics, Inc.[Xylogic]      08-00-6E Excelan/Concurrent[Cncrrnt]
00-80-52 TE Concepts[TE]              08-00-75 Danish Data ElektronikAS[DDE]
00-80-8C Frontier Software Dvlpmt[Fro 08-00-77 Retix Inc.[Retix]
00-80-A3 Lantronix[Lantrnx]           08-00-7C Vitalink bridge[Vitalink]
00-80-A9 Clearpoint[Clearpnt]         08-00-80 XIOS[XIOS]
00-80-D3 Shiva[Shiva]                 08-00-86 Imagen/QMS[I/QMS]
00-AA-00 Intel[Intel]                 08-00-87 Xyplex[Xyplex]
00-DD-00 Ungermann-Bass[U-B]          08-00-89 Kinetics[Kinetics]
00-DD-01 Ungermann-Bass[U-B]          08-00-8B Pyramid[Pyramid]
00-DD-02 Ungermann-Bass[U-B]          08-00-8D XYVision[XYVision]
00-DD-03 Ungermann-Bass[U-B]          08-00-8E Jupiter[Jupiter]
00-DD-04 Ungermann-Bass[U-B]          08-00-90 Retix Inc.[Retix]
00-DD-05 Ungermann-Bass[U-B]          10-00-5A IBM[IBM]
00-DD-06 Ungermann-Bass[U-B]          48-44-53 HDS ??[HDS ??]
00-DD-07 Ungermann-Bass[U-B]          AA-00-00 DEC[DEC]
00-DD-08 Ungermann-Bass[U-B]          AA-00-01 DEC[DEC]
00-DD-09 Ungermann-Bass[U-B]          AA-00-02 DEC[DEC]
00-DD-0A Ungermann-Bass[U-B]          AA-00-03 DEC[DEC]
00-DD-0B Ungermann-Bass[U-B]          AA-00-04 DEC networking[DECnet]
00-DD-0C Ungermann-Bass[U-B]          CE-00-00 Ethernet spec (global)[gbl]
00-DD-0D Ungermann-Bass[U-B]          FE-FF-FF Ethernet spec (global)[gbl]
00-DD-0E Ungermann-Bass[U-B]
Total of 141 manufacturers defined, 141 displayed.
@End(OutputExample)

@Section(Multicast Addresses)
These are the multicast address currently known to and "hardwired" 
into ETHERMON. There are two types of multicast addresses: those that 
have a single fixed address (truly hardwired), and those which are 
assigned a range of addresses where the specific address not only 
means multicast but to a specific subgroup within the total group 
covered by the set of multicast addresses. The latter set, in a few 
cases, can be recognized and identified by ETHERMON as belonging to 
the specific subgroup, sometimes even naming the subgroup (ex: local 
area VAXcluster group ID multicasts).
@Index(address)
@Index(multicast address)

The fixed multicast addresses are:
@Begin(OutputExample)
  01-80-C2-00-00-00 bridge spanning tree 
  01-DD-00-68-DE-00 U-B:??? #1 
  01-DD-00-A1-BC-00 U-B:??? #2 
  01-DD-00-FF-FF-FF U-B:??? #3 
  01-DD-01-00-00-00 U-B:spanning tree hello
  09-00-02-04-00-01 Bridge:printer msgs 
  09-00-02-04-00-02 Bridge:All Bridges (DBD/DSTD) 
  09-00-07-FF-FF-FF Apple:Appletalk ARP brdcst 
  09-00-09-00-00-01 H-P:Probe 
  09-00-09-00-00-04 H-P:DTC 
  09-00-1E-00-00-00 Apollo:DOMAIN 
  09-00-2B-00-00-00 DEC:MUMPS? 
  09-00-2B-00-00-01 DEC:DSM/DTP? 
  09-00-2B-00-00-03 DEC:LAN Traffic Monitor 
  09-00-2B-00-00-04 DEC:MAP End-System Hello 
  09-00-2B-00-00-05 DEC:MAP Intermediate-Sys Hello 
  09-00-2B-00-00-06 DEC:CSMA/CD Encryption 
  09-00-2B-00-00-07 DEC:NetBIOS Emulator (PCSG) 
  09-00-2B-00-00-0F DEC:LAT (LANCE) 
  09-00-2B-01-00-00 DEC:Bridge Mgmt 
  09-00-2B-01-00-01 DEC:Bridge hello 
  09-00-2B-02-00-00 DEC:Lvl 2 Routers 
  09-00-2B-02-01-00 DEC:DNA Name Svc Advert 
  09-00-2B-02-01-01 DEC:DNA Name Svc Solicit 
  09-00-2B-02-01-02 DEC:DNA Time Service? 
  09-00-2B-04-00-00 DEC:LA Sys Transport (LAST) 
  09-00-2B-23-00-00 DEC:Argonaut Console 
  09-00-77-00-00-01 Retix:bridge spanning tree 
  09-00-7C-01-00-01 Vitalink:DLS Multicast 
  09-00-7C-01-00-02 Vitalink:DLS Hello Multicast 
  09-00-7C-01-00-03 Vitalink:DLS Inlink Hello Multi 
  09-00-7C-01-00-04 Vitalink:DLS/Non-DLS Multicast 
  09-00-7C-02-00-05 Vitalink:diagnostics 
  09-00-7C-04-00-01 Vitalink:bridge logging 
  09-00-7C-05-00-01 Vitalink:gateway? 
  09-00-7C-05-00-02 Vitalink:Network Validation 
  09-00-87-00-FF-FF Xyplex:Load Assistance
  AB-00-00-01-00-00 DEC:Dump/Load Assistance 
  AB-00-00-02-00-00 DEC:Remote Console 
  AB-00-00-03-00-00 DEC:Lvl 1,2 Routers 
  AB-00-00-04-00-00 DEC:All Endnodes 
  AB-00-03-00-00-00 DEC:LAT (old) 
  CF-00-00-00-00-00 gbl:Loopback Assistance 
  FF-FF-FF-FF-FF-FF gbl:Broadcast 
Total of 44 addresses defined, 0 active, 44 displayed.
@End(OutputExample)

The variable address blocks are:
@Begin(Enumerate)
the DEC Local Area VAXcluster group ID multicast addresses, of the 
form AB-00-04-01-@i<xx-yy>, where the hexadecimal number @i<yyxx> is 
the group ID number plus 256 (decimal).
@Index(LAVC)
@Index(VAXcluster)

the AppleTalk router zone broadcast addresses 09-00-07-@i<aa-bb-cc>, 
where @i<aa-bb-cc> is a dynamically negotiated-for code for a particular 
AppleTalk zone.
@Index(AppleTalk)
@End(Enumerate)

@Section(Protocol Types)
These are the protocol types (IEEE 802.3 SNAP subprotocols and 
plain-vanilla Ethernet protocols) currently known to ETHERMON, as 
displayed by the SHOW PROTOCOL_NAMES/ALL command. In cases where the 
protocol type is assigned to a particular manufacturer, that 
manufacturer's "short name" (the one in square brackets in the 
manufacturer prefix table) is prepended to the protocol name (if the 
name is known). Some protocols are assigned to manufacturers but the 
use thereof is unknown; these have "???" as their name, or only the 
manufacturer's name is given.
@Index(protocol type)

@Begin(OutputExample)
 02-00 XEROX: PUP                  80-6E Landmark Graphics
 02-01 XEROX: PUP Addr. Trans      80-6F Landmark Graphics
 04-00 Nixford                     80-70 Landmark Graphics
 06-00 XEROX: NS IDP               80-71 Landmark Graphics
 08-00 Internet IP (DoD)           80-72 Landmark Graphics
 08-01 Internet IP (X.75)          80-73 Landmark Graphics
 08-02 Internet IP (NBS)           80-74 Landmark Graphics
 08-03 Internet IP (ECMA)          80-75 Landmark Graphics
 08-04 Chaosnet                    80-76 Landmark Graphics
 08-05 X.25 Level 3                80-77 Landmark Graphics
 08-06 Internet ARP                80-7A Matra
 08-07 XNS Compatibility           80-7B Danak Data Elektronik
 08-1C Symbolics: private          80-7C U.M.:Merit Internodal
 08-88 Xyplex: terminal net        80-7D Vitalink
 08-89 Xyplex: ???                 80-7E Vitalink
 08-8A Xyplex: ???                 80-7F Vitalink
 09-00 U-B: Net Debug              80-80 Vitalink: TransLAN III
 0A-00 XEROX: 802.3 PUP            80-81 Counterpoint Computers
 0A-01 XEROX: 802.3 PUP AdrTrans   80-82 Counterpoint Computers
 0B-AD Banyan Systems              80-83 Counterpoint Computers
 10-00 Berkeley: trailer           80-9B AppleTalk
 10-01 IP trailer 1 blk           i80-9B AppleTalk
 10-02 IP trailer 2 blks           80-9C Datability
 10-03 IP trailer 3 blks           80-9D Datability
 10-04 IP trailer 4 blks           80-9E Datability
 10-05 IP trailer 5 blks           80-9F Spider Sys.LAN Monitor
 10-06 IP trailer 6 blks           80-A3 Nixdorf
 10-07 IP trailer 7 blks           80-A4 Siemens Gammasonics
 10-08 IP trailer 8 blks           80-A5 Siemens Gammasonics
 10-09 IP trailer 9 blks           80-A6 Siemens Gammasonics
 10-0A IP trailer 10 blks          80-A7 Siemens Gammasonics
 10-0B IP trailer 11 blks          80-A8 Siemens Gammasonics
 10-0C IP trailer 12 blks          80-A9 Siemens Gammasonics
 10-0D IP trailer 13 blks          80-AA Siemens Gammasonics
 10-0E IP trailer 14 blks          80-AB Siemens Gammasonics
 10-0F IP trailer 15 blks          80-AC Siemens Gammasonics
 16-00 VALID systems               80-AD Siemens Gammasonics
 42-42 PCS Basic Block             80-AE Siemens Gammasonics
 52-08 BBN: SIMnet                 80-AF Siemens Gammasonics
 60-00 DEC: Experimental           80-B0 Siemens Gammasonics
 60-01 DEC: MOP Dump/Load          80-B1 Siemens Gammasonics
i60-01 DEC: MOP Dump/Load          80-B2 Siemens Gammasonics
i60-02 DEC: MOP Remote Console     80-B3 Siemens Gammasonics
 60-02 DEC: MOP Remote Console     80-C0 DCA: ???
 60-03 DEC: DECnet Phase 4         80-C1 DCA: Data Exchange
 60-04 DEC: LAT                    80-C2 DCA: ???
 60-05 DEC: Diagnostics            80-C3 DCA: ???
 60-06 DEC: Customer/VAXELN        80-C6 Pacer Software
 60-07 DEC: LAVC                   80-C7 Applitek
 60-08 DEC: AMBER                  80-C8 Intergraph
 60-09 DEC: MUMPS                  80-C9 Intergraph
 60-10 3Com: ???                   80-CA Intergraph
 60-11 3Com: ???                   80-CB Intergraph
 60-12 3Com: ???                   80-CC Intergraph
 60-13 3Com: ???                   80-CD Harris
 60-14 3Com: ???                   80-CE Harris
 70-00 U-B: NIU Boot               80-CF Taylor Instruments
 70-01 U-B: Network Management     80-D0 Taylor Instruments
 70-02 U-B: NIU Diagnostic         80-D1 Taylor Instruments
 70-03 Interlan: ???               80-D2 Taylor Instruments
 70-05 U-B: Bridge                 80-D3 Rosemount Corp.
 70-06 U-B: Network Management     80-D4 Rosemount Corp.
 70-20 LRT: ???                    80-D5 IBM: SNA Service
 70-21 LRT: ???                    80-DD Varian Associates
 70-22 LRT: ???                    80-DE I.S. TRFS
 70-23 LRT: ???                    80-DF Integrated Solutions
 70-24 LRT: ???                    80-E0 Allen Bradley
 70-25 LRT: ???                    80-E1 Allen Bradley
 70-26 LRT: ???                    80-E2 Allen Bradley
 70-27 LRT: ???                    80-E3 Allen Bradley
 70-28 LRT: ???                    80-E4 Datability
 70-29 LRT: ???                    80-E5 Datability
 70-30 Proteon: ???                80-E6 Datability
 70-34 Cabletron                   80-E7 Datability
 80-03 Cronus VLN                  80-E8 Datability
 80-04 Cronus Direct               80-E9 Datability
 80-05 HP Probe                    80-EA Datability
 80-06 Nestar                      80-EB Datability
 80-08 AT&T                        80-EC Datability
 80-10 Excelan                     80-ED Datability
 80-13 SilGraph: diag              80-EE Datability
 80-14 SilGraph: net games         80-EF Datability
 80-15 SilGraph: reserved          80-F0 Datability
 80-16 SilGraph: XNS NameSvc       80-F2 Retix: Router Mgmt
 80-19 Apollo: remote file sys     80-F3 ARP AppleTalk
 80-2E Tymeshare: ??              i80-F3 ARP AppleTalk
 80-2F Tigan Inc.: ?               80-F4 Kinetics: Appletalk?
 80-35 Reverse ARP                 80-F5 Kinetics: Appletalk?
 80-36 Aeonic Systems: ??          80-F7 Apollo: ???
 80-38 DEC: LAN Bridge             80-FF Wellfleet Communications
 80-39 DEC: DSM/DTP                81-00 Wellfleet Communications
 80-3A DEC: Argonaut console       81-01 Wellfleet Communications
 80-3B DEC: VAXeln (hah!)          81-02 Wellfleet Communications
 80-3C DEC: DNA Name Service       81-03 Wellfleet Communications
 80-3D DEC: Encryption             81-07 Symbolics: private
 80-3E DEC: DNA Time Service       81-08 Symbolics: private
 80-3F DEC: LAN Traffic Monitor    81-09 Symbolics: private
 80-40 DEC: NetBios emulator       81-2B Talaris TLAP data
 80-41 DEC: LA Sys Transport       81-30 Waterloo Microsystems
 80-42 DEC: -unassigned-           81-31 VG Laboratory Systems
 80-44 Planning Research Corp.     81-37 Novell: old NetWare IPX
 80-46 AT&T                        81-38 Novell: NetWare IPX
 80-47 AT&T                        81-39 KTI: ???
 80-49 Expert Data                 81-3A KTI: ???
 80-5B Stanford V Exper            81-3B KTI: ???
 80-5C Stanford V Product          81-3C KTI: ???
 80-5D Evans & Sutherland          81-3D KTI: ???
 80-60 Little Machines             81-4C SNMP
 80-62 Counterpoint Computers      81-4F TE Concepts
 80-65 U.Mass.                     85-2B Talaris TLAP status
 80-66 U.Mass.                     90-00 Loopback
 80-67 Veeco Integrated Auto       90-01 Bridge: XNS mgmt
 80-68 General Dynamics            90-02 Bridge: TCP/IP sys
 80-69 AT&T                        90-03 Bridge: loop detect
 80-6A Autophon                    AF-AF Logicraft: ???
 80-6C ComDesign                   FF-00 BBN VITAL-LANBridge
 80-6D Compugraphic
Total of 233 protocols defined, 233 displayed.
@End(OutputExample)