ETHLOAD is a shareware running on any MS-DOS PC with an Ethernet
or Token Ring controller.
Currently, ETHLOAD supports the following drivers (for Ethernet and Token Ring):
The purposes of ETHLOAD are twofold:
ETHLOAD allows you to:
In a TCP/IP network, ETHLOAD allows you to:
In a DECnet network, ETHLOAD allows you to:
In an OSI network, ETHLOAD allows you to:
In a Microsoft NetBEUI network, ETHLOAD allows you to:
In a Novell NetWare network, ETHLOAD allows you to:
In a LAN Manager or Windows for Workgroups network, ETHLOAD allows you to:
This software is based on the very first version of ETHLOAD I
have developed while I was working in a company called Network
Research Belgium. This version was already free and in the
public domain thanks to the management of this company.
Now, the source code has been completely rewritten and improved. I just mention this copyright to be fair-play to my old colleagues.
Right now, all software developments are made home and tested after working hours in my current employeer: Cisco Systems. So, here follows the usual disclaimer: Cisco Systems and NRB are by no means responsible for any good or bad effects of this program. And by the way, the quality of ETHLOAD does not reflect the usual quality of NRB or Cisco Systems software.
If you have problems to run ETHLOAD, please read carefully this
manual and also check the common pitfalls in appendix A.4.
The official Ethload home page is at
http://www.hec.be/~evyncke/utilities/ethload.
Anyway, you can get some support from the author since he wants
to promote this software... You can reach the author through email:
evyncke@hec.be or by post mail:
Eric Vyncke
Allée des Chardonnerets, 3
B-4432 Alleur
Belgium (Europe).
If you are happy with ETHLOAD, my little sons, Pierre (born 92) and Thibault (born August 95), would appreciate to receive any postcard (they still live with us :-)!
Due to the large 'success' of ETHLOAD, I'm no more able
to reply to all questions or comments addressed to my email address.
In no case, shall I answer to phone calls at my office (except for those of you who are working for Cisco Systems)... Don't forget that I am paid by Cisco Systems and that I have a lot of work to do at the office :-)
The reference URL of Ethload is http://www.hec.be/~evyncke/utilities/ethload
Mirror servers are welcome specially because the Internet connectivity
is quite poor!
If you do so, please warn me by email in order to keep a list of distribution channels.
I would like to thank anyone of you about his/her comments.
I thank especially my beta-testers:
Ralf Buettemeyer, buettemeyer@hagenuk.netuse.de
Bob Childress, bchildress@ti.com
Michel Dalle, michel@d92.cb.sni.be
Serge Hoffman, Serge.Hoffman@belgium.honeywell.com
Niels Kr. Jensen, msterlje@vm.uni-c.dk
Hans-Joachim Koch, koch@lifra.lif.de
D. Lange, cintra@u.washington.edu
Neil J. Long, Neil.Long@materials.oxford.ac.uk
Hans-Michael Pronk, hpronk@hk.nl
A.A.L. Reijnierse, A.A.L.Reijnierse@research.ptt.nl
Frank Van Uffelen, frankvu@bix.com, fvu@te6.siemens.be
I thank also for comments, suggestions, ...:
Joe Doupnik, jrd@cc.usu.edu
Knut Eckstein, eckstein@isd.uni-stuttgart.de
Thomas Gasser, thomasg@staff.tc.umn.edu
Derek Johnston, ugcsjj9697@mtvms2.mtech.edu
Ross Lazarus, rossl@westmead.health.su.oz.au
Ted Llellewyn, tsl@panix.com
Jos Minnema, jos.minnema@pagv.agro.nl
Craig Morgan, cmrcm@staffs.ac.uk
Russ Nelson, nelson@crynwr.com
Hugo Philips, zigo@uc.sni.be
Oliver Rehmann, orehmann@itr.ch
Lars Scheffmann, scheffmann@dou.dk
Russell Thamm, rmt@gwd.erl.dsto.gov.au
And, all of you who have send a postcard :-)
As usual, all trademarks (Ethernet, DEC, NetWare, ...) are properties of their respective owners.
After being flamed on some mailing lists for having put a sniffer
source code in the public domain and as I understand their fears
(even if a large bunch of other Ethernet sniffers are available
everywhere), I have decided that the source code is not made available.
If you do need some parts of code, please refer first to public domain sniffers before asking me for parts of the code. What can be disclosed to you, is some parts of ETHLOAD, please email me for this.
All version of ETHLOAD (1.01 to 1.04) are copyrighted partly by
NRB and Eric Vyncke.
Version 1.01, 1.02, 1.03 and 1.04 were and are still free, you
may use it, copy it (on any support), distribute it as long as
you don't earn money from it (of course you may get paid a little
for the media/transmission cost). This right is given for an unlimited
period of time :-) I would appreciate it if my little sons
received a postcard from you (see 2.3).
As ETHLOAD is now more than 65,000 lines of C code, version ETHLOAD 2.00 is now a shareware with two possibilities:
The registration fee (USD $200, ECU/Euro 200, BEF 8000) will allow
you the right to use it for an unlimited period of time on any
PC within your organization. Moreover, you will receive a 'registration
key' that will allow you to get print-outs of ETHLOAD, an
Excel compatible file for the load of the day, a larger number
of internal buffers (so less dropped frames), a fully configurable
of table size (in order to avoid the 'Filled since ...' message).
See the attached registration form.
Version 2.0 has a completely different screen layout. The code
is now completely different from the code of the NRB version and
the copyright of NRB has been deleted.
Now, enough about these stuffs, let's have fun and start ETHLOAD
!
ETHLOAD should never be a major security leak on your LAN.
ETHLOAD just may disclose the addresses used in your LAN and also
the usernames of people.
If for some reason, you HAVE to monitor some telnet/rlogin/FTP/POP
sessions, ETHLOAD will be able to do this. To be allowed to monitor
these sessions or to check the contents of connect initiate of
DECnet, you need a special software key linked to the Ethernet
ROM address of your PC. This key will be delivered only after
I have received an OFFICIAL paper letter from a very high level
manager of your company (e.g. for University the rector or for
a commercial organisation the head of EDP department or of a CEO).
This letter should bear the name of the PC operator, his/her email
address and the physical address of the PC. Even with this paper
letter, the author may not give you the authorization for any
reason.
In order to run in basic mode (i.e. without translation of addresses
into names,...) ETHLOAD does not require any configuration file.
The configurations are required only if you want to achieve good
printings: host name instead of addresses, ...
It is possible to suppress the messages about loading these files,
by using the -q option when starting ETHLOAD.
All configuration files are in the same format:
Most of these files are the MS-DOS image of the well known TCP/IP
files for UNIX: /etc/hosts, /etc/ethers, /etc/protocols, ... The
simplest way to use them is to FTP them from your UNIX box.
If you are using TCP/IP you should FTP /etc/hosts of a UNIX host
and perhaps add some MAC addresses to the ETHERS file.
If you are using DECnet, you probably don't need to modify any
of these files.
If you are using another protocol, you will probably need to modify
ETHERS file together with TYPES and/or SAPS.
All these optional files must be located in the current directory
of the current drive or in the directory specified by the MS-DOS
environment variable ETHLOAD.
When ETHLOAD first runs or when one configuration file is changed,
a new index file (usually with the .EVX extension) is created
in the same directory as for the configuration file. This also
means that you need write access to this directory.
If a configuration file is missing, ETHLOAD will complain about
that but will further continue to execute. If an index file cannot
be created, ETHLOAD will also complain and continue.
This file contains the mapping between MAC Ethernet addresses
into host names.
The key token is the Ethernet MAC address in the format HH-HH-HH-HH-HH-HH
where HH is a pair of hexadecimal digits.
The value token is any character string representing the name
of this host.
Part of ETHERS file:
AB-00-03-00-00-00 DEC: Local Area Transport -LAT-
FF-FF-FF-FF-FF-FF Broadcast
CF-00-00-01-00-00 Loopback Assistance
00-00-00-00-00-00 Null Address
Remark: ETHLOAD is smart enough to recognize a DECnet node and
display the DECnet address of any MAC address. If you want to
display DECnet address by node name, you may use the MKNODE.EXE
program documented in annex A.3.
Remark 2: ETHLOAD is also listening for ARP requests and replies,
so it can display the IP address of any MAC address.
Remark 3: ETHLOAD as it is (i.e. without ETHERS) cannot even display
correctly well known address as the null address or even the broadcast
address.
Remark 4: you should add your own MAC addresses only if you are
not using DECnet or TCP/IP, moreover, you should add these addresses
at the end of ETHERS file and keep the original contents of ETHERS.
This file contains the mapping between IP address and host names.
The key token is an IP address in the format ddd.ddd.ddd.ddd where
ddd is up to three decimal digits.
The value token is any character string representing the name
of this host.
Part of HOSTS file:
139.21.20.18 d012s509.mch.sni.de d012s509
139.21.18.140 d012s322.mch.sni.de d012s322
139.21.22.206 d012s712 rm400ap 139.21.24.1 cisco.ap.mch.sni.de
139.24.16.44 baumann
The best way to initiate this file is to get a /etc/hosts from a UNIX machine (or the stdout of the ypcat hosts.byaddr if you are running NIS).
This file contains the mapping between IP address and network
names. It is used to display the IP addresses when no information
can be found in the host file.
The key token is an IP address in the format ddd.ddd.ddd.ddd where
ddd is up to three decimal digits.
The value token is any character string representing the name
of this network.
Part of NETWORKS file:
193.210.175.0 PS
193.210.184.0 CSL
The best way to initiate this file is to get a /etc/networks from a UNIX machine (or the stdout of the ypcat networks.byaddr if you are running NIS) and use sed to get the correct format.
This file contains the mapping between IP protocols and protocol
names.
The key token is a decimal number up to 255.
The value token is any character string representing the name
of the protocol.
One again, the best way to initiate this file is to get /etc/protocols
from a Unix machine or using the PROTOCOL file you may have receive
with ETHLOAD. The first solution is probably not useful since
/etc/protocols are always nearly the same.
The shipped PROTOCOL file contains:
0 ip
1 icmp
3 ggp, gateway-gateway protocol 6 tcp 8 egp, exterior gateway protocol 12 pup 17 udp 20 hmp, host monitoring protocol 22 xns-idp
27 rdp, reliable datagram protocol
This file contains the mapping between IEEE 802.2 LLC SAP and
SAP names.
The key token is two hexadecimal digits.
The value token is the name representing the Service Access Point.
Part of a sample SAPS file:
80 3Com XNS
8E Proway-LAN
AA TCP/IP SNAP (Ethernet type in LLC) BC Banyan VINES E0 Novell NetWare
F0 IBM NetBIOS
Remark: ETHLOAD has a built-in knowledge of SNAP.
This file contains the mapping of TCP (resp. UDP) well-known services
ports.
The key token is a decimal number up to 65535 which is the port
number assigned to the service.
Part of a sample WKS.TCP file:
79 finger
21 ftp
101 hostnames 2156 informix
1524 ingreslock
This file together with WKS.UDP contains all the information of
the usual /etc/services
UNIX file but in a slightly different format.
Since the file /etc/services is always the same on all Unix machine, you may probably use the files provided with ETHLOAD.
This file contains the mapping of the DIX Ethernet packet type
into names.
The key token is 4 hexadecimal digits.
Part of a sample TYPES file:
0600 XNS
0601 XNS Address Translation
0800 DOD IP
0801 X.75 internet
This file contains the mapping between the IEEE vendor codes and
the vendor names. The IEEE vendor code is representing the most
significant three bytes of the MAC address of any adapter built
by this manufacturer.
The key token is 3 bytes represented each by two hexadecimal digits,
each byte is separated by a dash.
Part of a sample VENDORS file:
00-00-0C cisco
00-00-0F NeXT
00-00-10 Sytek
00-00-1D Cabletron
This file contains the mapping between the DECnet object number
and the object name.
The key token is a decimal number between 1 and 255.
The file shipped should be enough for all sites. Here follow some
lines of the file:
25 MIRROR
26 EVL
27 MAIL 29 PHONE
42 CTERM
This file contains the mapping between the XNS (or IPX) network
numbers and their names.
This file is used when you are displaying XNS/Novell screens else
it can be safely deleted.
The key token is the network number in the format XX-XX-XX-XX
where each X is an hexadecimal digit.
The shipped NETWORK.XNS file contains:
00-00-00-00 Local
FF-FF-FF-FF Broadcast
; ; The rest has to be customized ;
00-00-00-03 Net3
Of course this file will have to be heavily customized for each
site.
This file contains the mapping between the XNS (or IPX) protocol
types and their names.
This file is used when you are displaying XNS/Novell screens else
it can be safely deleted.
The key token is the type number in the format XX where each X
is an hexadecimal digit.
The file TYPES.XNS contains:
00 Unknown
01 RIP (Routing Information Protocol)
02 Echo 03 Error 04 PEP (Packet Exchange, datagram) 05 SPP/SPX (Sequence Packet Protocol)
11 Netware Core Protocol
This file should be correct for most networks.
This file contains the mapping between the XNS (or IPX) socket
numbers and their names.
This file is used when you are displaying XNS/Novell screens else
it can be safely deleted.
The key token is the socket number in the format XX-XX-XX-XX where
each X is an hexadecimal digit.
The file WKS.XNS contains:
0001 RIP (Routing Information)
0002 Echo
0003 Error Handler 0451 Novell File Service 0452 Novell Service Advertising 0453 Novell Routing Information 0455 Novell NetBIOS 0456 Novell diagnostic
0457 Novell Copy Protection
This file should be correct for most sites.
This file contains the mapping between the first byte of the network
PDU for the OSI stack.
Currently, the file contains only:
00 ISO 8473: inactive network layer
81 ISO 8473: ES-ES
This should be correct for most sites.
This file contains the mapping between the NSAP selector (last
byte of a NSAP) and its name.
The key token format is two hexadecimal digits.
Here follow a few lines from the file:
00 Network Layer Identifier
06 TCP & UDP with Bigger Addresses (TUBA): TCP
11 TCP & UDP with Bigger Addresses (TUBA): UDP 1E CLNP short term ping request 1F CLNP short term ping reply 20 DECnet/OSI: NSP transport
21 DECnet/OSI: OSI transport
This file may be customized for your network but should be correct.
This file contains the mapping between a NSAP and its name.
The format of the key token is HH-HH....-HH where HH is a hexadecimal
digit. There can be up to 20 bytes in the NSAP. The file may contain
NSAP of different length.
Here follow a possible line for the NSAPS.OSI file:
39-52-8F-11-00-00-09-10-00-00-00-00-40-BB-BB-AA-AA-00-10-00 tuba10
This file should be customized for your site, the shipped file is just an example.
This file contains the mapping between the Authority and Format
Identifier (first byte of a NSAP) and its name.
The key token format is HH where h is an hexadecimal digit.
Here follows some lines from the shipped AFI.OSI:
36 X.121: decimal coded: non-zero first IDI digit
37 X.121: binary coded: non-zero first IDI digit
38 DCC (Data Country Code): decimal coded
39 DCC (Data Country Code): binary coded
The file should be correct as shipped.
This file contains the mapping between an ISO IDI with the format
Internal Code Designator and the name of the organization.
The key token format is HH-HH.
Here follow a few line from the shipped ICD.OSI:
0057 Saint Gobian
0058 Siemens Corporate Network
0059 DANZNET
0060 Data Universal Numbering System
The file should be correct as shipped.
This file contains the mapping between an ISO IDI with the format
Data Country Code and the name of the country.
The key token format is HH-HH.
Here follow a few lines from the shipped file:
052 BARBADOS
112 BELARUS
056 BELGIUM
084 BELIZE
The file should be correct as shipped.
ETHLOAD as already said is currently running as it is on the top of four different datalink drivers. ETHLOAD automatically configures itself to use the first driver found. It tries in the following order:
If you use another driver and you have a specification of its
API (or even some C routines in the public domain), please email
me because I would like that ETHLOAD runs on nearly all datalink
drivers... ;-)
Sun PC-NFS drivers are NOT supported by ETHLOAD, mainly because
the specification is not freely available and also because Sun
seems to prefer to use NDIS now.
If this order does not work for you, you will have to use the
-d option in the command line for starting ETHLOAD (see section
5).
Some of these datalink drivers allow for simultaneous execution
of ETHLOAD and of you usual protocol stack: NDIS and ODI. All
other drivers prevent the execution of your usual protocol stack,
it means that you will abort all current connections to any servers.
Some of these datalink drivers do not require a PC reboot after
running them: DLL, NDIS version 2.0, packet driver and ODI.
Finally, only one kind of drivers namely ODI allows for the identification
of faulty frame by their source or destination addresses.
In conclusion, if your Ethernet hardware has a ODI driver with
promiscuous mode support, it is better to use ODI.
ETHLOAD despite its name can probably work on all IEEE LAN (with
48 bits addresses and IEEE 802.2 LLC sub-layer). Starlan has been
analyzed through ETHLOAD. The single point to keep in mind is
that the MAC screen (see further) is computed for a bandwidth
of 10 Mbps (or you may elect to use the -b option to specify the
LAN bandwidth). If you want to try ETHLOAD on non IEEE 802.3 LANs,
I would be happy to work with you to support these LANs (i.e.
FDDI, ...).
Another important point is that most Token Ring adapters do not
support promiscuous mode (notably IBM adapters). So, when starting
ETHLOAD a warning message will be displayed and only broadcast/multicast
packets will be analyzed showing a very lightly loaded token ring!
The only way to escape this problem is to get a promiscuous mode
adapter and driver (IBM has a trace adapter, Olicom supports
promiscuous mode). The ODI driver for Madge adapters is supported
by ETHLOAD.
A final remark, packet driver does not differentiate between the various kind of errors in its statistics. So, you should use any other driver if possible.
The first thing to note is that only very few ODI drivers supports
the promiscuous mode which is needed for ETHLOAD. Novell has a
list of those drivers since the promiscuous mode is also needed
by Novell LANanalyzer product.
You should also check that your NET.CFG has enough buffers and
mempool allocation (see also the annex about common pitfalls).
To use ETHLOAD, you just have to load the ODI driver (preceded
as usual by loading LSL.COM) and having a correct NET.CFG. If
you can run any other ODI application (Novell LAN Workplace for
DOS, Siemens Nixdorf LAN 1, ...), you should be able to run ETHLOAD
as it is. Nevertheless, it seems that IPXODI and NETX cannot be
loaded before ETHLOAD.
The use of ETHLOAD is not disruptive to your other network application
which will continue to run at very bad efficiency...
ETHLOAD does not support IEEE 802.2 type 2 frames, so if your
NET.CFG contains several frame types, you may have to use the
-do2 option to select the second frame type, or the -do3, ...
To start ETHLOAD, just issue the ETHLOAD command to the MS-DOS
prompt.
Remark: when using a recent LSL or ODI MLID driver, ETHLOAD can refuse to start with the error message 'Error: cannot register receive monitor because not supported'. If so, you should use the special RXMONSTK utility provided by Novell. This utility ùust be loaded immediately after LSL and before the ODI driver. (This information comes from Ken Cornetet and I would appreciate to receive more information from knowledgeable people about this).
Before running ETHLOAD for the first time, you must modify your
PROTOCOL.INI (usually located as C:\LANMAN\PROTOCOL.INI see your
C:\CONFIG.SYS file and the DEVICE=..PROTMAN... /I:<path>).
You must add the following lines in your PROTOCOL.INI (anywhere
in the file but after a section):
[ETHLOAD]
drivername = ETHLOAD$
bindings = MYMAC
where MYMAC is the name of the MAC module you want to use.
These modifications do not modify the usual behaviour of your
PC, so you may leave these lines in your PROTOCOL.INI file even
if you don't use ETHLOAD.
After you have made these changes, you must reboot your PC.
After this reboot, when you want to use ETHLOAD you must issue
the ETHLOAD command to the MS-DOS prompt.
By the way, the Protocol Manager directory (containing NETBIND.EXE,
...) should be in the PATH of MS-DOS.
Remark 1: in PROTOCOL.INI the case of the left part of '=' does
not matter, but uppercase characters must be used on the right
part as indicated in the examples above.
Remark 2: as you are using a version of Protocol Manager older than version 2.0.1 , ETHLOAD will display some warnings and you have to pay special attention to the following points:
don't run NETBIND.EXE before ETHLOAD (so look out in your AUTOEXEC.BAT for an automatic run of NETBIND.EXE)
reboot your PC after running ETHLOAD since Protocol Manager cannot be reset in a correct state
some statistics are missing.
Before running ETHLOAD for the first time, you must modify your
PROTOCOL.INI (usually located as C:\LANMAN\PROTOCOL.INI see your
C:\CONFIG.SYS file and the DEVICE=..PROTMAN... /I:<path>).
You must add the following lines in your PROTOCOL.INI (anywhere,
after a section):
[ETHLOAD]
drivername = ETHLOAD$
bindings = MYMAC
where MYMAC is the name of the MAC module you want to use. The
MAC module name is what is between [] in PROTOCOL.INI which is
followed by a drivername= line with the name of the device driver
loaded in CONFIG.SYS (the name of a MAC module often ends with
_NIF).
You also have to modify the [PROTOCOL MANAGER] entry to add a
dynamic line. But first try without this modification before modifying
further your PROTOCOL.INI file.
[PROTOCOL MANAGER]
devicename = PROTMAN$
dynamic = YES bindstatus = YES
priority = ETHLOAD
These modifications do not modify the usual behaviour of your
PC, so you may leave these lines in your PROTOCOL.INI file even
if you don't use ETHLOAD.
After you have made these changes, you must reboot your PC.
After this reboot, when you want to use ETHLOAD you must issue
the ETHLOAD command to the MS-DOS prompt.
By the way, the Protocol Manager directory (containing NETBIND,
...) should be in the PATH of MS-DOS.
Remark 1: in PROTOCOL.INI the case of the left part of '=' does
not matter, but uppercase characters must be used on the right
part as indicated in the examples above.
Remark 2: the use of ETHLOAD should not be disruptive for your
favourite protocol stacks, so you should not have to reboot your
PC.
Remark 3: you may have to run READPRO before loading ETHLOAD if the image copy of PROTOCOL.INI is corrupted (i.e. ETHLOAD displays an error message like 'PROTOCOL.INI corrupted').
If DLL.EXE (or DLLDEPCA.EXE) is already loaded, you have nothing
to do before starting ETHLOAD by the ETHLOAD command.
Note 1: in order to go promiscuous, DLL requires that ETHLOAD
shutdown ALL connections: LAT, DECnet, ... After using ETHLOAD
you probably will have to reset the whole DECnet protocol stack
(so reboot your PC).
Note 2: it seems that at least for version 4.1 of DLL, it is impossible
to run ETHLOAD in a DOS box within MS-Windows 3.1.
Note 3: it seems that since Pathwork 5.0, ETHLOAD cannot be used anymore... If some Digital employees, gurus or customer could send me the update API to these drivers, I would be happy to add support for Pathwork 5.0.
Packet drivers exist for nearly all known Ethernet adapters. There
even exists 'packet driver shim' that transform some other
datalink drivers into a packet driver.
You have to use a software interrupt between 0x60 and 0x7F in
order to let ETHLOAD run.
ETHLOAD will use the first packet driver found while checking
from interrupt 0x60 up to 0x7F.
The use of ETHLOAD is not disruptive to your other network application
which will continue to run at very bad efficiency...
To start ETHLOAD, just issue the ETHLOAD command to the MS-DOS
prompt.
Remark: nearly all packet drivers can be found in numerous anonymous
FTP server including ftp.crynwr.com.
For BITNET users, they can also be fetched through TRICKLE server.
The Crynwr Packet Driver Collection is copyrighted using the GNU
General Public License.
Remark 2: for the 3Com 3C509 you should use version 11.* of the
Crynwr packet driver or even the latest packet driver from 3Com
(comment from Andy Leigh, BBC).
Remark 3: for some packet drivers, you may have to run PKTRCV with the mode 3 before running ETHLOAD, you may even have to unload all programs using the packet driver...
This driver allows to test ETHLOAD mainly for debugging purposes.
It can be used also to check the start-up of ETHLOAD, ...
To use this driver, you must use options on the command line.
This driver reads frames from an ASCII file. By default the file
ETHLOAD.IN is used but other files can be specified by using parameters
on the command line.
Of course, the input file format is compatible with the output
file format of ETHLOAD used in recorder mode and with ETHDUMP.
The format of the file is simple:
- empty lines or lines beginning with a ';' are ignored;
- else line consists of 2 decimal tokens followed by the frame.
The decimal tokens are:
1) a time-stamp when the frame was received expressed in MS-DOS ticks from the start of the recording;
2) the length of the received frame including the FCS, this length
may be different from the length of the frame in the file.
The frame itself starts with the first byte of the destination
address (excluding the preamble) and goes through all fields:
source address, Ethernet type or IEEE 802.3 length, data bytes,
... For Token Ring, FA and AC are also copied.
Each byte is represented by two contiguous hexadecimal digits.
Bytes can be separated by spaces, tabs and '-'.
An example of input file is:
0000000087 0060 000E20009127 0000E80109FC 0020 FF-FF-00-20-01-00-00-00-00-03-00-0E-20-00-91-27-40-05-00-B0-BB-1E-00-00-00-00-00-01
;
0000000125 0060 00AA001E1FE4 000080CAC901 0020 FF-FF-00-20-01-00-00-00-00-03-00-AA-00-1E-1F-E4-40-05-00-00-02-01-00-00-00-00-00-01
;
0000000141 0110 FFFFFFFFFFFF 00AA001E1FE4 0060 FF-FF-00-60-00-04-00-00-00-00-FF-FF-FF-FF-FF-FF-04-52-00-00-00-03-00-AA-00-1E-1F-E4
In nearly all configurations, ETHLOAD can be started without specifying
command line options. In some case, you may need to use these
command lines options: special datalink drivers configuration,
few memory left, ...
Command line option can be specified in either the UNIX shell format:
ETHLOAD -do1 -i65 -t
or in the MS-DOS format:
ETHLOAD /D:O1 /I:65 /T
Case does not matter.
ETHLOAD can be forced to use a special datalink driver instead
of trying to find automatically the best one.
To use Novell ODI, specify: -do or /D:O
To use Novell ODI with the MLID board 3, specify: -do3 or /D:O3
To use Microsoft/3Com NDIS, specify: -dn or /D:N (you may specify the MAC module to which ETHLOAD must bind)
To use Digital Equipment DLL, specify: -dd or /D:D
To use Packet driver at first interrupt found between 0x60 and 0x80, specify: -dp or /D:P
To use Packet driver at interrupt 0xHH, specify: -dphh or /D:PHH
To use Loopback driver, specify: -dl or /D:L
To use the file driver (default filename is ETHLOAD.IN), specify: -dffilename or /D:Ffilename
ETHLOAD by default analyzes all protocols. This requires both
more memory and more processing than analyzing a single protocol.
By using the -p option, you can restrict the protocols to be analyzed
by ETHLOAD.
To analyze DECnet, specify d after the -p.
To analyze the TCP/IP protocol suite, specify i after the -p.
To analyze the OSI protocol suite, specify o after the -p.
To analyze the TUBA protocol suite, specify t after the -p.
To analyze the XNS/NetWare protocol suite, specify n after the -p.
To analyze the IEEE 802.2 LLC sublayer, specify l after the -p.
To analyze the Netbeui protocol suite, specify b after the -p.
By specifying a digit after the -p, you specify the highest layer
to be analyzed. E.g. -p3 will analyze frames up to layer 3 (e.g.
no DECnet NSP, no TCP or UDP, ...).
This option may be useful if you need more memory (as ETHLOAD will allocate fewer tables for its operation) or if you need more CPU power or time accuracy.
ETHLOAD can display the very first bytes of all received frames
in real time on the bottom line of the display.
This behaviour is set by using the -t option on the command line.
Remark: in version 1.01, ETHLOAD always displayed the first bytes
of the packet.
ETHLOAD works by default in fast mode with packet driver and ODI.
The unsecured (the default) is defined as enabling IRQ while a
frame is analyzed. The disadvantage is that the datalink driver
may be overloaded, but, the big advantage is that a lot of frames
are neither dropped nor ignored.
If you want stability instead of accuracy, you may elect to use
the -s option.
By using this option, ETHLOAD can see much more packets but may
sometimes runs into problems...
So, this option should be set ONLY if you encounter no problems
with ETHLOAD (PC that hangs, inconsistent display, ...) and you
have a high percentage of lost packets.
The meaning of this option is different for the file driver, if used with the file driver, ETHLOAD will ignore the timestamps in the file and receives all frames as fast as it can process them (so no frame will be dropped and this will go fast).
ETHLOAD measures the load of the LAN at regular interval, the
screen is also automatically refreshed at the same rate.
By default, this interval is 5 seconds. You may select another
measure/screen refresh interval by using the -i option followed
by the number of seconds.
ETHLOAD normally wait for a key to be pressed before actually
analyzing frames so you can read the startup information.
If you want to automatically start the analysis you may specify
the -q option in the command line. This option could be useful
in batch files, ...
The -q option will also suppress the line displayed when loading
dictionaries.
ETHLOAD can also record all received frames into an ASCII file
instead of analyzing them.
Of course, this file is compatible with the file format used by
the file driver (-df).
By default, the output file is ETHLOAD.OUT but any other valid
name can be specified directly after the -r option.
Please note that only the first part of the frames are recorded.
ETHLOAD needs the LAN bandwidth to compute and display the load.
Generally, ETHLOAD can ask the datalink driver for the LAN bandwidth.
But, for packet drivers and DLL drivers this is impossible and
ETHLOAD defaults to 10 Mbps (i.e. Ethernet).
The -b option allows to specify the LAN bandwidth expressed in
bit/s.
E.g. -b1000000 or -b1.0E+6 will set the bandwidth for Starlan
1 Mbps LAN.
ETHLOAD requires promiscuous mode to correctly analyze all frames
of the LAN.
Not all LAN adapters and not all datalink drivers support this
mode. By default, if the promiscuous mode is not supported, ETHLOAD
does not start and exits immediately.
Anyway, you might want to start ETHLOAD and analyze the very small
fraction of the LAN traffic which is broadcast or multicast. If
you want this, you have to use the -o option when starting ETHLOAD.
Note: if your LAN adapter and datalink driver support promiscuous
mode, you should not use this option.
By default, ETHLOAD analyzes (or records) all received frames. If you want to analyze (or record) only specific frames, you must use the filter option to specify:
- the IEEE 802.2 LLC SAP to analyze: -fhh where hh are two hexadecimal digits specifying the SAP value for both the DSAP and SSAP (see file SAPS for more details);
- the Ethernet type or DoD SNAP type to analyze: -fhhhh where hhhh are four hexadecimal digits specifying a type (see file TYPES for more details);
- the MAC source or destination addresses to analyze: -fhh-hh-hh-hh-hh-hh
where hh are hexadecimal digits of the MAC address.
For some datalink drivers (ODI, NDIS, packet driver), the datalink
driver can benefit of having several buffers to put frames in
at hardware interrupt time and allowing ETHLOAD to analyse them
after.
With the current version of ETHLOAD, the default is to use a single
buffer. The maximum number of buffers to be allocated is 5.
Please note, that the use of several buffers may lead to a problem:
ETHLOAD in some case may analyse frames out of order. So, events
histories can be disordered and timestamps can be slightly false.
After quitting ETHLOAD, the number of buffer misses is displayed,
this is the number of times that a frame had not been analysed
because no buffer was available. The allocated queue size is also
displayed together with its maximum size.
As a rule of the thumb, you should increase the number of buffer
until having no buffer miss.
Remark: with ODI if a protocol stack is used while ETHLOAD is
running, these buffers are not used and there can be only one
frame received at a time.
The different screens displayed by ETHLOAD have all the same design:
- the top line is just a copyright notice + version identification + percentage of dropped frames due to internal buffer shortage (either in ETHLOAD or in data link driver or even in Ethernet controller);
- in the top right corner a character is flipping from '+' to '-' as frames are received;
- the character on the left of the '+/-' flip-flop is displayed as a 'P' when ETHLOAD is processing a frame else it is a space;
- the second line is a summary of all commands available for this screen;
- if the real time trace option was specified in the command line, the bottom line displays the first bytes of the last received frame:
* six bytes of MAC destination address ;
* six bytes of MAC source address ;
* two byte(s) for either DIX packet type or for IEEE 802.3 frame length;
* a few bytes of data.
- on a Token Ring, the ring status is displayed in RED on the
top line when the ring is beaconing or being purged.
All screens are automatically refreshed every measure interval
(5 seconds by default) to reflect the current statistics or table
contents. You may also press the SPACE key to refresh the screen.
You can enter a single character command. The case of the character
is ignored.
Two commands are always recognized:
- 'Z' or '0': for resetting all statistics of ETHLOAD to zero and clearing all tables. Note that all statistics are cleared and not only the ones currently displayed;
- 'X' or <ESC>: for leaving the current screen
and getting back to the previous menu.
On some screens a large table is displayed: ARP table, ... As
these tables are larger than the 23 lines of display available,
you have to use the PgUp (or F8) and PgDn
(or F7) key to scroll between the different pages; the
keys Home and End will display the first and the
last pages.
The NumLock key is used to switch between numeric address
format (when NumLock is lit) and symbolic name (when NumLock
is not lit).
Three common display are often used:
- top of sorted table display;
- raw table display;
- history of events display.
The 'top display' consists of a title beginning
with 'Top of...' and displays the contents of an internal table
sorted from the highest frequency down to the lowest frequency.
An example of such a display is the display of MAC Transmitter.
The percentage displayed before each line is relative to:
- the number of frames relevant for this screen;
- the number of frames analyzed by ETHLOAD ;
- the estimated bandwidth used relative to the raw LAN bandwidth
(10 Mbps for Ethernet).
For instance, if during 10 seconds on a 10 Mbps Ethernet there were 1000 DECnet packets and 1000 IP packets and within these 1000 IP packets there were 100 UDP packets, the IP protocol screen will display for the UDP protocol (assuming a mean packet length of 1000 bits):
- 10 % (i.e. 10% of IP packets are UDP datagrams);
- 5% (i.e. 5% of frames are UDP datagrams);
- 0,1% (i.e. 0,1% of the Ethernet bandwidth is used by UDP datagrams).
A reference is also displayed by indicating how many frames represents
100%. The user can switch from one display to another by pressing
the '%' key.
As all counters are 32 bits, they are limited to about 4E+9 frames.
Once they reach this upper bound they are stopped and the whole
table is kept unchanged. The time of this table overflow is then
displayed in red.
As the size of the table is limited in size, when the table is
filled, this is displayed by a yellow message on the top of the
screen.
Each line of a 'top display' consists of:
- percentage (e.g. the percentage of Ethernet frames transmitted by the displayed Ethernet node in respect to the total number of Ethernet frames);
- display of the node (e.g. Ethernet MAC address with perhaps the corresponding host name of DECnet address);
- a bar graph for visual representation (resolution 2.5%).
The 'raw table display' is just the display of a
non sorted internal table. An example is the display of the ARP
table.
Each line of a 'raw table display' consists of two
values (e.g. the Ethernet MAC address associated with an IP address).
The 'event history' is used to display a chronological
log of events (e.g. the list of ICMP requests).
Each line of an 'event history' consists of:
- a time stamp in the form hh:mm:ss.hh;
- a description of the event.
A final remark must be done on the accuracy of the figures:
- some packets are lost, so the load is always higher than indicated if you are using a slow Ethernet controller or a non efficient driver;
- ETHLOAD relies on the MS-DOS timer which has a resolution of about 50 msec, moreover if the network load is high and you have a powerless CPU some timer ticks can be missed;
- if you are running with IRQ disabled (i.e. without the -f option),
some datalink drivers can miss frames without further notification,
so the drop percentage is always higher than the one displayed
by ETHLOAD.
To summarize, ETHLOAD give reliable figure on a medium loaded
Ethernet (10% ?) and on a correct CPU 80386dx 25 MHz. In all other
case, ETHLOAD can only indicate that your Ethernet is probably
heavily loaded and you will have to buy an expensive LAN analyzer!
Moreover, all tables have a maximum size, so it may occurs that
on a medium or large LAN some tables are filled. This is indicated
on the screen. E.g. the MAC flow table will probably be more or
less useless on a LAN with more than 50 stations.
Version 2.0 of ETHLOAD will:
- drop less frames due to an ordered multi-buffered scheme (only for NDIS and ODI);
- use a finer timer.
The MAC level screen can be divided into two parts:
- three statistics summaries: last five seconds, busiest five seconds, cumulative;
- VU-meter of the peak and current load.
Important figures are displayed for three important samples:
- the last five seconds;
- the busiest five seconds, i.e. the five seconds period when the Ethernet load was the highest ;
- the cumulative since the start of ETHLOAD or the last reset.
For all these samples, the following figures are displayed:
- total number of Ethernet frames: the mean interframe gap is also displayed if available;
- total number of bytes of data: i.e. MAC header + MAC data (the FCS and preamble is not taken into account) and the load of Ethernet in % of the 10 Mbps bandwidth of Ethernet;
- the number of frames containing errors + rate of error per second.
As the internal counters are 32 bits, counters are bounded to
about 4E+9 frames/bytes. Once the counters reach this count; they
are stopped and displayed as ******.
If the datalink driver supports error differentiation (namely all but packet driver), the kind of error is also indicated:
- CRC error (cabling problem ?);
- too long packet (babbling transceiver or controller);
- too short packet (garbage of collision).
If you are using the ODI datalink driver, by using the 'E' command
you have access to the MAC source address of faulty Ethernet frames
(by the way don't be amazed by unknown MAC addresses because even
the source address can be faulty in faulty frames... specially
for runt frames).
The VU-meter is at the bottom of the screen and is graduated in
Mbps.
The '>' is the peak marker, i.e. the highest load on five seconds
since ETHLOAD has been started or reset.
The bar is the last five seconds marker.
The color of the peak marker and of the bar is changing in respect to the load:
- green under 1 Mbps;
- yellow under 5 Mbps;
- red over 5 Mbps.
The MAC level screen has two main commands:
- 'Q' to quit ETHLOAD and get back to MS-DOS (a confirmation is requested);
- 'P' to go to the Protocol screen (to choose between IP,
XNS, OSI, DECnet, Netbeui).
In very short, you can display:
- ARP: table of the mapping between IP addresses and MAC addresses (can be used to detect two hosts sharing the same IP address), the last ARP packet, the ARP senders, the requested IP addresses;
- the IP fragmenters and the size of fragments, i.e. the IP host that transmit fragmented datagram (should be empty !);
- important information about IP hosts: largest MTU (Maximum Transmit Unit) seen, missing IP datagrams (should be zero if host is on the same LAN and has only one interface), repeated IP datagrams (could indicate faulty transceiver or SQE test enabled were it shouldn't), minimum and maximum TTL (Time To Live) seen from this host;
- ICMP: the last ICMP datagrams, the senders of ICMP datagrams;
- mostly used protocols: UDP, TCP, ...
- TCP: events (connection request, end of connection), connections, most used services (ports), important events for SMTP and POP, monitoring Telnet connections, ...
- UDP: associations, most used services (ports), important events for BOOTP and TFTP,...
In very short, you can display:
- Connect Initiate (with nearly all fields including objects,...) history;
- Disconnect Initiate history;
- Returned frames by a router because the end-node is no more reachable;
- Top nodes (classified by transmitters and receivers): not to be confused with the MAC layer transmitters/receivers. On the MAC screens, DECnet routers usually represent a very high percentage but on the DECnet network layer screen, DECnet routers usually represent nothing and you can see remote DECnet address (i.e. some DECnet nodes on remote LAN).
In very short, you can display:
- the Active network layer hosts (not tested, if it runs please email me ;-)
- the Inactive network layer hosts;
- the most important Transport layer events: connection,
disconnection, error. NSAP are displayed in hexadecimal and TSAP
are displayed in hexadecimal, ASCII and EBCDIC. Important parameters
are decoded and displayed.
This chapter explains in very few words all important screens
of ETHLOAD. In version 2.0, you will receive more information
once you are registrated.
Each screen is described under the name of the access path, i.e.,
the letters to be typed in from the first screen to reach it.
Display the top nodes that transmit bad frames, error type is
not indicated only the source address of the frame. Of course,
the source address is often corrupted and displayed as FF's or
AA's or whatever. Displayed only with an ODI driver.
It displays the top traffic flows: from source to destination.
This screen was already described previously.
This screen displays the length distribution of all received frames
(including addresses and FCS but not the preamble). Check for
too long frames or too short frames!
Display the top destination addresses (including multicast addresses
flagged by a M after the address).
Display the top source addresses.
Display the top used IEEE 802.2 LLC SAP, Ethernet 2.0 types, SNAP
encapsulated frames and Novell raw Ethernet.
Caution: Ethload and no other protocol analyzers can distinguish
between Novell raw Ethernet and SAP FF (and even in some case
SAP FE).
Displays the mapping between IP address and MAC address.
The display looks like: IP address, MAC address.
Some routers (namely cisco) use what is called proxy-arp routing:
they hide non local IP addresses behind their own MAC address.
This scheme should be used only with very dumb IP machines (that
don't allow subnetting, or...) and is indicated by a comment 'proxy
router?'. This should not be considered as an error but rather
as a trick.
Display the very last ARP events by showing the target protocol
(IP) and hardware (MAC) address and the source protocol and hardware
addresses.
To indicate whether this is a request or a reply the event is
flagged with either a '?' (request) or '!' (reply).
The display is only correct if the protocol is IP and the hardware
is IEEE 48 bits address.
Display the IP addresses owned by MAC addresses.
The display looks like: MAC address, IP address.
If the same IP address is available through more than one MAC
address this is flagged as an error and displayed in yellow. This
is a severe configuration error that should be corrected as soon
as possible. The vendor name of the Ethernet controller is indicated
so you could more easily find the faulty machines.
Display the last ARP packet received together with the rate of
ARP requests and replies per second.
Display the top IP address which send ARP requests.
In some case, this display may indicate a host which expire or
reset its ARP cache too often.
Display the top requested targets.
I.e. the IP addresses which other hosts try to map to MAC address.
If a target cannot be found and ETHLOAD hasn't seen any reply
for this IP address, ETHLOAD will display in yellow the comments
'unresolved'.
This may either indicate:
- a host which is temporary down (usually a X-term contacted by a X-Windows client and the X-term is switched off);
- a badly configured IP host which tries to contact a non existent
IP address... (bad subnetting, ...).
Digital Equipment, 'PCSA Data Link Programer's Reference
Manual', April 1989, EK-PCDLL-PR-001
FTP Software, 'PC/TCP Packet Driver Specification',
Revision 1.09, September 1989 [from anonymous FTP server vax.ftp.com]
3Com/Microsoft, 'LAN Manager Network Driver Interface
Specification', Version 2.0.1, October 1990 [from anonymous
FTP servers ftp.microsoft.com]
Novell, 'Open Data-Link Interface - Developer's Guide
for DOS Workstation Protocol Stacks', Version 1.10, March
1992 [from anonymous FTP server sjf-lwp.novell.com]
Here follows a very short and not restrictive list of tested datalinks:
- Protocol Manager 2.01 + Cogent LP486E NDIS driver;
- SMC 8003, packet driver 8003PKDR V2.03;
- SMC 8003, ODI promiscuous mode SMC8000 V3.03 (920925) and LSL 1.0 (900530);
- EXOS205 V 10.1.2, packet driver;
- NE2000 Crynwr packet driver;
- XIRCOM Ethernet adapter II with DLL 3.0.5;
- DEPCA, DE202 and DE100 with version 4.1 of DLLDEPCA;
- Crynwr packet driver for 3Com 503 version 4.1;
- Madge Smart AT Ringnode with MADGEODI 1.28 (921015) and LSL 2.01;
- Madge MADGEFMP ODI driver;
If you can run ETHLOAD on other drivers or even on IEEE 802.5
or 802.6 LAN, please email me in order to increase the size of
tested datalink drivers.
It seems impossible to run ETHLOAD with the Crynwr packet driver
for NI5210 because promiscuous seems not to be supported.
It also seems that 3Com 3C509 adapter with 2 KB of memory cannot run ETHLOAD.
A utility program provided with ETHLOAD, MKNODE, allows to display
DECnet node names after DECnet address.
MKNODE simply converts DECnet addresses in the form of area.node
(e.g. 1.1) into Ethernet address in the form of AA-00-04-00-xx-yy
(e.g. AA-00-04-00-01-04).
MKNODE is a MS-DOS filter program, i.e. it takes input from the stdin and its output is stdout. The usual way of using MKNODE is:
1) get the list of DECnet node addresses and names (e.g. by running $ NCP SHOW KNOWN NODES TO nodes on a VAX/VMS) in a MS-DOS called NODES. The format of this file is:
area.node name
2) on MS-DOS, issue the command:
MKNODE < NODES >> ETHERS
3) that's done !
Here is an example for the file NODES:
;
; List of DECnet nodes
; ; 1.1 RM 1.76 MDCPC 2.3 DSRV03
2.4 DSRV04
And here is the added lines in ETHERS:
#
# The next Ethernet addresses are built with MKNODE.EXE
# # (c) vyncke@csl.sni.be # Can be copied and used freely # # Input is stdin and consists of line in the format # area.node nodename # # Output is stdout and should be appended to ETHERS # # Run of Sun Jul 11 10:18:32 1993 # # # 1.1 RM AA-00-04-00-01-04 RM # 1.76 MDCPC AA-00-04-00-4C-04 MDCPC # 2.3 DSRV03 AA-00-04-00-03-08 DSRV03 # 2.4 DSRV04
AA-00-04-00-04-08 DSRV04
Remark: I'm not really satisfied with this two-steps procedure.
If you have written any VMS/DCL procedure that has the same result
and you wish to put this procedure into the public domain, I would
be pleased to include it in the distribution kit of ETHLOAD.
Here follows a list of common pitfalls.
From: Wey Jing Ho <sci240@monu6.cc.monash.edu.au), some datalink
drivers cannot be loaded in high memory (LH command in MS-DOS
5.0), they MUST be loaded in conventional memory.
On a highly loaded network, you may have to analyze only the bottom
layers in order to have enough CPU for the analyse. (You may specify
the highest layer to be analyzed with the -p option, e.g; -p2
analyzes only MAC layer).
From: Drew Letcher <drew-letcher@uiowa.edu>. Ethload always
fails if in your CONFIG.SYS there is a STACKS=0,0 line. Ethload
is memory hungry (especially during interrupt processing), so
you should have at least STACKS=9,512
From: Klaus Troja <klaus@mail.sz.etc.tu-bs.de>. When running Ethload with an ODI driver, the file NET.CFG should contains:
Link Support
Buffers 4 1600
MemPool 4096
Moreover, it seems that Novell LAN Workplace can run while Ethload
is running but IPXODI and NETX cannot be loaded when Ethload is
running. So, IPXODI and NETX must be unloaded before starting
Ethload.
The NET.CFG file should also contain a line
Frame Ethernet_II
for your network adapter. Then you should try to specify this
frame type to Ethload but starting Ethload with the -do1
or -do2 or -do3
command line option.
With NDIS driver, ETHLOAD needs much more memory than with other
drivers, so you may have to specify which protocols you want to
analyze by using the -p option.
Packet drivers sometimes require to use PKTMODE 6 before starting
ETHLOAD and to use PKTMODE 3 after ETHLOAD is exited.
Packet drivers sometimes do not allow other protocols to be loaded
before ETHLOAD is run.
From: Eric Vyncke, here is the set-up to use ETHLOAD with PC-NFS of Sun (when the NDIS driver is used):
excerpt from CONFIG.SYS:
DEVICE=c:\NFS\PCNFS.SYS
DEVICE=c:\NFS\SOCKDRV.SYS
DEVICE=c:\LANMAN\PROTMAN.SYS rem Replace the next line with your actual NDIS driver DEVICE=C:\LANMAN\ELNKPL device=c:\usr\lan\dis_pkt.gup
DEVICE=C:\LANMAN\NFS-NDIS.SYS
How to register ?
You shall then receive by E-mail, fax or post a special key
file which will enable the use of all features of Ethload.
Postal addresses:
Eric Vyncke
Allée des Chardonnerets, 3
B-4432 Alleur
Belgium (Europe)
| Company name | |
| Department + office location | |
| Last name | |
| First name | |
| Street and No | |
| Zip code + State + City | |
| Country | |
| E-mail address | |
| Fax number | |
| Version of Ethload+type of driver | |
| Do you want to receive the latest version available ? | |
| Invoice needed (not for Belgium) ? |
1. Introduction. 22. Miscellaneous and acknowledgements. 42.1. Original copyright. 42.2. Current copyright and disclaimer. 42.3. Support. 42.4. Distribution channel. 52.5. Thanks to testers. 52.6. Changes. 62.7. Trademarks. 72.8. Source code. 82.9. Licensing. 82.10. Security. 93. Configuration files. 10ETHERS 10HOSTS 11NETWORKS 12PROTOCOL 12SAPS 13WKS.TCP (resp. WKS.UDP) 13TYPES 14VENDORS 14OBJECTS.DNA 14NETWORKS.XNS 15TYPES.XNS 15WKS.XNS 16NLIDS.OSI 16SELECTOR.OSI 17NSAPS.OSI 17AFI.OSI 17ICD.OSI 18DCC.OSI 184. Set-up of datalink drivers. 204.1. Novell ODI. 214.2. Microsoft 3Com NDIS v 1.0.1. 224.3. Microsoft 3Com NDIS v2.0.1. 234.4. Digital Equipment DLL. 244.5. Packet driver. 244.6. Loopback driver. 254.7. File driver. 255. Command line options. 275.1. Datalink driver: -d 275.2. Protocols to be analyzed: -p 275.3. Real time frame trace: -t 285.4. Slow/secure mode: -s 285.5. Measure interval: -i 285.6. Quiet Mode: -q 295.7. Recorder mode: -r 295.8. LAN bandwidth: -b 295.9. Promiscuous override: -o. 295.10. Filter: -f. 305.11. Buffers in memory: -m. 306. The different screens of ETHLOAD 326.1. Introduction 326.2. MAC Level screen 356.3. TCP/IP screens 366.4. DECnet screens 366.5. OSI screens 376.6. Summary of all screens. 37A. Annexes 40A.1. Data Link layer references 40A.2. Tested data links 40A.3. Adding DECnet node names to display. 40A.4. Common pitfalls. 42Registration form 44Table of contents 45