Analyst/Probe
(c) 1995 Network Instruments, LLC
Minneapolis, MN  USA



TABLE OF CONTENTS

INTRODUCTION TO ANALYST					7
Functional Overview					8
The Analyst Station					9
The Probe PC						11
Netware Discoverer					12
Who Should use Analyst/Probe and Netware Discoverer	14
Limited Warranty					16
Copyright and License					17
System Requirements					18
Technical Support					19
INSTALLATION						21
Licensing						21
Quick overview for experts				22
Installing the Analyst files on your PC:		22
Installing the Probe files on a PC:			24
Configuring the DOS component of Probe:			25
Configuring the DOS component of Netware Discoverer:	25
Running the Probe, Analyst and Netware Discoverer:	26
Step by Step Installation for the Analyst Station:	26
Step 1: Copy the Analyst files onto the PC		28
Step 2: Decide if you will run Netware Discoverer	29
Step by Step Installation for the Probe PC:		29
Step 1: Configuring ODI					30
Step 2: Copy the Probe files onto the PC		32
USING ANALYST						35
Overview and quick start				35
The Main MDI window					37
Main MDI Window Button Bar				38
File Menu						39
Options Menu						40
Window Menu						41
Probe Window Controls					42
Filters							42
Modes							43
Notify							43
Filters							44
Saving a Filter						46
Adding and Editing Hardware Addresses			47
Setting Hardware Address Filters			48
Choosing a Protocol as a sub-filter			49
Discovery Mode						50
Network Statistics					52
Bandwidth Utilization Mode				52
General Statistics Information				55
Received Packets Statistics				56
Size Distribution Statistics				58
Protocol Statistics					60
Printing Statistics screens				61
Packet capture mode					61
Viewing Captured Packets				62
Printing captured packets				67
Saving Captured Packets to a File			68
Loading and Saving a Packet Buffer			69
Preferences Dialog					69
Probe Remote Settings					71
Probe Local Settings					73
Notify Probe						74
USING PROBE						77
Probe Settings						78
USING NETWARE DISCOVERER				81
Overview and quick start				81
The Main MDI Window					83
File Menu						85
Options Menu						86
The Preferences dialog					87
Discoverer Discovery Mode				91
Server exclusion List					92
Login to Server						93
The Window Menu						95
The MDI Window Button Bar				95
The List of Nodes View					97
Information Windows (general)				98
Server Information Windows				101
Charts							102
Number Connections (server)				102
Open Files (server)					102
IPX Packet Statistics (server)				102
SPX Packet Statistics (server)				103
Total Packet Statistics (server)			103
Bridge Statistics (server)				104
Volume Usage (server)					106
Options							107
Lists							107
IPX Packet Statistics List (server)			108
SPX Packet Statistics List (server)			110
Total Packet Statistics (server)			114
Bridge Statistics List (server)				116
Volume Information List (server)			118
Open Files List (server)				118
Info:							118
Server Version (server)					118
IPX-SPX Versions (server)				118
Bridge Driver Configuration (server)			119
Node Information Windows				120
Charts							121
IPX Packet Statistics chart (node)			121
SPX Packet Statistics chart (node)			121
Total Node Packets chart (node)				122
Options							122
Lists							123
IPX Packet Statistics List (node)			123
SPX Packet Statistics List (node)			125
Shell Driver Statistics List (node)			129
Shell Statistics List (node)				131
Info:							134
OS Version Information (node)				134
IPX-SPX Versions (node)					134
Shell Driver Configuration (node)			134
User Volume Information (node)				136
REFERENCE						137
A Short Overview of TCP/IP for troubleshooting		137
Monitoring TCP/IP Sessions with Analyst			140
Ethernet Frame Header					140
Token Ring Frame Header					141
IEEE 802.2 and IEEE 802.2_SNAP subheaders		143
Internet Addresses					143
Address Resolution Protocol (ARP)			144
Internet Protocol (IP)					146
Transport Control Protocol (TCP)			148
User Datagram Protocol (UDP)				152
Internet Control Message Protocol (ICMP)		154
Short Overview of Novells IPX and SPX protocols	156
Internetwork Packet Exchange (IPX) packet header	157
Sequential Packet Exchange (SPX) packet header		158
Netware Core Protocol (NCP).				161
Service Advertising Protocol (SAP).			165
Routing Information Protocol (RIP)			166
Serialization packets					167
WatchDog Packets					168
APPENDIX						169
Program Descriptions					169
Program Flags						171
ANALYST.EXE						171
PROBE.EXE						171
VPACKODI.EXE						172
Troubleshooting						175
Probe Troubleshooting					177
Discoverer Troubleshooting				181
Sample Configuration Files:				182
ODI:							182



INTRODUCTION TO ANALYST

As Local Area Networks (LANs) become part of our 
every day lives, the need to manage and troubleshoot 
these LANs becomes increasingly important.  Most 
network operating systems have some ability to 
diagnose problems but these abilities usually fall short 
as truly useful LAN analysis tools.

Analyst/Probe is a network protocol analyzer and LAN 
monitoring tool for multi-segment LANs and WANs. 
With Analyst/Probe you can:

*  monitor bandwidth utilization
*  collect statistics by user, packet size, or protocol
*  capture, view, and decode LAN traffic

More important, Analyst/Probe lets you to perform 
these functions from a single location for any LAN or 
WAN segment in your network.

With Analyst/Probe, you stay informed with real-time 
LAN traffic information and ongoing trend data.  This 
information helps you quickly pinpoint problems or 
anticipate potential problems before they lead to 
disaster - all from a single PC at one location using a 
convenient Windows interface.

By providing remote protocol analysis and complete 
network monitoring from a central location, 
Analyst/Probe lets you be in many places at one time, 
monitoring multiple LANs and even multiple sites. Youll 
view each LAN more clearly and see all network traffic 
in real time. Analyst/Probe allows you to base your 
network management decisions on facts, not 
guesswork.

Best of all, while the high cost of this type of high-level, 
proactive debugging tool traditionally has made it cost-
effective for only large organizations with extensive 
networks, Analyst/Probe is priced low enough to make 
it affordable for smaller LAN sites.

Analyst allows you to keep track of your network 
conditions, warns you about a network overload, and 
captures packets from a single computer (or multiple 
computers) on the network.  Analysts Netware 
Discoverer collects Novell specific statistics and 
displays or graphs them over time.
FUNCTIONAL OVERVIEW
Analyst/Probe contains three separate programs 
designed to complement each other:

Analyst/Probe functions around a "client/server" 
relationship between the Analyst Station which is 
installed on a PC running Microsoft Windows and a set 
of Probes installed on each segment being monitored.  
The Analyst Station functions as a server, collecting 
and decoding packets and/or real-time LAN traffic data 
from the Probe clients.

Any Windows PC on the network can host a Probe.  
The Probe runs in the background, collecting network 
information and sending it to the Analyst Station while 
the user continues to work as usual.  Probes 
communicate with the Analyst station using Microsoft 
Winsocks and the TCP/IP protocol.

An Analyst Station can monitor up to 252 Probes at one 
time.  Probes can be located on any network - local or 
remote, Ethernet or Token Ring - connected to the 
Analyst Station via IP.  Netware servers, IP routers, or 
WAN connections can serve as bridges between the 
Analyst Station and its Probes.

Netware Discoverer is a Netware specific statistical 
collection tool.  Discoverer continually polls both Novell 
servers and nodes to collect statistics and information.  
Because Discoverer polls each station, it is quite active 
on your LAN, and (using Analyst if you like) you will see 
that Discoverer generates its own small amount of LAN 
traffic.

The Analyst Station

All of the Probe information is provided in Analysts 
Multiple Document Interface (MDI) main window, where 
a system administrator can simultaneously monitor up 
to 252 Probes.  The MDI window can display multiple 
Probe windows showing the general condition of a 
segment and/or a packet capture of another segment.  
All Probe windows display similar information, or 
completely different information each MDI sub-window 
(known as a Probe information window).

Analyst/Probe has four main modes of operation.  Each 
mode gives you insight into different functions of your 
LAN in real time.  Most modes are affected by filters 
you set.

DISCOVERY mode allows you to capture all of the 
network addresses on a Probes LAN segment, store 
them in the Probes filter table, and alias them as 
names or IP addresses.

PACKET CAPTURE mode displays a graph that 
represents a Probes current packet capture state.  This 
graph shows you, in real time, how many and what kind 
of packets are being captured and whether packets are 
being dropped.  Once packets have been captured, 
they can be viewed using the Packet Captures view 
mode.

BANDWIDTH UTILIZATION has two modes:  Standard 
Bandwidth Utilization allows you to graphically monitor 
the amount of a Probe segments total network 
bandwidth that is currently being used - showing the 
data in a sliding 8-16 minute graph.  Long Term 
Bandwidth Utilization (LTBU) shows graphically high, 
low, and average utilization over an adjustable time 
frame (up to 7 days).  This data can also be exported to 
a comma-delimited spreadsheet format for further 
analysis and charting.

NETWORK STATISTICS mode includes Received Packet 
Statistics, Size Distribution Statistics, and Protocol 
Statistics.  These statistical modes let you see who is 
using a Probes segment, and who or what is 
generating traffic.  Each mode a sheds different light on 
the workings of your LAN.

In each of the four modes, there are many filters and 
sub-filters which can be used.  You can choose to trace 
all protocols on a Probes segment or choose to filter on 
a subset of protocols.  Packet capturing and filtering 
can help you localize problems.  Translation of packets 
into function and type gives a record and an explanation 
of the data exchange on a segment.  If you need to 
thoroughly study packet content byte by byte, raw mode 
allows the packets to be viewed without any translation.  
Once packets are captured, you can filter and print 
captured packets to a printer or to a file.


The Probe PC

The Probe software runs on a standard Windows PC 
and requires no additional hardware.  The Probe must 
be installed on at least one PC for each segment you 
want to monitor.  Multiple probes can be installed on a 
single segment thus providing redundant sources of 
information for Analyst.  Having multiple probes on a 
segment helps ensure that back-up information sources 
remain available when one or more Probe PCs are shut 
down or malfunctioning.  Each Probe automatically 
registers with Analyst when Windows runs and Analyst 
tracks the status of all available Probes.


Netware Discoverer
 
Netware Discoverer provides detailed information and 
statistics collected from Novell servers, stations, 
bridges, and routers.  Discoverer also provides a 
Discovery Mode search similar to Analyst's Discovery 
Mode.  Discoverers Discovery Mode supplements 
Analyst's Discovery Mode auto aliasing of IP address to 
the hard network address.  In Netware Discoverer's 
Discovery Mode, you can auto alias a users Novell 
login name to the hard network address.

Netware Discoverer supplies information about all of the 
Novell servers reachable on the network (both LAN and 
WAN).

For servers, some examples of this kind information is: 
the number of users logged in on a server, the nodes 
that are currently down, free/used disk space on all 
volumes, number of open files - the total number and 
the number used by each user, and much more.  For 
users, information about number of files, directories and 
disk space used is provided.

Statistical information from the Server's bridge drivers 
provides detail about the general condition of the 
network and routing activity between networks.  IPX 
and SPX statistics provide information about a 
particular node or server, number of packets sent and 
received, number of good and bad packets, and ECB 
availability and failures.

Lists provides miscellaneous version information about 
servers, stations, and users which may be useful for a 
network administrator during daily operation.  This may 
be particularly helpful for keeping a network up to date. 

Important information that changes over time can be 
monitored as it develops in a graphical format (charts).  
These charts include IPX and SPX traffic statistics, 
number of users attached to a server, volume usage, 
and bridge statistics.  All of these graphs are auto 
scrolling, showing your particular information graphically 
as it develops over time.

Finally, all of this information is provided in a MDI 
(Multiple Document Interface) where a system 
administrator can simultaneously monitor the general 
condition of a network server and a number of servers 
or users in particular - displaying similar information, or 
completely different information, all at the same time in 
each MDI sub-window (known as an information 
window).

Information windows come in two classes: 1) NODE 
information windows which display station (node) 
information and charts, and 2) SERVER information 
windows which display information that the server 
provides.

For example, the initial list on the left of the Discoverer 
main MDI window (List of Nodes) shows a list of 
servers.  Each Netware server can be double clicked 
(using the LEFT mouse button) to display a list of users 
currently connected to that server (print and other 
servers may or may not have users associated with 
them).  Clicking on the RIGHT mouse button on a 
server or node icon opens the SERVER or NODE 
information window (on the right of the MDI window).

On the right part of the MDI window, there can be a 
graphic chart showing network traffic on a server, 
and/or volume information of another server, and/or 
number of NODE windows showing statistics and charts 
for different users attached to different servers.  In 
essence, like Windows within Windows, where 
SERVER or NODE information windows can be re-
sized, placed in different order, tiled, cascaded, 
minimized, etc.  With all of this power, an administrator 
can run Discoverer and notice very little interruption of 
the other functions of the Windows PC - Discoverer 
uses very few resources to function.


WHO SHOULD USE ANALYST/PROBE AND NETWARE 
DISCOVERER

Any LAN administrator, Systems Consultant or Network 
Programmer will find Analyst/Probe and Netware 
Discoverer helpful.  Analyst/Probes utilities are 
designed to meet the needs of the most technical 
network professional, as well as to provide useful 
information for an average LAN administrator.

Analyst will be most useful for a network LAN 
administrator who knows his or her LAN workings from 
a functional view, but wants to see what is really going 
on "on a wire" for troubleshooting an existing problem 
or pre-solving a network condition that could spell 
disaster in the future.

Analyst/Probe, unlike other network analyzers "sees" all 
traffic on a Probes LAN segment - and on all segments 
that host a Probe.  To see and analyze traffic on a 
different segment, you do not need to load and run 
Analyst from a PC on that segment - you will only need 
to install a Probe on one of the Windows PCs on that 
segment.

Discoverer will be most useful for a Novell Netware 
administrator who manages Netware LANs that are 
either physically far apart or have elusive non-
reproducible problems that happen over the course of 
time and need to be isolated.  Note:  Netware 
Discoverer is only useful if you have a Novell LAN.  If 
you do not have a Novell LAN, do not choose to install 
Netware Discoverer during the installation process.

To set up and use Analyst, Probes, and Netware 
Discoverer, you will need to be familiar with both DOS 
and Windows, including editing files, changing  
configurations, and a basic knowledge of your LAN 
setup.

The Analyst software consists of only Windows 
programs.  The Probe software consists of both DOS 
and Windows programs.  The Probe software must be 
installed on at least one PC on each network segment 
to analyze network traffic for that segment.  For an 
Analyst or Probe installation, a network card is required 
for both the Analyst Station and the Probe PC.  
Additionally a Winsock 1.1 TCP/IP is required at both 
the Analyst Station and the Probe PC.  No additional 
hardware is required on the Analyst Station or Probe 
PC.

Netware Discoverer requires LSL.COM, IPXODI.COM 
and the VLMs (VLM.EXE and any other components 
your VLM is configured to use) to be installed and 
running.  Additionally, you will need to have Novell's 
Windows Network support drivers and DLLs properly 
(and completely) installed on your PC 
(NETWARE.DRV, NWCALLS.DLL and 
NWIPXSPX.DLL and all of the DLLs, DRVs and VxDs 
and *.386s that they call need to be present in your 
Windows SYSTEM subdirectory).  If you are using 
Microsoft Windows for Workgroups (WFW), you will 
need to make certain that you are using WFW over 
ODI, and that you have set up Windows Networking to 
recognize the Netware Shells.

The Netware Windows drivers and DLL's are 
proprietary programs of Novell Inc., and are either 
included with your Novell system or you can download 
the latest versions of the Drivers and DLL's from 
Internet (ftp.novell.com), or from CompuServe.  
Otherwise you can ask your Novell dealer for the latest 
VLMUPx, WINDRx and NWDLLx (where "x" is the 
version number).
LIMITED WARRANTY
Network Instruments, LLC will replace defective media 
or documentation for 60 days after the shipment of the 
product from Network Instruments, LLC.  Should 
Network Instruments, LLC release a new version of 
Analyst within 60 days of shipment of the product, 
Network Instruments, LLC will update the copy of 
Analyst/Probe at no charge.  This update may consist 
of disks or a manual or both, at the discretion of 
Network Instruments, LLC.

The Analyst/Probe license does not guarantee the 
usability of Analyst or Probe, expressed or implied.  In 
cases of loss, destruction, or corruption of data, 
Network Instruments, LLC shall not be liable.

Network Instruments, LLC makes no other warranty.
COPYRIGHT AND LICENSE
Analyst/Probe (including Netware Discoverer) is neither 
shareware nor freeware.  Analyst is a commercial 
software package that is subject to international 
copyright laws.

Upon registration of Analyst/Probe, you are licensed to 
use one Analyst and one Probe on your LAN.  
Additional segments can be monitored by purchasing 
additional Probes.  When additional Probes are 
purchased, you will then be licensed to run one Analyst 
Station and as many Probes as you have licenses.

Multiple Analyst Station licenses are available at a 
reduced license fee.  Contact Network Instruments for 
more information.

Analyst, Probe and Netware Discoverer are the 
property of Network Instruments, LLC and may not be 
copied for purposes other than backup.

Depending on how you purchase Analyst/Probe, you 
will either have a RTU (Right To Use) license or, upon 
registration of the DEMO, you will receive a RTU.  In 
either case, the RTU is your proof of purchase.  You will 
need to produce this document for upgrades and you 
will need to provide the RTU activation numbers to 
receive technical support.

This software is licensed as stated above.  The license 
does not constitute ownership of the software, only the 
right to use it.


SYSTEM REQUIREMENTS

Analyst Station Hardware Requirements:
Minimum: 486DX/33 w/8MB RAM, Windows 3.11, a 
Winsock 1.1 compatible TCP/IP and a supported 
network adapter.
Recommended: Pentium P-66 (or better) w/16MB of 
RAM, Windows 3.11, MS-32 TCP/IP, 16-bit network 
adapter, 1024x768 Super VGA and a 17" VGA color 
monitor.

Probe Station Hardware Requirements:
486SX/33 w/ 8MB RAM, Windows 3.11, a Winsock 1.1 
compatible TCP/IP running over ODI, and a supported 
network adapter.

Network Compatibility: Novell, UNIX, Windows for 
Workgroups, Banyan, LANtastic, LAN Manager (SCO & 
MS), many others.

Topologies: Ethernet (Thick, Thin, 10BASET) and 
Token Ring (4/16Mb)

Network Interface Cards Supported:
Analyst Station: Any network adapter card with an ODI 
(Novell) or NDIS (Microsoft Windows for Workgroups) 
driver that supports your Winsock 1.1 TCP/IP (Note: A 
Netware license is required for use with ODI).

Probe PC: Any network adapter card with an ODI driver 
that supports promiscuous mode.

Note: The Probe PC requires ODI.  Analyst Stations 
can use either ODI, NDIS or a Packet Driver.

Analyst/Probe may run on systems with less power and 
RAM than those listed above, but Network Instruments 
does not support configurations with less than the 
minimum stated requirements.


TECHNICAL SUPPORT

Network Instruments provides technical support from 
9:00 AM to 5:00 PM Central Standard Time.  Technical 
support is provided on the phone at (612) 822-2025, by 
fax at (612) 825-5647, or by email at 
support@netinst.com.

Before calling technical support, please read the 
troubleshooting section at the end of this manual and 
the README.WRI on your distribution disk to see if 
your issue has not already been addressed.

Suggestions are welcomed - submit detailed 
suggestions in writing to support@netinst.com or by 
FAX at (612) 825-5647.


INSTALLATION

LICENSING

Analyst/Probe is always sold in a DEMO version.  The 
DEMO version can be licensed to become a fully 
functioning product for as many Probes (i.e. segments) 
your site requires.

Analyst/Probe will run in DEMO mode until it is licensed.  
The DEMO mode will simulate LAN traffic for each 
Probe and does not require a LAN or LAN hardware to 
be present.  If you choose to install Analysts Netware 
Discoverer, it will run in DEMO mode "unlicensed" for 5 
minutes and then it will disable itself (Note: Netware 
Discoverer DOES require a network adapter and ODI to 
be loaded even in DEMO mode).

The DEMO mode is provided so that a potential 
Analyst/Probe user can get a feel for the package 
without having to purchase it.  You can turn a DEMO 
version of Analyst into a licensed version with a license 
number as described below.

This license number is unique and can only be used for 
one copy of Analyst and will only work for one site.  The 
license number will enable the Analyst Station for use 
for a specific number of Probes.  You do not need to 
license the Probe PCs. 

To turn the DEMO version of Analyst into a fully 
functioning licensed version, you will need to fill 
out the license dialog with your name and your 
company name to generate your unique customer 
identification number.  To bring up the license 
dialog, choose "File"  "License" from the main 
Analyst (or Discoverer) screen.

Once the licensing information has been filled out, you 
will need to fax your company identification number and 
the number of Probes you would like to license the 
Analyst Station for (and payment - depending on how 
you purchased Analyst) to Network Instruments to 
receive your license number.  The license number will 
turn your DEMO copy of Analyst into a fully functioning 
copy of Analyst.  Network Instruments FAX number is 
(612) 825-5647.

Depending on where and how you purchased 
Analyst/Probe, you may have a "Right to Use" (RTU) 
certificate.  If you have purchased such a certificate, 
follow the instructions on the Right to Use document to 
license Analyst/Probe.  If a Right to Use certificate 
came with your copy of Analyst, follow the instructions 
on that Right to Use document to license Analyst.

Once you have licensed Analyst, Analyst and Analysts 
Netware Discoverer will automatically be licensed.


QUICK OVERVIEW FOR EXPERTS

Installing the Analyst files on your PC:
Note: If you are running Analyst in licensed (not DEMO) 
mode, the Analyst software expects that you have a 
Winsock 1.1 compatible TCP/IP installed and 
functioning on your PC.

Run Analyst/Probes installation program from Windows 
by putting the Analyst disk in your floppy drive and 
running the program A:\INSTALL.EXE from the 
Windows "File"  "Run" menu.

Install will ask you into which directory you would like 
Analyst installed.  Unless you have a compelling reason 
to install Analyst elsewhere, we suggest that you install 
Analyst in the default destination.  Make sure that you 
have selected the "Analyst" as opposed to the "Probe" 
on the initial Installation screen.

INSTALL lets you choose between DEMO mode (check 
the DEMO box) or licensed mode (un-check the DEMO 
box).  As mentioned, DEMO mode will simulate network 
traffic so that you can see Analyst functioning as if it 
were on a real LAN.

When installing in DEMO mode, you will not be given 
the chance to install Netware Discoverer (see note 
below for more information on DEMOing Netware 
Discoverer).

To install in licensed mode, uncheck the DEMO mode 
box in the initial installation screen.  Once the product is 
licensed and a license number is provided, Analyst will 
capture data from how ever many Probes you have 
licensed Analyst for, and will function without any of the 
DEMO limitations. To run Analyst in non-DEMO mode, 
you will need to have a Winsock 1.1 compatible TCP/IP 
installed and functioning on your Analyst Station.

Note:  If you do not have a Novell LAN, do not 
install Netware Discoverer.  If you are not using 
ODI, you cannot use Netware Discoverer.  See note 
below.

Make sure to check the README.WRI for any late-
breaking installation information.

NOTE:  Because Netware Discoverer requires ODI, 
including LSL, IPXODI, VLM support and ALL of the 
Netware Windows DRVs, DLLs, 386s and VxDs, it is 
not automatically installed during DEMO installation.  If 
you would like to DEMO Netware Discoverer, and are 
confident that you have your Windows PC properly 
configured as described above, uncheck the DEMO box 
and install Analyst in licensed mode including Netware 
Discoverer.  Both Analyst and Netware Discoverer will 
run in DEMO mode if not licensed.  For Analyst this 
means it will play simulated data.  For Netware 
Discoverer this means that it will only function for 5 
minutes, but it will see real data from your LAN.
Installing the Probe files on a PC:
Any Windows PC that is running a Winsock 1.1 
compatible TCP/IP over ODI can host a Probe.

Note: When running Analyst/Probe in DEMO mode you 
will not need to install any Probes.  The DEMO Analyst 
Station will virtualize Probes and data for viewing.

To install the Probe software, run Analyst/Probes 
installation program from Windows by putting the 
Analyst/Probe disk in your floppy drive and running the 
program A:\INSTALL.EXE from the Windows "File"  
"Run" menu.

Install will ask you into which directory you want the 
Probe software installed.  Unless you have a compelling 
reason to install Probe elsewhere, we suggest that you 
install the Probe in the default destination.  Make sure 
that you have selected the "Probe" as opposed to 
"Analyst" choice on the initial Installation screen.

Probes installation program will offer to make the 
required changes in your AUTOEXEC.BAT (and other 
required files).

Probes installation program will ask the IP address of 
the Analyst Station.

Make sure to check the README.WRI for any late-
breaking installation information.
Configuring the DOS component of Probe:
The Probes Windows programs require a DOS TSR 
that interfaces with your network driver and makes 
packets available to the various Windows DLLs and 
programs.  This TSR will take less than 5K of RAM 
when Probe is inactive.

INSTALL will automatically install VPACKODI.EXE in 
your AUTOEXEC.BAT. This installation will expect that 
your ODI network interface is up and running and 
configured correctly for a protocol analyzer to function.  
If you run into trouble, see the step-by-step installation 
for your particular network setup for help.
Configuring the DOS component of Netware Discoverer:
If you choose to install Netware Discoverer, it requires 
ODI and the VLMs to be installed and running.  
Additionally, you will need to have Novell's Windows 
Network support DRVs, VxDs, 386s, and DLLs 
properly (and completely) installed on your PC.  For 
more information on exactly what is required see the 
"Decide if you will run Netware Discoverer" section 
under Step 2.  Note: If you are using Microsoft 
Windows for Workgroups (WFW), you will need to 
make certain you are using WFW over ODI.

If installing in licensed mode, Install will then ask to 
reboot your PC.

Running the Probe, Analyst and Netware Discoverer:

Once you have rebooted your Probe PC and 
VPACKODI.EXE has been loaded, you can start the 
Probe by double-clicking on the Probe icon in the 
Analyst group.

On the Analyst Station, you can run Analyst by double-
clicking on the Analyst icon.

Start Netware Discoverer by double-clicking on the 
Netware Discoverer icon.

If a Probe fails to load with an error indicating that you 
do not have enough DOS memory to allocate 
VPACKODIs buffer space, see the section on Program 
Flags in this manuals Appendix or the troubleshooting 
section in the Appendix.  Both sections describe the 
method for locking VPACKODIs buffer space prior to 
going into Windows before other applications can steal 
it away.


STEP BY STEP INSTALLATION FOR THE ANALYST STATION: 

The installation of the Analyst Station will involve the 
following 2 steps:

1. Run INSTALL to install the Analyst Station software. 

2. Decide if you will install Netware Discoverer.

This installation procedure expects that you have your 
network adapter installed and configured properly.  In 
addition, this installation procedure expects that you 
have a Winsock 1.1 TCP/IP protocol stack functioning 
on  the Analyst Station.  If you are able to connect to 
your network and run your network software, you 
probably have the network adapter installed and 
configured properly.  If you are able to communicate to 
a UNIX host (if you have one), your TCP/IP is probably 
configured correctly.

Note: If you plan on using Netware Discoverer, you 
must use ODI at your Analyst Station.  If you are not 
going to use Netware Discoverer, the Analyst 
Station can function over whatever interface your 
Winsock TCP/IP will run over (i.e. ODI, NDIS or 
Packet Driver).

If you are using Netware Discoverer

For Discoverer to work properly it requires: LSL.COM, 
IPXODI.COM and VLM.EXE to be installed and running 
(this includes any *.VLMs that VLM.EXE may require).  
Additionally, you will need to have Novell's Windows 
Network support drivers (*.DRVs,  DLLs, VxDs and 
386s) properly (and completely) installed on your PC 
(NETWARE.DRV, NWCALLS.DLL and 
NWIPXSPX.DLL and all of the drivers that these files 
call need to be present in your Windows SYSTEM 
subdirectory).  You must also configure Windows to 
recognize the Netware shells.  This is done in Setup for 
Windows 3.1 and in the Network dialog in WFW (3.11).

The Netware Windows drivers and DLL's are 
proprietary programs of Novell Inc., and are either 
included with your Novell system or you can download 
the latest versions of the Drivers and DLL's from 
Internet (ftp.novell.com) or from CompuServe.  
Otherwise ask your Novell dealer for the latest 
VLMUPx, WINDRx and NWDLLx (where "x" is the 
version number).

Step 1: Copy the Analyst files onto the PC
Run Windows and click on "File""Run".  In the "Run" 
dialog box, fill in the path to the executable 
A:\INSTALL.EXE.
 
You can now choose to install Analyst in DEMO mode 
or in licensed mode.  To install in DEMO mode, check 
the DEMO box at the bottom of the install dialog.  To 
install in licensed mode, uncheck the DEMO box.

The install dialog box will then ask if you want Analyst 
installed in the C:\ANALYST directory.  Unless you 
have a compelling reason to install Analyst elsewhere, 
we suggest that you install Analyst in this default 
destination.

If you chose to install in DEMO mode, you will not be 
asked to install Netware Discoverer.  You can now go to 
the "Using Analyst" section of this manual.

If you are installing in licensed mode, you will be asked 
if you are sure you want to install in licensed mode.  If 
so, answer YES.

Step 2: Decide if you will run Netware Discoverer
If you installed in licensed mode, Install will then query 
you if you would like to install Netware Discoverer.  If 
you do not have a Novell LAN do not install Netware 
Discoverer (uncheck the box at the bottom of the 
dialog).

If you do have a Novell LAN, read the dialog carefully, 
and decide if you want to install Discoverer or not.  If 
so, leave the "Install Netware Discoverer" checkbox 
checked.

If you are installing in licensed mode you can now move 
on to installing the Probe software.

If you are running Analyst in DEMO mode, you can now 
go to the Using Analyst section.


STEP BY STEP INSTALLATION FOR THE PROBE PC:

Note: If you are installing Analyst in DEMO mode, you 
will not need to go through this procedure  - you can go 
directly to the Using Analyst section.

The installation of Probe will involve the following three 
steps:

1. Configure ODI on your Probe PC.

2. Run INSTALL at the Probe PC to install the Probe 
software from Windows.

3. Reboot your PC.

This installation procedure expects that you have your 
network adapter installed and configured properly.  In 
addition, this installation procedure expects that you 
have a correctly configured Winsock 1.1 TCP/IP 
protocol stack functioning over ODI on the Probe PC.  If 
you are able to connect to your network and run your 
network software over ODI, you probably have the 
network adapter installed and configured properly.  If 
you are able to communicate to a UNIX host (if you 
have one), your TCP/IP is probably configured 
correctly.

Since you will be using the ODI to interface for each 
Probe PC, you may need to modify your NET.CFG ODI 
configuration file on the Probe PC.

Step 1: Configuring ODI

This procedure assumes that you have a Novell LAN 
and a pre-existing ODI setup.  This procedure 
describes what VPACKODI.EXE (Probes ODI 
interface) needs to have configured in your NET.CFG 
file.  Note: If you do not have a NET.CFG file, you will 
need to create one.  This file is the configuration file for 
LSL.COM and is usually in the same directory as 
LSL.COM.

If you are not sure whether you have an existing ODI 
configuration or not, check your AUTOEXEC.BAT or 
your STARTNET.BAT file for the following files:

LSL.COM
IPXODI.COM
NETX.EXE (or VLM.EXE)

If these files are being loaded on your system, you are 
using ODI. 

ODI uses the configuration file NET.CFG to give its 
programs and drivers information about the network 
protocol settings and network card driver settings.  You 
may need to add to your NET.CFG FRAME 
designations for each of the frame types that you will 
want to capture and examine.  Your NET.CFG may 
have one, some, or all of these types already.  For 
Ethernet add the ones that are not in your NET.CFG 
but are listed below (for Token Ring, check the 
Appendix under "Sample Files").

A sample NET.CFG file for a NE2000 network adapter 
might look like this (yours may be different):


LINK DRIVER NE2000
	INT 5
	PORT 300
	FRAME 	ETHERNET_802.3
	FRAME ETHERNET_II
	FRAME ETHERNET_802.2
	FRAME ETHERNET_SNAP

LINK SUPPORT
	BUFFERS 15 4028
	MEMPOOL 4096


Probes VPACKODI.EXE (this will automatically be 
installed in step 2) will capture and make available to 
the Probe software all protocols for each FRAME line in 
your NET.CFG.  VPACKODI.EXE will not see any 
FRAME types that are missing from your NET.CFG.  
We recommend adding all frame types unless you 
specifically know that you will not be using a particular 
one.  Note: If you are planning to monitor TCP/IP, you 
must have the ETHERNET_II frame type listed in your 
NET.CFG.  [See the Appendix for a sample NET.CFG 
for Token Ring.)

Step 2: Copy the Probe files onto the PC
Run Windows and click on "File"->"Run".  In the "Run" 
dialog box, fill in the path to the executable 
A:\INSTALL.EXE.

The install dialog box will then ask if you want Probe 
installed in the C:\ANALYST directory.  Unless you 
have a compelling reason to install the Probe software 
elsewhere, we suggest that you install Probe in this 
default destination.

INSTALL will then ask you to provide the IP address of 
the Analyst Station.

Probes installation program will now offer to make the 
necessary changes in your AUTOEXEC.BAT file.

If you tell INSTALL not to modify your AUTOEXEC.BAT 
file, you will need to run VPACKODI.EXE or add it to 
your AUTOEXEC.BAT for the Probe to function. 
Sample files are given in the Appendix of this manual.  
If your PC uses DOS 6.xs multiple boot setup, Probes 
installation program will create a file called 
AUTOEXEC.INS in your Analyst directory with the 
required load lines to run the Probe.  You should copy 
these load lines into the appropriate section of your 
AUTOEXEC.BAT.

Once the Probe files have been installed on your PC, 
INSTALL will ask to reboot your system.  Once you 
reboot your system, you will be able to start Windows 
and run the Probe by double-clicking on the Probe icon 
in the Analyst group.  You may want to run Probe each 
time Windows starts.  You can do this by placing a copy 
of the Probe icon in the stations Windows Startup 
group.

If the Probe fails to load with an error indicating 
that you do not have enough DOS memory to 
allocate or VPACKODIs buffer space, see the 
section on Program Flags in the Appendix of this 
manual or the troubleshooting section in the 
Appendix.


USING ANALYST

OVERVIEW AND QUICK START

Analyst/Probe functions around a "client/server" 
relationship between the Analyst station - installed on a 
PC running Microsoft Windows - and a set of Probes 
installed on each segment being monitored. The 
Analyst station functions as a server, collecting and 
decoding packets and/or real-time LAN traffic data from 
the Probe clients.

Any Windows PC on the network can host a Probe. The 
Probe runs in the background, collecting network 
information and sending it to the Analyst while the user 
continues to work as usual. Probes communicate with 
the Analyst station using Microsoft Winsocks and the 
TCP/IP protocol.

The Analyst station can monitor up to 252 Probes at 
one time. Probes can be located on any network - local 
or remote, Ethernet or Token Ring - connected to the 
Analyst station via IP. Netware servers, IP routers, or 
WAN connections can serve as bridges between the 
Analyst station and its Probes.

Analyst has five main modes of operation for each 
Probe:

1. Discovery mode allows you to capture all of the 
network addresses on each Probe's segment, store 
the addresses in the Probes Filter table, and alias 
them as names or IP addresses.

2. Packet Capture mode allows you to capture 
packets from a particular Probe' s segment.  Once 
packets have been captured, you can view the 
capture buffer contents or filter and print the results.  
The packets captured will depend on the filters you 
set in the "Filters" dialog.

3. Bandwidth Utilization mode allows you to view a 
real-time graph of a Probe segments network 
traffic, graphed against the network theoretical 
maximum bandwidth.

4. Long Term Bandwidth Utilization mode allows 
you to view a Probes segments bandwidth 
utilization over an extended period of time.  This 
graph shows high, low, and average utilization 
points for a configurable time periods.  You can 
view this graph or export the data to a comma 
delimited file.  This file can then be further 
processed for use in charts or reports using a 
spreadsheet program - Microsoft Excel, for 
example.

5. Network Statistics mode displays the network 
utilization based on a segments network station or 
network protocol, or shows packet size distribution 
based on station address.

Packet Capture mode and Network Statistics mode 
allow filtering by address or protocol or both.  You can 
set filters from the "Filters" dialog from any Probes 
screen.  Bandwidth Utilization mode does not use any 
filters - it reads and records all packets on a Probes 
segment regardless of type or address.  [Note: 
Bandwidth Utilization will only see registered FRAME 
types as described in the Probes NET.CFG file.]

To monitor the network utilization you must set the 
maximum theoretical network bandwidth of the Probes 
segment in the "Modes" then "Probe Remote Settings" 
dialog box (the default is 10MB/s - the speed of an 
Ethernet network).

Note:  Windows provides a multitasking environment for 
applications - sort of.  Windows 3.x multitasking is non-
preemptive single threaded multitasking.  This means 
that you can run other applications while Probe is 
running, but if you are doing a packet capture (this is 
not a problem in the statistical modes) depending on 
the speed of the PC, the amount of filtering you are 
doing, and the load that the other applications put on 
the PC, Windows may not give the Probe the processor 
time it requires and thus the Probe PC may drop 
packets.  This is most likely to be a problem on a slow 
PC or in a heavily trafficked LAN with a very large 
capture taking place.  If you believe that you are not 
seeing all of the packets that you should, or if the Probe 
is reporting dropped packets, try running the Probe PC 
without any other Windows applications active.


THE MAIN MDI WINDOW

Analyst's initial main screen (the MDI window) consists 
of a menu bar, button bar, List of Probes listbox (on the 
left), and Probe information window area (on the right) 
divided by a vertical splitbar.

The List of Probes is a graphical representation of the 
Probes on your LAN.   Analyst fills the List of Probes 
with icons of Probes.  Initially every Probe icon appears 
as black (or "dead"), and light up when Probes on the 
LAN/WAN register with Analyst.

Main MDI Window Button Bar

The Main MDI Window button bar is provided for quick 
access to some of the most often used functions of 
Analyst.

Short help information describing the purpose of each 
button can be seen by pressing (and holding down) the 
RIGHT mouse button on the button in question.

Here is the list of the buttons and their functions in 
order from left to right:

List of Probes Display Options - this allows you to 
configure the display of the Probe text in the List of 
Probes.  Analyst can display the Probe name only, the 
Probe address, or the Probe name + address.

Save List of Probes - this saves the current list of 
Probes.  Should your network configuration change, 
this can be a convenient way to display all Probes that 
SHOULD be active.  Analyst always loads a list of 
saved Probes on startup.

Delete entry - this deletes a highlighted entry in the List 
of Probes.

Tile Probe Windows Horizontally, Tile Probe 
Windows Vertically and Cascade Probe Windows 
can be used to arrange Probe information Windows in 
the view area.

Exit - closes Analyst.
File Menu
File menu includes the following items:

License - this is where Analyst is licensed. For more 
information, see the Licensing section of this manual 
(page 21)

About Analyst - this displays the Analyst copyright and 
Analyst version information

Print Setup - this allows you to choose a default printer 
for printing Analyst reports

Exit - this terminates Analyst.

There are a few more options involving printing or 
saving/loading from a file.  These options may be 
grayed depending on the state of Analyst.  They are:

Print Protocol Statistics Dialog (page 61)
Save Long Term Bandwidth Utilization (page 55)
Load a Saved Packet Buffer (page 69)

Each is described in detail later in this manual.

Options Menu

The Options menu consists of three entries:

Save Current List of Probes, Delete Probe Entry, and 
Configure List of Probes Display.

The Preferences dialog allows a user to set general 
operational parameters for Analyst, and is described in 
more detail in the "Preferences Dialog" section (page 
69) of this manual.

Save Current List of Probes - this option saves the list 
of "discovered Probes".  You might want to do this to 
collect a list of Probes that are active at any one point in 
time.  Later, this list may be useful to display all Probes 
on the LAN/WAN - regardless of whether they are 
active or not.  Probes that are not active will be 
displayed with "dark" screens.

Delete Probe Entry - this will delete a highlighted 
Probe from the "List of Probes".

Arrange Probe Names - this allows you to choose how 
you would like to display your Probes.  The choices are:

Probe Address - displays the Probes IP address

Probe Name - displays the Probes name (you can 
modify this with a RIGHT mouse click on the Probe)

Probe Name + Address - both of the above.

Window Menu

The Window Menu contains the following items:

Tile Horizontal - this tiles Probe windows in a 
horizontal direction

Tile Vertical - this tiles all Probe windows in a vertical 
direction

Cascade - this arranges Probe windows in a standard 
Windows cascade

Arrange Icons - if there are minimized Probe windows, 
this option lets you neatly arrange them

Close All - closes all Probe windows

In addition, when there are one or more Probe windows 
active, a list of the active Probe windows is appended to 
this menu.  You can select one of these menu items 
referring to a Probe window - this will make it the active 
window.


PROBE WINDOW CONTROLS

A Probe information window is displayed in the 
information area after a user double clicks on the LEFT 
mouse button on an active Probe icon in the List of 
Probes.

A Probe information window consists of a button bar 
with Filters, Modes, Notify popdown menu buttons, and 
an Exit button.  Button bar buttons can be selected 
using mouse clicks and, in most cases, pressing the 
letter on the keyboard that corresponds to one 
displayed in red on the button.

Note: Due to the nature of the MDI interface, you DO 
NOT use ALT when accessing the Probe information 
window buttons.  You do, however, use ALT-KEY 
combination to popdown menus on the Main MDI  
window.

Filters

The Filters menu consists of two choices:

Current Filter - this is where you set or modify the 
current filter.

Select Filter - this dialog allows you to select a saved 
filter, or allows you to save and name the current filter.

Modes

The Modes menu allows you to change the Probes 
settings and switch the Probes mode of operation.

Some of each Probes information is stored locally in 
the Analyst's configuration files (Probe Local Settings), 
and other information is stored remotely on the Probe 
PC (Probe Remote Settings).

Analyst/Probe modes are summarized in the following 
list:

Packet Capture
Bandwidth Utilization
Long Term Bandwidth Utilization
Received Packets Statistics
Size Distribution Statistics
Protocol Statistics
Discovery Mode

more information is available for each in their respective 
sections of this manual

Notify

Sometimes it is necessary for the Analyst operator to 
communicate to a Probe PC to ensure that the Probe 
PC is not under a heavy use (copying big files or 
transferring print jobs) for some period of time.  The 
Analyst operators might want to do this if they need to 
do a Packet Capture on the Probes segment and do 
not want to lose any packets due to the Probe's PCs 
high CPU load.

To notify the Probe PC, the Analyst operator can then 
click on the Probe's Notify button and a chat dialog will 
appear both on the Analyst Station and Probe PC.  The 
administrator can then notify the Probe PC user when 
he/she will be starting the capture and when the 
capture is complete.

For more detail see: Notify Probe Dialog (page 74)


FILTERS

Before you use Analyst/Probe you will need to 
familiarize yourself with the Filters dialog box (Figure 7).  
The setting and use of filters is central to the 
functioning of Analyst/Probe.  If you do not set a filter 
for a particular Probe, the Probe will capture all packets 
and all protocols on the Probes segment.  In other 
words, setting no filter is just like setting an 
ANY_ADDRESS to/from ANY_ADDRESS address filter 
with an "All Protocols" sub-filter.  

Since LAN traffic can generate a tremendous amount of 
data, we suggest that you filter out as much as possible 
to make the interpretation of the captured data easier.

Filtering allows you to choose an address or set of 
addresses (an "address filter") and a protocol or set of 
protocols ("a protocol sub-filter") to filter the capture, 
and to display packets.  These filters and sub-filters will 
sort packets and capture only those that you wish to 
capture.

The "Filters" -> "Current Filter" dialog on every Probe 
window allows you to select one to five specific 
computers (or hosts) by address for monitoring network 
traffic or statistics.  See "Saving a Filter" later in this 
section.

You can select "ANY_ADDRESS" and one computers 
address to get information from that computer to any 
address or from any address to that computer.

You can also select "ANY_ADDRESS" to and from () 
"ANY_ADDRESS" to activate a "filter" that sees all 
addresses and thus all LAN activity on the Probes 
segment. (Within the parameters of your protocol sub-
filter and your ODI FRAME specifications.)

Filtering can be done by address or protocol or both.  
You can select a specific protocol that you want to 
monitor or choose to monitor all protocols present on 
your network.  Analyst currently supports specific 
translation of the IP, IPX/SPX and NetBIOS/NetBEUI 
suite of protocols.  Other protocols are viewed in raw 
mode.

After you make changes in the Filters dialog box, you 
can either click on the "O.K." button to save and enable 
the changes or "Cancel" to discard all changes and 
preserve previous filter settings.

Filters are stored in the file ANALYST.FLT in Analysts 
installation directory.  This file is a text file and can be 
edited with any text editor.

Saving a Filter

Once you have set a filter for a Probe, it can be saved 
as a named filter that can then be selected at a later 
time using the "Filters" -> "Select Filter" dialog (Figure 
8) from that Probes window.  You can save and name 
up to 5 different filters to be recalled at a later time.

Filter names can be edited by clicking in the name 
section of the dialog.

Changes are kept in a text file in your Analyst 
installation directory called ANALYST.FLT.
Adding and Editing Hardware Addresses
The hardware address listbox (refer to Figure 7) shows 
the addresses (and aliases) you may want to monitor.  
You can create as many entries as you require (up to 
1024), however you can only filter up to 5 addresses at 
a time.  See the section on Discovery mode for more 
information about adding network addresses

The format of an address entry is either the six 
numbers of the Ethernet address separated by colons 
or dots, or the Token Ring address.  This may be 
followed by a space and then an alias up to 17 letters 
long.  An "alias" is a name that Analyst will substitute for 
an address when showing the headers of incoming 
packets (if you tell Analyst to use aliases).  This can 
make packets easier to recognize and analyze.

For example:

	00:02:8A:49:B2:48    David Jones

To manually add a hardware address, click on the edit 
line at the top of the Filter dialog box and enter the 
hardware address and press <ENTER> or click on the 
down arrow at the end of the edit line.  The entry will be 
added to the list.  To edit an existing entry, select that 
entry using your mouse and click on the "Edit" button to 
the right from the hardware addresses list or simply 
double-click on the line you want to edit.  The address 
will appear in the edit line and you can make all 
necessary changes and save it as described above.  
You cannot edit or change the "ANY_ADDRESS" entry.

To remove an address entry, highlight the address by a 
clicking on it and click on the "Remove" button.

Setting Hardware Address Filters

A Probes filter allows you to capture packets coming 
from one hardware address to another - in one or both 
directions:  All incoming packets to a particular address 
from any source, all outgoing packets from a particular 
address to any destination, or all the traffic on the 
network - subject to the protocol sub-filter.

To set up a filter, select one of the five lines in the 
three boxes below the hardware address with a mouse click.  
Then click on an address you want to monitor in the hardware 
address box and click on the "Add" button over the right or 
left filter sub-box.  Repeat the above procedure for the 
second address.

Once you have added both addresses, you can choose 
the direction to capture.  Choose "->" to see only the 
packets from the left address the right address on the 
filter line.  Choose "" to see only the packets from the 
right address to the left address on the filter line.  
Choose "" to see packets from or to the right and left 
addresses on the filter line.

If you want to capture all packets in one or both 
directions - select the line "ANY_ADDRESS" in the 
hardware addresses box and add it to the filter line.

If you want your current filters to be loaded upon 
activation of the Probe window, check the "Enable 
current filters on startup" box.  Otherwise the Probe will 
start up with no filter and thus default to a capture all 
packets state.

Choosing a Protocol as a sub-filter

Each Probe allows you to select a protocol that you 
want to monitor as a sub-filter for that Probes segment.  
The choices in this list will depend on whether you are 
using Ethernet or Token Ring.  For Ethernet you have 5 
choices of protocol sub-filters:

All protocols (no filtering by protocol)
TCP/IP set of protocols (TCP,UDP,ICMP,....)
IPX-SPX ETHERNET II (Novell)
IPX - IEEE 802.3 (Novell)
IPX - ETHERNET II + IEEE 802.3 (Novell)

For Token Ring, the protocol sub-filter list will show:

All protocols (no filtering by protocol)
TOKEN-RING_SNAP - all sub-protocols
TOKEN-RING_SNAP - TCP/IP set of protocols
TOKEN-RING_SNAP - IPX/SPX set of protocols
TOKEN-RING - all sub-protocols
TOKEN-RING - IPX/SPX set of protocols
MAC frames only

To choose a protocol, click the arrow on the right of the 
"Protocol" line at the bottom of the "Filters" dialog box.  
Select the option that best filters the situation you wish 
to monitor.  It is best to do as much filtering as possible 
when trying to isolate network problems.

Note: Analyst can analyze many more protocols than it 
allows you to filter.  If your particular protocol is not 
present in the specific list of protocols, just choose the 
"All Protocols" (no filtering by protocol) line.


DISCOVERY MODE

Discovery mode allows you to capture all of the network 
addresses on a Probes segment, store them in a 
Probes filter table, and alias them as names or IP 
addresses.

Analyst allows you to add addresses manually or to 
"discover" addresses for a Probes segment with the 
Discovery mode dialog.  To start Discovery mode 
choose "Modes" -> "Discovery Mode" from the Probes 
menu.

Once you are in Discovery mode, you can have the 
Probe "listen" to the segment and record all of the 
active network addresses on that segment.

By pressing the start button on the right of the screen, 
the Probe will begin to collect all of the active addresses 
on the Probes LAN segment.  Addresses will be added 
immediately as each station accesses the LAN (up to 
the number of addresses for which you are licensed).

Once you have collected the addresses you are 
interested in saving, you can save them by clicking on 
"Save All", or highlight just a few addresses using your 
mouse, and save only those.  The addresses will be 
saved in the ANALYST.ADR file.  They will then be 
available for use in the Probes Filter dialog.

You can choose to alias addresses at this point, or you 
can wait until you need to use an address and alias it in 
the Filter dialog.

Clicking on the "Load list of addresses at startup" loads 
all of the addresses you have stored in your 
ANALYST.ADR file when going into the Discovery 
mode dialog.  If you start Discovery mode with "Load a 
list of addresses" checked on, then clicking on the 
"Highlight New" button will display all of the addresses 
that are newly discovered in this Discovery mode 
session.

If you are using TCP/IP, Discovery Mode allows you to 
automatically fill the alias of an address with the IP 
address of that station.  To activate this feature check 
the "Fill new addresss alias with IP address" checkbox 
at the bottom of the Discovery mode dialog.


NETWORK STATISTICS

Each Probe in the Analyst MDI window has four modes 
which allow you to monitor and observe different 
aspects of the movement of data across the Probes 
segment: Bandwidth Utilization (short and long term), 
Received Packets Statistics, Size Distribution Statistics, 
and Protocol Statistics.

Bandwidth Utilization Mode

Each Probe provides two different bandwidth utilization 
modes for its segment:

1. Bandwidth Utilization - this displays a graph that 
shows an instantaneous "window" of a Probe 
segments bandwidth utilization.  Information is real 
time but the graph will only display up to 16 minutes 
of information.  Sampling is done once per second.

2. Long Term Bandwidth Utilization (LTBU) - this 
displays (and allows for export) longer term 
information about a Probe segments bandwidth 
utilization.  The graph shows high, low and average 
over time - up to 7 days.  Sampling is still once per 
second but the display can be configured to report 
at various time intervals.

The Bandwidth Utilization screen can be activated from any 
Probe window by selecting "Modes" -> "Bandwidth Utilization".

Once you are in the Bandwidth Utilization screen, the 
graph shows the current utilization.  A Maximum 
Utilization value is kept at the top of the graph.  This 
value is reset each time you start and stop Bandwidth 
Utilization.

This graph shows the amount of data on the Probes 
network segment graphed against the maximum 
theoretical bandwidth for your network topology - as set 
in the "Modes" -> "Probe Remote Settings" dialog box.  
For Ethernet, you should choose "10 Mbps".  For Token 
Ring choose either "4 Mbps" or "16 Mbps" depending 
on your LAN.

Note: This graph is not subject to any filters.

The Long Term Bandwidth Utilization screen can be activated 
from a Probes main window by selecting "Modes" -> "Long 
Term Bandwidth Utilization".

Once the LTBU graph pops up, it automatically begins 
capturing data.  Three lines will be shown: red for  
maximum, blue for average, and green for minimum.  
Although data points are only shown for the time period 
set in "Modes" -> "Probe Local Settings", data is 
collected and processed every second.

The scroll bar at the bottom of the graph will allow you 
to see historical utilization data.  The LTBU graph can 
collect 10,922 data points.  For example, if you choose 
a 1 minute averaging time, it will be 7.59 days before 
the LTBU graph will reach its data limit.

You can save the LTBU data to a coma-delimited file by 
choosing "File" -> "Save Long Term Bandwidth 
Utilization" from Analysts main MDI window.

See the "Probe Local Settings" section for more 
information on Averaging Time and Time scales.

Note: Long Term Bandwidth Utilization is not subject to 
any filters.
General Statistics Information
To start a statistics capture, click on the "Start" button.  
To stop the capture, click on the "Stop" button.

Once you are in a Probes network statistics screen, 
you have a number of choices to make.

A Probes network statistics screen has three views: 
Received Packets, Size Distribution, and Protocol 
Statistics.  You can view LAN traffic by address and 
percentage of captured bandwidth, by address and 
packet size distribution as a percent of captured 
bandwidth, or by protocol.  You can choose the view 
you would like to see from each Probe "Modes" menu.  
Each of the network statistics windows are shown and 
explained below.

Some screens have additional options which are 
explained in each of the dialogs individual sections that 
follow.

By default each statistics view will show all traffic on the 
Probes segment (subject to your current filter 
selections) by the "Destination Address".  You can 
press the "Direction" button to switch from a 
"Destination Address" listing to "Source Address" listing.

You can press the "-Aliases" button to switch from a 
listing of hard network address to a list of aliased 
addresses which you have set up in the Probes 
"Filters" dialog box.  (For more information on how to 
set aliases, see the Filter section.)  When the button 
shows "-Aliases", aliasing is off.  When it shows 
"+Aliases" - aliasing is on.

The "Clear" button clears the current screen, clears the 
capture buffer and stops the capture.  Press the "Start" 
button to begin a new capture.

Received Packets Statistics

The Received Packets window can be activated from a 
Probes main window by selecting "Modes" -> 
"Received Packets Statistics".

To begin a capture press the "Start" button.

The Destination/Source Address field will show either 
the destination or source address.  This can be either a 
hard network address or an alias (depending on the 
state of the alias button).

The "%" field shows the percent of bandwidth utilization 
for that destination/source address.  Note that this is 
the % of filtered bandwidth.  If you would like to see the 
percent of total bandwidth that that particular address 
is using, you will need to set up an ANY_ADDRESS to 
and from ANY_ADDRESS filter.

The "Packets" field shows the number of packets to (or 
from) the destination/source address, subject to the 
current filter set.

The "Bytes" field shows the bytes to (or from) the 
destination/source address, subject to the current filter 
set.

The "Sort" button activates the sort dialog.

The sort dialog allows you to choose the direction of the 
display (with respect to source or destination) and the 
sort order of the window.  Sorting is useful for 
determining which stations are sending the most data 
and which are less active.

Once the capture begins, you can double click on any 
address to copy the hard address into the Windows 
clipboard.  This can provide a convenient way to begin 
building an alias table.  For example, if you double click 
on an address and then switch to the "Filter" dialog box, 
you can then paste that address into the "Hardware 
Address" edit box using Shift-Ins.  To automatically 
build a complete hard address table, see the section on 
Discovery mode.

Size Distribution Statistics

The Destination/Source Address field will show either 
the destination or source address.  This can be either a 
hard network address or an alias (depending on the 
state of the alias button).

The "%" field shows the percent of number of packets 
detected for that destination/source address.  Note that 
this is the % of filtered packets.  If you would like to 
see the percent of total packets that a particular 
address is using, you will need to set up an 
ANY_ADDRESS to and from ANY_ADDRESS filter.

The "Packets" field shows the number of packets to (or 
from) the destination/source address, subject to the 
current filter set.

The rest of the screen shows the packet size 
distribution divided by packet size in bytes.  This is 
shown as a percentage of the total for that address.  
This is a good way to determine if a particular station is 
being as efficient as it might be by sending mostly large 
or mostly small packets.

Protocol Statistics

The Protocol Statistics screen (Figure 16) shows a 
Probes Ethernet LAN traffic divided by network 
protocol and sub-protocol (the Token Ring display will 
be slightly different).  Protocols are displayed as a 
percentage of the total filtered traffic.  Sub-protocols 
are displayed by the number of packets received of that 
type.

Printing Statistics screens

Any of the statistics screens can be printed by selecting 
"File" -> "Print (whatever) Statistics" from the main 
Analyst MDI window.


PACKET CAPTURE MODE

A Probes Packet Capture screen consists of a menu bar, 
monitor graph, Start(/Stop), View and Clear buttons.

Note: To capture packets, you should first select a filter 
set.  This can be done using the "Filters" menu choice 
from any Probes window.  See the section on "Filters" 
for more information.

To begin capturing packets, press the "Start" button.  
You will see three different lines on the capture graph.  
The red line shows the non-captured traffic, the blue 
line shows the captured traffic.  The black line shows 
dropped packets (if there are any).

Note the red blinking "Capturing" in the upper right hand 
corner of the graph.  This is the Probes  "Capture is on" 
indicator.  The Probe window will also tell you the 
percent of your capture buffer that is full and will 
automatically stop capturing when the Probes buffer 
becomes full.  For more information on the capture 
buffer size, see the "Probe Remote Settings" dialog 
section in this manual.

Once you have captured some quantity of packets, you 
can view the packets with the "View" button or save the 
capture buffer to a file to view later.  Pressing the 
"View" button will turn capturing off.

For information on viewing captured packets see the 
"Viewing Captured Packets" section.

To save a Probe capture buffer to a file, capture the 
information you want to save and select "Save Packet 
Buffer" from the "File" menu on the View screen.  To 
load a previously saved capture buffer, choose "Load 
Packet Buffer" from the "File" menu in Analysts main 
MDI window.

To stop capturing packets, press the "Stop" button.

To clear the capture buffer and stop the capture, press 
the "Clear" button.

Viewing Captured Packets

To view the packets in the capture buffer, click on the 
"View" button from the "Receive Packets" screen.

Once you are in the view screen, you can click on a 
particular packet (with your LEFT mouse button) in the 
top window to display the packet decoded information in 
the bottom window.  The two windows are fully sizable 
by dragging the middle border up or down.  Analyst 
decodes all TCP/IP, IPX/SPX, and NetBIOS/NetBEUI 
packets.  Other packets are shown in raw mode.

You can click on the "Show aliases" box at the bottom 
of the screen to enable aliasing of network addresses.

Clicking on the "Raw Packets" box at the bottom of the 
screen will switch from a decoded packet view to a raw 
packet view.

The Settings menu choice has two options:

Select Frame Colors - this item displays the colors 
dialog.  You can also access this dialog by single 
clicking your RIGHT mouse button on any packet line 
on the top part of the View Packets screen.  In either 
case, this allows you to choose the color of the packet 
line you would like to associate with the selected frame 
type.  For example, you could set all IP packet types to 
show with a white background and a green foreground, 
while displaying all IEEE 802.3 packet types (Netware 
3.xs default) as white foreground with a red 
background. This can help you visually pick out a 
particular packet type if you are capturing multiple 
types.

View Configuration - this item up the View 
Configuration dialog where you can control Analysts 
post-capture filtering.

Probably one of the most powerful features of Analysts 
packet capture/decode, view configuration allows you to 
filter the packet capture after you have captured a 
buffer.  These post-filters will filter out any unwanted 
data - both in the packet decode screen and on any-
print outs of the data capture.

The view configuration dialog options include the IP 
post-filter dialog and the TCP header post-filter dialog.  
Both are shown below.

This dialog allows you to "post-filter" all or some of the 
IP header information.

This dialog allows you to "post-filter" all or some of the 
TCP header information.

Show Differential Packet Times - choosing this option 
(check the checkbox) will display the differential packet 
times in the Packet View window.  Differential packet 
times show the difference in time of arrival (and thus 
time sent) for the current packet and the previous 
packet.  This is called the packet delta.

You can search the data segment of a packet capture 
buffer by using the "File"-> "Find Packet" dialog.

Multiple instances of the Find Packet dialog can be 
active at one time.  To activate the multiple instance 
search, start one search and choose "File"->""Find 
Packet" again without closing your first search - both 
will remain active.

Printing captured packets

You can print a packet capture buffer (the "View 
Packets" screen content) on a printer attached to your 
computer or on any printer available on your network.

To set up a printer for Analyst select "Print" -> "Print 
Setup" from  the View Packets dialog box and select 
either the default printer or choose a different printer 
from the "Specific Printer" dialog.

To print out a packet capture from the View Packets 
window click on the "File" -> "Print" to bring up the 
printer dialog sub-menu.

You will be given options for the set of packets to print.  
The default is set to print all captured packets.

You can choose to print commented or raw packets or 
both (which can be most useful for a programmer 
analyzing packet details in depth).  You can have 
Analyst print out either Ethernet addresses or aliases 
as the printed headers

You can also choose whether Analyst will print packets 
continuously or print each packet on a single page. 
(Providing that length of a packet allows it, every new 
packet will always start printing on a new page.) 

Once you have made your print option selections, click 
on the "Print" button.

To exit without saving, press "Cancel".

Saving Captured Packets to a File

To save a packet capture to a file, select the "Print" -> 
"Save to a File" item from the View Packets window.

You will be given a choice of packet numbers to print.  
The default is set for all captured packets.  However, if 
after reviewing a packets contents in the "View 
Packets" dialog you are interested in some particular 
section of the capture, you can specify only that 
section.

Next, you can choose to save commented or raw 
packets or both (which can be most useful for a 
programmer analyzing packet details in depth). You can 
let Analyst save either Ethernet addresses or aliases as 
the printed headers.  

When you have made your option choices, click on the  
"Save" button.  You will be given a choice of file name 
and directory to save the capture.

To exit without saving, press "Cancel".

Loading and Saving a Packet Buffer

In Analyst, you can load or save the packet buffers for 
later analysis exactly as if they were received from the 
network.

You can save a packet buffer by selecting "File" -> 
"Save Packet Buffer" from the "View Packets" window.

Selecting the "File" -> "Load Saved Packet Buffer" 
option from the "File" menu, either in "View Packets" 
window or in Analysts main MDI window, will load a 
saved Packet Buffer for Analyst to view.  The View 
screen will display the loaded Packet Buffer file.


PREFERENCES DIALOG

The Preferences dialog box allows you to set the global 
variable information in Analyst.

Ask confirmation on exit - this option, when checked 
will display a warning before allowing you to exit 
Analyst.

Show tips - this option, when checked on, will display 
starting tips when entering Analyst.

Probe display mode - this option allows you to set the 
initial Probe window display.

Time out for send command - this is the amount of 
time Analyst will wait for a Probe to send data before it 
assumes that the Probe is down.

Warn about losing captured packets - when this 
checkbox is selected, Analyst will display a warning 
every time the user tries to switch from the packet 
capture mode.  The packet capture buffers are cleared 
when you switch from the packet capture mode.

Warn about losing Long Term Utilization data -  
similarly warns you about possible loss of data when a 
user switches from the Long Term Utilization mode.


PROBE REMOTE SETTINGS

Note: Although you set these values at the Analyst, 
they all pertain to the Probe for which you are setting 
them.

Windows buffer size - this is the amount of Windows 
memory that a Probe will set aside to store captured 
packets.  Values are in kilobytes, so a setting of 132 
would represent a .132 megabyte (MB) buffer.  A 2048 
KB buffer would represent a 2.048 MB buffer.

You should choose the smallest buffer that will capture 
your event of interest. Analyst will show each Probes 
buffer percentage full value thus you will get an idea of 
what is the best buffer for a particular situation.  Keep in 
mind that a full 4 MB buffer is a lot of data to examine.  
You will want to capture an event in as little time with as 
little buffer space as possible.

It is not recommended (although it is allowed) to use a 
buffer larger than the amount of physical RAM in your 
PC.  In this case, Windows in its infinite wisdom, may 
decide to swap itself out of RAM, leaving you, Analyst, 
and your PC in a very bad position.

On a 16 MB system, the maximum recommended 
buffer is 10 MB (a setting of 10,000).  On a 8 MB 
system, the maximum recommended buffer is 4 MB (a 
setting of 4,000).  Again, use the smallest buffer 
possible to capture the event of interest.

Lock Windows buffer from paging - this will tell 
Windows not to page out the Probe's packet buffer.  
This will make the Probe more efficient since its buffers 
will always stay in RAM (as opposed to Windows 
swapping out the buffer).

This is the recommended mode for operation of a 
Probe but be careful.  If you set your buffer size too 
high and lock the buffer from paging, Windows may 
swap out its own programs causing Windows to crash.

Network Bandwidth - this sets the network bandwidth 
of the Probes segment.  This will be used to calculate 
the % of Bandwidth Utilization when in Bandwidth 
utilization mode.  Modes are:

4 Mbps	- Used for 4 MB Token Ring
10 Mbps	- Used for all ethernets
16 Mbps	- Used for 16 MB Token Ring

Probe's Report Period - this value is the amount of 
time between each Probe report.  In other words it is 
the number of seconds a Probe waits between sending 
new information to the Analyst station.  Values range 
from 5-30 seconds.


PROBE LOCAL SETTINGS

This dialog allows you to set Probe-specific information 
that is kept local to the Analyst Station.

Long Term Bandwidth Utilization (LTBU)

Averaging Time - the amount of time that a Probe will 
collect data before it averages and reports high, low, 
and average.  A Probe LTBU graph can display and 
record 10,922 data points.  For example, if you choose 
a 30 second averaging time, then Analysts buffer 
would capture and display for 3.79 days (10922 (points) 
/ 120 (points per hour) / 24 (hours per day) = 3.79 days)

Stretch time scale - by default the LTBU graph will plot 
each data point 10 pixels apart (10x) and fill in the 
distance between with a solid line.  Setting this to 1x will 
plot data points one pixel apart.  LTBU will plot times on 
the graph in a manner which ensures that no time 
stamp will overwrite the previous on or the next one.  All 
export files contain all time stamps and all data points 
as described in the averaging time above.

Show Packet Capture Legend - turns the legend off or 
on in the Capture Packets graph.


NOTIFY PROBE

In Packet View and Decode mode, Analyst provides a 
built-in chat utility that allows the network administrator 
to communicate in real time with Probe PC users.
Pressing the Notify button will open a chat window on 
the Probe PC.

USING PROBE

The Probe software on a host PC has few options, and 
once configured, should not require any additional care 
to function correctly for your Analyst Station.

The Probe software requires a Winsock 1.1 
compatible TCP/IP installed on the host PC 
configured to run over ODI.

Once you have verified that the Windows PC has the 
correct environment available for the Probe software, 
you can start a Probe by double clicking on the Probe 
icon.  (For information on installing the Probe software 
see the Installation section at the beginning of this 
manual.)

The Main Probe window has the following menu 
choices.

About - this displays the Probes copyright and version 
information for the Probe software.

Settings - this activates the "Probe Local Settings" 
dialog.  This is the same dialog as Analysts "Probe 
Remote Settings".

Exit - this exits the Probe.

In addition to the menu choices,  the Probe will display 
status information including: Probes IP address, 
Analyst Stations IP address, Buffer size, current Mode 
and a status window.


PROBE SETTINGS

Each Probe has a Settings dialog that can be accessed 
from the local Probe by choosing "Settings..." from the 
Probe main window on the Probe PC or by choosing 
"Probe Remote Settings" from any Probe window on 
the Analyst Station.  Modifying either of these dialogs 
sets the same information in the chosen Probe.

The Settings choices are as follows:

Windows buffer size - this is the amount of Windows 
memory that a Probe will set aside to store captured 
packets.  Values are in kilobytes, so a setting of 132 
would represent a .132 megabyte (MB) buffer.  A 2048 
KB buffer would represent a 2.048 MB buffer.

You should choose the smallest buffer that will capture 
your event of interest. Analyst will show each Probes 
buffer percentage full value thus you will get an idea of 
what is the best buffer for a particular situation.  Keep in 
mind that a full 4 MB buffer is a lot of data to examine.  
You will want to capture an event in as little time with as 
little buffer space as possible.

It is not recommended (although it is allowed) to use a 
buffer larger than the amount of physical RAM in your 
PC.

On a 16 MB system, the maximum recommended 
buffer is 10 MB (a setting of 10,000).  On a 8 MB 
system, the maximum recommended buffer is 4 MB (a 
setting of 4,000).  Again, use the smallest buffer 
possible to capture the event of interest.

Lock Windows buffer from paging - this will tell 
Windows not to page out the Probe's packet buffer.  
This will make the Probe more efficient since its buffers 
will always stay in RAM (as opposed to Windows 
swapping out the buffer).

This is the recommended mode for operation of a 
Probe but be careful.  If you set your buffer size too 
high and lock the buffer from paging, Windows may 
swap out its own programs causing Windows to crash.

Network Bandwidth - this sets the network bandwidth 
of the Probes segment.  This will be used to calculate 
the % of Bandwidth Utilization when in Bandwidth 
utilization mode.  Modes are:

4 Mbps	- Used for 4 MB Token Ring
10 Mbps	- Used for all ethernets
16 Mbps	- Used for 16 MB Token Ring

Probe's Report Period - this value is the amount of 
time between each Probe report.  In other words it is 
the number of seconds a Probe waits between sending 
new information to the Analyst station.  Values range 
from 5-30 seconds.

Analysts IP address - this is the IP address of the 
Analyst Station to which this particular Probe reports.


USING NETWARE DISCOVERER

OVERVIEW AND QUICK START

To start Discoverer double click on the Discoverer icon.

Note:  As mentioned in the Install section, Discoverer 
REQUIRES Novell Netware and ODI.  Also the VLMs 
and all of the Netware Windows DRVs, DLLs and 
VxDs must installed and running.  If you experience 
problems running Discoverer, see the installation 
section under ODI for things to check.

Additionally, to receive Netware statistics you must be 
using Novells 802.3 for your IPX/SPX FRAME type.  
This is the Netware default.  This is a Novell limitation.

Discoverer's main window consists of a MDI window 
with a menu on top and a set of  often used commands 
in a button bar.  On the left there is a graphical list of 
servers and nodes (Called the "List of Nodes"), the right 
side is separated by a split window bar and is the area 
reserved for SERVER and NODE information windows.

All the buttons on the button bars have a short 
informational description for each button.  This 
information can be invoked by placing the cursor over a 
particular button and holding down the RIGHT mouse 
button.

To display a List if Nodes attached to a particular 
server, double click on the server icon on the left side of 
the MDI window (known as the "List of Nodes") with the 
LEFT mouse button.  To close the graphic node list of a 
particular server, double click on the server icon again 
(using the LEFT mouse button).

To display a SERVER or NODE informational window, 
click on the RIGHT mouse button on a server or node 
icon in the graphical list of servers on the left of the MDI 
interface.  An information window will appear in the area 
to the right.

From the SERVER or NODE informational window, you 
may select the information you would like to display.  
This information includes might include the following:

Charts menu - this shows graphical information in real 
time about the network

Lists menu - this shows tables of information that 
update over time

Info menu - this shows version information and 
statistics that are not updated as often

Based on your selection you may use different entries 
in the Options menu to customize the display to fit your 
needs and preferences.  You can set update periods 
and colors separately for every type of chart.  The Color 
Setup dialog may also be invoked by clicking the 
RIGHT mouse button anywhere on a chart.  The vertical 
scale of a chart can be changed in the Scale menu 
under Options in the specific NODE or SERVER 
information window.

The NODE list's update period is set under "Options" -> 
"Timing" from any NODE information window.  This sets 
the polling simultaneously for all NODE lists.  Setting 
this from a SERVER information window sets it for all 
SERVER lists.  Timing set while displaying a chart sets 
timing for that chart only.

Note:  At certain moments when Discoverer polls 
the network or collects information, new  
commands that may interfere with current activity 
will be ignored.  Do not be alarmed - this is the 
normal way in which Discoverer operates.


THE MAIN MDI WINDOW

Discoverer's initial main screen (the MDI window) 
consists of a menu bar, button bar, List of Nodes listbox 
(on the left) and information window area (on the right) 
divided by vertical splitbar.

The List of Nodes is a two level graphical 
representation of servers and nodes on the LAN.   
Discoverer fills the List of Nodes with icons of servers 
which it finds on your LAN in the first few seconds after 
startup.

Note:  The success of the first polling is an indication of 
the Novell support VLMs, drivers and DLLs installation.  
If you do not get the initial listing of servers, some piece 
of the Novell driver set was not properly installed.  An 
error message should appear telling you which file(s) 
needs to checked or added.

After the listing of servers appears, you can display a 
list of the nodes attached to any server by double 
clicking on the LEFT mouse button.  This "opens" the 
server list.  Double-clicking again on the LEFT mouse 
button closes the list.

Clicking on the RIGHT mouse button over any server or 
node icon opens a SERVER or NODE information 
window on the right side of the MDI window.

File Menu

Discoverers "File" menu includes the following items:

License - appears only if Analyst and Discoverer are 
not licensed.  You can license either program from 
either license dialog.

Store List of Nodes - stores the current List of Nodes 
for Discoverer to recall or reuse at a later point in time.  
(Duplicates the functionality of the button in the Main 
MDI window button bar.)

This is an important concept.  The "List of Nodes" 
should be saved and added to from time to time as you 
add stations to your LAN.  Think of it as your template 
from which you begin each Discoverer session.  When 
your template is accurate - listing all nodes and servers 
- you can see which nodes or servers are running and 
active.  Most importantly, you will also be able to see 
any inactive nodes or server.  If you do not save and 
update the List of Nodes, Discoverer will only see active 
stations each time it starts up, and thus will not show 
any stations or servers that may be down for valid or 
non-valid reasons.

Load List of Nodes - loads saved List of Nodes stored 
with "Store List of Nodes" and forces Discoverer to 
display the saved list.

Save List of Nodes to a Text File - saves the 
complete, current List of Nodes to a text file (*.SAV).

Print List of Nodes - prints out the currently displayed 
List if Nodes including all servers and all attached 
nodes.

Save Node Information to a File - stores List or Info 
tables to a file.  If the active information window 
(window displaying server or node information ) is 
currently displaying a chart, this menu item is replaced 
by the following two items:

Save Chart in Spreadsheet Format - allows 
you to save the charted information in coma-
delimited text format compatible with Microsoft 
Excel and other spreadsheet applications.

Print Node Statistics - prints the List or Info table.  If 
the active information window (window displaying server 
or node information) is currently displaying a chart, this 
menu item is replaced by:

Copy Chart to Clipboard - copies the current 
chart to a Windows clipboard to be processed 
by any image editor such as Windows 
Paintbrush.

Print Setup - lets you select and configure a printer 
from the currently installed Windows printer list.

Exit - exits Discoverer.

About Discoverer - displays version and copyright 
information.

Options Menu

Discoverers "Options" menu consists of three entries:

Preferences - this is the dialog to set the general 
operational parameters for Discoverer.  (A more 
detailed explanation of this dialog is located in the 
Preferences section later in this manual.)

Discovery Alias List - Discoverers Discovery Alias List 
is designed to collect hardware addresses used on the 
network.  In the same way as Analyst aliases the 
hardware address with an Internet Addresses, 
Discoverer aliases hardware addresses with Novell user 
names.  When saved, these aliases will be used by 
Analyst for Packet Viewing.

Server exclusion List - the dialog that allows you to 
exclude/include various servers from the List of Nodes.

Login to Server - lets an administrator login to a 
highlighted (on the List of Nodes) server.  To receive a 
list of users from the server, a Discoverer operator 
MUST HAVE SUPERVISOR privileges.  If he or she 
logged in earlier with a different name, this option first 
logs you out, then asks you to login as supervisor (or 
equivalent).  If desired, Discoverer can autologin on 
some or all of the servers (this option must be enabled 
in Preferences dialog).

The Preferences dialog

Ask Confirmation on Exit - if selected, Discoverer 
displays a warning message when a user chooses 
either the Exit button or chooses "Exit" from the "File" 
menu.  This is intended to prevent accidental 
termination of Discoverer and loss of collected data.

Ask confirmation to save List of Nodes - if selected 
this prevents accidental overwriting of the List of Nodes 
by displaying a confirmation dialog.

Show Tips - if selected, enables the display of a short 
list of the most essential Discoverer tips.

Statistics display mode - allows the choice of the 
three information window displays:

Single maximized window node - in this mode 
only one maximized information window can be 
displayed at one time.  When a user starts an 
information window for a different SERVER or 
NODE, the current information window 
terminates.

Multiple maximized window nodes - in this 
mode an information window is maximized as in 
the previous option.  However, when starting a 
new window, the previous one does not 
terminate.  The new window takes place of the 
previous one.  A user can switch between the 
windows using the CTRL-TAB key combination.  
The windows can then be tiled or cascaded with 
the appropriate buttons from the menu bar or 
menu choice.

Multiple normal window nodes - in this mode 
all of the information windows are displayed 
non-maximized.  They can be positioned, tiled, 
and cascaded to enable monitoring of multiple 
servers or workstations simultaneously.

Load saved List of Nodes on startup - automatically 
loads the current saved List of Nodes.  Otherwise, the 
List of Nodes starts blank and is gradually filled with 
active servers and nodes (as they respond to polling).  
Note: This must be checked to use an exclusion list.  In 
other words, if this is not checked, the List of Nodes fills 
with all of the servers that answer and no exclusions 
are made.

Allow autologin to selected servers - automatically 
logs in to the servers that the Discoverer's PC has 
included on its List if Nodes - independent of the 
servers that were attached to Discoverer PC prior to 
login.  If the login entry was not saved, a user will be 
asked to login.  If the user selects to save the current 
login (from the login dialog), Discoverer will save and 
then use this login and password in the future.

Note: To receive information about users attached, and 
associated information from the server, you must be 
logged in as SUPERVISOR, or as a user with 
equivalent privileges.  If you were not logged in as 
SUPERVISOR prior to starting Discoverer, you may find 
that all nodes are dark (if Load Saved List of Nodes on 
startup option was selected), or that there are no nodes 
attached to the server.  In this case, LOGIN TO THE 
SERVER from the "Options" menu.  On the next polling 
session (every 20 seconds by default) Discoverer will 
autologin to the server or you will be asked to enter 
your name and password.

Display polling cursor when minimized - toggles 
off/on the display of the Discover hourglass cursor 
when Discoverer is minimized but is still polling servers 
or nodes.  This special cursor will help you determine 
whether a system delay is caused by Discoverer polling 
or by another program.  When Discoverer is the active 
window, it always displays the Discoverer hourglass 
when polling.

Discoverer server polling period - this allows you to 
adjust the polling period Discoverer uses to update the 
"List of Nodes" table on the left of the main MDI 
Discoverer Window.  Two values are required:

Window - the number of seconds that 
Discoverer waits to poll all servers/nodes active 
in the "List of Nodes" while discoverer is active 
(not minimized).

Minimized - the number of seconds that 
Discoverer waits to poll all servers/nodes active 
in the "List of Nodes" while Discoverer is 
iconified.  You may want to set this quite high 
(i.e. 200 or 300) if you are collecting statistics on 
a node or a server.  Doing so will minimize the 
disruption of your work while Discoverer is 
running.

Addition Polling Time - a tuning parameter which 
should be used on large or busy LANs when the time 
required for the server to respond to a poll is so long 
that Discoverer believes that the server is down.  
Typically this should be left at 0.  If your servers seem 
to go dark (i.e. Discoverer thinks they are down) every 
so often, introduce a 1 or 2 second additional polling 
time.  That should solve the problem.

Discoverer Discovery Mode

Discovery mode allows you to capture all of the hard 
network addresses on your LAN, store them in 
Analyst's the filters table, and alias them as names or 
Novell Login names.

Press "Add New" to begin and the Discovery mode 
table will begin polling servers and capturing addresses.  
Once you have a list of addresses captured, you can:

Clear - clears the table

Add/Edit Alias - selecting an address and pressing this 
button will pop up the edit box to add an alias.  Make 
sure you click on the down arrow on the right when 
complete.

Highlight New - shows new addresses.  These are 
addresses that have been discovered but are not yet on 
the address list in Analyst's filter section.

Save Highlighted - saves a highlighted address to 
Analyst's filter table.

Save All - saves all of the addresses/aliases 
(overwriting all others).

Check the box at the bottom of the Discovery mode 
dialog to automatically "Fill Addresses with Novell 
Name".

Check the "Load List of addresses at startup" have 
Discovery mode to load Analyst's filter tables 
addresses at startup.  You may want to do this to try to  
discover Novell login names for addresses without 
aliases.

Server exclusion List

Discoverer includes the ability to "exclude" certain 
servers from the List of Nodes.  You may want to do 
this if you have many servers that cannot provide useful 
information in your List of Nodes.  To exclude a server, 
choose "Options" -> "Server exclude List".  Highlight the 
server you want to exclude in the "Display Servers" list 
and press the "Exclude" button.

To clarify, if you have many print servers, CDROM 
servers, dead servers (servers that your active servers 
can see across a wide area network, but are not 
available for your inspection), or servers that you are 
simply not interested in - you can exclude these.  As 
long as you have "Load saved List of Nodes on Startup" 
checked in the Preferences dialog, they will not appear 
in your List of Nodes.

You can restore any server simply by going into the 
"Server exclude list", highlighting the server to be 
restored in the "Excluded Severs" box, and pressing the 
"Restore" button.

Login to Server

To receive information about the users attached to a 
server, you must be logged in as SUPERVISOR, or a 
user with SUPERVISOR equivalent privileges.  If you 
are not logged in as SUPERVISOR, you may find that 
all the nodes are dark (if load saved List of Nodes on 
startup option was selected), or there are no nodes 
displayed when you select a server.  In that case, 
"Login to the Server" from the Options menu.  On the 
next polling session (which happens every 20 seconds 
by default), Discoverer will autologin to the server (if 
you have saved the servers autologin information and 
have Allow Autologin to Servers checked in 
preferences) or you will be asked to enter your name 
and password.

The Login to Server dialog has the following options:

Login name - this should be SUPERVISOR or a user 
with SUPERVISOR equivalencies.

Password - the users password.

Save current login - this saves the login information  
for autologin (if you have "Allow Autologin to Selected 
Servers" enabled in "Options" -> "Preferences").  This 
information is kept encrypted in the DISCOVERER.INI 
file.

Do not login (print server only) - this deactivates the 
autologin feature for the highlighted server.  Use this 
option only the server does not require a login (i.e. a 
print server).  If you do not want to login to a standard 
server, use the Server exclude/include option.

The Window Menu

The Window Menu contains the following items:

Tile - tiles all information windows (both SERVER and 
NODE).

Cascade - arranges information windows in a standard 
Windows cascade.

Arrange Icons - if there are minimized information 
windows, this option lets you neatly arrange them.

Close All - closes all information windows.

In addition, a list of all info windows is appended to this 
menu.  From this list you can choose a window to make 
it the active window.


THE MDI WINDOW BUTTON BAR

The Main MDI Window button bar is provided for quick 
access to some of the frequently functions of 
Discoverer.

Short help information describing the use of each 
button can be seen holding down the RIGHT mouse 
button on the button in question.

Here is the list of the buttons and their functions (from 
left to right):

List of Nodes Display Options - allows you to 
configure the display of the contents of the server and 
node text in the List of Nodes.  It can be a node name 
only, node name + address, or node name + address + 
attach time.

Save List of Nodes - this is used to save the current 
List of Nodes (and servers). [This is useful to get a 
complete listing of all stations to determine when the 
network configuration changes or to display which 
stations are up or down.]  You might use this to save a 
list of all servers and workstations.  At a later date you 
could "Load List of Nodes" (see below) and Discoverer 
would display not only the active stations discovered but 
also all stations in the saved List of Nodes.  This would 
then display all active stations and all non-active 
stations in the saved list.

It is recommended that you keep the "Ask Confirmation 
to Save List of Nodes" checkbox selected (in "Options" 
-> "Preferences") to prevent inadvertent overwriting of 
the current list.

Load Saved List of Nodes - this loads the saved List 
of Nodes.  You may want to do this prior to saving the 
List if Nodes.  This way you can get all stations, both 
active and non-active, in your List if Nodes.

Delete entry - this deletes a highlighted entry on the 
List of Nodes.  You might use this to remove a station 
or server that has been stored on the List of Nodes but 
has since been removed from your site.

Stop Polling for Statistics - is used to completely stop 
polling.  You can start polling again by pressing the 
button again.  Stopping the polling will  prevent 
updating the List of Nodes.  Stop Polling can be also 
used to save the current state of a chart or list when it is 
necessary to prevent it from updating or changing 
position.

Tile Node Windows and Cascade Node Windows -
can be used to arrange information windows in the view 
area.

Exit - closes Discoverer.


THE LIST OF NODES VIEW

The "List of Nodes" View is the actual list of SERVERS 
and NODES on the left hand side of the main MDI 
window.  This is where you will see a graphical 
depiction of all of the NODES, SERVERS, ROUTERS, 
BRIDGES, etc. on your LAN.

You can expand any server by double-clicking on the 
LEFT mouse button on the server icon.  You can 
display a SERVER or NODE information window on any 
SERVER or NODE by single-clicking the icon with your 
RIGHT mouse button.


INFORMATION WINDOWS (GENERAL)

The following information applies to both the NODE 
information window and the SERVER information 
window.

An information window Options button menu displays 
the following five choices 2D, 3D, Colors, Scale and 
Timing.

2D - 2D charting offers the choice of Lines, Columns or 
Pie charts.  Sample charts are shown below:

3D - 3D charting offers Separate and Alternate 
Columns.  A user can choose the chart that is most 
useful for his or her needs.  Some menu items may be 
grayed out depending on the applicability to the active 
window (charts only).

Colors - the Colors dialog appears when the Colors 
item is selected from the Options menu or when a user 
clicks on the RIGHT mouse button anywhere on a 
chart.  It allows you to select the background and 
foreground colors, hatch, axis, coordinate lines, 
appearance, and color of a specific attribute.  This is 
done separately for every type of chart that appears in 
Charts menu and separately for servers and nodes 
(charts only).

Scale - the Scale submenu allows you to expand or 
contract the vertical scale of a chart to accommodate 
the charts scale to the wide range of amplitudes of 
data.  This value is saved separately for every type of 
chart.

Timing - the Timing dialog is applied to all updateable 
information window display modes (included in Charts 
and Lists menus for SERVERS and NODES).  This is 
where the polling period is set for a chart or list.  The list 
refresh period is the interval of time between polling a 
server or a node by Discoverer.  Values range from 10 
seconds to 1 hour.


SERVER INFORMATION WINDOWS

A SERVER information window is displayed in the 
information area (on the left of the MDI main window) 
after a user clicks on the RIGHT mouse button on a 
server icon in the List of Nodes.  SERVER information 
windows (which are very similar to NODE information 
windows) consist of a button bar with Charts, Lists, Info, 
and an Options popdown menu button, and an Exit 
button.

Button bar buttons can be selected using mouse clicks, 
and, in most cases, by pressing a letter on the 
keyboard that corresponds to one displayed in red on 
the button. (Note: Due to the nature of the MDI 
interface, you DO NOT use ALT when accessing the 
information window buttons.  Use ALT-KEY 
combination to popdown menus on the Main MDI  
window).

Context-sensitive help is available from any window by 
pressing F1.

Charts

The SERVER information window Charts menu 
contains the following choices (sample charts are 
located in the "Information Windows" (general) section):

Number Connections (server)

The Number of Connections chart displays the number 
of active connections on a specific Novell server.  This 
is also called the number of logged-in users.  This 
statistic is received directly from the Novell server.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Open Files (server)

The Open Files chart shows the number of files that are 
currently open on a specific Novell server. This statistic 
is received directly from the Novell server.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

IPX Packet Statistics (server)

The IPX statistics chart displays the number of sent and 
received IPX packets as a function of time.  It shows 
the server's IPX packet flow activity.

Malformed packets for send and Get ECB (Event 
Control Block) for receive are a sum of several failure 
conditions, and can indicate, if significant, improper 
functioning or overload of the server.  More detailed 
information can be seen in the IPX Statistics List.

This chart can be saved to a file in spreadsheet format 
("File" -> "Save Chart in Spreadsheet Format"), or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (Paintbrush, for 
example).

SPX Packet Statistics (server)

The SPX statistics chart displays the number of sent 
and received SPX packets as a function of time.  It 
shows the server's IPX packet flow activity.

Bad Send Packets for send and Get Bad Receive 

Packets receive are a sum of several failure conditions, 
and can indicate, if significant, improper functioning or 
overload of the server.  More detailed information can 
be seen in SPX Statistics List.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Total Packet Statistics (server)

The Total Packet Statistics chart displays the number of 
total packets (all protocols) sent and received by a 
server as a function of time.  It is an indication of the 
server's total network activity.

"Bad Send Packets" for send and "Get Bad Receive 
Packets" for receive are a sum of several failure 
conditions.

Bad Send Packets combines sum of: Send Packet Too 
Big, Send Packet Too Small, and Send Miscellaneous 
Errors.  These can indicate improper functioning of a 
server or a malfunctioning NLM.

Get Bad Receive Packets is the sum of a set of error 
conditions, and if significant, indicates an overload of 
the server.  More detailed information can be seen in 
Bridge Driver Statistics List.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Bridge Statistics (server)

The Bridge Statistics displays the number of packets 
routed through the bridge as a function of time.  Novell 
considers each network card driver in your server as a 
"Bridge".  Novell considers each instance of the driver 
loaded (usually for each frame supported) as a "board".  
So, each "Bridge" (card in your server) may have one or 
more logical "boards" loaded in it.  Each "board" is 
displayed and each statistic is kept for each "board".  
You can only "see" the Bridge in the server that you are 
connected to (this is a Netware limitation).

This chard includes the number of packets serviced and 
packets routed.  It also includes some of the most 
common error conditions: 

Total Packets Serviced - the total number of packets 
that the bridge has serviced since the bridge was 
initialized.  This is the number of packets that have 
arrived on the server, but is not necessary the number 
that have been routed.

Total Packets Routed - the total number of packets 
the router actually routed.

Too Many Hops - this is an indication that the packet 
that reached the current server has "hopped" too many 
times before reaching its destination.  It is the number 
of times, since the bridge was initialized that the bridge 
received packets on the fifteenth hop across an 
Internetwork bridge.  These packets are discarded.

Hop is the transition of a packet on its way to a 
destination server (or station) from another server (or 
station).  The "Too many Hops" error may indicate that 
the routing scheme used on the network is inadequate, 
or that possibly the server with a more direct connection 
path is currently down or out of order.  The situation 
may require the network administrators intervention.  
This error will occur only on larger sites with many nets 
and bridges or on sites experiencing an "infinite loop" 
between routers or server.

Unknown Network - these are packets that have 
reached the server and can not be routed because the 
destination network is unknown to the server.

This error may appear if a router that was transferring 
packets to the known destination is down or was shut 
down.  In this case, the router sends "going down" 
broadcasts from which all routers update their routing 
tables to remove any routes that are no longer 
available.

No Space for the Service - this is the number of times 
(since the bridge was initialized) that the bridge has 
received Internetwork packets that it could not 
accommodate because the router did not have enough 
space in its DGroup area to copy the packets.  These 
packets are lost.

This condition can be an indication of network overload 
or the server may be too slow to process the amount of 
data on a growing network.  Monitoring the network 
bandwidth utilization using Analyst can help clarify this 
situation.  In either case, if the condition persists and 
has an adverse effect on network performance, it may 
be necessary to add a server to split the network load 
between them, upgrade the server system with a faster 
CPU or more RAM, or reconfigure stations and servers 
via segmentation of the wire to provide a more even 
load on the bridges and servers.

No Receive Buffers - this is the number of times (since 
the bridge was initialized) that the bridge could not 
receive inbound packets because of inadequate buffer 
space.  These packets are lost.

This condition is essentially similar to the previous one 
except that the error occurs at an earlier stage of 
packet processing and indicates either too few receive 
buffers or a network (as opposed to server or bridge) 
that is overloaded.  Again a more definite answer can 
be obtained by monitoring long and short term 
bandwidth utilization using Analyst.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Volume Usage (server)

The Volume Usage chart displays used and free 
volume space on a server (separately by each available 
volume). If the number of volumes is larger than will fit 
in the information window area, use the scroll bar to 
move along the volume listing.  This is useful for 
checking remotely how much free disk space remains 
on a server volume and allows you to take appropriate 
actions when any of the volumes reach critical usage.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Options

A user can customize the charts display by selecting 
the Options button in the SERVER information window 
and then choosing 2D or 3D, Colors, Timing, and Scale 
options from the Charts menu.

Under 2D the choices are Lines, Columns and Pie 
charts.  Under 3D, the choices are Lines, Separate 
Columns, Alternate columns.

The Colors dialog lets customize colors for every chart 
separately.  You can have a different chart type and set 
of colors for Open File and for IPX Packet Statistics, 
and for Volume usage, etc.

The Timing dialog allows you to set timing periods for 
each chart separately.  You can also set one common 
timing value for all Lists. 

The Scale dialog lets change the vertical scale of a 
chart to best fit your system parameters.  The best way 
to understand this dialog is to experiment with it.

Lists

Lists are updateable tables of information about 
servers. The update period is set in "Options"-> 
"Timing" menu.

The SERVER information window List menu has the 
following choices:

IPX Packet Statistics List (server)

The IPX Packet Statistics List shows a summary of  IPX 
traffic since the Novell server was booted.  It includes:

Send Packet Count - the total number of IPX packets 
sent.

Malformed Packets - the number of times (since IPX 
was loaded) that applications have passed malformed 
packets to IPX.  A packet is malformed if the value in its 
ECB's fragment count field is 0 or if the value of the 
size field within ECB's first fragment descriptor is less 
than 30 bytes.  This can be due to malfunctioning of 
one of the NLMs.

Get ECB Request Count - the number of times (since 
IPX was loaded) that IPX has supplied Receive ECBs 
for incoming packets.  Event Control Blocks (ECB) 
should be provided for every incoming packet in order 
to process it.  This count does not indicate an error 
condition.

Get ECB Failure Count - the number of packets the 
driver has received for which there was no available 
ECB.  In a network or server overload condition there 
can be no ECBs available and packets may be lost.

AES Event Count - the number of times (since IPX 
was loaded) that IPX has used the AES to schedule an 
event.

Asynchronous Event Service (AES) is called when the 
stack is not able to keep up with the processing of 
network traffic and must schedule a send or receive 
event to happen later (usually a few milliseconds later).

Postponed AES Events - the number of times (since 
IPX was loaded) that IPX has been unable to service an 
AES event on time.  This can be due to a MLID being in 
a critical section.  For example, IPX cannot send an 
outgoing packet to an ECB that is busy with another 
packet.  In this case, the AES must be postponed to 
happen at a later time.  If the number of Postponed 
AES Events is high, it can be an indication of high 
network or processing load on the server and may 
indicate that it is time to upgrade all or parts of the 
server (CPU, memory, disk access time, etc.).

Max Configured Sockets - the maximum number of 
open sockets possible on the target server.

Max Opened Sockets - the maximum number of 
sockets open simultaneously since IPX was loaded.  
This should not exceed 75% of the Max Configured 
Sockets.

Open Socket Failures - the number of times (since 
IPX was loaded) that applications have unsuccessfully 
called IPXOpenSocket.  IPX cannot open a socket if the 
socket table is full or if the socket is already open.  If 
this number is greater than 0, you will need to tune your 
server to accommodate more sockets.

Listen ECB Count - the number of times (since IPX 
was loaded) that applications have given IPX a Listen 
ECB.

A Listen ECB is given when a Netware application 
expects to receive a packet associated with a specific 
socket (usually a reply to a "just sent command" or 
reques).  Neither a low or high value is an indication of 
a failure condition.

ECB Cancel Failures - the number of times (since IPX 
was loaded) that IPX has been unable to cancel an 
ECB.  For example, IPX cannot cancel an ECB if the 
driver and the ECB have entered a critical section just 
prior to sending a packet.  In this case, the cancellation 
is too late and would be flagged as an ECB Cancel 
Failure.

Find Route Failures - the number of times (since IPX 
was loaded) that IPX has been unable to find a route to 
a requested network address.

This error may appear if a router that was transferring 
packets to the known destination was shut down.  In 
this case the router sends "going down" broadcasts 
from which all routers update their routing tables and 
remove any routes not longer available.
SPX Packet Statistics List (server)
The SPX Packet Statistics List displays a summary of 
the SPX traffic since the Novell server was booted.  It 
includes:

Max Connections - the maximum number of SPX 
connections possible on the target server.

Max Used Connections - the maximum number of 
SPX connections open simultaneously since IPX was 
loaded.

Establish Connection Requests - the number of times 
(since SPX was loaded) that applications have called 
SPXEstablishConnection.  This call attempts to contact 
a partner to establish a session.

Establish Connection Failure - the number of times 
(since SPX was loaded) that SPXEstablishConnection 
calls failed because the SPX Packet Header was too 
small, the SPX Connection Table was full, no router 
was found to the target network, or the target node was 
down.

Listen Connections Requests - the number of times 
(since SPX was loaded) that applications have called 
SPXListenForConnection.  This call is issued by a 
Netware application that instructed SPX to watch for a 
connection request from a peer system.

Listen Connection Failure - the number of times 
(since SPX was loaded) that SPXListenForConnection 
calls failed because the SPX Connection Table was full. 
This is an indication that the total number of available 
SPX connections on the server is not adequate for 
current network activity.

Send Packet Count - the number of times (since SPX 
was loaded) that applications tried to send a SPX 
packet.  This number is a sum of all send packet 
attempts, successful and not successful.

Window Choke Count - the number of times (since 
SPX was loaded) that SPX failed to send a packet 
because the target station had not allocated a receive 
buffer.  This is an indication of high load on the target 
station.  This statistic does not show the station 
responsible.  If necessary, the station responsible can 
be identified using Analyst in Packet Capture mode or 
Protocol Statistics mode.

Bad Send Packets Count - the number of times (since 
SPX was loaded) that SPXSendSequencedPacket was 
incorrectly called by passing an invalid connection ID or 
by passing the address of an ECB - indicating a packet 
header size of less than 42 bytes.  This can indicate a 
malfunctioning SPX application.  In this case the 
connection to the target station is aborted.

Send Failure Count - the number of times (since SPX 
was loaded) that SPX was unable to send a packet 
across a connection and receive acknowledgment.

This can happen when a remote peer closes a 
connection without acknowledging the SPX packet.  In 
this case there is no guarantee that the packet was 
received.  Other causes can be a connection closed 
abnormally (frozen or a rebooted station).

In such a case, SPX aborts the connection and informs 
the calling application.

Abort Connection Count - the number of times (since 
SPX was loaded) that SPXAbortConnection has been  
called.

This event is initialized when some catastrophic 
condition occurs (from the point of view of the 
application that is using this connection).  This could be 
an indication of a malfunctioning NLM application.  In 
this case the connection is terminated unilaterally by the 
current application without notifying the other machine.  
The partner discovers the broken connection when it 
tries to send a packet to the application (getting Send 
Failure error, see above) or when the WatchDog 
checks the connection after the inactivity time expires.

Listen Packet Count - the number of times (since SPX 
was loaded) that applications gave Listen ECBs to SPX.  
Listen ECB is given when a Netware application 
expects to receive a packet associated with a specific 
socket (usually a reply to a just sent command or 
reques).  Neither a high or low value is any indication of 
an error condition.  There is no limitation on the number 
of Listen ECBs which should be provided by a Netware 
application.

Bad Listen Packet Count - the number of times (since 
SPX was loaded) that applications passed SPX a 
packet whose associated ECB is malformed.  An ECB 
is malformed if the value in Fragment Count is 0, if the 
value in its first Fragment Descriptor Size is less than 
42, or if the listen socket is not open.  

Incoming Packets - the number of times (since SPX 
was loaded) that the node's driver gave an incoming 
packet to SPX.

Bad Incoming Packets - the number of times (since 
SPX was loaded) that SPX received and discarded a 
packet because the connection ID in the packet was 
wrong.

Suppressed Packet Count - the number of times 
(since SPX was loaded) that SPX discarded inbound 
packets because they were duplicates of previously 
received packets.  This condition indicates the sending 
station has not received an acknowledgment for a sent 
packet (due to delay or collision).  It may indirectly 
indicate high network utilization.  Analyst will help 
determine if this is the case.

No Session Listen ECB Count - the number of times 
(since SPX was loaded) that SPX was forced to discard 
an inbound SPXEstablishConnection packet because 
SPX lacked a corresponding SPX Listen For 
Connection ECB.

WatchDog Destroy Sessions - the number of times 
(since SPX was loaded) that WatchDog destroyed a 
connection because the connection was no longer valid.  
WatchDog packets are sent periodically if no packets 
are received from a peer within 5 minutes.  If there is no 
WatchDog reply, the station repeats WatchDog request 
ten times in one minute intervals, after which the 
connection is considered invalid.
Total Packet Statistics (server)
The Total Packet Statistics List includes the following 
entries:

Driver Version the LAN driver version for the specified 
LAN board.

Statistics Version - the major and minor version 
number of the Driver Diagnostic Table.

Total Sent Packets - the number of packets the driver 
has successfully transmitted since the last driver reset 
or initialization.

Total Received Packets - the number of packets the 
driver has successfully received and passed into the 
system since the last reset or initialization.

No ECB Available Count - the number of packets the 
driver has received (since the last reset or initialization) 
for which there was no listening ECB.  In a server 
overload condition, there may be no ECBs available 
and packets may be lost.

Packet Too Big for Send - the number of times (since 
the last reset or initialization) that applications have 
asked the driver to send a packet over the maximum 
legal size.  This can indicate improper functioning or 
configuration of an application.

Packet Too Small for Send - the number of times 
(since the last reset or initialization) that applications 
have asked the driver to send a packet under the 
minimum legal size.  This can indicate improper 
functioning or configuration of an application.

Receive Packet Overflow - the number of times (since 
the last reset or initialization) the driver has received a 
packet larger than the buffer space allocated for the 
packet.  When a packet is received, the protocol stack 
that accepted the packet provides a set of buffers into 
which the packet should be dispersed.  If there is not 
enough buffer space or if for any reason the protocol 
stack has allocated a smaller buffer, this error occurs.

Received Packet Too Big - the number of times (since 
the last reset or initialization) the driver has received a 
packet over the maximum legal size.  This may indicate 
an error in the packet header due to a collision or due 
to a malfunction by the sending application.

Received Packet Too Small - the number of times 
(since the last reset or initialization) the driver has 
received a packet under the maximum legal size.  This 
may indicate an error in the packet header due to a 
collision or malfunction by the sending application.

Transmit Misc. Errors - the number of miscellaneous 
errors preventing the driver from transmitting a packet.

Receive Misc. Errors - the number of miscellaneous 
errors preventing the driver from receiving a packet.

Send Retry Count - the number of times (since the last 
reset or initialization) the driver resent a packet.  For  
example, when the driver detects a collision or does not 
receive a confirmation on a sent packet, the driver re-
sends a packet.  If significant, this number can indicate 
high network bandwidth utilization.  Use Analyst to 
check this assumption.

Checksum Error Count - the number of checksum 
errors occurring while receiving packets (since the last 
reset or initialization).  High checksum errors can 
indicate bad cabling or a bad hub.

Receive Hardware Mismatch - the number of times 
(since the last reset or initialization) the hardware has 
received more or fewer bytes than expected.
Bridge Statistics List (server)
Novell refers to the "Bridge" as the physical LAN board 
in your server.

Bridge Statistics List includes the following values:

Total Packets Routed - the total number of packets 
the router actually routed.

Too Many Hops - this is too many hops for the packet 
(that reached the current server) to reach it's 
destination.  It is the number of times (since the bridge 
was initialized) the bridge received packets on the 
fifteenth hop across an Internetwork bridge.  These 
packets are discarded. 

Hop is the transition of a packet on its way to a 
destination server or station from another server or 
station.  The above error may indicate that the routing 
scheme used on the network is inadequate or possibly 
that the server which was servicing a more direct 
connection path is currently down or out of order.  The 
situation may require the network administrators 
intervention.  This error will occur on larger sites with 
many nets and bridges, or on sites experiencing an 
"infinite loop" between routers or server.

Unknown Network - these are packets that have 
reached the server can not be routed because the 
destination network is unknown to the server.

This error may appear if a router that was transferring 
packets to the known destination was shut down.  In 
this case, the router sends "going down" broadcasts 
upon which all routers update their routing tables and 
remove the unavailable routes.

No Space for the Service - the number of times (since 
the bridge was initialized) that the bridge has received 
Internetwork packets that it could not accommodate 
because the router did not have enough space in its 
DGroup area to copy the packets.  These packets are 
lost.

This condition can be an indication of network overload 
or of a server which may be too slow to process amount 
of data on a growing network.  Monitoring the network 
bandwidth utilization using Analyst can help clarify this 
situation.  In either case, if the condition persists and 
has an adverse effect on network performance, there 
may be a need add a server and split the network load, 
upgrade the server system with a faster CPU or more 
RAM, or reconfigure stations and servers via 
segmentation of the wire providing a more even load on 
the bridges and servers.

No Receive Buffers - the number of times (since the 
bridge was initialized) that the bridge could not receive 
inbound packets because of inadequate buffer space.  
These packets are lost.

This condition is similar to the previous one, with the 
exception that the error occurs at a earlier stage of 
packet processing.  This indicates that there is either 
too few buffers, or network (as opposed to server or 
bridge) overload.  Again, a more definite answer can be 
obtained by monitoring long and short term network 
utilization using Analyst.

Not My Network - the number of incoming packets with 
a destination other than LAN A.  This statistic shows all 
the packets that are routed through the current LAN.

NetBIOS Propagate - the number of times the bridge 
received NetBIOS broadcasts since it was initialized.

Volume Information List (server)

The Volume Information List provides information about 
available disk space on the server volumes.  It includes 
total and free disk space and total and free directory 
entries for each volume.  It can be used to check 
remotely the amount of free disk space remaining on a 
server volume and take appropriate action when any of 
the volumes reach critical usage.
Open Files List (server)
The Open Files List displays the number of files 
currently open.  This list shows the total number of files 
open on a server and the number of files opened by 
each user attached to the server.

Info:

Info menus consist of version and other constant 
information that does not need updating on the server.  
The Info menu consists of:

Server Version (server)

The Server version provides an extensive list of 
versions of the Novell server and miscellaneous utilities 
and services, as well as maximum number of 
connections, current connections and maximum 
number of available volumes.

IPX-SPX Versions (server)

The IPX-SPX version display contains the specific IPX 
and SPX version numbers of the server's IPX/SPX 
drivers (not of the node or operating system).

Bridge Driver Configuration (server)

This displays the logical LAN board driver in your 
server.  This is how Novell describes the actual 
loadable card driver for each FRAME.  With respect to 
the Bridge Driver, each value is:

Max Data Size - the maximum size of a packet's data 
portion for the target driver.  The data portion's 
maximum size is always 64 bytes less than the packet 
size advertised with the LAN board.  (The packet 
header and control information require 64 bytes).

Transport times (ticks) - the value indicating the 
speed of the LAN associated with the target driver and 
board.  Speed is measured by the amount of time it 
takes a 576-byte packet to travel from one node on the 
LAN to another node.  Time is measured in units of 
1/18 second and is rounded to the next highest 1/18.

Shell Version - the major and minor versions of the 
driver release.  This does not identify the installed 
Netware version.

Description - the LAN hardware currently connected to 
the driver.

I/O Address - the I/O address block to be decoded by 
the LAN board with which the driver is associated.  If 
the board uses a second I/O address, this field will also 
be present in the list (if it uses I/O).

RAM Address - the memory address block to be 
decoded by the LAN board (if it uses shared memory).

DMA Line - the DMA line used by the LAN board (if it 
uses DMA),

Selected Line - the value indicating which hardware 
configuration in the Hardware Configuration Table the 
driver is using,

LAN hardware ID - the value that is hard-coded into 
the Master Configuration Table.  This uniquely identifies 
the LAN hardware.  (i.e. the OEM/Driver Support Group 
Manager that Novell assigns this ID)

Note: Not all fields listed here will be available with 
different versions of Novell servers and drivers.


NODE INFORMATION WINDOWS

A NODE information window is displayed in the 
information area after a user clicks on the RIGHT 
mouse button on a node icon in the List of Nodes.  
NODE information windows (which are very similar to 
SERVER information windows) consist of a button bar 
with Charts, Lists, Info, Options popdown menu 
buttons, and an Exit button.

Button bar buttons can be selected by using mouse 
clicks and in most cases by pressing a letter on the 
keyboard that corresponds to the one displayed in red 
on the button. (Note: Due to the nature of the MDI 
interface, you DO NOT use ALT when accessing the 
information window buttons.  Use ALT-KEY 
combination to popdown menus on the Main MDI  
window).

Context-sensitive help is available from any window by 
pressing F1.

Charts

The NODE information window Charts menu has the 
following choices (sample charts are displayed in the 

"Information Windows" (general) section):

IPX Packet Statistics chart (node)
The IPX statistics chart displays the number of sent and 
received IPX packets as a function of time.  It shows 
the node's IPX packet flow activity.

Malformed packets for send and Get ECB (Event 
Control Block) for receive are a sum of several failure 
conditions and can indicate, if significant, improper 
functioning or overload of the server or node.  More 
detailed information can be seen in the IPX Statistics 
List.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

SPX Packet Statistics chart (node)

The SPX statistics chart displays the number of sent 
and received SPX packets as a function of time.  It 
shows the node's IPX packet flow activity.

Bad Send Packets for send and Get Bad Receive 
Packets receive are a sum of several failure conditions 
and can indicate, if significant, improper functioning or 
overload of the server or node.  More detailed 
information can be seen in the SPX Statistics List.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Total Node Packets chart (node)

The Total Packet Statistics chart displays the total 
number of packets (all protocols) sent and received by 
a node as a function of time.  It allows you to see 
node's total network activity.

Bad Send Packets for send and Get Bad Receive 

Packets receive are a sum of several failure conditions 
and can indicate, if significant, improper functioning or 
overload of the node drivers.  More detailed information 
can be seen in Bridge Driver Statistics List.

This chart can be saved to a file in spreadsheet format 
("File"-> "Save Chart in Spreadsheet Format") or the 
current view of the chart can be copied to the clipboard 
to be used by an image editor (i.e. Paintbrush).

Options

A user can customize the charts display by selecting 
the Options button in the NODE information window 
and then choosing 2D or 3D, Colors, Timing, and Scale 
options from the Charts menu.

Under 2D the choices are Lines, Columns and Pie 
charts.  Under 3D, the choices are Lines, Separate 
Columns, Alternate columns.

The Colors dialog lets customize colors for every chart 
separately.  You can have a different chart type and set 
of colors for Open File and for IPX Packet Statistics, 
and for Volume usage, etc.

The Timing dialog allows you to set timing periods for 
each chart separately.  You can also set one common 
timing value for all Lists. 

The Scale dialog lets change the vertical scale of a 
chart to best fit your system parameters.  The best way 
to understand this dialog is to experiment with it.

Lists

Lists are updateable tables of information about nodes 
or servers. The update period is set in "Options" -> 
"Timing" menu.  The NODE information window List 
menu has the following choices:

IPX Packet Statistics List (node)

The IPX Packet Statistics List shows a summary of IPX 
traffic since the node's IPX/SPX shell was loaded.  It 
includes:

Send Packet Count - the total number of sent IPX 
packets.

Malformed Packets - the number of times (since IPX 
was loaded) that applications have passed malformed 
packets to IPX.  A packet is malformed if the value in its 
ECB's fragment count field is 0 or if the value of the 
size field within ECB's first fragment descriptor is less 
than 30 bytes.  This can be due to malfunctioning of 
one of the NLMs.

Get ECB Request Count - the number of times (since 
IPX was loaded) that IPX has supplied Receive ECBs 
for incoming packets.  Event Control Block (ECB) 
should be provided for every incoming packet in order 
to process the packet.  This count does not indicate an 
error condition.

Get ECB Failure Count - the number of packets the 
driver has received for which there was no available 
ECB.

If the nodes shell does not provide enough ECBs, 
(usually in high transfer rate conditions), no ECBs 
available will result in a failure to receive or send 
packets.

Many things can cause this count to rise including a 
slow network card in a fast system or a network card 
with I/O or memory conflicts.

AES Event Count - the number of times (since IPX 
was loaded) that IPX has used the AES to schedule an 
event.

Asynchronous Event Service is called when the stack is 
not able to keep up with the processing of network 
traffic and must schedule a send or receive event to 
occur at later time (usually within a few milliseconds).

Postponed AES Events - the number of times (since 
IPX was loaded) that IPX has been unable to service an 
AES event on time.  This can be due to MLID being in a 
critical section.  For example, IPX cannot send an 
outgoing packet to an ECB which is busy with another 
packet.  In this case, the AES must be postponed to 
happen at a later time.  If the number of Postponed 
AES Events is high, it can be an indication that the 
stations network or processing load is to high.

Max Configured Sockets - the maximum number of 
open sockets possible on the target station.

Max Opened Sockets - the maximum number of 
sockets open simultaneously since IPX was loaded.

Open Socket Failures - the number of times (since 
IPX was loaded) that applications have unsuccessfully 
called IPXOpenSocket.  IPX cannot open a socket if the 
socket table is full or if the specific socket is already 
open.

Listen ECB Count - the number of times (since IPX 
was loaded) that applications have given IPX a Listen 
ECB.

A listen ECB is given when a Netware application 
expects to receive a packet associated with a specific 
socket (usually a reply to a "just sent command" or 
reques).  Neither a low or high value is an indication of 
a failure condition.

ECB Cancel Failures - the number of times (since IPX 
was loaded) that IPX has been unable to cancel an 
ECB.  For example, IPX cannot cancel an ECB if the 
driver and the ECB have entered a critical section just 
prior to sending a packet.  In this case, the cancellation 
is too late and the packet is lost.

Find Route Failures - the number of times (since IPX 
was loaded) that IPX has been unable to find a route to 
a requested network address.

This error may appear if a router which was transferring 
packets to the known destination was shut down.  In 
this case the router sends "going down" broadcasts 
upon which all routers update their routing tables and 
remove any routes that are no longer available.

SPX Packet Statistics List (node)

The SPX Packet Statistics List shows a summary of 
SPX traffic since the node loaded IPX/SPX.  It includes:

Max Connections - the maximum number of SPX 
connections possible on the target node.

Max Used Connections - the maximum number of 
SPX connections open simultaneously since IPX was 
loaded.

Establish Connection Requests - the number of times 
(since SPX was loaded) that applications called 
SPXEstablishConnection.  This call attempts to contact 
a partner to establish a communication session.

Establish Connection Failure - the number of times 
(since SPX was loaded) that SPXEstablishConnection 
calls failed because the SPX Packet Header was too 
small, the SPX Connection Table was full, or no router 
was found to the target network. 
SPXEstablishConnection can also fail if the target node 
is down.

Listen Connections Requests - the number of times 
(since SPX was loaded) that applications called 
SPXListenForConnection.  This call is issued by a 
Netware application to instruct SPX to watch for a 
connection request from a peer system.

Listen Connection Failure - the number of times 
(since SPX was loaded) that SPXListenForConnection 
calls failed because the SPX Connection Table was full.

This is an indication that the total number of available 
SPX connections on the node is not adequate for 
current network activity.  This value is set in the 
NET.CFG file.

Send Packet Count - the number of times (since SPX 
was loaded) that applications tried to send a SPX 
packet.  This number is a sum of all send packet 
attempts - successful and not successful.

Window Choke Count - the number of times (since 
SPX was loaded) that SPX failed to send a packet 
because the target station had not allocated a receive 
buffer.  This is an indication of high load on the target 
station.  This statistic does not show the station 
responsible.  If that information is necessary, the station 
can be determined using Analyst in Packet Capture 
mode or Protocol Statistics mode.

Bad Send Packets Count - the number of times (since 
SPX was loaded) that SPXSendSequencedPacket was 
incorrectly called by passing an invalid connection ID or 
by passing the address of an ECB indicating a packet 
header size of less than 42 bytes.  This can indicate a 
malfunctioning SPX application.  In this situation the 
connection to the target station is aborted.

Send Failure Count - the number of times (since SPX 
was loaded) that SPX was unable to send a packet 
across an SPX connection and receive 
acknowledgment.  This happens when a remote peer 
closes the connection without acknowledging the 
packet.  In this situation there is no guarantee that the 
packet was received.  A connection that closed 
abnormally may be caused by a frozen or rebooted 
station.

In such a case, SPX aborts the connection and informs 
the calling application.

Abort Connection Count - the number of times (since 
SPX was loaded) that SPXAbortConnection was called.

This event is initialized when some catastrophic 
condition (from the point of view of application that is 
using this connection) occurs.  This can be an 
indication of malfunctioning NLM application.

In this case, the connection is terminated unilaterally by 
the current application without notifying the other 
machine.  The partner discovers the broken connection 
when it tries to send a packet to this application (getting 
Send Failure error, see above)  or when the WatchDog 
checks the connection after the inactivity time expires.

Listen Packet Count - the number of times (since SPX 
was loaded) that applications gave listen ECBs to SPX.  
Listen ECB is given when a Netware application 
expects to receive a packet associated with a specific 
socket (usually a reply to a "just sent" command or a 
"reque").

This value is a count and does not indicate an error 
condition.  There is no limit on the number of Listen 
ECBs that should be provided by a Netware application.

Bad Listen Packet Count - the number of times (since 
SPX was loaded) that applications passed SPX a 
packet whose associated ECB is malformed.  An ECB 
is malformed if the value in Fragment Count is 0, if the 
value in its first Fragment Descriptor Size is less than 
42, or if the listen socket is not open.

Incoming Packets - the number of times (since SPX 
was loaded) that the node's driver gave an incoming 
packet to SPX.  This value is a count and does not 
indicate an error condition.

Bad Incoming Packets - the number of times (since 
SPX was loaded) that SPX received and discarded a 
packet because the connection ID in the packet was 
wrong.

Suppressed Packet Count - the number of times 
(since SPX was loaded) that SPX discarded inbound 
packets because they were duplicates of previously 
received packets.  This condition indicates that the 
sending station has not received an acknowledgment 
for a sent packet (due to delay or collision).  It may 
indirectly indicate high network utilization.  Analyst will 
help to determine if this is the case.

No Session Listen ECB Count - the number of times 
(since SPX was loaded) that SPX was forced to discard 
an inbound SPXEstablishConnection packet because 
SPX lacked a corresponding SPXListenForConnection 
ECB.

WatchDog Destroy Sessions - the number of times 
(since SPX was loaded) that WatchDog destroyed a 
connection because the connection was no longer valid.  
A WatchDog packet is sent periodically if no packets 
are received from a peer in 5 minutes.  If there is no 
WatchDog reply, the station repeats the WatchDog 
request ten times in one minute intervals after which the 
connection is considered invalid.
Shell Driver Statistics List (node)
The Shell Driver Statistics List includes the following 
entries specific to the node:

Driver Version - the LAN driver version for the 
specified LAN board.

Statistics Version - the major and minor version 
number of the Driver Diagnostic Table.

Total Sent Packets - the number of packets the driver 
has successfully transmitted since the last driver reset 
or initialization.

Total Received Packets - the number of packets the 
driver has successfully received and passed to the 
system since the last reset or initialization.

No ECB Available Count - the number of packets that 
the driver has received (since the last reset or 
initialization) for which there was no listening ECB.  In a 
CPU overload condition there can be no ECB available, 
and packets may be lost.

Packet Too Big for Send - the number of times (since 
the last reset or initialization) that applications have 
asked the driver to send a packet over the maximum 
legal size.  This can indicate improper functioning or 
configuration of an application.

Packet Too Small for Send - the number of times 
(since the last reset or initialization) that applications 
have asked the driver to send a packet under the 
minimum legal size.  This can indicate improper 
functioning or configuration of an application.

Receive Packet Overflow - the number of times (since 
the last reset or initialization) the driver has received a 
packet larger than the buffer space allocated for the 
packet.  When a packet is received, the protocol stack 
that accepted it provides a set of buffers into which the 
packet should be dispersed.  If there is not enough 
buffer space for any reason or the protocol stack 
allocated a smaller buffer, this error occurs.

Received Packet Too Big - the number of times (since 
the last reset or initialization) the driver has received a 
packet over the maximum legal size.  It may indicate an 
error in the packet header due to a collision or a 
malfunctioning sending application.

Received Packet Too Small - the number of times 
(since the last reset or initialization) the driver has 
received a packet under the maximum legal size.  This 
may indicate an error in the packet header due to a 
collision or a malfunctioning sending application.

Transmit Misc. Errors - the number of miscellaneous 
errors preventing the driver from transmitting a packet.

Receive Misc. Errors - the number of miscellaneous 
errors preventing the driver from receiving a packet.

Send Retry Count - the number of times (since the last 
reset or initialization) the driver resent a packet.  For  
example, when the driver detects a collision or does not 
receive a confirmation on a sent packet, the driver re-
sends a packet.  If significant, this number can indicate 
high network bandwidth utilization.  Use Analyst to 
check this assumption.

Checksum Error Count - the number of checksum 
errors occurring while receiving packets (since the last 
reset or initialization).  If this value is high, this can be 
an indication of bad cabling or a bad hub port.

Receive Hardware Mismatch - the number of times 
(since the last reset or initialization) the hardware has 
received more or fewer bytes than expected.
Shell Statistics List (node)
Shell Statistics List includes the following values:

Shell Requests - the number of times (since the shell 
was activated) that the shell has made request to a file 
server.

Operator Aborts - the number of times (since the shell 
was activated) that the user has aborted the shell-
server connection by entering "A" in reply to a "Network 
Error" message.

Operator Retries - the number of times (since the shell 
was activated) that the user has instructed the shell to 
retry an operation.

Time-outs - the number of times (since the shell was 
activated) that the shell has sent a request to a server 
and then timed out without receiving a reply.  (Normally, 
the shell sends another request packet.)

Write Errors - the number of times (since the shell was 
activated) the driver has been unable to send a request 
to a file server (after repeated retries).  In this case, the 
shell displays the message "Error writing to network" on 
the workstation screen.  The shell does not increment 
this counter if, after repeated retries, the driver is able 
to send the request.

Invalid Reply Headers - the number of times (since the 
shell was activated) that the shell has received a reply 
packet header whose Checksum was -1 or whose 
PacketType indicated the packet was not a file server 
reply.

Invalid Slot Count - the number of times (since the 
shell was activated) that the shell has received a file 
server reply packet specifying an incorrect connection 
ID.

Invalid Sequence Number - the number of times 
(since the shell was activated) that the shell received a 
file server reply packet specifying an incorrect 
sequence number.  It usually indicates the reply was 
unnecessary.

Errors Receiving - the number of times (since the shell 
was activated) that IPX has indicated an error even 
though a packet was received on the socket.  It usually 
indicates an "Overrun" error.

No Router Found - the number of times (since the 
shell was activated) that the shell tried and failed to find 
a route to a destination node.  The shell attempts to 
reroute a packet when a connection seems to fail and 
the user requests a "Retry.".

Being Processed - the number of times (since the 
shell was activated) that the shell received a "being 
processed" reply from a file server.  A file server sends 
this reply to a shell when the server, while processing 
the shell's request, receives duplicate requests from the 
shell for the same service.

Unknown Errors - the number of times (since the shell 
was activated) that the shell received a packet 
containing an undefined error value.

Invalid Server Slot - the number of times the shell 
attempted to communicate on a particular client 
connection number and the server indicated the 
connection number is invalid.

Network Gone Count - the number of times (since the 
shell was activated) that the shell received a packet 
from a file server indicating the target network has gone 
away.  Only a 68000 file server can generate this kind 
of packet.

Allocate Can Not Find Route - the number of times 
(since the shell was activated) that the shell, asked by 
an application to establish a connection with a file 
server, could not find a route to the destination.

Allocate No Slots Available - the number of times 
(since the shell was activated) that the shell, asked by 
an application to establish a connection with a file 
server, could not establish the connection because the 
file server's connection table was full.

Allocate Server Is Down - the number of times (since 
the shell was activated) that the shell, asked by an 
application to establish a connection with a file server, 
could not establish the connection because the target 
file server was down.

Info:

Info menus consist of version and other constant 
information that does not need updating over time on a 
node.  The Info menu consists of:
OS Version Information (node)
OS Version Information of a node includes:

Machine type - type of the computer on which the shell 
is running

Operating System - for example, MS DOS 6.22

Shell Version - The IPX/SPX shell version number

IPX-SPX Versions (node)

The IPX/SPX versions list shows the IPX and SPX 
version numbers of the nodes IPX/SPX driver (not the 
shell version number).

Shell Driver Configuration (node)

Information regarding the board driver on the node (i.e. 
the ODI or IPX driver):

Max Data Size - the maximum size of a packet's data 
portion for the target driver.  The data portion's 
maximum size is always 64 bytes less than the packet 
size advertised with the LAN board.  (The packet 
header and control information require 64 bytes.)

Transport times (ticks) - the value indicating the 
speed of the LAN associated with the target driver and 
board.  Speed is measured by the amount of time it 
takes for a 576-byte packet to travel from one node on 
the LAN to another node.  Time is measured in units of 
1/18 second and is rounded to the next highest 1/18.

Shell Version - the major and minor versions of the 
driver release.  This does not identify the installed 
Netware version.

Description - displays the LAN hardware currently 
connected to the IPX/SPX driver.

I/O Address - the I/O address block to be decoded by 
the LAN board or the driver.

RAM Address - the memory address to be decoded by 
the LAN board (if it uses shared memory).

DMA Line - the value of the DMA line used by the LAN 
board (if it uses DMA).

Interrupt Lines - value of the interrupt used by the LAN 
board.

Selected Configuration - the value indicating which 
hardware configuration in the Hardware Configuration 
Table the driver is using.  This value ranges from 0 to n 
or -1,  where n is the maximum number of 
configurations supported by the driver and -1 means no 
value (and is not displayed by Discoverer).

Note: Not all fields listed here are available with 
different versions of Novell servers and drivers.
User Volume Information (node)
The User Volume Information list provides information 
about space restrictions for a specific user, numbers of 
used directories, files, and bytes.

Note:  Because the server has to check all volumes 
and file systems to collect this information, obtaining 
this information can take considerable period of time 
(up to a few minutes).


REFERENCE

A SHORT OVERVIEW OF TCP/IP FOR TROUBLESHOOTING
TCP/IP is a family of protocols designed to perform a 
wide set of network activities.

This overview will give a short description of TCP/IP 
from the prospective of packet transfer and monitoring.

While TCP/IP is the name by which we refer to this 
protocol, it is really a family of protocols based around 
the IP method of addressing.  TCP is one of the family 
of protocols included in IP.

The main components of TCP/IP are (there are 
numerous less used components):

IP - Internet Protocol,
ICMP - Internet Control Message Protocol,
TCP - Transmission Control Protocol,
UDP - User Datagram Protocol,
ARP - Address Resolution Protocol.

The descriptions here are based on a model which uses 
the term "lower" to describe the starting point of a 
packet and higher to describe deeper and deeper 
information within a packet.  The vegetable analogy 
would be an onion.  It has a skin (the lowest level) and 
many possible layers within (each one a higher layer to 
the last).

TCP/IP datagrams are transferred on top of (inside) a 
network specific frame (or packet - the most common 
are Ethernet and Token Ring) and are used in turn to 
transfer higher level specialized protocols which 
actually define the kind of activity performed on the 
network.  Some of these are: Telnet, FTP, NFS, SNMP, 
remote printing, and many others.  In other words, 
TCP/IP packets are really packets within packets.  A 
TCP/IP packet is wholly contained in a Ethernet frame 
(i.e. packet or wrapper).

In order to transfer information (i.e. a file) through the 
network, it must be divided into shorter data units that  
contain information about the source from which data 
originates, destination, length, position of the particular 
data unit in a data stream (of many units), different 
kinds of management information, routing in the case 
the datagrams have to cross one or more bridges, and 
checksums to insure that data was delivered without 
loss or alteration due to network conditions such as  
packet collisions or noise.  These units are called 
datagrams or frames.  They can be considered as a 
sequence of bytes ordered according to certain rules.

To make the process of managing packets controllable, 
protocol and datagrams produced by TCP/IP are built in 
a layered fashion.  On the lowest level (and arranged in 
stream of data at the first position) is a network specific 
frame header.  It can be different for different types of 
networks, but generally contains a destination and 
source hardware address, the size of the packet, and 
the frame type.  For example, this layer may define the 
packet as either Token Ring or Ethernet.

A network card adds a network specific preamble and 
checksum to a packet and converts the frame into a 
stream of radio frequency signals that are transmitted 
through the network wire.  On the other end, the 
receiving network card converts the radio signal back 
into a stream of characters, determines if it is to the 
addressee, and if so, transfers it to an application which 
processes it further.

Following the layered structure, everything that is 
placed after the frame header can be considered as a 
data portion of the frame.  In the same fashion, each 
higher level portion can be considered a data portion of 
the underlying one - making assembling before sending 
and then disassembling and extracting transferred data 
or a command portion of transmission as easy and as 
logical as possible.

In TCP/IP, the frame header that follows the IP header 
is either TCP, UDP, ICMP, or another higher protocol 
header.  This is followed by the data portion of the 
packet or a still higher level protocol header (i.e. RPC 
NFS on top of a UDP header).

So, for example, when you look at a packet, you might 
first see the MAC portion of the packet, followed by the 
IP portion, followed by either the TCP, UDP, etc. portion 
(depending on why the packet was formed), and then 
the data portion.

Knowledge of the basic structure of TCP/IP protocols 
will help you to determine the possible causes of 
problems on your network and will help you choose the 
appropriate actions to correct them.

IMPORTANT POINT! -> Another approach to 
deciphering a problem that occurs on a station is to try 
to find a good example of how the network 
communication SHOULD function.  For example, it may 
be helpful to capture a TCP connection or a file transfer 
that seems to work properly and then compare it to one 
received from a malfunctioning station or host.

A detailed description of TCP/IP protocols is a lengthy 
subject and there are many sources available.  
Although it could be edifying for one to learn everything 
available on the subject, many problems can be 
detected and solved with a basic understanding of the 
main TCP/IP protocols.  The next section gives a short 
overview of the most important packet structures as 
they are viewed by Analyst and a concise explanation of 
each of the labels (in View Packets) and their function.
MONITORING TCP/IP SESSIONS WITH ANALYST
The descriptions here decode each type of packet, 
starting at the beginning of the packet structure and 
moving down, layer by layer.
Ethernet Frame Header
An Ethernet frame contains a preamble and a frame 
checksum, which are added and removed by the 
Ethernet network card and are not passed to the higher 
levels.  TCP/IP on an Ethernet Network uses an 
Ethernet II type of frame.  This consists of a destination 
and a source hardware address and a frame type field.  
The hardware address field is six bytes long and 
uniquely identifies a network card on the network.

In Analysts View Packets window, the Ethernet Frame 
header is shown in two places.  First in the List of 
Packets (in the top portion of the screen), all packet are 
displayed in order of arrival from the network.  
Hardware addresses use the following notation 
(example): 80:00:00:21:D5:98,  where every number 
separated by a colon is a byte (number from 0 to 255) 
represented in a hexadecimal form.

The next field in the List of Packets is the frame type. 
For example, ARP (0806),  IP (0800), or Netware 
Ethernet II (8137).

There is a bit of inconsistency in the frame type field.  If 
the frame type is smaller than 1518, this field actually 
means the length of the packet - the frame type for all 
the packets below 1518 is called IEEE 802.3 (real 802.3 
as opposed to Novell 802.3).

Using Analysts List of Packets options

In addition to displaying hardware addresses and frame 
types, the List of Packets can show differences in time 
of arrival (and thus time sent) for the current packet and 
the previous packet.  This is called the packet delta.  To 
enable this option, select differential times option in 
"Settings" -> "View Configuration" and this entry will 
appear in the List of Packets.

All hardware addresses can be aliased to the names of 
users or any desirable text from the list of hardware 
addresses in Filters dialog.

Token Ring Frame Header

The Token Ring frame header is very close to an 
Ethernet header.  It consists of start and end delimiters 
(performing similar functions to the preamble in the 
Ethernet header).  There are two additional bit fields: 
Access Control field (AC) and Frame Control field (FC) 
- see note below for more detail on these fields.  These 
are followed by hardware destination and source 
address, which may be followed by a routing 
information field.  Because there is no frame type field, 
a Token Ring frame header is always followed by IEEE 
802.2_SNAP, or IEEE 802.2 subheader specifying the 
higher level protocol used.  TCP/IP packets are formed 
on top of the 802.2_SNAP header.

An Access Control field has the following bit fields:

Priority Bits - states the priority of a frame or a token.  
The value can range from 0 to 7.

Token Indicator - if this field is not set, the packet is a 
token not a frame.  These packets are not displayed by 
Analyst.

Monitor Count Bit - this allows the Active Monitor to 
determine whether a packet was not removed from the 
ring by the responsible station. [If it was not it does so if 
necessary.]

Priority Reservation Bit - this sets the priority of the 
packet.  Higher priority packets will be processed 
before lower priority packets.  Values range from 0-7.

The Frame Control field determines whether the frame 
is a MAC or a data frame.  It consists of the following bit 
fields:

Frame Type - this determines whether the frame is 
MAC or data.

Control Field - valid only for MAC frames, this field 
specifies the MAC control message or mode of 
processing for the following data fields. 

Hardware destination and source addresses are similar 
to Ethernet headers except that the highest bit in the 
first byte of the source address serves as a routing 
information indicator.  When this bit is set, the routing 
information field immediately follows the source 
address.  The routing field has a few subfields which 
specify if the frame is a broadcast, and if it is, what type 
of broadcast, the maximum size of the frame, the 
direction of the routing path (either originator or 
respondent), and the path itself.

IEEE 802.2 and IEEE 802.2_SNAP subheaders

These subheaders can be used as an extension of an 
Ethernet frame header (IEEE 802.2_SNAP), and are 
always used as an extension for the Token Ring frame 
header to specify the overlying protocol.

The first two fields in both subheaders are Destination 
Service Access Point (DSAP) and Source Service 
Access Point (SSAP), which denote the destination and 
the packets upper layer protocol.

For example:
If DSAP and SSAP are 0xE0, the subheader is IEEE 
802.2 (Novells Ethernet 802.2) and the protocol is IPX.

If DSAP and SSAP equal 0xAA, the subheader is IEEE 
802.2_SNAP.

Both subheaders have a control field (Netware 
protocols do not rely on this field).  This field closes the 
IEEE 802.2 subheader.  The first field in IEEE 802.2 
specifies the protocol and, because the same field in 
IEEE 802.2_SNAP specifies that this subheader is 
IEEE 802.2_SNAP, there is one more  field of this 
subheader which specifies the protocol.  Protocol 
numbers in 802.2_SNAP protocol field are the same as 
those used in an Ethernet II frame header.

Internet Addresses

When systems communicate with each other on 
Ethernet and Token Ring networks, they use 48 bit (6 
byte) hardware addresses.  Hardware addresses are 
usually assigned by the manufacturer of a network 
card.  Different manufacturers have major card 
numbers assigned, and then create unique minor card 
numbers for every card.  On most networks, there are 
network cards of different manufacturers, which creates 
quite a wide range of hardware addresses.

To make internetworking routability easier and to be 
able to assign some systematized set of addresses for 
the station on a local net and on the Internet as a 
whole, Internet addresses use 32 bit (4 byte) numbers 
instead of 6 byte hardware addresses.

Internet addresses are uniquely assigned by an Internet 
authority for every network. (This can be YOU if you are 
not connected to the Internet or THE Internet authority 
if you are connected to the Internet).

IP addresses are usually represented by four numbers 
which range from 0 to 255, each separated from the 
next by a period.  

For example:  200.200.200.18

Internet addresses can be either class A, B, C or D.  
Each determines how many machines can be on the 
local network.  A class A address can use 3 lower bytes 
as a local address (9.27.6 for an address of 
9.27.6.100), B - two bytes, C - one byte, and D are 
multicast addresses.  This allows a class A address to 
have up to 65,536 machines on the network and a class 
C only 256.  To make even finer subdivisions, subnet 
address masks can be used to assign only a part of an 
address to a network address space.

Address Resolution Protocol (ARP)

Because the IP layer uses a four byte Internet Address, 
and frame headers contain actual hardware addresses 
of the network cards receiving and sending the 
datagrams, it is necessary to find out which hardware 
address corresponds to an IP address and store this 
information in the ARP table for later use.  Address 
Resolution Protocol (ARP) serves this purpose.

If a station needs to establish a TCP connection to a 
server or peer, there are two possible scenarios:

1. If a connection was already established to the 
destination station, the hardware -to- IP address 
mapping may already be in the local ARP table.  In 
this case the station will directly proceed with 
establishing a connection using a hardware address 
from the table.

2. Otherwise, an ARP broadcast packet is sent to the 
IP address that the connection needs to be 
established with, and the station waits for a reply 
from the station in question.  This ARP packet 
contains the hard network address and the IP 
address of the sending station.  The requested 
station, if it is present on the network, sends an 
ARP reply with its hardware address as one of the 
reply fields.  The requesting station places the IP -
to- hardware correspondence in the local ARP table 
and is ready to establish connection.

An ARP message contains the following fields:

Type of Operation - indicates an ARP request or a 
ARP reply.

Source Host address - the IP address of the 
requesting host or the replying host, if the ARP 
message is a reply.

Destination Host address - the IP address of the 
requested host or the host that sent the request if this is 
a reply.

Source Hardware address and Destination 
Hardware address - the hardware addresses of the 
sending and receiving station.  If it is an ARP request, 
the destination hardware address is set to zeroes.  An 
ARP reply always contains both addresses.
Internet Protocol (IP)
The Internet Protocol Datagram is the second level of 
encapsulation after the frame level.

Encapsulation allows IP to be completely ignorant 
concerning the type of network packets that are sent. IP 
headers look the same for all networks and frame 
header+subheader combinations.  While Internet 
Protocol can be considered as a data portion of the 
frame, it in turn has as its own data portion - TCP, UDP, 
ICMP, or another higher level protocol(s).

A station can only begin to send IP packets if it has 
resolved the IP-to-hardware address mapping (see 
ARP section).

If the destination station is not on the local network and 
the datagram is transferred through a bridge or 
gateway, the layered structure allows the bridge to 
remove the frame header of the incoming frame, 
replace it with its own, and send it to the next network 
destination (which can be a different type of network) 
until it reaches the destination host.

The main function of IP is packet delivery and the 
routing of packets through Internet bridges and routers.  
IP itself does not contain any provision to make delivery 
of the packet reliable.  It delivers packets by "best effort 
attempt" through the network to their destination but IP 
has no way of knowing if the packet was lost, 
underwent a collision, or could not be received by the 
destination machine due to network congestion or 
destination machine overload.  Responsibility for taking 
care of  these kinds of problems is done by a higher 
level protocol (i.e. TCP, or an application).

An overview of the IP header structure will show the 
means by which IP tries to meet its goal.  The IP 
header has the following fields:

Source host - the Internet address of the sending 
station.

Destination host - the Internet address of the 
destination station.

Version - the version of the IP protocol that was used 
to create the datagram.  This is used to see if the IP 
header format is the same on the sending and receiving 
stations.  The current IP protocol version is 4.

IP header length - this specifies the length of the IP 
header.  Most of the fields in the IP header are fixed, 
except IP options which can be absent or of variable 
length.  If IP options are not present, IP header length 
is 20 bytes (or 5 four byte words).

Service type - this field is split into four bit fields:

Precedence - ranging from 0 (normal 
precedence) to 7 (network control).  Currently 
most hosts and gateways ignore precedence.

The next three fields are the mode of transport the 
datagram has requested:

Delay - normal or low, 
Throughput - normal or high,
Reliability - normal or high.

Total IP length - the length of IP datagram in bytes, 
including the IP header.

ID - a unique integer that identifies the datagram.  This 
is used to reassemble fragmented packets.

Fragments - this can be "Yes" or "No".  There are a 
few bit fields that give more detailed information about 
the datagram fragmentation but, for practical purposes, 
it is only important to know whether the packet is 
fragmented or not.  More detailed information about 
fragmentation is rarely needed and can be obtained by 
viewing the IP header in raw mode.

Time to live - this specifies how many hops the IP 
Datagram is allowed to perform on the Internet system.

Protocol - this specifies which higher level protocol is 
encapsulated as IP data.

Header checksum - the checksum that ensures that 
the IP header is not corrupted during transmission.

The IP header contains many fields.  If you are  
interested in only a few of them, use Analysts post-
filtering in the "Settings" -> "View Configuration" dialog.  
This allows you to select the fields which will be 
displayed.  For example, you might be interested only in 
source and destination address and protocol type.  

Transport Control Protocol (TCP)

In the same way that IP can be considered a data 
portion of network frame, the TCP portion of the 
datagram can be looked at as IP data.  TCP adds one 
more level of complexity and functionality to the TCP/IP 
protocol set.

TCP is a data stream and connection oriented protocol.  
In order to communicate, two machines must first 
establish a connection.  A unique port number is 
assigned to each connection on the two machines.  
Because there can be more than one connection 
established between two machines, using different port 
numbers provides the means to distinguish between 
connections.

While IP provides "best effort" in delivering a packet, it 
can not guarantee packet delivery or reception.  TCP 
protocol provides mechanisms to make the overall 
delivery service reliable.  This is achieved by means of 
positive acknowledgment (ACK) and retransmition.  In 
TCP, the recipient of data must send back an 
acknowledgment to the sending station about the 
received data.  If the period in which the sender expects 
to receive an acknowledgment expires, the sender will 
re-send the packet.  Sometimes for efficiency, a station 
may "piggyback" an ACK along with the next bit of data.  
This is well within the TCP/IP specification.

When analyzing a TCP data exchange, it is important to 
understand  the concept of a sliding receiving data 
window.  If the sender was waiting for an 
acknowledgment on every packet sent, the data 
exchange rate would be quite slow.  Using a sliding 
window mechanism, two systems can exchange 
information about how much data each machine can 
send and receive.  This is called the window size.  
When sending a data stream, the sender sends 
packets without waiting for acknowledgment until it 
sends enough data to fill the known receiving station 
window size.  The other side sends back 
acknowledgments as it receives data and the sending 
machine continuously updates the amount of data it can 
send.  Ideally, if no packets are lost, this mechanism 
allows transmission of large amounts of data without 
idle periods while waiting for acknowledgment.  This 
also handles the common situation with a multi-tasking 
operating system where the receiving machine may be 
too busy doing something else to immediately send an 
acknowledgment.

From a network traffic analysis perspective, this means 
that one can not expect that every packet is going to be 
immediately acknowledged.  In addition, checking the 
stream of data sequence and acknowledgment number 
patterns can help in discovering a malfunctioning TCP 
interaction.  These problems are much more common 
than most people expect.  Different TCP 
implementations react differently in certain "soft error" 
conditions.  Just because Hewlett-Packard or IBM wrote 
the host TCP software, this does not make that TCP 
infallible.  It is the job of all TCP/IPs (specifically host-
based TCP/IPs where size, speed and memory 
limitations are few) to handle and try and overcome 
error conditions.

Analyst can help to find the causes of problems that 
manifest themselves as slow transport rate or stopping 
and going during terminal sessions.  This knowledge 
can be used to tune either the host or station TCP 
software or to request from the software provider more 
specific information about the solution to the displayed 
problem.

The TCP packet header includes the following fields:

The TCP label itself, which can contain, if present in the 
TCP header, a Code field which indicates the purpose 
of the packet.  For example, it might show whether the 
packet is an acknowledgment to a received data 
stream.

Source port and Destination port - identify the port 
assigned to an application on both sides of the 
connection.  If the port number is one of well known 
origin, Analyst displays the name of service the port 
provides (i.e. telnet for port 23).

Sequence number - this identifies the position where 
the current packet should be attached in the senders 
stream of data.  If the packet contains data, the next 
sequence number will be increased by the size of the 
transferred data (provided the data was acknowledged, 
or the next packet fits into the window size).

Acknowledgment number - this indicates until which 
position the data in the receivers current packet stream 
has been acknowledged.  Or, in other words, starting 
from which position in the stream it expects data to be 
accepted.

TCP header length - this specifies the length of the 
TCP header.  Most of the fields in the TCP header are 
fixed, except TCP options, which can be absent or of 
variable length.  If the TCP option field is not present, 
the TCP header length is 20 bytes (or 5 four byte 
words).

Window - (or window size) the amount of data in bytes 
that the sender of the packet has advertised that it is 
able to receive.  Usually this is equal to the size of the 
buffer assigned by the TCP implementation to the 
current connection.

TCP data length - the length of data that follows the 
TCP header.  In most cases this is raw TCP data (i.e. 
the case of a file transfer or terminal emulation).  It can 
also be a still higher level header with its own data, 
according to the general encapsulation model.

Checksum - the TCP checksum is calculated in a 
similar way as the IP header checksum.  In the case of 
TCP segments, it includes both the header and the data 
in the calculation.  Applications use the TCP checksum 
to ensure that the TCP segment (and thus the packet) 
arrived intact.

Sequence number + data length - this is not a part of 
the TCP header.  It is provided by Analyst to give a 
administrator a convenient way to compare sequence 
and acknowledgment numbers without constantly 
adding what can be quite long sequence and data 
length numbers.  Using this value one can immediately 
know what sequence number to expect in the next 
packet if the packet was accepted (ACKed) 
successfully.

TCP options - there are three TCP options:

End of Option List, No Operation, and 
Maximum Segment Size (MSS).  The only 
important one is the Maximum Segment Size 
option.  The sender of the packet with this 
option informs the other side about the 
maximum size of the TCP/IP data buffer of the 
receiving system.  Usually the Maximum 
Segment Size TCP option appears only once 
during the initial negotiation between systems - 
although there is no restriction on using this 
more than once.

User Datagram Protocol (UDP)

UDP, like TCP, is a higher encapsulation level protocol 
of the IP protocol.

UDP uses IP to transport messages from one machine 
to another.  Unlike TCP, UDP does not provide a 
reliable mechanism for data transfer.  It does not 
require acknowledgment of received data and does not 
provide a means to control data position in transmitted 
datagrams.  Datagrams can be lost or arrive out of 
order.  However like TCP, UDP also provides multiple 
port destinations that can support multiple connections 
from one station to another.

Applications using UDP as a transport must accept full 
responsibility for making UDP a reliable communication 
process.  This includes managing potential loss of 
packets, delays, receiving duplicates of packets, etc.

Although it may sound as if UDP is an inferior protocol 
to TCP, it has its own advantages (speed, block 
transfers, etc.) and there are many protocols and 
applications using UDP.  Several good examples are 
NFS and SNMP.

UDP headers include the following fields:

Source port and Destination port - identify the port 
assigned to an application on both sides of the 
connection.  If a port is one of the well known ports, 
Analyst displays the name of service this port provides.

UDP length - the length of the UDP Datagram including 
the length of the header.

Checksum - the checksum calculated on the whole 
UDP Datagram (including the UDP header).  This value 
is optional, and if a zero is placed in the UDP header a 
checksum is not calculated.  However, using UDP 
checksum is the only way to ensure that a UDP 
datagram arrived intact, and therefore is usually 
calculated.

Internet Control Message Protocol (ICMP)

On an IP network, each bridge or gateway operates 
autonomously.  Sometimes datagrams can not be 
delivered to their destination.  Some reasons for this 
include: the destination machine is down or out of 
order, the network the system is on cannot be reached 
(permanently or temporarily), a bridge or router is down 
or disconnected, there are delays in the gateways and 
the datagrams time to live expires, a network bridge is 
overloaded and can not deliver incoming datagrams.  In 
any of these cases, some mechanism is necessary for 
delivery of the error messages.  This mechanism is 
called Internet Control Message Protocol.  ICMP is 
designed to report error conditions to the original 
source of data transmission.

ICMP messages are transferred through the network as 
the data portion of an IP datagram.  This means that 
ICMP messages themselves can be lost.  In this case, 
to avoid generation of error messages about error 
messages, new error messages about ICMP errors are 
not generated.

ICMP packets contain the following messages:

Echo reply - returns exact copy of data sent by Echo 
request.  This message has Identifier and Sequence 
number fields used to match replies with requests.  It 
can be used to test destination reachability and status 
(this is what PING uses).

Destination unreachable - this reports about an  
unreachable destination with a description of possible 
reasons for problem.

Source quench - this is sent when a datagram can not 
be accepted by a gateway or destination station 
because of a network congestion or station overload.

Redirect - if a gateway detects that a host is not using 
an optimal route to route a datagram through the 
network, a Redirect ICMP message is sent to the host.  
The original datagram is still delivered to the 
destination.

Time exceeded - sometimes a routing path has too 
many hops or an error in the routing table produces a 
circular routing cycle.  In this case, when time to live 
(hop count) reaches zero, the datagram is discarded by 
the gateway on which it happened.  This gateway sends 
an ICMP Time exceeded message to the source host 
notifying it about this condition.

This message is also sent when time-out for 
reassembling of a fragmented datagram is reached.

Parameter problem - this ICMP message is sent to the 
source host when an error occurs in a datagram.  For 
example, a gateway receives a datagram with an 
incorrect datagram header.  A pointer field indicates 
which parameter in the original Datagram is considered 
to be incorrect.

Timestamp request and Timestamp reply - used to 
synchronize clocks between machines.

Address mask request  - this is used by a machine 
that needs to receive a subnet mask for a current net.  
If the machine knows the address of a requested host, 
it can send it directly to the host.  Otherwise the 
message can be broadcasted.  Address mask reply 
serves to return a subnet mask to the requesting 
machine.


SHORT OVERVIEW OF NOVELLS IPX AND SPX PROTOCOLS

Netware uses two network communication protocols: 
IPX and SPX.  SPX has two flavors: SPX and SPX II 
which is an extended version of SPX.

In the general scheme of things, IPX and SPX can be 
considered as a data portion of the network packet 
frame, the same way that TCP/IP protocols relate to 
packet frame.  The earlier discussion of Ethernet and 
Token Ring packet frames also apply.  (For more 
information, see the sections about packet frame 
headers in the TCP/IP protocols overview).

IPX and SPX provide different types of services for the 
applications which use them.  IPX employs 
connectionless services, like TCP/IPs UDP.  SPX uses 
a connection-oriented model somewhat like the TCP 
protocol.

This means that IPX does not provide reliable data 
delivery.  Data can be lost or can be received out of 
order.  The application or protocol employing IPX must 
handle these conditions.  Being a connectionless 
protocol, IPX supports the broadcast of packets.

On the other hand, SPX and SPX II are connection-
oriented protocols.  They do not support broadcasts 
and, for two stations to send and receive data, they 
must establish connection first.  When a connection is 
established, all received data packets are 
acknowledged by the receiving station.  The next 
sections give a short overview of IPX and SPX 
protocols, packet headers, and some higher level 
protocols used by IPX - all from the prospective of 
network monitoring and analysis.

Internetwork Packet Exchange (IPX) packet header

Lets consider the structure of an IPX packet, this will 
help show the ways IPX meets its goals.  

The IPX packet header has 10 fields:

Checksum - this field is the first field of the IPX packet 
and is not usually used by Novell Netware.  This field is 
always set to 0xFFFF in Netware before 4.0, but 
starting from Netware 4.01 it can be optionally used.

Packet length - this is the length of the IPX packet, 
including the IPX header and data.

Transport control - this field shows the number of 
routers that a packet passed.  This number is set to 0 
by the source station and is increased by one by every 
bridge that is passed.  When the count reaches 16, the 
packet is discarded, limiting reachability of IPX packets 
to 15 routers.

Protocol type - this defines the protocol that a packet 
will use.  IPX uses 0 or 4.  SPX uses 5.  NCP use 17.

Destination Address - comprises two IPX header 
fields: destination network address, which is the four 
byte address of the network to which the node belongs, 
and destination node address, which is a six byte 
hardware address of the network card in the node.  If 
the destination node is a Netware server, hardware 
address is replaced by address 00-00-00-00-00-01.  
The network frame address will still contain the network 
card hardware address.  The destination address can 
be a broadcast address (the largest of all possible 
addresses, namely FF-FF_FF-FF-FF-FF).

Destination Socket - this defines the destination 
process the packet is addressed to.  Some of the main 
processes include the following which will be discussed 
later:

	Netware Core Protocol (NCP),
	Service Advertising Protocol (SAP),
	Routing Information Protocol (RIP),
	NetBIOS,
	Diagnostics,
	Serialization.

Stations use a range of socket numbers from 4000 to 
8000 hexadecimal to specify the remote or local 
process entry point numbers.

Source Address - this also comprises two IPX header 
fields: source network address and source node 
address, which are similar to destination addresses 
(see above) and define the sending nodes coordinates.

Source Socket - this field is similar to destination 
socket number.

Sequential Packet Exchange (SPX) packet header

The SPX headers first ten fields are exactly the same 
as an IPX packet headers first ten fields.

For comparison purposes, if it was defined this way, the 
SPX part of the header could be considered as a higher 
level protocol to IPX, just as UDP is for IP.  However, 
the SPX header not only has the same 10 fields as IPX, 
but it also has its own additional fields.  Lets look at the 
following seven fields additional to SPX, plus one more 
additional field of SPX II:

Connection flag - this is a one byte bit field that can 
have the following values:

System - designates a system packet (used 
internally by the server).

ACK - indicates that data was sent and an 
acknowledgment is required.

End of Message - indicates that the sending 
side wants to close the connection.

Datastream type - this is used for the end of a 
connection request and acknowledgment.

Source connection ID - this specifies the connection 
number for the source SPX.  It is used to determine the 
difference between potential multiple connections from 
the same node and to the same source socket.

Destination connection ID - this is similar to Source 
connection ID except that during the initial 
establishment of the connection, the Destination 
connection ID can be set to -1 (FFFF hexadecimal) 
since the destination is unknown at that time.

Sequence number - this is the number of packets 
transmitted from the node.  It is incremented by one 
after reception of acknowledgment from the destination 
node for the packet sent.

Acknowledgment number - this is the value of the 
sequence number expected to be received.  If a packet 
is lost and the sequence number does not reach the 
acknowledgment number before the time-out period, a 
sending node assumes that the packet was lost.

Allocation number - this is the number of available 
receive buffers on the station.  The actual number of 
buffers is equal to the allocation number plus one.

For example, a value of 0 means that one buffer is 
available.  If the station receives packets and can not 
keep up with the packet processing, the allocation 
number decreases.  As packets are processed, the 
allocation number is increased with each released 
buffer.

SPX II is an enhancement of SPX which supports 
packet sizes up to 1518 bytes (SPX can send and 
receive a maximum of 576 byte packets).  Additionally, 
while SPX requires acknowledgment for every packet,  
SPX II employs a window size mechanism similar to 
that of a TCP sliding window.

To accommodate these additions, SPX II packets 
contain one more field and, in addition, new definitions 
for connection control and datastream fields.  SPX II 
also uses an enhanced packet sequencing mechanism.

The additional values in the Connection flags field are:

Size - this allows SPX II to negotiate the size of 
the send and received packets.

SPX II packet type - this indicates that the 
packets are in fact SPX II.

Datastream type also contains two additional values: 
Orderly release request, and Orderly release 
acknowledgment.

The additional SPX II field is called Extended 
Acknowledgment.   This is for the situation where one 
station uses SPX and the other uses SPX II.  In this 
case, the SPX II station automatically switches to SPX 
during initial connection establishment.

Netware Core Protocol (NCP).

While IPX and SPX are the means for transfer of 
packets, NCP is the main communication protocol used 
by Novell Netware - as is implied by the word "Core".  
NCP is a higher level encapsulation protocol to IPX and 
SPX.  NCP controls the establishment of connections, 
opens, transfers and closes files, establishes service 
queues, and performs many other tasks.  Overall, there 
are over three hundred NCP functions.

The NCP protocol is comprised of a series of requests 
and replies.  A station sends a NCP request with a 
number of a function specified in the NCP header and 
waits for a reply, usually confirmation of the execution.

NCP headers are slightly different for requests and for 
replies.

REQUEST HEADER contains the following fields:

Request type - this field is displayed by Analyst next to 
the NCP label itself.  It specifies the type of NCP 
message and can be one of the following:

	1111	Create service connection.
	2222	Service request.
	5555	Destroy service connection.
	7777	Burst mode transfer.

When a station connects to a server it sends a Create 
service connection request.  When disconnecting, it 
sends a destroy service connection request.  The 
service request is an example of the most common field 
encountered in NCP.

The fields following the NCP header specify precisely 
what kind of request the NCP packet carries.  These 
kind of requests are:

Sequence - this field is a one byte field that keeps track 
of the sequence of commands between the station and 
server.  It is increased by one with every packet until it 
gets to 255, it then begins again at 0.

Connection - this is a service connection number that 
the server assigns to the station during the initial 
connection.

Task - this is the number of the task that is making a 
request.  It also allows the server to de-allocate specific 
resources when a task terminates.

Connection high - this is an additional connection 
number that appears only on 1000 user versions of 
Netware to keep track of the higher number 
connections.

These fields can be followed in the NCP request by the 
following fields:

Function code - the a major number of the function 
being requested.

Length - this is the length of NCP data, if present.

Sub-function code - the sub-function number of the 
major function.

For example, the function 58h has the sub-function 
codes:

Get Volume Audit Statistics (01), or
Add Audit Property (02), etc.

REPLY HEADER contains the following fields:

Reply type - this field is displayed by Analyst next to 
the NCP label.  It specifies the type of NCP reply 
message and can be one of the following:

	3333	Service reply.
	7777	Burst mode connection.
	9999	Request being processed.

Service reply - this  is the most common reply and is 
used as an answer to most requests.

During the transferring of files in burst mode, the server 
uses a Burst mode connection reply.

Request being processed appears when a server 
accepts a packet and queues it for execution, but is not 
able to process it immediately.  If the station time-out 
expires and it repeats the request, the server may reply 
again with Request being processed.

Sequence, Connection, Task, and Connection high  
fields are similar to NCP request fields and are followed 
by:

Completion code - this indicates whether the client 
request was successful.

Connection status - this indicates if the server is going 
down.  This field is usually set to 0.  When the server is 
going down, this value is set to 1 in the NCP reply.

The BURST MODE HEADER is different from the NCP 
request and reply header and contains the following 
fields:

Request type - displayed by Analyst next to the NCP 
label and has the value of 7777 hexadecimal.

Flags - this is a bit field that specifies the mode or 
condition of the connection.

Stream type - this currently has only value of 2, which 
means burst.

Source ID - this is a unique, random number created to 
identify a current burst connection by a sender.

Destination ID - this is a unique, random number 
similar to Source ID but created by the receiver.

Packet sequence - this number is similar to a NCP 
non-burst sequence number and is used to track 
transmitted packets.

Send delay time - this specifies the delay time between 
packets in burst in units of 100 microseconds.

Burst sequence number - this is the sequence 
number of the burst.  Each burst is counted as one unit.

Acknowledgment sequence number - this is the 
sequence number that the node expects to receive 
next.  This indicates whether the last burst transmission 
was received successfully.

Total burst length - this specifies the length of the 
whole burst transaction.

Burst offset  - this is the number of the packet in a 
burst.

Burst length - this is the length of the current burst.

Fragment list - this defines the number of elements 
that are missing from the transaction.

Function - this specifies whether the current burst is a 
read or write.
Service Advertising Protocol (SAP).
Service Advertising Protocol (SAP) provides service 
information on all known servers throughout the  
Internetwork.

SAPs are transmitted in two situations.

1. There are periodic SAPs broadcasted by a server 
on a LAN.  This periodic broadcast occurs at 1 
minute intervals.  If a server does not broadcast 
SAP information for more than a three minute 
period, all routers and servers assume that the 
server is not available and remove it from their 
binderies.

2. SAP packets are sent by the server (in this case a 
SAP reply) when a station loads a redirector (NETX 
or VLM).  The redirector sends a SAP request to 
locate the nearest server.  This request is called the 
"Get Nearest Server" request. 

SAP messages are transferred in IPX packets with the 
Socket number set to 452h (SAP).

SAP REQUESTs contain the following fields:

Packet type - this currently has only one possible 
value: nearest service request.

Server Type - this specifies the type of server 
requested.

The most common are:
	File server - (04)
	Job server - (05)
	Print server - (07)
	Job queue - (0A)

SAP RESPONSE contain the following fields:

Packet type and Server Type - are similar to those 
fields in SAP request, followed by the list of servers that 
are specified in the following fields:

Server name - the name of the server.

Network address - the 4 byte network address.

Node address - a 6 byte server node address (contains 
00-00-00-00-00-01 for all servers).

Socket - this is the socket number that receives the 
service requests.

The fields above will be repeated as many times as 
there are servers in the list.
Routing Information Protocol (RIP)
Routing Information Protocol passes the routing 
information between servers and routers.  RIP is sent 
for the following reasons:

1. When a router initializes, it informs other routers 
that it is available.

2. When a router first loads, it requires initial routing 
information from other routers and thus requests 
this information via RIP.

3. For periodical update of the routing tables, RIPs are 
broadcast at one minute intervals.

4. When a router changes any routing information in 
its tables, it sends a RIP broadcast to notify other 
routers about the change.

5. When a router is going down, it notifies any other 
routers.

RIP messages are transferred by IPX packets with a 
value of 453h in Socket field.

Routing information packets have the following format:

Packet Type - a request or reply.  This is followed by 
these three fields which are repeated as many times as 
there are routes:

Network address - this is the address of the network.  
In a RIP request, this field can be set to broadcast and 
receive information for all available networks.

Hops - this specifies the distance to a network in 
number of bridges that have to be crossed.

Ticks - this specifies the amount of time necessary to 
reach the network. One tick is equal to 1/18 of a 
second.

Serialization packets

Serialization packets are sent periodically to ensure that 
a server with the same serial number is not installed 
twice on the same network.  Every Netware server is 
sold with a unique serial number.  Loading more than 
one server with the same distribution copy is not 
allowed and serialization packets check and notify 
everyone if a license is being broken.

Serialization packets are transferred as broadcasts in 
IPX packets with the Socket number of 457h.

WatchDog Packets

The WatchDog protocol is used to determine if a station 
that does not transmit packets for a long period of time 
is still up.  If the station is inactive for 5 minutes (a 
default which can be changed), a server sends a 
WatchDog packet to the station.  If the station is alive, it 
sends a WatchDog reply.

If the server does not receive a WatchDog reply, it 
continues to send WatchDog packets once a minute for 
ten minutes (both values are defaults and can be set 
separately).  If the server does not receive the 
WatchDog reply after this period, the server considers 
the connection closed and clears the connection from 
the connection table.


APPENDIX

PROGRAM DESCRIPTIONS

Analyst is a Microsoft Windows based program which 
captures and analyzes information submitted by 
software-based Probes located on Windows PCs on 
different segments of your LAN or WAN.

The Probe software resides on Windows PCs 
throughout your LAN or WAN.

The Analyst software resides on the Analyst Station.

Analyst has only Windows based programs.  Probe has 
both DOS and Windows components.

Discoverer is also a Microsoft Windows based program, 
but it does not require any DOS based programs for 
function (from Network Instruments - it does require 
ODI and the VLM shells to be loaded at the 
workstation).

Analyst/Probes main components are:

ANALYST.EXE is the main program for viewing and 
capturing Probe segment information.

*.DLLs are the Windows Dynamic Link Libraries for  
ANALYST.EXE.

VPACKODI.EXE is the ODI interface that makes 
network packets available to a Probes Windows 
programs.  VPACKODI.EXE will only work with Novells 
ODI.  For more information on the ODI, see the 
Installation section or this Appendix.

ANALYST.HLP is the Windows help file for 
ANALYST.EXE.

ANALYST.INI (stored in the Windows directory) is 
where Analyst stores Windows information.

ANALYST.ADR (stored in the ANALYST installation 
directory) stores all of the hard address and alias 
information.

PROBE.EXE is the Probe program

PROBE.DAT is Probes installation data file

PROBEx.ADR is the "x" Probes address file

PROBES.LST is the List of Probes data file

INSTALL.EXE is the installation program.

INSTALL.DAT is installs data file.

DISCOVER.NIC stores information about the charting 
and display for Discoverer. (not a text file)

DISCOVER.NOD stores information about the NODES 
Discoverer finds. (not a text file)

DISCOVER.SRV stores information about servers.  (not 
a text file)

DISCOVER.HLP is the help file for Discoverer.

DISCOVER.EXE is the main Discoverer program.

NICHART.DLL is the charting DLL used by Discoverer.


PROGRAM FLAGS

This section discusses the optional flags for all 
programs that use flags.  Flags shown in brackets [] are 
optional.  Flags are not case sensitive.


ANALYST.EXE

ANALYST.EXE has the following optional flag:


ANALYST [-DEMO]

where:

-DEMO
This starts Analyst in DEMO mode.  In this mode, 
Analyst will use simulated data, and does not require a 
LAN or LAN adapter to function.

Example:

ANALYST -DEMO
PROBE.EXE
PROBE.EXE has the following optional flags:


PROBE [-i=xx] [-DEMO] [-TOKEN]

where:

-i=xx
This is the software interrupt which you specified in 
VPACKODIs command line.  It is only required if you 
have specified a similar flag with VPACKODI.  Values 
(xx) are in hex and can range from 60-6F.  6F is the 
default.

This flag can be used in conjunction with any other flag.

Example:

PROBE -i=63

-DEMO
This starts Probe in DEMO mode.  In this mode, the 
Probe will simulate data and report it to the specified 
(during install) Analyst Station.

Example:

PROBE -DEMO

-TOKEN
Only used with the -DEMO flag, this tells the Probe  
DEMO that you would like it to simulate Token Ring 
data.

When using the Probe in licensed mode, it will 
automatically determine whether you are using Token 
Ring or Ethernet.

Example:

PROBE  -TOKEN  -DEMO
VPACKODI.EXE
VPACKODI has the following option flags.


VPACKODI  [-i=xx]  [-m=y]


where:

-i=xx
This is the software interrupt.  You may want to specify 
this if the default (6F) is conflicting with some other 
program.  If you have specified a software interrupt 
different than the default, you must also specify the 
same interrupt on the PROBE.EXE command line.  
Values (xx) are in hex and can range from 60-6F.

-m=y
where y can be:

6	for a 60K buffer
5	for a 50K buffer
4	for a 40K buffer
3	for a 30K buffer
2	for a 20K buffer 

Example:

VPACKODI  -m=3

This flag allows you to lock a capture buffer when 
loading VPACKODI.  This ensures that a buffer is 
allocated no matter what is using lower DOS memory in 
Windows.

Since the allocation of the lower DOS memory under 
Windows is dynamic and is often very inefficiently laid 
out, locking VPACKODIs memory usually wont result 
in any loss of functionality.  In other words, programs 
often take as much RAM as is available and if they get 
less, it will not hurt them - i.e. WFW networking.

If you see an error indicating that you do not have 
enough contiguous DOS memory to allocate 
VPACKODIs buffer, you will need to use the "-m" flag.

This error is VPACKODI telling you that other 
applications have taken all of the DOS memory 
available and have not left enough room for VPACKODI 
to allocate a buffer.

First off, lets explain how Windows handles DOS 
drivers and what happens to your lower DOS RAM 
when you start Windows.

Users often believe that because they see 500+K of 
RAM free when they open a DOS window in Windows, 
that 500+K of RAM is how much RAM they actually 
have available in DOS.  This is not true.  Each time 
Windows opens a new DOS window it allocates an 
additional 640K of RAM from the RAM above 1 MEG.  
Your original (lower) DOS memory (the memory that is 
below 1 MEG) is used by Windows and Windows 
programs for all sorts of things.  For example, Windows 
for Workgroups drivers may use up to 450K of your 
original DOS memory to load.  If it cannot allocate this 
RAM, Windows will not load WFW networking.  (Try 
and load WFW with only 420K free in DOS - you will 
see what we mean.)

VPACKODI was designed to take only 3K of DOS 
memory when a Probe is not running and to auto 
allocate up to 60K of DOS buffer when you run a Probe 
(memory that is returned when you terminate the 
Probe). VPACKODI will try to allocate 60K if it can find 
the 60K contiguous.  If VPACKODI can not find 60K, 
then it will try 50K, 40K, 30K then 20K.  After that it will 
give up and you will see an error message.

This can be solved in two ways:

1. Unload some of the offending programs.  Sound 
blasters, screen savers, clock utilities, and unused 
network protocols are the usual suspects.  And try 
running VPACKODI again.

2. Run VPACKODI with a locked memory buffer - the 
"-m" flag which is explained above.
TROUBLESHOOTING
Although most installations of Analyst will proceed 
without any trouble, due to the vast number of network 
configurations and PC hardware/software options that 
Analyst supports, sometimes trouble arises.

If you experience trouble in setting up Analyst, keep a 
number of things in mind.

First and foremost, try to simplify your setup in any way 
possible.  This means if you have a screen saver 
loaded, disable it.  If you are running some fancy 
network add on peer-to-peer jet engine turbo stimulator, 
remove it.  This does not mean that you will not be able 
to use Analyst with your other products, but if you can 
determine where the problem is, you can focus on that 
piece of the puzzle and you may be well on your way to 
solving the problem.

Second, dont trust anyone or anything.  The only way 
to really know what your hardware settings are is to 
have the card or device in one hand and the manual in 
the other.  Programs which try and discover interrupts 
and other settings only function properly when 
everything is working correctly - exactly when you dont 
need them.  Don't blindly trust other network drivers - 
they may or may not be reporting the correct 
information.

Third, do not, under any circumstances, share 
interrupts, i/o ports, or memory addresses between 
adapters.  No matter what worked before or what might 
work in the future, sharing interrupts or memory 
settings is not a valid configuration.

Troubleshooting checklist:

1. Does your network work without any Analyst or 
Probe programs or drivers loaded?  If not, check 
your network installation instructions.  Once your 
network appears to be running correctly, try and 
install Analyst or Probe again.

2. Does the Probes VPACKODI driver load and report 
back that all is well?  If not, check the underlying 
network driver and verify that you have loaded the 
specific driver according to the Probes installation 
directions.

3. Try installing Analyst or Probe on a different PC and 
see if you experience the same problem.  This does 
not mean that you will not be able to use Analyst or 
the Probe on the desired PC.  It may give you some 
insight into the problem that you are having.

4. Analyst and Probe may run on unusual or non-
supported systems or configurations - we are even 
surprised at the range of systems and 
configurations people use our software on.  BUT, if 
you are having troubles, try to stay within the 
guidelines of the stated system requirements - if 
only for a test to determine if the problem is with the 
Analyst or Probe software or with the unusual 
Hardware or OS setup.
Probe Troubleshooting
Probe is not "seeing" the packet types you are 
interested in?

Check to make sure you have included the correct 
FRAME line in your NET.CFG.

Probe is not accepting packets on your LAN?

Are you licensed?  See the "Licensing" section in this 
manual for information on turning a DEMO version of 
Analyst into a licensed product.  You can tell the state 
of your license by clicking on "File" -> "About Analyst".

Do you have the correct filter(s) set?  Check the 
Probes "Filter" dialog to verify the active filter set.

Note: When setting up a to/from filter, you should set 
the address of interest in the left side of the filter box 
and ANY_ADDRESS in the right section.  Then select 
"".  You should not put the desired address in both 
sides of the filter.

Probe can not allocate DOS packet buffer?  Not 
enough contiguous DOS memory to allocate a DOS 
packet buffer?

This error is VPACKODI telling you that other 
applications are using all of the DOS memory available 
and there is not enough room for VPACKODI to 
allocate a buffer.

VPACKODI is designed to take only 3K of DOS 
memory when a Probe is not running and to auto 
allocate up to 60K of DOS buffer when you run a Probe 
(the memory is returned when you terminate the 
Probe). VPACKODI will try to allocate 60K if it can find 
the 60K contiguous.  If it can not find 60K, then it will try 
50K, 40K, 30K then 20K.  After that VPACKODI will 
give up and you see the error message.

This can be solved in two ways:

1. Unload some of the offending programs.  Sound 
blasters, screen savers, clock utilities, and unused 
network protocols are the usual suspects.  And try 
running VPACKODI again.

2. Run VPACKODI with a locked memory buffer - 
explained below.
 
VPACKODI has a flag that allow you to lock a memory 
buffer when loading.  This makes sure that VPACKODI 
gets its buffer no matter what starts in Windows.  Since 
the allocation of the lower DOS memory under 
Windows is dynamic and is often very inefficiently laid 
out, locking VPACKODIs memory will not usually result 
in any loss of functionality.  In other words, programs 
often take as much RAM as is available.  If they get 
less, it will not hurt them. (WFW networking is an 
example of this.)

The flags for VPACKODI are:

-m=y

where y is either:

6 for a 60K buffer
5 for a 50K buffer
4 for a 40K buffer
3 for a 30K buffer
2 for a 20K buffer 

A sample command would look like:

VPACKODI  -m=3

See the Program Flags section on VPACKODI for a 
further explanation on why this error occurs and what 
Windows is doing with the lower DOS memory.

Can not register MLID receive monitor or MLID 
version to old.

This is indicating that your ODI driver for your network 
card does not support the receive monitor function.

Most ODI drivers developed before early 1993 do not 
support receive monitor.

Check with your card manufacturer and download or 
get a more recent driver.

This may also mean that you will need to run the 
program RXMONSTK.COM.

VPACKODI reports "MLID does not support 
promiscuous mode, or MLID version to old.  Update 
MLID drivers to the newest version"

Typically, ODI drivers distributed after 1993 support 
"promiscuous mode".  This is a mode that directs the 
driver to accept all packets broadcasted on the 
segment.  This is opposed to only packets destin for the 
drivers network cards particular address.  If you receive 
this error, check the date of your MLID driver (the ODI 
CARD driver) if it is old you will need to quire a newer 
one from the manufacturer.

VPACKODI reports "Cannot register MLID receive 
monitor, or MLID version to old.  Update MLID 
drivers to the newest version"

Typically, ODI drivers distributed after 1993 and before 
1995 support "receive mode monitor".  This is a mode 
that allows a protocol analyzer to duplicate packets at 
the driver level and thus to function with other network 
applications.  If you receive this error, check the date of 
your MLID driver (the ODI CARD driver) if it is old you 
will need to quire a newer one from the manufacturer.  
If it dated after 9/22/94 see the section below:

Latest ODI Drivers (dated after 9/22/94)
If you are using the latest (dated after 9/22/94) ODI 
drivers you will need to follow the instructions in the file 
VLMUPx.TXT that is included with VLMUPx.EXE.  The 
following is a excerpt from the file that describes the 
new interface for receive mode monitor.  The following 
text is (c) Novell, Inc..

RXMONSTK.COM

Due to an architecture change, programs like Analyst, 
LANalyzer and LanDesk will not run with the new ODI 
drivers in this file without loading a SHIM.  
RMONSTK.COM is a shim between LSL.COM and the 
MLID that will allow a program that uses the "Receive 
Monitor Stack" to function (i.e. Analyst, LANalyzer etc.).  
The load order that should be used is as follows:

      LSL
      RXMONSTK
      MLID
      IPXODI
      VLM

If you need to use this shim - copy RXMONSTK.COM 
from \VLMS to the NWCLIENT directory and the 
RXMONSTK.MSG from \VLMS to the 
NWCLIENT\NLS\ENGLISH directory.

The RXMONSTK.COM file has not been certified with 
any 32 bit cards - including the NE3200 and NE2_32.  
Workstations hanging while running the application that 
uses the Receive Monitor Stack is the most common 
symptom.  Novell does not recommend using the 
RXMONSTK.COM with a 32 bit card.  If you have a 32 
bit card, Novell recommends using the old LSL.COM (9-
10-93) and old MLID which do not require 
RXMONSTK.COM.

Discoverer Troubleshooting

Cannot find or load NWIPXSPX.DLL or 
NWCALLS.DLL.

This is an indication that you have not updated your 
Windows PC to the latest Novell shells.

See the ODI section of the step by step installation 
instructions for a detailed description of Discoverer 
requirements.

Discoverer hangs with a "Polling Server" message 
in the status bar.

This may be an indication that you are not using 
Novells 802.3 frame type for IPX/SPX.  At this time 
Novell requires you to use 802.3 as your frame to 
collect statistics.

Cannot get information about a particular node or 
set of nodes.

If this condition exists for some, but not all nodes, 
check to see what the nodes that do not respond have 
in common.

Maybe they are all using the same (faulty) driver?

Try updating the ODI drivers on the stations in question.
SAMPLE CONFIGURATION FILES:
Probe specific lines are indicated in bold.
ODI:
The following example is for a system using an Eagle 
NE2000 Ethernet adapter.

AUTOEXEC.BAT:

PROMPT $P$G
C:\DOS\SMARTDRV.EXE
C:\DOS\DOSKEY
SET MOUSE=C:\MSMOUSE
C:\MSMOUSE\MOUSE
PATH=C:\;C:\DOS;C:\WINDOWS 
SET TEMP=C:\TEMP
CD ODI
LSL
NE2000
IPXODI
VLM
C:\ANALYST\VPACKODI
WIN


A sample NET.CFG for use with Token Ring might look 
like:


LINK DRIVER TOKEN
	INT 5
	MEM CC000
	FRAME TOKEN-RING
	FRAME TOKEN-RING_SNAP

LINK SUPPORT
	BUFFERS 15 4028
	MEMPOOL 4096

(c) 1995 Network Instruments, LLC


