This topic describes the troubleshooting tools that are provided with Wanware. Using them can help you save time and money. Time is saved by diagnosing problems in the field without special data communications instrumentation. Money is saved by using the traffic statistics gathering capabilities to provide information for traffic studies.
We don't expect everyone installing and administering this product to be a data communications expert. The information here may be more than you need. However, the tools are no less useful for having background information on data communications described along with them.
Three kinds of information can help you determine your problem:
statistics
Statistics are cumulative counts which can be examined at any time. These are often useful during isolation of both functional and performance problems.
protocol traces
Protocol traces show you the protocol exchanged with the remote system from the local system's point of view.
event logs
Event logs provide a history of events which occurred at particular interfaces.
You access most of this information with tsgstat. tsgtrace allows you to examine protocol information in real time, or store it for later analysis.
tsgtrace is installed as root accessible only. It should never be generally executable because it will give a line trace which can include passwords.
To invoke tsgstat, as root, enter the command:
tsgstat [ -h ] | [ [ -n netid ] | network_name]
tsgstat displays on standard output the status of the specified link, network_name. network_name is defined in file /etc/packetnets. The counts it displays are set to zero whenever services are started.
The following table describes the information that appears.
|
Field |
Description |
|
Frames received OK |
The number of frames received without a CRC error. A rapidly increasing count indicates an active receive data path. |
|
# bytes received OK |
The number of data bytes (any protocol headers plus contents of frames) received. The average frame size is the bytes received OK count divided by the Frames received OK count. |
|
Frames transmitted OK |
The number of the frames transmitted. |
|
# bytes transmitted OK |
The number of characters transmitted excluding flags and CRCs. |
|
underrun count |
The number of frames unsuccessfully transmitted because characters were not supplied to the serial communications interface fast enough to maintain synchronization. Significant values (10% of frames transmitted OK), indicate the line is overloaded, possibly due to one or more links being clocked at higher than rated speeds. |
|
overruns count |
The number of frames rejected because characters were not read into memory as fast as they arrived. Usually indicates that the link is running above its maximum rated speed. |
|
receive aborts |
The number of abort sequences (strings of 7 or more contiguous 1 bits) received. A non-zero value is not a problem unless it is greater than 10% of good frames received. This may indicate a problem with the Received Data signal or with the remote transmitter. |
|
crc errors |
The number of frames received with bad FCS (Frame Check Sequence), that is, Cyclic Redundancy Check bytes received do not match the values calculated from the data received. A non-zero count indicates a noisy data link or problems with the remote transmitter. |
|
Frames < 2 bytes |
The number of frames that were too short. That is, less than 2 bytes long. A non-zero count indicates a noisy data link or problems with the remote transmitter. |
|
no recv buffer available |
The number of instances that a buffer was unavailable during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the capabilities of the system. |
|
CTS changes |
The number of times that the Clear to Send (CTS) signal changed. A rapidly increasing count indicates a modem or cable problem. |
|
DCD changes |
The number of times that the Data Carrier Detect (DCD) pin changed. A rapidly increasing count indicates a data link or the modem problem. |
|
DSR changes |
The number of times that the Data Set Ready (DSR) pin changed. A rapidly increasing count indicates a problem with the modem or the cable between the modem and the communications controller. |
|
CTS |
The current state of the CTS signal. |
|
DCD |
The current state of the DCD signal. |
|
DSR |
The current state of the DSR signal. |
tsgtrace allows you to see data exchanged between the remote andWanware in real-time, as they are being transmitted.
You can redirect the standard output of an tsgtrace invocation to a disk file so it can be sent to support individuals for protocol analysis.
tsgtrace displays the data exchanged over the specified network, network_name. network_name is defined in file /etc/packetnets.
Consult the tsgtrace manual page for usage information.
Note that older versions of Wanware do not support tracing of raw synchronous links.
No data will be exchanged on the link until an application opens that link. You may wish to use a TSG-supplied application to ensure that you are debugging only link setup issues and not API issues at the same time. The application stest can be used to send and/or receive data across the link.
While the application is running, you can use tsgstat (see above) to look at the count of bytes transmitted and/or received to verify that they are increasing. You can also look at the data being exchanged using tsgtrace.
Copyright © 1997-2004 The Software Group
Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software
Group Limited.