Ethload User's Guide.txt

       ETHLOAD user's guide                         40
                                 
                                 
       
                                 
                                 
                                 
                                 
                           ETHLOAD 1.04
                                 
                           USER'S GUIDE
                                 
                                 
                                 
                                 
                                 
                                 
                                 
                                 
                                 
                           A simple free
                                 
                  Ethernet load/problems analyzer
                         and events tracer
                                 
                                 
                                 
                                 
                                 
                                 
                                 
                             E. Vyncke
                                 
                         vyncke@csl.sni.be
                                 
                          16 January 1994
                                 

1. Introduction.
       
       ETHLOAD is a free software running on any MS-DOS PC with  an
       Ethernet controller.
       
       Currently,  ETHLOAD  supports  the  following  drivers  (for
       Ethernet and Token Ring):
         - Digital Equipment Corp. DLL specification;
         - Microsoft    3Com    NDIS   (Network   Driver    Interface
           Specification);
         - packet  driver as issued from PC/TCP, Clarkson  University
           or from the Crynwr collection;
         - Novell   ODI  (Open  Datalink  Interface)  if  the  driver
           supports promiscuous mode;
         - ASCII file containing Ethernet frames;
         - loopback driver (mainly for debugging purposes).
       
       The purposes of ETHLOAD are  twofold:
         - display  very  simply  non  accurate  numbers  about   the
           Ethernet load (number of frames/sec, bits/sec, ...);
         - display  important parameters, events and  loads  for  the
           TCP/IP, DECnet, OSI, XNS, NetWare and Netbeui protocols.
       
       ETHLOAD allows you to:
           -  check  simply the load of your Ethernet  (with  error
           rate, inter frame gap,...);
           - check which host is sending most of frames;
           - see which host is sending to which host;
           -  see  what  kind  of  protocols are  in  use  in  your
           Ethernet;
           - ...
       
       In a TCP/IP network, ETHLOAD allows you to:
           - see ARP table contents;
           - see which host is sending (un)resolved ARP probes;
           -  see the IP host which is sending most of the IP,  UDP
           or TCP packets;
           -  see what kind of protocols are in used (either TCP or
           UDP);
           -  see which is the mostly used telnet/rlogin server (or
           client);
           -  see  the boot sequence with important BOOTP and  TFTP
           events;
           -  see some characteristics of IP hosts (fragments size,
           MTU,   IP  retransmission,  options  used  --  including
           source routing, ...);
           - see main RFC 1001/1002 NetBIOS events and names;
           - see the working of DNS;
           -    see    important   TCP   events:   start/stop    of
           connections,...
       
       In a DECnet network, ETHLOAD allows you to:
           -  see  which node are sending/receiving most of  DECnet
           packets;
           -  see  all  Connect Initiate packets (including  object
           number, ...) ;
           - see returned packets;
           - ...
           
       In an OSI network, ETHLOAD allows you to:
           - see the top transmitter/receiver NSAP;
           -  see  what  happens  with TUBA (TCP  &  UDP  with  Big
           Addresses);
           -  see the exchange of information between ES and IS and
           between IS;
           -   see   important  events  for  the  transport  layer:
           connection/disconnection,   TSAP   are   displayed    in
           hexadecimal, ASCII and EBCDIC.
           
       In a Microsoft NetBEUI network, ETHLOAD allows you to:
           - see the main naming events;
           - see the connections and the datagrams.
           
       In a Novell NetWare network, ETHLOAD allows you to:
           - see the routers;
           - see the different XNS/IPX networks;
           - see the advertised services ;
           - see who is connected to who.
           
                               * * *
                                * *
                                 *

2. Miscellaneous and acknowledgements.
       
 
 2.1. Original copyright.
       
       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.
       
       Here  follows the copyright included in the source files  of
       about 0,1% of the current version of ETHLOAD.
       
       /*  This  software  and  documentation can  be  copied,  used,
       modified freely as long as:
       - the source contains this text
       -  this  software, documentation is provided  free  of  charge
       (but for the cost of media: paper, CD-ROM, ...).
       Network  Research Belgium and the individuals who have written
       this  software DO NOT ASSUME any responsibilities  in  respect
       to the use, (un)expected side -effects of this program.
       The  software  and  documentation is provided  as  it  is.  No
       maintenance will be given.
       Anyway,  we  would  be pleased to hear of  any  use  of  these
       softwares by email, fax:
               bert@nrb.be
               fax: +32.41.48.11.70
       Suggestions, modifications are always welcome.
       These  softwares have been developed by a special team  called
       BERT  in a company called Network Research Belgium located  in
       Herstal, Belgium, Europe .
       This team includes:
               Eric Vyncke, vyncke@nrb.be now vyncke@csl.sni.be
               Frederic Blondiau, blondiau@nrb.be
               Michel Ghys, now mghys@cisco.com
               Marie-Christine Timmermans, timmermans@nrb.be
               Jean Hotterbeex, now jhotterb@cisco.com
               Manu Khronis,   khronis@nrb.be
               Vincent Keunen, keunen@manex.uucp
       */
       
 
 2.2. Current copyright and disclaimer.
       
       Right  now,  all  software developments are  made  home  and
       tested  after  working hours in my current company:  Siemens
       Nixdorf Informationsystems, SNI. So, here follows the  usual
       disclaimer:  Siemens  Nixdorf  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 SNI software.
       
       NRB,  Siemens  Nixdorf and the author do  not  support  this
       software  and are, in no case, responsible for any  bad  use
       or  any bad effect or any false result or anything caused by
       any version of ETHLOAD.
 
 2.3. Support.
       
       If  you  have problems to run ETHLOAD, please read carefully
       this  manual and also check the common pitfalls in  appendix
       A.4.
       
       The  UseNet  comp.protocols.tcp-ip.ibmpc  newsgroup  is  the
       right  place to state your problems, to comment on  ETHLOAD,
       ...  I'm  reading  this newsgroup every day  (together  with
       comp.sys.novell  and the BITNET mailing  list  about  NOVELL
       and  PATHWORKS).  This  if the preferred  way  to  get  some
       'support'.
       
       Anyway,  you can get some support from the author  since  he
       wants  to promote this software... You can reach the  author
       through       email:       vyncke@csl.sni.be1,        X.400:
       /c=be/admd=rtt/prmd=sni/o=siemens  nixdorf/ou1=liege/ou2=L1/
       ou3=D1/ou4=csl/g=eric/s=vyncke/ or by post mail:
       
         Eric Vyncke
         Rue Nolden, 25
         B-4432 Alleur
           Belgium (Europe).
       
       If  you are happy with ETHLOAD, my little son, Pierre, would
       appreciate  to receive any postcard (he is still very  young
       and still lives 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...   So,  you  are  strongly  urged   to   try   the
       comp.protocols.tcp-ip.ibmpc newsgroup.
       
       In  no  case,  shall I answer to phone calls  at  my  office
       (except  for those of you who are working for a  company  of
       the  Siemens  group)...  Don't forget  that  I  am  paid  by
       Siemens Nixdorf and that I have a lot of work to do  at  the
       office :-)
 
 2.4. Distribution channel.
       
       I  have no access to internet, so I cannot place ETHLOAD  on
       anonymous  FTP  server, if you run  such  a  server  I  will
       appreciate that you reserved some place for ETHLOAD on  your
       BBS or anon FTP server...
       
       If  you  do so, please warn me by email in order to  keep  a
       list of distribution channels.
       
       Normally,   ETHLOAD   is   available   as   package   called
       ETHLDvrr.ZIP  (where  vrr are version and  release  numbers)
       from   the   Simtel  repository  (aka  oak.oakland.edu)   in
       /pub/msdos/lan            and            also             in
       ub4b.eunet.be:/pub/ub4b/network/msdos. A  companion  program
       called   ETHDUMP  is  generally  available  from  the   same
       locations under the name ETHDPvrr.ZIP.
       
       These  servers can be accessed by email via TRICKLE  servers
       on   BITNET   for  the  Simtel  repository  or   via   mail-
       server@ub4b.eunet.be (commands: help,  reply  <address>  and
       get ethld104.zip).
 
 2.5. Thanks to testers.
       
       I would like to thank anyone of you about his/her comments.
       
       I thank especially my beta-testers:
           Ralf Buettemeyer, buettemeyer@hagenuk.netuse.de
           Michel Dalle, michel@d92.cb.sni.be
           Niels Kr. Jensen, msterlje@vm.uni-c.dk
           Hans-Joachim Koch, koch@lifra.lif.de
           Hans-Michael Pronk, hpronk@fac.fbk.eur.nl
           A.A.L. Reijnierse, A.A.L.Reijnierse@research.ptt.nl
           Frank Van Uffelen, frankvu@bix.com, fvo@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 :-)
 
 2.6. Changes.
       
   1.01:
       - support for packet driver, ODI and NDIS
       - support for TCP/IP
       - no more load graphics
       - dictionaries
       - bug correction in the length display
       -  porting from large model in Borland C to small  model  in
       Borland C++
       
   1.02:
       - bug correction in DLL support
       - documentation about copyright on packet drivers
       - dropped packets percentage in MAC screen
       - MAC flow screen
       - SMTP, TFTP and BOOTP support
       - Telnet/rlogin monitoring
       - options in command line
       - OSI support
       - improved DLL, ODI, NDIS and packet driver routines
       
   1.03:
       - use a local stack for all interrupt time routines;
       - add file driver;
       - support DNS, RFCNBIOS in TCP/IP;
       - add NetBEUI and XNS/NetWare supports;
       - improved display routines;
       -  NumLock  key for switching between numeric  and  symbolic
       display;
       - improved memory management;
       - port to large model C;
       - slight changes in DECnet presentation.
       
   1.04:
       - consider socket instead of packet types for Novell;
       - addition of TUBA
       - better OSI support (active network layers)
       - slight modifications in packet driver
       - add the -b option to specify LAN bandwidth
       - add the -f option to allow very trivial filtering
       - add the -m option to specify more buffers
       -  add  the -o option to allow partial work of ETHLOAD  even
       if promiscuous mode is not supported
       - remove the old -s (stack) option
       -  replace  the old -f (fast) option by a -s (slow)  option,
       the default is now fast mode
       - some IEEE 802.5 support (MAC frames, ring status, ...)
       - decode MSS option in TCP
       - decode IP options
       - add a dictionary for DNA objects
       -  ETHDUMP (the companion) can record short frames  (  <  14
       bytes) and can be put in quiet mode
       - the key '%' change top display percentage
       - length in recorded file now includes all headers and FCS
       - -l command line option to get panic messages
 
 2.7. Trademarks.
       
       As  usual, all trademarks (Ethernet, DEC, NetWare, ...)  are
       properties of their respective owners.
 
 2.8. Source code.
       
       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.
 
 2.9. Licensing.
       
       All  version  of  ETHLOAD (1.01 to 1.04) are copyrighted  by
       NRB and Eric Vyncke.
       
       Version 1.01, 1.02, 1.03 and 1.04 are 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  if  my little son received a postcard  from  you
       (see 2.3).
       
       As  ETHLOAD is now more than 65,000 lines of C code (roughly
       about  60 evenings ;-)), next version of ETHLOAD (2.0)  will
       be  shareware:  i.e.  you will be allowed  to  copy  it  and
       distribute it as before but you will be allowed  only  a  90
       days test period before having to be registered.
       
       The  registration fee (probably about $199 or ECU 199)  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),  and
       also a special electronic mail address for a support.
       
       Version  2.0 will have a completely different screen  layout
       and  a  on-line help. The code will be completely  different
       from  the code of the NRB version and the copyright  of  NRB
       will be deleted.
       
       Now,  enough  about these stuffs, let's have fun  and  start
       ETHLOAD !
       
 
 2.10. Security.
       
       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
       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.
       
                               * * *
                                * *
                                 *

3. Configuration files.
       
       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:
         - plain ASCII files, i.e. lines ended by CR/LF;
         - any line beginning with a ';' or a '#' is considered as  a
           comment;
         - empty lines are ignored;
         - other  lines  must  begin with a token generally  numeric,
           called  the key, then a series of space or TAB characters,
           followed  by  another token, called the value.  The  value
           token is ended by the CR/LF end of line.
       
       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.
       
 
 ETHERS
       
       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.
       
 
 HOSTS
       
       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 NIS2).
 
 NETWORKS
       
       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:
       
       150.144.0.0    UCCLE
       150.148.0.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 NIS3).
 
 PROTOCOL
       
       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
 
 SAPS
       
       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.
       
       
 
 WKS.TCP (resp. WKS.UDP)
       
       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.
 
 TYPES
       
       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
       
 
 VENDORS
       
       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
       
 
 OBJECTS.DNA
       
       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
 
 NETWORKS.XNS
       
       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.
       
 
 TYPES.XNS
       
       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.
       
 
 WKS.XNS
       
       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.
       
 
 NLIDS.OSI
       
       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.
       
 
 SELECTOR.OSI
       
       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.
 
 NSAPS.OSI
       
       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.
 
 AFI.OSI
       
       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.
       
 
 ICD.OSI
       
       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.
       
 
 DCC.OSI
       
       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 correct4 as shipped.
       
                               * * *
                                * *
                                 *

4. Set-up of datalink drivers.
       
       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:
         - Novell ODI;
         - Microsoft 3Com NDIS version 2.0.1 or higher5;
         - Digital Equipment DLL;
         - PC/TCP packet driver;
         - ASCII file driver.
       
       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 or higher, 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).
       
       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.
 
 4.1. Novell ODI.
       
       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.
       
 
 4.2. Microsoft 3Com NDIS v 1.0.1.
       
       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  6, 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)7
             reboot  your  PC after running ETHLOAD since  Protocol
           Manager cannot be reset in a correct state
            some statistics are missing.
 
 4.3. Microsoft 3Com NDIS v2.0.1 or higher.
       
       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 ETHLOAD8.
       
       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').
 
 4.4. Digital Equipment DLL.
       
       If  DLL.EXE  (or DLLDEPCA.EXE) is already loaded,  you  have
       nothing  to  do  before  starting  ETHLOAD  by  the  ETHLOAD
       command.
       
       Note:  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.
 
 4.5. Packet driver.
       
       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 the Simtel repository.  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.
       
       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...
 
 4.6. Loopback 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.
       
 
 4.7. File driver.
       
       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 ETHDUMP9.
       
       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 ticks10 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
                                 
                               * * *
                                * *
                                 *
       

5. Command line options.
       
       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.
       
 
 5.1. Datalink driver: -d
       
       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
 
 5.2. Protocols to be analyzed: -p
       
       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.
 
 5.3. Real time frame trace: -t
       
       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.
       
 
 5.4. Slow/secure mode: -s
       
       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).
 
 5.5. Measure interval: -i
       
       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.
       
 
 5.6. Quiet Mode: -q
       
       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.
       
 
 5.7. Recorder mode: -r
       
       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.
       
 
 5.8. LAN bandwidth: -b
       
       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.
       
 
 5.9. Promiscuous override: -o.
       
       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.
       
 
 5.10. Filter: -f.
       
       By  default,  ETHLOAD  analyzes (or  records)  all  received
       frames.  If  you want to analyze (or record)  only  specific
       frames, you must use the filter11 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.
       
 
 5.11. Buffers in memory: -m.
       
       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.
       
                               * * *
                                * *
                                 *

6. The different screens of ETHLOAD
       
 
 6.1. Introduction
       
   6.1.1. Screen layout
       
       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 frame12:
           * 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.
       
   6.1.2. Commands.
       
       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).
       
   6.1.3. Data display.
       
       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 estimated13 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%14 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.
       
   6.1.4. Accuracy
       
       A final remark must be done on the accuracy of the figures:
         - some packets are lost15, 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.
       
 
 6.2. MAC Level screen
       
       The MAC level screen can be divided into two parts:
         - three  statistics summaries: last five16 seconds,  busiest
           five seconds, cumulative;
         - VU-meter of the peak and current load.
       
   6.2.1. MAC Summary
       
       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
           load17  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).
       
   6.2.2. MAC VU-meter
       
       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.
       
   6.2.3. MAC Commands
       
       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).
       
 
 6.3. TCP/IP screens
       
       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,...
 
 6.4. DECnet screens
       
       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).
 
 6.5. OSI screens
       
       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.
       
 
 6.6. Summary of all screens.
       
       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.
       
   (E)rror: MAC level errors
       
       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.
       
   (F)low: MAC level traffic matrix
       
       It   displays  the  top  traffic  flows:  from   source   to
       destination.
       
   (M)AC: MAC level statistics
       
       This screen was already described previously.
       
   (L)ength: MAC level frame length.
       
       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!
       
   (R)eceiver: MAC receivers.
       
       Display  the top destination addresses (including  multicast
       addresses flagged by a M after the address).
       
   (T)xr: MAC transmitters.
       
       Display the top source addresses.
       
   (P)rotocol (T)ype/SAP: LLC SAP and Ethernet types.
       
       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).
       
   (P)rotocol  (I)P  (A)RP  (C)ache:  mapping  IP  address  to  MAC
   address
       
       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.
       
   (P)rotocol (I)P (A)RP (H)istory: last ARP events
       
       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.
       
   (P)rotocol  (I)P (A)RP (I)nvertedCache: mapping MAC  address  ->
   IP 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.
       
   (P)rotocol    (I)P    (A)RP    (M)iscellaneous:    miscellaneous
   informations.
       
       Display the last ARP packet received together with the  rate
       of ARP requests and replies per second.
       
   (P)rotocol (I)P (A)RP (S)enders: top senders.
       
       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.
       
   (P)rotocol (I)P (A)RP (T)argets: top targets.
       
       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, ...).
       
                               * * *
                                * *
                                 *

A. Annexes
                                 
 
 A.1. Data Link layer references
       
       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]
       
 
 A.2. Tested data links
       
       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.3. Adding DECnet node names to display.
       
       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.
       
 
 A.4. Common pitfalls.
       
       Here follows a list of common pitfalls.
       
       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
            Buffer 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.
       
       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 onventional
       memory.
       
       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.
       
       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).
       
       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.
       
                               * * *
                                * *
                                 *

Table of contents
1. Introduction.                                          2
2. Miscellaneous and acknowledgements.                    4
    2.1. Original copyright.                             4
    2.2. Current copyright and disclaimer.               4
    2.3. Support.                                        5
    2.4. Distribution channel.                           5
    2.5. Thanks to testers.                              6
    2.6. Changes.                                        6
    2.7. Trademarks.                                     7
    2.8. Source code.                                    8
    2.9. Licensing.                                      8
    2.10. Security.                                      8
3. Configuration files.                                  10
    ETHERS                                              10
    HOSTS                                               11
    NETWORKS                                            11
    PROTOCOL                                            12
    SAPS                                                12
    WKS.TCP (resp. WKS.UDP)                             13
    TYPES                                               13
    VENDORS                                             13
    OBJECTS.DNA                                         14
    NETWORKS.XNS                                        14
    TYPES.XNS                                           15
    WKS.XNS                                             15
    NLIDS.OSI                                           16
    SELECTOR.OSI                                        16
    NSAPS.OSI                                           16
    AFI.OSI                                             17
    ICD.OSI                                             17
    DCC.OSI                                             17
4. Set-up of datalink drivers.                           19
    4.1. Novell ODI.                                    20
    4.2. Microsoft 3Com NDIS v 1.0.1.                   20
    4.3. Microsoft 3Com NDIS v2.0.1 or higher.          21
    4.4. Digital Equipment DLL.                         22
    4.5. Packet driver.                                 22
    4.6. Loopback driver.                               23
    4.7. File driver.                                   23
5. Command line options.                                 25
    5.1. Datalink driver: -d                            25
    5.2. Protocols to be analyzed: -p                   25
    5.3. Real time frame trace: -t                      26
    5.4. Slow/secure mode: -s                           26
    5.5. Measure interval: -i                           26
    5.6. Quiet Mode: -q                                 26
    5.7. Recorder mode: -r                              27
    5.8. LAN bandwidth: -b                              27
    5.9. Promiscuous override: -o.                      27
    5.10. Filter: -f.                                   28
    5.11. Buffers in memory: -m.                        28
6. The different screens of ETHLOAD                      29
    6.1. Introduction                                   29
    6.2. MAC Level screen                               31
    6.3. TCP/IP screens                                 33
    6.4. DECnet screens                                 33
    6.5. OSI screens                                    33
    6.6. Summary of all screens.                        33
A. Annexes                                               37
    A.1. Data Link layer references                     37
    A.2. Tested data links                              37
    A.3. Adding DECnet node names to display.           37
    A.4. Common pitfalls.                               39
Table of contents                                        40
       
       
_______________________________
       1email  in  Belgium is not free :-( So that's  my  employeer
       which  pays any email. If any site in Belgium or  BITnet  is
       whishing  to  start-up a distribution list  for  ETHLOAD,  I
       would  really appreciate ;-) I should also get very  soon  a
       Fidonet address.
       2Also known previously by Yellow Pages.
       3Also known previously by Yellow Pages.
       4For a while... ;-)
       5The  version  1.0.1  is also supported,  but  with  several
       restrictions (see further)...
       6You  can  check  the  version  by  looking  at  the  banner
       displayed  when Protocol Manager is loaded from  CONFIG.SYS.
       Also,  if  the  Protocol Manager directory  is  missing  the
       PROTMAN.EXE file, you can bet you have a old 1.0 version.
       7If   ETHLOAD   displays  a  message  like   'Cannot   parse
       PROTOCOL.INI', you should modify your startup  procedure  to
       run  ETHLOAD  as soon as possible after loading  PROTMAN  in
       the CONFIG.SYS.
       8But  for  the  bindstatus=YES, which increase the  resident
       part  of  the Protocol Manager, thus, reducing the available
       base memory. If you are concerned with base memory, you  may
       instead  use bindstatus=NO, then ETHLOAD won't  be  able  to
       display  some  informations about Protocol Manager  but  wil
       anyway work as usual.
       9ETHDUMP  is a companion utility that dumps all frames  seen
       on  the LAN into an ASCII file (roughly equivalent to the -r
       option).  It  is  a  public  domain  program,  available  as
       ETHDPvrr.ZIP from Simtel repository or from ub4b.buug.be.
       10A tick is generated by the PC clock 18.2 times per second.
       11Please note that the filter option is very trivial and can
       consist of a single -f option.
       12This  display  together with the '+/-' flip-flop  is  only
       displayed by memory mapped IO on colour displays.
       13This  is a rough estimation: preamble are neglected,  runt
       packets  are  not analyzed, all frames are  assumed  of  the
       same length...
       14This  results comes from: 100 frames * 1000  bits/frame  /
       (10E+7 bits/second * 10 second) = 10E-3 = 0,1%
       15It  even seems that packet drivers do not count  the  lost
       packets  so  Ethload  cannot  display  the  dropped   frames
       percentage.
       16Or whatever interval you have specified with the -i option
       on the command line.
       17The  load is computed as: sum(MACheader+MACdata+FCS)*8/LAN
       bandwidth*100%.