Ethload User's Guide
Category: Tutorial
<< Buy This Book on Amazon >>
80 views since 2007-05-19, updated at 2007-05-27.
Description
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 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:
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:
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.