ࡱ; v  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuwxyz{|}~Root Entry FZtCompObjbWordDocumentkObjectPoolSYtSYt  FMicrosoft Word 6.0 Document MSWordDocWord.Document.6;  Oh+'0$h   @ d (C:\MSOFFICE\WINWORD\TEMPLATE\NORMAL.DOTEthload User's GuideEthload User's Guide'Documentation of the shareware ETHLOܥe= ekj,jjlj(mLZpZpZpTsTsTsTsTs `s@sTs?`vt`|v|v|v|v| prrrHكH!Tx?Zp #v|v|?ZpZpv|vtZpv|Zpv|pnpqtmnZpZppV ETHLOAD 2.00 USER'S GUIDE A shareware Ethernet load/problems analyzer and events tracer E. Vyncke Eric.Vyncke@csl.sni.be SAVEDATE \@ "d MMMM yyyy"5 September 1996 1. Introduction. ETHLOAD is a shareware running on any MS-DOS PC with an Ethernet or Token Ring controller. Currently, ETHLOAD supports the following drivers (for Ethernet and Token Ring): Digital Equipment Corp. DLL specification (Pathworks); Microsoft 3Com NDIS (Network Driver Interface Specification) version 2; 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 or Token Ring 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, LAN Manager 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 main RFC 1006 (ISO on TCP) events; see the working of DNS; see important TCP events: start/stop of connections,... links to LAN Manager and Windows for Workgroup; see some events for services like WWW, NNTP, ... 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; links to LAN Manager; 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. In a LAN Manager or Windows for Workgroups network, ETHLOAD allows you to: see the different servers and redirectors (clients); see the different SMB protocol operations; see the file operations; see the NET USE operations; works with NetBEUI, TCP/IP and DECnet (Pathworks). * * * * * * 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. Now, the source code has been completely rewritten and improved. I just mention this copyright to be fair-play to my old colleagues. 2.2. Current copyright and disclaimer. Right now, all software developments are made home and tested after working hours in my current employeer: 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. 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 trying to read this newsgroup every day. Anyway, you can get some support from the author since he wants to promote this software... You can reach the author through email: Eric.Vyncke@ping.be or by post mail (not valid after 1st April 1997): Eric Vyncke Rue Nolden, 25 B-4432 Alleur Belgium (Europe). After this date: Eric Vyncke Alle des Chardonnerets, 3 B-4432 Alleur Belgium (Europe). If you are happy with ETHLOAD, my little sons, Pierre (born 92) and Thibault (born August 95), would appreciate to receive any postcard (they still live with us :-)! Beware that the above address is no more valid after 31st December 1996 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. The reference URL of Ethload is http://www.sni.be/as-ref The reference FTP site is ftp.tornado.be. Mirror servers are welcome specially because the Internet connectivity is quite poor! If you do so, please warn me by email in order to keep a list of distribution channels. 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 Bob Childress, bchildress@ti.com Michel Dalle, michel@d92.cb.sni.be Serge Hoffman, Serge.Hoffman@belgium.honeywell.com Niels Kr. Jensen, msterlje@vm.uni-c.dk Hans-Joachim Koch, koch@lifra.lif.de D. Lange, cintra@u.washington.edu Neil J. Long, Neil.Long@materials.oxford.ac.uk Hans-Michael Pronk, hpronk@hk.nl A.A.L. Reijnierse, A.A.L.Reijnierse@research.ptt.nl Frank Van Uffelen, frankvu@bix.com, fvu@te6.siemens.be I thank also for comments, suggestions, ...: Joe Doupnik, jrd@cc.usu.edu Knut Eckstein, eckstein@isd.uni-stuttgart.de Thomas Gasser, thomasg@staff.tc.umn.edu Derek Johnston, ugcsjj9697@mtvms2.mtech.edu Ross Lazarus, rossl@westmead.health.su.oz.au Ted Llellewyn, tsl@panix.com Jos Minnema, jos.minnema@pagv.agro.nl Craig Morgan, cmrcm@staffs.ac.uk Russ Nelson, nelson@crynwr.com Hugo Philips, zigo@uc.sni.be Oliver Rehmann, orehmann@itr.ch Lars Scheffmann, scheffmann@dou.dk Russell Thamm, rmt@gwd.erl.dsto.gov.au And, all of you who have send a postcard :-) 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 1.99 safer frame reception routines new internal routines to remove NRB stuff quits a menu registered versions have more functions: save displayed screen on disk by save periodically statistics on file larger number of buffers support for LAN Manager and NFS (including RPC) support of OSI on TCP/IP support of HTTP and NNTP on TCP/IP code ported from Borland C to Microsoft C (most ODI routines written now in assembler :-( ) 1.99 partial NDIS 3.0 support via NDIS3PKT Coming soon: Banyan Vines support (I need a Vines user!) FDDI and other non IEEE 802.3/802.5 LAN (I also need a FDDI user!) NDIS 3.0 support (Windows for Workgroups and probably Windows 95) Internet security (tracking probes, source routed packets, ...) 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 partly by NRB and Eric Vyncke. Version 1.01, 1.02, 1.03 and 1.04 were and are still free, you may use it, copy it (on any support), distribute it as long as you don't earn money from it (of course you may get paid a little for the media/transmission cost). This right is given for an unlimited period of time :-) I would appreciate it if my little sons received a postcard from you (see 2.3). As ETHLOAD is now more than 65,000 lines of C code, version ETHLOAD 2.00 is now a shareware with two possibilities: unregistered with limited functionalities, you are allowed to use it, to copy it and distribute it as before but you have the moral duty :-) to send a postcard to one of my two sons (either Pierre born 1992 or Thibault born 1995 -- both are still living at the same address as me) registered with additional functionalities: more diligent support, print outs, periodic statistics into a file, more buffers, ... The registration fee (USD $199, ECU 199, BEF 8000) will allow you the right to use it for an unlimited period of time on any PC within your organization. Moreover, you will receive a 'registration key' that will allow you to get print-outs of ETHLOAD, an Excel compatible file for the load of the day, a larger number of internal buffers (so less dropped frames), a fully configurable of table size (in order to avoid the 'Filled since ...' message). See the attached registration form. Version 1.99 has a completely different screen layout. The code is now completely different from the code of the NRB version and the copyright of NRB has been deleted. Now, enough about these stuffs, let's have fun and start ETHLOAD ! 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/FTP/POP sessions, ETHLOAD will be able to do this. To be allowed to monitor these sessions or to check the contents of connect initiate of DECnet, you need a special software key linked to the Ethernet ROM address of your PC. This key will be delivered only after I have received an OFFICIAL paper letter from a very high level manager of your company (e.g. for University the rector or for a commercial organisation the head of EDP department or of a CEO). This letter should bear the name of the PC operator, his/her email address and the physical address of the PC. Even with this paper letter, the author may not give you the authorization for any reason. * * * * * * 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. When ETHLOAD first runs or when one configuration file is changed, a new index file (usually with the .EVX extension) is created in the same directory as for the configuration file. This also means that you need write access to this directory. If a configuration file is missing, ETHLOAD will complain about that but will further continue to execute. If an index file cannot be created, ETHLOAD will also complain and continue. 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 NIS). 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: 193.210.175.0 PS 193.210.184.0 CSL The best way to initiate this file is to get a /etc/networks from a UNIX machine (or the stdout of the ypcat networks.byaddr if you are running NIS) and use sed to get the correct format. 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 correct 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 Microsoft 3Com NDIS version 3.0 (Windows for Workgroup, Windows 95) can be supported with Dan Lancianis NDIS3PKT converter 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, packet driver and ODI. Finally, only one kind of drivers namely ODI allows for the identification of faulty frame by their source or destination addresses. In conclusion, if your Ethernet hardware has a ODI driver with promiscuous mode support, it is better to use ODI. ETHLOAD despite its name can probably work on all IEEE LAN (with 48 bits addresses and IEEE 802.2 LLC sub-layer). Starlan has been analyzed through ETHLOAD. The single point to keep in mind is that the MAC screen (see further) is computed for a bandwidth of 10 Mbps (or you may elect to use the -b option to specify the LAN bandwidth). If you want to try ETHLOAD on non IEEE 802.3 LANs, I would be happy to work with you to support these LANs (i.e. FDDI, ...). Another important point is that most Token Ring adapters do not support promiscuous mode (notably IBM adapters). So, when starting ETHLOAD a warning message will be displayed and only broadcast/multicast packets will be analyzed showing a very lightly loaded token ring! The only way to escape this problem is to get a promiscuous mode adapter and driver (IBM has a trace adapter, Olicom supports promiscuous mode). The ODI driver for Madge adapters is supported by ETHLOAD. A final remark, packet driver does not differentiate between the various kind of errors in its statistics. So, you should use any other driver if possible. 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. Remark: when using a recent LSL or ODI MLID driver, ETHLOAD can refuse to start with the error message Error: cannot register receive monitor because not supported. If so, you should use the special RXMONSTK utility provided by Novell. This utility ust be loaded immediately after LSL and before the ODI driver. (This information comes from Ken Cornetet and I would appreciate to receive more information from knowledgeable people about this). 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 , ETHLOAD will display some warnings and you have to pay special attention to the following points: \SYMBOL 183 \f "Symbol" don't run NETBIND.EXE before ETHLOAD (so look out in your AUTOEXEC.BAT for an automatic run of NETBIND.EXE) \SYMBOL 183 \f "Symbol" reboot your PC after running ETHLOAD since Protocol Manager cannot be reset in a correct state \SYMBOL 183 \f "Symbol" some statistics are missing. 4.3. Microsoft 3Com NDIS v2.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, after a section): [ETHLOAD] drivername = ETHLOAD$ bindings = MYMAC where MYMAC is the name of the MAC module you want to use. The MAC module name is what is between [] in PROTOCOL.INI which is followed by a drivername= line with the name of the device driver loaded in CONFIG.SYS (the name of a MAC module often ends with _NIF). You also have to modify the [PROTOCOL MANAGER] entry to add a dynamic line. But first try without this modification before modifying further your PROTOCOL.INI file. [PROTOCOL MANAGER] devicename = PROTMAN$ dynamic = YES bindstatus = YES priority = ETHLOAD These modifications do not modify the usual behaviour of your PC, so you may leave these lines in your PROTOCOL.INI file even if you don't use ETHLOAD. After you have made these changes, you must reboot your PC. After this reboot, when you want to use ETHLOAD you must issue the ETHLOAD command to the MS-DOS prompt. By the way, the Protocol Manager directory (containing NETBIND, ...) should be in the PATH of MS-DOS. Remark 1: in PROTOCOL.INI the case of the left part of '=' does not matter, but uppercase characters must be used on the right part as indicated in the examples above. Remark 2: the use of ETHLOAD should not be disruptive for your favourite protocol stacks, so you should not have to reboot your PC. Remark 3: you may have to run READPRO before loading ETHLOAD if the image copy of PROTOCOL.INI is corrupted (i.e. ETHLOAD displays an error message like 'PROTOCOL.INI corrupted'). 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 1: in order to go promiscuous, DLL requires that ETHLOAD shutdown ALL connections: LAT, DECnet, ... After using ETHLOAD you probably will have to reset the whole DECnet protocol stack (so reboot your PC). Note 2: it seems that at least for version 4.1 of DLL, it is impossible to run ETHLOAD in a DOS box within MS-Windows 3.1. Note 3: it seems that since Pathwork 5.0, ETHLOAD cannot be used anymore... If some Digital employees, gurus or customer could send me the update API to these drivers, I would be happy to add support for Pathwork 5.0. 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 ftp.crynwr.com. For BITNET users, they can also be fetched through TRICKLE server. The Crynwr Packet Driver Collection is copyrighted using the GNU General Public License. Remark 2: for the 3Com 3C509 you should use version 11.* of the Crynwr packet driver or even the latest packet driver from 3Com (comment from Andy Leigh, BBC). Remark 3: for some packet drivers, you may have to run PKTRCV with the mode 3 before running ETHLOAD, you may even have to unload all programs using the packet driver... 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 ETHDUMP. The format of the file is simple: - empty lines or lines beginning with a ';' are ignored; - else line consists of 2 decimal tokens followed by the frame. The decimal tokens are: 1) a time-stamp when the frame was received expressed in MS-DOS ticks from the start of the recording; 2) the length of the received frame including the FCS, this length may be different from the length of the frame in the file. The frame itself starts with the first byte of the destination address (excluding the preamble) and goes through all fields: source address, Ethernet type or IEEE 802.3 length, data bytes, ... For Token Ring, FA and AC are also copied. Each byte is represented by two contiguous hexadecimal digits. Bytes can be separated by spaces, tabs and '-'. An example of input file is: 0000000087 0060 000E20009127 0000E80109FC 0020 FF-FF-00-20-01-00-00-00-00-03-00-0E-20-00-91-27-40-05-00-B0-BB-1E-00-00-00-00-00-01 ; 0000000125 0060 00AA001E1FE4 000080CAC901 0020 FF-FF-00-20-01-00-00-00-00-03-00-AA-00-1E-1F-E4-40-05-00-00-02-01-00-00-00-00-00-01 ; 0000000141 0110 FFFFFFFFFFFF 00AA001E1FE4 0060 FF-FF-00-60-00-04-00-00-00-00-FF-FF-FF-FF-FF-FF-04-52-00-00-00-03-00-AA-00-1E-1F-E4 * * * * * * 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 filter option to specify: - the IEEE 802.2 LLC SAP to analyze: -fhh where hh are two hexadecimal digits specifying the SAP value for both the DSAP and SSAP (see file SAPS for more details); - the Ethernet type or DoD SNAP type to analyze: -fhhhh where hhhh are four hexadecimal digits specifying a type (see file TYPES for more details); - the MAC source or destination addresses to analyze: -fhh-hh-hh-hh-hh-hh where hh are hexadecimal digits of the MAC address. 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 frame: * six bytes of MAC destination address ; * six bytes of MAC source address ; * two byte(s) for either DIX packet type or for IEEE 802.3 frame length; * a few bytes of data. - on a Token Ring, the ring status is displayed in RED on the top line when the ring is beaconing or being purged. All screens are automatically refreshed every measure interval (5 seconds by default) to reflect the current statistics or table contents. You may also press the SPACE key to refresh the screen. 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 : 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 estimated bandwidth used relative to the raw LAN bandwidth (10 Mbps for Ethernet). For instance, if during 10 seconds on a 10 Mbps Ethernet there were 1000 DECnet packets and 1000 IP packets and within these 1000 IP packets there were 100 UDP packets, the IP protocol screen will display for the UDP protocol (assuming a mean packet length of 1000 bits): - 10 % (i.e. 10% of IP packets are UDP datagrams); - 5% (i.e. 5% of frames are UDP datagrams); - 0,1% (i.e. 0,1% of the Ethernet bandwidth is used by UDP datagrams). A reference is also displayed by indicating how many frames represents 100%. The user can switch from one display to another by pressing the '%' key. As all counters are 32 bits, they are limited to about 4E+9 frames. Once they reach this upper bound they are stopped and the whole table is kept unchanged. The time of this table overflow is then displayed in red. As the size of the table is limited in size, when the table is filled, this is displayed by a yellow message on the top of the screen. Each line of a 'top display' consists of: - percentage (e.g. the percentage of Ethernet frames transmitted by the displayed Ethernet node in respect to the total number of Ethernet frames); - display of the node (e.g. Ethernet MAC address with perhaps the corresponding host name of DECnet address); - a bar graph for visual representation (resolution 2.5%). The 'raw table display' is just the display of a non sorted internal table. An example is the display of the ARP table. Each line of a 'raw table display' consists of two values (e.g. the Ethernet MAC address associated with an IP address). The 'event history' is used to display a chronological log of events (e.g. the list of ICMP requests). Each line of an 'event history' consists of: - a time stamp in the form hh:mm:ss.hh; - a description of the event. 6.1.4. Accuracy A final remark must be done on the accuracy of the figures: - some packets are lost, so the load is always higher than indicated if you are using a slow Ethernet controller or a non efficient driver; - ETHLOAD relies on the MS-DOS timer which has a resolution of about 50 msec, moreover if the network load is high and you have a powerless CPU some timer ticks can be missed; - if you are running with IRQ disabled (i.e. without the -f option), some datalink drivers can miss frames without further notification, so the drop percentage is always higher than the one displayed by ETHLOAD. To summarize, ETHLOAD give reliable figure on a medium loaded Ethernet (10% ?) and on a correct CPU 80386dx 25 MHz. In all other case, ETHLOAD can only indicate that your Ethernet is probably heavily loaded and you will have to buy an expensive LAN analyzer! Moreover, all tables have a maximum size, so it may occurs that on a medium or large LAN some tables are filled. This is indicated on the screen. E.g. the MAC flow table will probably be more or less useless on a LAN with more than 50 stations. Version 2.0 of ETHLOAD will: - drop less frames due to an ordered multi-buffered scheme (only for NDIS and ODI); - use a finer timer. 6.2. MAC Level screen The MAC level screen can be divided into two parts: - three statistics summaries: last five seconds, busiest five seconds, cumulative; - VU-meter of the peak and current load. 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 load of Ethernet in % of the 10 Mbps bandwidth of Ethernet; - the number of frames containing errors + rate of error per second. As the internal counters are 32 bits, counters are bounded to about 4E+9 frames/bytes. Once the counters reach this count; they are stopped and displayed as ******. If the datalink driver supports error differentiation (namely all but packet driver), the kind of error is also indicated: - CRC error (cabling problem ?); - too long packet (babbling transceiver or controller); - too short packet (garbage of collision). If you are using the ODI datalink driver, by using the 'E' command you have access to the MAC source address of faulty Ethernet frames (by the way don't be amazed by unknown MAC addresses because even the source address can be faulty in faulty frames... specially for runt frames). 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. Memory From: Wey Jing Ho . 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 . When running Ethload with an ODI driver, the file NET.CFG should contains: Link Support Buffers 4 1600 MemPool 4096 Moreover, it seems that Novell LAN Workplace can run while Ethload is running but IPXODI and NETX cannot be loaded when Ethload is running. So, IPXODI and NETX must be unloaded before starting Ethload. The NET.CFG file should also contain a line Frame Ethernet_II for your network adapter. Then you should try to specify this frame type to Ethload but starting Ethload with the -do1 or -do2 or -do3 command line option. NDIS driver With NDIS driver, ETHLOAD needs much more memory than with other drivers, so you may have to specify which protocols you want to analyze by using the -p option. Packet driver 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. Sun PC-NFS From: Eric Vyncke, here is the set-up to use ETHLOAD with PC-NFS of Sun (when the NDIS driver is used): excerpt from CONFIG.SYS: DEVICE=c:\NFS\PCNFS.SYS DEVICE=c:\NFS\SOCKDRV.SYS DEVICE=c:\LANMAN\PROTMAN.SYS rem Replace the next line with your actual NDIS driver DEVICE=C:\LANMAN\ELNKPL device=c:\usr\lan\dis_pkt.gup DEVICE=C:\LANMAN\NFS-NDIS.SYS Registration form How to register ? fill this form send it by E-mail to Eric.Vyncke@ping.be or by post to the address printed below the registration fee is USD $200 ECU 130 BEF (Belgian Francs) 5.000 you can send the registration fee either by: postal money order send to my postal address Eurocheque in Belgian Francs (beware that the location should be Lige/Belgium) bank giro to my Belgian bank BBL 340-0923670-74 (mention ETHLOAD and your name as communication) You shall then receive by E-mail, fax or post a special key file which will enable the use of all features of Ethload. Postal addresses: Before 1st April 1997 After 1st April 1997 Eric Vyncke Eric Vyncke Rue Nolden, 25 Alle des Chardonnerets, 3 4432 Alleur 4432 Alleur Belgium (Europe) Belgium (Europe) Company nameDepartment + office locationLast nameFirst nameStreet and NoZip code + State + CityCountryE-mail addressFax numberVersion of Ethload+type of driverDo you want to receive the latest version available ?Invoice needed (not for Belgium) ? * * * * * * Table of contents TOC \o "1-2"1. Introduction.  GOTOBUTTON _Toc366594489  PAGEREF _Toc366594489 2 2. Miscellaneous and acknowledgements.  GOTOBUTTON _Toc366594490  PAGEREF _Toc366594490 4 2.1. Original copyright.  GOTOBUTTON _Toc366594491  PAGEREF _Toc366594491 4 2.2. Current copyright and disclaimer.  GOTOBUTTON _Toc366594492  PAGEREF _Toc366594492 4 2.3. Support.  GOTOBUTTON _Toc366594493  PAGEREF _Toc366594493 4 2.4. Distribution channel.  GOTOBUTTON _Toc366594494  PAGEREF _Toc366594494 5 2.5. Thanks to testers.  GOTOBUTTON _Toc366594495  PAGEREF _Toc366594495 5 2.6. Changes.  GOTOBUTTON _Toc366594496  PAGEREF _Toc366594496 6 2.7. Trademarks.  GOTOBUTTON _Toc366594497  PAGEREF _Toc366594497 7 2.8. Source code.  GOTOBUTTON _Toc366594498  PAGEREF _Toc366594498 8 2.9. Licensing.  GOTOBUTTON _Toc366594499  PAGEREF _Toc366594499 8 2.10. Security.  GOTOBUTTON _Toc366594500  PAGEREF _Toc366594500 9 3. Configuration files.  GOTOBUTTON _Toc366594501  PAGEREF _Toc366594501 10 ETHERS  GOTOBUTTON _Toc366594502  PAGEREF _Toc366594502 10 HOSTS  GOTOBUTTON _Toc366594503  PAGEREF _Toc366594503 11 NETWORKS  GOTOBUTTON _Toc366594504  PAGEREF _Toc366594504 12 PROTOCOL  GOTOBUTTON _Toc366594505  PAGEREF _Toc366594505 12 SAPS  GOTOBUTTON _Toc366594506  PAGEREF _Toc366594506 13 WKS.TCP (resp. WKS.UDP)  GOTOBUTTON _Toc366594507  PAGEREF _Toc366594507 13 TYPES  GOTOBUTTON _Toc366594508  PAGEREF _Toc366594508 14 VENDORS  GOTOBUTTON _Toc366594509  PAGEREF _Toc366594509 14 OBJECTS.DNA  GOTOBUTTON _Toc366594510  PAGEREF _Toc366594510 14 NETWORKS.XNS  GOTOBUTTON _Toc366594511  PAGEREF _Toc366594511 15 TYPES.XNS  GOTOBUTTON _Toc366594512  PAGEREF _Toc366594512 15 WKS.XNS  GOTOBUTTON _Toc366594513  PAGEREF _Toc366594513 16 NLIDS.OSI  GOTOBUTTON _Toc366594514  PAGEREF _Toc366594514 16 SELECTOR.OSI  GOTOBUTTON _Toc366594515  PAGEREF _Toc366594515 17 NSAPS.OSI  GOTOBUTTON _Toc366594516  PAGEREF _Toc366594516 17 AFI.OSI  GOTOBUTTON _Toc366594517  PAGEREF _Toc366594517 17 ICD.OSI  GOTOBUTTON _Toc366594518  PAGEREF _Toc366594518 18 DCC.OSI  GOTOBUTTON _Toc366594519  PAGEREF _Toc366594519 18 4. Set-up of datalink drivers.  GOTOBUTTON _Toc366594520  PAGEREF _Toc366594520 20 4.1. Novell ODI.  GOTOBUTTON _Toc366594521  PAGEREF _Toc366594521 21 4.2. Microsoft 3Com NDIS v 1.0.1.  GOTOBUTTON _Toc366594522  PAGEREF _Toc366594522 22 4.3. Microsoft 3Com NDIS v2.0.1.  GOTOBUTTON _Toc366594523  PAGEREF _Toc366594523 23 4.4. Digital Equipment DLL.  GOTOBUTTON _Toc366594524  PAGEREF _Toc366594524 24 4.5. Packet driver.  GOTOBUTTON _Toc366594525  PAGEREF _Toc366594525 24 4.6. Loopback driver.  GOTOBUTTON _Toc366594526  PAGEREF _Toc366594526 25 4.7. File driver.  GOTOBUTTON _Toc366594527  PAGEREF _Toc366594527 25 5. Command line options.  GOTOBUTTON _Toc366594528  PAGEREF _Toc366594528 27 5.1. Datalink driver: -d  GOTOBUTTON _Toc366594529  PAGEREF _Toc366594529 27 5.2. Protocols to be analyzed: -p  GOTOBUTTON _Toc366594530  PAGEREF _Toc366594530 27 5.3. Real time frame trace: -t  GOTOBUTTON _Toc366594531  PAGEREF _Toc366594531 28 5.4. Slow/secure mode: -s  GOTOBUTTON _Toc366594532  PAGEREF _Toc366594532 28 5.5. Measure interval: -i  GOTOBUTTON _Toc366594533  PAGEREF _Toc366594533 28 5.6. Quiet Mode: -q  GOTOBUTTON _Toc366594534  PAGEREF _Toc366594534 29 5.7. Recorder mode: -r  GOTOBUTTON _Toc366594535  PAGEREF _Toc366594535 29 5.8. LAN bandwidth: -b  GOTOBUTTON _Toc366594536  PAGEREF _Toc366594536 29 5.9. Promiscuous override: -o.  GOTOBUTTON _Toc366594537  PAGEREF _Toc366594537 29 5.10. Filter: -f.  GOTOBUTTON _Toc366594538  PAGEREF _Toc366594538 30 5.11. Buffers in memory: -m.  GOTOBUTTON _Toc366594539  PAGEREF _Toc366594539 30 6. The different screens of ETHLOAD  GOTOBUTTON _Toc366594540  PAGEREF _Toc366594540 32 6.1. Introduction  GOTOBUTTON _Toc366594541  PAGEREF _Toc366594541 32 6.2. MAC Level screen  GOTOBUTTON _Toc366594542  PAGEREF _Toc366594542 35 6.3. TCP/IP screens  GOTOBUTTON _Toc366594543  PAGEREF _Toc366594543 36 6.4. DECnet screens  GOTOBUTTON _Toc366594544  PAGEREF _Toc366594544 36 6.5. OSI screens  GOTOBUTTON _Toc366594545  PAGEREF _Toc366594545 37 6.6. Summary of all screens.  GOTOBUTTON _Toc366594546  PAGEREF _Toc366594546 37 A. Annexes  GOTOBUTTON _Toc366594547  PAGEREF _Toc366594547 40 A.1. Data Link layer references  GOTOBUTTON _Toc366594548  PAGEREF _Toc366594548 40 A.2. Tested data links  GOTOBUTTON _Toc366594549  PAGEREF _Toc366594549 40 A.3. Adding DECnet node names to display.  GOTOBUTTON _Toc366594550  PAGEREF _Toc366594550 40 A.4. Common pitfalls.  GOTOBUTTON _Toc366594551  PAGEREF _Toc366594551 42 Registration form  GOTOBUTTON _Toc366594552  PAGEREF _Toc366594552 44 Table of contents  GOTOBUTTON _Toc366594553  PAGEREF _Toc366594553 45  Also known previously by Yellow Pages. Also known previously by Yellow Pages. For a while... ;-) The version 1.0.1 is also supported, but with several restrictions (see further)...  By information, I mean version of LSL or ODI specification, location of RXMONSTK (FTP site or shipped with Netware) and also location on the Internet of the latest ODI spec. You 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. If 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. But 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. ETHDUMP 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. A tick is generated by the PC clock 18.2 times per second. Please note that the filter option is very trivial and can consist of a single -f option. This display together with the '+/-' flip-flop is only displayed by memory mapped IO on colour displays. This is a rough estimation: preamble are neglected, runt packets are not analyzed, all frames are assumed of the same length... This results comes from: 100 frames * 1000 bits/frame / (10E+7 bits/second * 10 second) = 10E-3 = 0,1% It even seems that packet drivers do not count the lost packets so Ethload cannot display the dropped frames percentage. Or whatever interval you have specified with the -i option on the command line. The load is computed as: sum(MACheader+MACdata+FCS)*8/LAN bandwidth*100%. ETHLOAD user's guide \PAGE \* ARABIC46 !/=nnࡱ; SummaryInformation(HAD Eric Vyncke Eric Vyncke@Ϸ@@^Stq'@8Microsoft Word 6.0,124ࡱ;    ! Yde4 SBU^vy +Y+M,W,i-j-#.3.33&7M777;;;;==AAAAAABBCC D D7D8DBD uDPU]aU^VUVa^UU]] uDUc(Uc(UBDEDjExEE FPJ]JJJOOq^r^^^__hhijmnooooooppssssttntotptqtttttuu+y,yAUo}ijfg?[^běόҌ׌;>BFҍՍۍߍ QTU^acuD]VU uDPU]aaU]XT`dm«ǫ18t{CPدٯil@Sĵ׵3Bop]^оѾ#$y 6:DG0<D"iqUVU uDPU^aa^)*K\^%35iZ=Dls.26:>Bde&'_gfhLNq-.EFGIcduDV]VaaUaU^ &'>?@B^_z{*+,.@A\]tuvx 9:QRSUno #$uDc$&(23NOfgikuv"#:;=?FGbcz{}12IJLNYZuv&'BCZ[]_juDcjk "#%'01LMdegi 01LMdegi/0KLcdfh:;uDc;RSUWqr&'BCZ[]_z{89PQSUmn34KLNPcd45LMOuDcOQde679;PQlm&')+78STklnpFGbcz{}./uDc/JKbceghijk#$  i j v  % 2             qr<=u uDcc] uDPuD9 !"/Oabcdn !rI$%%%%% % %%%%%%%%%%%%%%%&%%%%&%&%D%&%&%&%%%D 4 &)')()))   !  !p.Fy9 u $ K c ) f  %D%&%%&%&%&%&%&%&%%&%&%&%&%&%&%D%&%&%&%&%&%&%&%%&%&%&%&%%%&   4  4  O   F b x 'DE %XY_ce%&%&%D%%%&%&%&%%%&%&%&%&%%%&%&%&%&%&%%&%%&%%&%R%&   4n   4DENO 4BTUCDRS}~-EF%%%%R%%%R%%%%%%%%%%%%%%%%%%%%%c%%%R%%%%%%%%%R%%%&)')()))+Nu @wxBo/Ryz ?%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%R%%%&%&%&%&%&%&  48&.G_k 0 K !1!\!!!! "g"""#-#?#`##%%%&%&%&%&%&%&%&%&%&%%%&%&%&%&%&%&%&%&%&%%%&%&%&%&%&%&%&%D%&%&%&%&%&%&%D  4'##$K$L$Q$p$$$$$!%:%j%%%&&-&.&;&g&&&,'='>''%&%&%&%%%&%&%&%&%&%&%&%&%&%&%D%%&%&%%&%&%&%&%R%%  4  4  4'''(())))Y+Z++,j-k-R/S///?0@0P0Q00000333333344G5H5%R%%%%%R%%%%%%%D%%%%%%%R%%%%% %%%%%%%%%%  4%H5x55566677 8 8\8]888p9q9e:f:;;&;';w;x;;;9<:<O<P<<<<<<==J>K>%%&%&%c%%%%%%%%%%%%%%%R%%%%%%%%%%%&%%%% 4'K>>>??????[@\@@@@@@A9A]AuAvABBBBBCCgChCCCCCCaDjDkDDDDD1E2E&F'F%%%%%R%%%%%%%%%%%%&%S%R%%%%%%%%%&%%R%%%%%%%%-'FKFLFWFdFFFFFFF G3G8G9GGGGGGG HHH0HZHnHHHHHHHHH2I3IIIIIIIIIJ%%%%%%%%%%%&%%%%%%%%%%%%%&%%%%R%%%%%%%%%%&-JJJJKKKZK[KKKKKKKKKKKLLL?M@M_M`MsMMMMMMMNNHNINNNNNNNNNN%S%%S%R%%%%%%%%%&%R%%%%%%%%%&%R%%%%%%%%%%&%-N6O7OOOOO P!P7PQPSPuPwPPPPPPP7Q8QQQQQ R RR?RHRRRvRRRRRRRRISJSSS T T%%%%%%%%%%%%&%%%R%%%%%%%%%%%%%%&%%%R%%%%%%- T&T'TITVTlTTTTTTUUKULUVUWUUUUUVVVAVBVOVPVVVVVWW$WTWWWWWXXEXOXPX%%%%%%%%%%&%%%R%%%%%&%%R%%%%%%%%%%%%&%%R%,PXXX2Y3YgYhYYYYZZyZzZZZZZ[P[{[[[[[[[T\U\t\u\\\\\\]]>]?]G]H]]]%%%%%%&%%R%%%%%%%%&%%%R%%%%%%%%%&%%R%%+]]] ^ ^^0^C^V^W^^^^^^^^z___&`=`S`f`g`6a7aaaZb[b`cacccddeddd%%%%%%&%%%%%%%&%&%D%&%&%&%%%%%%%%%%%%%% 4&dffhhi/i0ijjjjkkflgl!m"mimjm*oLoMo p plpmpwppppppvqwqqqrrrr1s2sspt%%%%%%R%%%%%%%%%%%%%%R%%%%%%&%%%%%%%%%%%%%,ptt uAuBuuuRvSv]vtvvvww4x5xHx_xnxxxx.y/ykylyyy?gGmbc̏CƐ%%%%%%%%%%%%%%%%%%R%%%%%%%%%%%R%%%%%%%%8+ƐJijڒےop͓Γab -.BCOPj%%%%%%R%%%%%%%R%%%%%%%%%%%%R%%%%%R%%%%%%%R%%%-jkޚߚ !89z{-.tuߜ./؝ٝ ewx_`%%%%%%R%%%%%%%%%R%%%%%%%%%R%%%%%%R%%%%%%%%%%,Хѥ,SӧϨ<SƩǩ,-ǭȭ !%%%%%%%%R%%%%%%%%%%%%%%%%%%%%%%%%%*!>?01kɯ#$4g۱ܱstKLӳԳ;<./Ķ Xijmn%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%,ncdջ6ǼȼW NOp$%klRh%%%%%%R%%%%%%%%%%%%%%%%%%%%%%%%%%, vwp4tB:cab%%%%%%%R%%%%%%%%R%%%%%R%%%%%R%%%%%%%%%,#$RSuv9: NO >?BCM%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-MN01_`#$HI5)*JK$%[\st%%%%%%%%%%%%%%%%%%%%%%%%%%R%D%%D%%D%%j%%R%+i@89-.78bq "1@Ahik%%%%%%%%%%%%%%%R%%%%%%%%%%%%%%%%&%%%,02fh!<=@AWX:;() {|%%%%%%%%%%%%%%%%%%%%&%%%R%%%%%%%%%%%%%&%%,|XYef_x4Rdew%xC%%%%%%%%%%%%%%%%%%&%%%%%%%&  4  4. Hu&'6XYfgh%&%&%%&%D%D%%D%%%%%%%%yyyyyyyyl F&  4.  4LMNqrstz~JC/y yyyyyyyyyyyyyyyy%%%%%%%%%%%%%%%%l F&( V)l@O`(jjiX`VQR<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-,qhj# i       q<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%" K&@&Normaln ]a c*@* Heading 1  U^c$&@& Heading 2Uc @ Heading 37U"A@"Default Paragraph Font"@" Normal Indent *@ Endnote Referenceh&@&TOC 3R!p#&@&TOC 2R9!p# &@&TOC 1R9!p#  @B Footer o# @R Header o#$&@a$Footnote Referencece"@r" Footnote Textc(O(computer  ]a"O" dcal <O<exemples & ' ( ) 1%]a?7Aq[\lpnq+vifجo]л  (PdiI7Y .     !"#$%&'()*+,-.PPPPPPPd77YYYYY   !"#$%&'()*+,- .!!!!!!!!! ! ! ! ! !!!!!!!!!!!!!!!!!!! !!!"!#!$!%!&!'!(!)!*!+!,!- .)e UB>$?-0w8v>LCGK OSW [[ ckpq'FJN TPX]dpt~Ɛj!nM| pqpqqqr-EGHc &>@A^z*,-@\tvw 9QSTn #&'2Nfiju":=>Fbz}~1ILMYu&BZ]^j "%&0Ldgh 0Ldgh/Kcfg:RUVq&BZ]^z8PSTm3KNOc4LOPd69:Pl&)*7SknoFbz}~.Jbefh 999 2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%D2%@2%@%(.! _Toc366594489 _Toc366594490 _Toc366594491 _Toc366594492 _Toc366594493 _Toc366594494 _Toc366594495 _Toc366594496 _Toc366594497 _Toc366594498 _Toc366594499 _Toc366594500 _Toc366594501 _Toc366594502 _Toc366594503 _Toc366594504 _Toc366594505 _Toc366594506 _Toc366594507 _Toc366594508 _Toc366594509 _Toc366594510 _Toc366594511 _Toc366594512 _Toc366594513 _Toc366594514 _Toc366594515 _Toc366594516 _Toc366594517 _Toc366594518 _Toc366594519 _Toc366594520 _Toc366594521 _Toc366594522 _Toc366594523 _Toc366594524 _Toc366594525 _Toc366594526 _Toc366594527 _Toc366594528 _Toc366594529 _Toc366594530 _Toc366594531 _Toc366594532 _Toc366594533 _Toc366594534 _Toc366594535 _Toc366594536 _Toc366594537 _Toc366594538 _Toc366594539 _Toc366594540 _Toc366594541 _Toc366594542 _Toc366594543 _Toc366594544 _Toc366594545 _Toc366594546 _Toc366594547 _Toc366594548 _Toc366594549 _Toc366594550 _Toc366594551 _Toc366594552 _Toc366594553e -,$$&@-08<?aA3DEHHJKMOLRBSEUVX?Z[f*l ry{g;mJp.! xwb*\AR   !"#$%&'()*+,-./0123456789:;<=>?@ CD<$$&O-0%8<?iA7DE HHJKMOURNSNUWXFZ[.fKl@r:y{|L7ψhA7ޙϢ~(Ir,Vc VSiemens-NixdorfC:\ERIC\ETHLOAD\ETHLOAD.DOC Eric VynckeC:\ERIC\ETHLOAD\ETHLOAD.DOC@TRIO DATAFAXWINSERVE:DATAFAXTRIO DATAFAXD& dTRIO DATAFAXD& d D`Times New Roman Symbol &Arial Tms Rmn5Courier NewRoman PS  V Βs- ^-e|q',m(,~#xEthload User's GuideEthload User's Guide&Documentation of the shareware ETHLOAD Eric Vyncke Eric Vynckeࡱ; v