This section of the on-line manuals describes the troubleshooting tools that are provided with SyncServer 1000. Using these tools can save you time by diagnosing problems in the field without special data communications instrumentation. Using the traffic statistics gathering capabilities can provide information for traffic studies that can add to your company's bottom line.
These pages are useful for providing background information on data communications.
To access the information used to diagnose problems, point a browser to
http://IPaddress
where 'IPaddress' is the IP address assigned to the SyncServer 1000 and log
in as User ID "admin".
There are several pages containing statistics and system information that can help you determine your problem:
Provides TCP Port and TCP connection information
Uptime, memory usage, CPU, network and process information.
Statistics are cumulative counts which can be examined at any time. These are often useful during isolation of both functional and performance problems. There are different levels of information you can choose to view. For X.25 links, you can view Packet level statistics and for either X.25 or LAPB, you can view Frame level, Device level or a table displaying the Active link configuration. For Raw Synchronous links, Device Level statistics are available.
A trace allows you to see the frames exchanged between the remote device and SyncServer 1000 on the synchronous port.
Logging can be turned on to provide a record of events.
This page displays a few top level statistics and a TCP port number for each
active server (a daemon which handles multiple incoming connections from
connected
SyncServer Clients.) If
more than one server is active then a list of TCP port numbers is displayed
from which one can select the corresponding server for which to show specific
statistics.
By default the first server's statistics will be displayed.
This page shows statistics on the TCP connections configured, displayed by TCP port and by TCP connection.
| Field | Description |
| Connection capacity | Displays the total number of TCP connections which can be made to the SyncServer 1000. |
| Maximum connections per port | The number of TCP connections which each separate server daemon can handle. |
| Servers running | Shows how many daemons are currently running. |
| Total Active Inbound IP Connections | Specifies the number of TCP connections that have been created. These may all come from the same client or from different clients . |
| Per Server Daemon/Port Statistics | |
|---|---|
| Active Inbound IP Connections | The number of active TCP connections currently handled by the daemon. |
| Total Inbound IP Connections processed so far | Number of all current and past TCP connections this daemon has handled, since the daemon was started at power up or when the software was restarted. |
| Time since statistics updated | Number of hours:minutes:seconds since last update of these statistics. While the web server will show you the statistics at any time, the daemon which generates the statistics just updates them periodically (usually every few seconds). This value indicates how long ago the daemon generated a new snapshot of the statistics |
When there is an active TCP connection, further information describing each connection will also be presented.
Select the Refresh link. If the frame/byte counts do not change when you expect the applications should be sending/receiving data, then there is a communication problem with the synchronous link.
This is a read-only page displaying information about the current status of the SyncServer 1000. There are several categories of information:
| System uptime | — | This displays the amount of time the system has been active. | |
| Memory usage | — | This field breaks down the memory usages into a variety of memory types including; total, free, shared, cached, buffers, etc. | |
| CPU information | — | This information includes the cpu type, clock speed, board revision and bogomips. | |
| Network information | — | This field shows the packets received and transmitted over the Ethernet interface and all the active internet connections established or listening. | |
| Processes | — | This field shows the processes running on the SyncServer 1000. Different processes will run depending on the functions which the SyncServer 1000 is configured to perform. |
In the left-hand navigation
There are several categories of information: Packet Level Statistical Information (X.25 only), Frame Level Statistical Information, Device Level Statistical Information and Active Link Configuration.
Counts are set to zero whenever the software is (re)started.
The following table describes the information that appears in this section.
| Field | Description |
| Active SVCs | Shows the number of switched virtual circuits that have a call connected or are in the process of making a call. |
| Active PVCs | Shows the number of permanent virtual circuits that are attached. |
| Link UP Status messages | Displays the number of times the HDLC-LAPB link has come up. |
| Link DOWN status messages | Displays the number of times the HDLC-LAPB link has gone down. |
| No buffers available | This is the number of times the SyncServer 1000 determined that there are no buffers available. This may indicate the machine is low on memory. |
| Last diagnostic packet received | Diagnostic bytes are part of the X.25 specification defined by CCITT. They have standard meaning to all equipment following this specification. The meaning of a diagnostic code displayed in this field is defined in the Explanation field below. Refer to X.25 Cause and Diagnostic Bytes for a complete list. |
| Explanation | This is a description of the diagnostic code displayed in the Last diagnostic packet received field above. |
The following table describes the information that appears in this section.
| Field | Description |
| Link Status | This is UP when the SyncServer 1000's frame level is successfully communicating with the remote's frame level and link startup frames have been exchanged. If UP, then the SyncServer 1000 has sent SABM and received a proper UA or SABM. Otherwise, status is DOWN. |
| Short Frames | The number of received frames that were too short to be legal. This count includes all frame types since the frame type may not have been available. Non-zero counts can indicate link quality problems or protocol implementation problems at the remote. |
| Long I Frames | The number of Information frames that were too long to be legal frames. Non-zero counts indicate either a parameter mismatch with the DCE (I frames too long) or a protocol implementation problem at the remote. |
| Long C Frames | The number of Control frames that were too long to be legal. Non-zero counts usually indicate a protocol implementation problem at the remote. |
| Illegal Address Frames | Two counts of bad frames are displayed: frames with illegal address bytes (that is, address bytes other than 01 or 03 hexadecimal), and frames with an unsolicited Final bit. Non-zero counts indicate a protocol problem at the remote. |
| Unsolicited F bit | These are Final (F) bits that arrived unexpectedly (i.e. when the SyncServer 1000 was not in timeout recovery mode). This value should always be zero. If it is not, it usually indicates protocol implementation problems at the remote. |
| P bits received | The number of frames received with the Poll bit set. When non-zero, this is an indirect measure of how often the remote's T1 timer timed out; the remote usually sends a command with the Poll bit set whenever its T1 timer times out. Non-zero counts may indicate that the remote is keeping an idle link active by periodically sending an RR command with Poll bit set. |
| Local T1 Timeouts | The number of times that the SyncServer 1000's retransmission timer ran out. A non-zero count indicates a link problem since the remote did not respond within T1 to a command SyncServer 1000 sent. |
| Local T2 Timeouts | Withhold acknowledgements timer. This allows N2 to suppress explicit RR packets in favor of "piggybacking" acknowledgements in outgoing data packets. |
| Local T3 Timeouts | The number of seconds of no link activity that will be allowed before RR is sent with the P bit. |
| Out of buffers | The number of times that the frame level was unable to get a buffer from the free queue. This count should always be zero. |
| Disconnected link because of | |
| Inability to transmit | A non-zero count indicates that the SyncServer 1000 is not receiving expected responses from its serial transmission hardware. Usually this indicates that a link configured for external clocking is not receiving a transmit clock signal. |
| No remote response | The number of times that the remote did not respond to a time-out recovery (transmission of RR with Poll bit set) for N2 retries. A non-zero count indicates an inactive remote or severed link, cable or modem problems. |
| Frame type counts: | |
| Information and Supervisory Frames | Counts are displayed for each type of information and supervisory frames transmitted and received. High I-frame and RR counts are normal since only I and RR frames are exchanged when the frame level is running successfully. Non-zero RRp, RRf, REJ and RNR counts are not unusual since the data link protocol resolves minor problems using RRp, RRf, REJ and RNR frames. High or constantly increasing REJ, RRp or RRf counts indicate that data transmission is succeeding, but that the link is subject to transmission errors. A non-zero RNR transmitted count indicates that the SyncServer 1000 is experiencing buffer scarcity. Running virtual circuits with smaller packet window sizes or packet sizes may alleviate the condition. A non-zero RNR received count indicates that the remote is throttling the link, usually because of buffer scarcity. |
| Unnumbered Frames | Counts are displayed for each type of unnumbered frame transmitted and received. The LAPB protocol uses unnumbered frames when the link is DOWN (not able to transfer information) or to indicate an unrecoverable error. Non-zero UA, DISC and SABM transmitted or received counts indicate attempts to bring up the link. If only the transmitted counts are increasing or if only the received counts are increasing, then there is a link or cable problem. If the only non-zero received count is for DM, it indicates that the remote cannot bring up the link. Non-zero FRMR transmitted or received counts indicate a protocol implementation problem or HDLC parameter mismatch. BAD frames counts are the number of frames received and transmitted with an illegal address, or with an illegal or out-of-sequence control field (that is, caused an FRMR frame to be transmitted). |
| I field of last FRMR | |
| I field of last FRMR received | This field contains the diagnostic information from the last Frame Reject (FRMR) frame received. Three or five bytes are displayed depending on whether LAPB is running in basic or extended operation. (Extended operations increase the size of some fields and therefore 5 bytes are returned in a frame reject rather than the 3 bytes returned in basic operation.) |
| I field of last FRMR transmitted | This field contains the diagnostic information from the last FRMR frame transmitted. Three or five bytes are displayed depending on whether LAPB is running in basic or extended operation. |
The following table describes the information that appears in this section.
| Field | Description |
|---|---|
Frames received |
The number of frames received without a CRC error. A rapidly increasing count indicates an active receive data path. |
Bytes received |
The number of data bytes received not including flags or CRC bytes. The average frame size is the Bytes received count divided by the Frames received count. |
Frames transmitted |
The number of the frames transmitted without error. |
Bytes transmitted |
The number of characters transmitted excluding flags and CRCs. |
Underruns |
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 an overload condition. |
Overruns |
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. |
Aborts received |
The number of abort sequences (strings of 7 or more contiguous 1 bits) received. A consistently increasing value or large values (greater than 10% of good frames received) indicate errors with the communications facility. It will usually be associated with CRC errors. |
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 large non-zero count indicates a noisy data link or problems with the remote's 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's transmitter. |
CTS |
Status of the CTS signal. |
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 |
Status of the DCD signal. |
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 |
Status of the DSR signal. |
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. |
DMA overruns |
The number of times that the DMA was unable to transfer receive data from the serial chip to memory fast enough. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
no received buffers |
The number of instances that a frame was flushed because no buffer was available to store the data during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
no transmit buffers |
The number of instances that a frame was flushed because no buffer was available to store the data during a transmit operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (No Header Buffers) |
The number of instances that a frame was flushed because no buffer was available to store message headers during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (No Data Buffers) |
The number of instances that a frame was flushed because no buffer was available to store message data during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (Flow Control in) |
The number of instances that a received data was flushed because of flow control in the device driver. If this count is increasing, traffic levels may be overloading the SyncServer 1000's processing capabilities. |
Rx Flushed (Flow Control above) |
The number of instances that a received data was flushed because of flow control in the protocol layers above the device driver. If this count is increasing, traffic levels may be overloading the SyncServer 1000's processing capabilities or the application may not be reading the data quickly enough. |
The configured global, frame level and packet level parameters are listed as well as the timers, other miscellaneous parameters and flags.
| Field | Description |
|---|---|
Reconfiguration Status |
A value is displayed when the drivers receive a reconfiguration request. Zero (0) indicates no errors were encountered when configuring the link. |
| Global Parameters | |
Protocol |
From the selected serial protocol |
Link Status |
Configured Parameter — linkenable |
DXE Support |
Configured Parameter — DXEsupport |
Max Frame size |
Configured Parameter — N1 |
Logical Gender |
Configured Parameter — DTE |
Network ID |
Configured Parameter — netid |
Clocking |
Configured Parameter — speed |
Line Encoding |
Configured Parameter — encoding |
| Frame Level Parameters | |
N2 |
Configured Parameter — N2 |
T1 |
Configured Parameter — T1 |
T2 |
Configured Parameter — T2 |
T3 |
Configured Parameter — T3 |
k |
Configured Parameter — k |
Extended Frame Sequence Numbering |
Configured Parameter — frm_extseq |
Modem ID |
Configured Parameter — modemid |
| Packet Level parameters | |
Window negotiation |
Configured Parameter — window_neg |
Size negotiation |
Configured Parameter — pktsize_neg |
Thruput cls negotiation |
Configured Parameter — class_neg |
| Timers | |
T14 |
Configured Parameter — T14 |
T20 |
Configured Parameter — T20 |
T21 |
Configured Parameter — T21 |
T22 |
Configured Parameter — T22 |
T23 |
Configured Parameter — T23 |
T28 |
Configured Parameter — T28 |
| Miscellaneous Parameters | |
Number of PVCs |
Configured Parameter — numpvcs |
One-way Incoming Channels |
Configured Parameter — owi_num |
One_way Outgoing Channels |
Configured Parameter — owo_num |
Two-way Logical Channels |
Configured Parameter — bwc_num |
Beginning of Subnet Address begins after called DNA digits |
Configured Parameter — called_length |
Our Data Network Addrss (DNA) |
Configured Parameter — DNA |
| Flags | |
These are all Yes/No set Parameters |
If a parameter is shown in the Set then the parameter is set to "Yes". |
Trace allows you to see frames exchanged through the synchronous port between a connected device and SyncServer 1000.
Consult the Trace manual page for usage information.
SyncServer 1000 attempts to bring its enabled links up, usually by sending DM to start the protocol exchange for link initialization. For X.25 links, this happens immediately after boot. For non-X.25 LAPB links, SyncServer 1000 only attempts to bring up the link when an application begins using that link. Make sure you are running an application which attaches to the link before reviewing the link status.
The first step in checking the link is to view the Link Statistics. The first field of the FRAME LEVEL information tells you explicitly whether or not the link is up. If the link is UP (ready to transfer Information, or I frames), you can proceed to making X.25 calls or exchanging LAPB data. If not, you have some more investigating to do.
The following is an example of some statistics fields that would indicate a problem.
| Inability to transmit | 0403 |
| No remote response | 0000 |
These values indicate that the local system is unable to transmit. If the link is externally clocked (see speed) then either your modem is not providing clocks or the cable connecting the SyncServer 1000 with the modem is not passing them through.
Flow control parameter negotiation causes a fair number of connection problems. The clue is usually in the Clearing Diagnostic associated with the call - 03/41 or 03/42, for example. 03/41 indicates an invalid facility in a call setup packet, while 03/42 indicates an invalid value for a facility parameter. Some common solutions to facility-related problems are:
Change force_negotiate from YES to NO (X.25 only).
By default, the software inserts all the flow control related negotiation facilities, as force_negotiate is YES, just to make sure that both ends explicitly know what values are being used. Some X.25 carriers or switch manufacturers allow only a subset of these parameters, and some do not allow them at all, depending on what the remote system thinks the link parameters ought to be.
Reduce the value for class_recv and class_send (X.25 only).
In the default configuration, an artificially high value for the throughput class negotiation parameters is set. This reduces the probability that the local node will clear incoming call packets requesting a particular value for throughput class, which is what it does when the remote system specifies a value in excess of class_recv and class_send.
This has the unfortunate side effect that outgoing call requests or call accepts may have an artificially high value for the throughput class parameters, and the remote call may clear if you specify a value in excess of the actual link speed.
Parameter Value |
Baud Rate |
7 |
1200 bps |
8 |
2400 bps |
9 |
4800 bps |
10 |
9600 bps |
11 |
19200 bps |
12 |
48000 bps |
14 |
64000 bps |
On X.25 links, using Trace may be able to show you the call clears. The most important thing with call clearing problems is who sent the clear (was it transmitted or received), and what the cause and diagnostic were. Cause and diagnostic bytes are described in X.25 Cause and Diagnostic Bytes.
On LAPB links, you can see if there was an acknowledgement (RR) to data frames which your application transmitted or if a reset was sent instead, indicating that the remote is not ready to receive your data. Likewise, you can see if any information is received from the remote.
Select Serial Link Statistics link in the left-hand navigation. The following table describes the information that appears. Note that counts are set to zero whenever the application is (re)started.
| Field | Description |
|---|---|
Frames received |
The number of frames received without a CRC error. A rapidly increasing count indicates an active receive data path. |
Bytes received |
The number of data bytes received not including flags or CRC bytes. The average frame size is the Bytes received count divided by the Frames received count. |
Frames transmitted |
The number of the frames transmitted without error. |
Bytes transmitted |
The number of characters transmitted excluding flags and CRCs. |
Underruns |
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 an overload condition. |
Overruns |
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. |
Aborts received |
The number of abort sequences (strings of 7 or more contiguous 1 bits) received. A consistently increasing value or large values (greater than 10% of good frames received) indicate errors with the communications facility. It will usually be associated with CRC errors. |
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 large non-zero count indicates a noisy data link or problems with the remote's 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's transmitter. |
Frames Too Long |
The number of frames that longer than the configured maximum frame size. A non-zero count indicates a difference between the configuration of the link and that of the remote device, a noisy data link or problems with the remote's transmitter. |
CTS |
Status of the CTS signal. |
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 |
Status of the DCD signal. |
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 |
Status of the DSR signal. |
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. |
DMA overruns |
The number of times that the DMA was unable to transfer receive data from the serial chip to memory fast enough. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
no received buffers |
The number of instances that a frame was flushed because no buffer was available to store the data during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
no transmit buffers |
The number of instances that a frame was flushed because no buffer was available to store the data during a transmit operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (No Header Buffers) |
The number of instances that a frame was flushed because no buffer was available to store message headers during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (No Data Buffers) |
The number of instances that a frame was flushed because no buffer was available to store message data during a receive operation. If this count is increasing rapidly, traffic levels may be overloading the SyncServer 1000's configured resources. |
Rx Flushed (Flow Control in) |
The number of instances that a received data was flushed because of flow control in the device driver. If this count is increasing, traffic levels may be overloading the SyncServer 1000's processing capabilities. |
Rx Flushed (Flow Control above) |
The number of instances that a received data was flushed because of flow control in the protocol layers above the device driver. If this count is increasing, traffic levels may be overloading the SyncServer 1000's processing capabilities or the application may not be reading the data quickly enough. |
Serial Link Tracing in the left-hand navigation window allows you to see frames exchanged through the synchronous port between a connected device and SyncServer 1000.
Note that tracing must be allowed by the application using the link for any data to appear in the trace. See the API function sync_open() for details.
Revision 6.3.0 (April 2004)
Copyright ©1997-2004The Software Group Limited.
All Rights Reserved.