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 contents1. Introduction.                                          22. 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.                                      83. 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                                             174. 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.                                   235. 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.                        286. 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.                        33A. 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.                               39Table 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%.