This topic describes the troubleshooting tools that are provided with the X.25 software. 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.
For X.25, you access most of this information from the Netcom Operator Console (noc) utility. You may find it useful in debugging any problems that you have.
The tsgtrace utility allows you to examine X.25 protocol information in real-time or store it for later analysis.
The utilities are stored in /etc. To preserve security you must have root privileges to use these utilities because they allow access to all information transferred on an X.25 link. Ensuring this directory is in the execution search path for the superuser can save a lot of typing when you are trying to solve X.25 link communication problems.
noc is menu-driven so it is easy to use. To invoke noc, you must have root privileges.
Enter the command:
noc <boardno>
The optional <boardno> is the board number that you wish to examine. If <boardno> is not specified, noc will use the first board that was found on system boot, starting from zero.
noc's main menu appears:
Netcom Operator Console
=======================
Statistics Menu:
1: Serial Reception Statistics
2: Serial Transmisson Statistics
3: Frame Level Statistics
4: Link Configuration (non-Packet)
5: Link Configuration (Packet)
6: Packet Level Statistics
Configuration/Hardware Menu:
a: frAme log (Ascii) e: Examine memory i: Interface log
c: device Config f: Frame log (hex) r: Reset board
d: driver DSPs g: driver Globals t: driver TTYs
Commands: l to select link, b to select board
| or q to quit
Enter Selection (Board 0, Link 0):
Select an item from the menu by entering its single character identifier.
Some menu items will subsequently prompt you for further input. In such cases the response to these prompts must be terminated with a cursor return.
noc will display information pertaining to the current board and link number that is displayed in its command prompt. These may be changed at any time with the b or l commands.
To select an item from this menu, type the appropriate item number. noc passes a statistics request to the front end processor (FEP), waits for a response, and displays the result. If the statistics you requested do not appear within a half-second, either the software has not been loaded onto the FEP or a major failure has occurred. Be patient for another few seconds; noc will eventually inform you if the request cannot be satisfied.
Statistics are not cleared after a request; statistics continue accumulating from board loading time. If you want to clear the statistics to zero, you must reload the board.
Receiver statistics measure device level (X.25 level 1) activity relating to data received on the X.25 link. Normally, none of the statistics values except for frames received ok and bytes received ok should be incrementing rapidly. Quick changes in any of the other values may indicate physical connection or performance problems.
The following is an example of what you see when you ask for receiver statistics. A description of each field follows the example.
Enter Selection (Board 0, Link 0): 1
RECEIVER STATISTICAL INFORMATION
frames received OK 88524 # bytes received OK 8157266
DSR changes 245774 DCD changes 0
lack ipb count 0
Aborts received 37 frames overrun 1
CRC errors 3
frames < 2 bytes 0
DCD 1 DSR 0
|
Field |
Description |
|
Frames received OK |
Frames received which do not have a CRC error associated with them. Rapid incrementing indicates an active receive data path. |
|
# bytes received OK |
Indicates the number of data bytes (protocol headers plus contents of X.25 packets) received. The average size of a frame is the number of bytes received OK divided by the frames received OK. |
|
DSR changes |
Number of times the Data Set Ready pin (in the EIA RS-232 interface) toggles. Rapid incrementing indicates a problem with the modem or the cable between the modem and the card. |
|
DCD changes |
Number of times the Data Carrier Detect pin (in the EIA RS-232 interface) toggles. Rapid incrementing indicates a problem with the data link or the modem. |
|
Lack ipb count |
Number of incoming frames that had to be ignored because buffer pools were depleted. If this count is being incremented frequently, your configuration and/or traffic levels may be overloading the card in some way. |
|
Aborts rx'd |
Number of abort sequences (strings of 7 or more contiguous 1 bits) received. The occasional abort is okay, but there is a problem if this value is greater than 10% of good frames received. Check for a problem with the Received Data signal or with the remote transmitter. |
|
Frames overrun |
Number of frames tossed out because characters weren't read into memory as fast as they arrived. Usually indicates that you are running the link above the maximum rated speed of the card. |
|
CRC errors |
Number of frames received with bad FCS. This means that Frame Check Sequence - Cyclic Redundancy Check bytes received do not match the values calculated from the data received and indicates a noisy data link, or problems with the remote transmitter. |
|
Frames < 2 bytes |
Number of frames that were too short (less than 2 bytes long). Indicates a noisy data link, or problems with the remote transmitter. |
|
# bytes received ok |
Total number of characters received, excluding flags and CRCs. |
Transmitter statistics measure device level (X.25 level 1) activity relating to data transmitted on the X.25 link. Normally, none of the statistics values except for frames transmitted ok and bytes sent should be incrementing rapidly. Quick changes in any of the other values may indicate physical connection or performance problems.
The following is an example of transmitter statistics. A description of each field follows.
Enter Selection (Board 0, Link 0): 2
TRANSMITTER STATISTICAL INFORMATION
frames transmitted ok 106596 # bytes sent to txISR 1818631
underrun count 0
CTS changes 409708
CTS 1
|
Field |
Description |
|
Frames transmitted ok |
Number of frames the transmitter has sent. |
|
# bytes sent to txISR |
Total characters sent, excluding flags and CRCs. |
|
Underrun count |
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 that the card is overloaded, possibly due to one or both links being clocked at higher than rated speeds. |
|
CTS changes |
Number of times the CTS signal changed. A rapidly increasing count indicates trouble with the modem or cable. |
|
CTS |
Sense of the CTS (Clear To Send) signal. |
The Frame Level of X.25 (Level II) provides an error-checked path between the sender and receiver. It is a full-duplex protocol using a sliding window and "go back n" re-transmit for error control. For an in-depth discussion of the X.25 frame level, see "Computer Networks", by Andrew S. Tanenbaum (Prentice-Hall, 1981).
Frame level statistics can be used to indicate link performance problems and malfunctions in the remote X.25 node. Here are a sample output of frame level statistics:
Enter Selection (Board 0, Link 0): 3
FRAME LEVEL STATISTICAL INFORMATION
The Link is UP.
Bad length frames: short 00000000, long I 00000000, long C 00000000
Bad frames: illegal adrs 00000000, unsolicited F bit 00000000
Local T1 Timeouts: 00000001 P bits received: 00012411
Disconnected link because of:
Inability to transmit: 00000000, no remote response 00000000
Frame Type Counts: Information and Supervisory Frames
I RR RRp RRf REJ RNR
r 48302 27821 12410 0 5 0
t 48431 45756 0 12410 4 0
Frame Type Counts: Unnumbered Frames
UA UI DISC SABM DM FRMR BAD
r 1 0 0 2 1 0 0
t 2 0 0 1 2 0 0
I field of last FRMR rx: 0 0 0 0 0
I field of last FRMR tx: 0 0 0 0 0
Frame level ran out of ipbs 00000000 times
An explanation of each statistic follows:
|
Field |
Description |
|
The Link is UP/DOWN. |
This important indication tells you whether your system's Frame Level is successfully talking to the remote Frame Level, and whether they have exchanged link startup frames. When UP, you have configured the clocking, cabling, and logical gender (DTE versus DCE) correctly. An UP indication is set after your system has sent SABM and received a proper UA, or proper SABM. |
|
Bad length frames |
Number of frames received with incorrect length: either too short or too long. Indicates either a parameter mismatch with the remote system (I frames too long), or protocol implementation problems on the remote system. |
|
Bad frames |
Number of frames with illegal address byte (must be 01 or 03), or an unsolicited Final bit. Indicates protocol problems at the remote system. |
|
Local T1 timeouts |
Number of times the X.25 re-transmission timer ran out. Detected in the remote system by receipt of a frame with the Poll bit set. Indicates link problems, as the software has had to poll the remote system for a response. |
|
P bits received |
Indirect measure of the number of times that the remote system's T1 (re-transmission) timer timed out, since normal behaviour on T1 time-out is to send a command with the P (poll) bit set. May indicate that the remote system is keeping an idle link active by sending an RR command with P set every now and then. If it is occurring locally, indicates link problems. |
|
Disconnected link because of |
Indicates that the software is not receiving expected responses from the serial transmission hardware. Usually indicates a link configured for external clocking isn't receiving a clock signal from the modem. |
|
Disconnected link because of |
Indicates that the remote system did not respond to time-out recovery (transmission of RR with P set) for N2 retries. Caused by inactive remote system, or severe link, cable, or modem problems. |
|
Frame Type counts: |
Number of I (Information) or S (Supervisory) frames transmitted, categorized by type. When an HDLC (X.25 Level II) data link is operating properly, only I and RR frames are exchanged. The protocol resolves minor problems using RRp, REJ and RNR frames. High I-frame and RR counts are normal. High REJ counts indicate data transmission is occurring, but the link is subject to errors. RNR - Transmitted, indicates that the software is running out of buffers occasionally. RNR - Received, indicates that the remote system is running out of buffers. Frame Type Counts: Unnumbered Frames. The HDLC protocol uses unnumbered frames when the link is DOWN (not able to transfer information), or to indicate an unrecoverable error of some kind. FRMR transmitted or received indicates protocol implementation problems, or HDLC parameter mismatch.
SABM, DISC, UA transmitted or received indicates that attempts to set
up the link are proceeding. If they are only going one way, link or
cable problems are indicated. UI frames are only used for X.32 (dial X.25) applications. The V.25bis auto-dialer command language uses UI frames to exchange protocol information. The topic on using the tsgtrace utility introduces the V.25bis dialer command language. Or, see Dial-up X.25 (X.32) Configuration. DM received indicates the remote system cannot bring the link up. BAD frames are those with illegal addresses (which are ignored), or those with an illegal or out-of-sequence Control field (which cause FRMR transmission). |
|
I field of last FRMR rx |
The FRMR (Frame Reject) protocol response contains diagnostic information in the three bytes of information that follow the protocol header. This, and the next item in the display, contain these bytes for further problem analysis. |
|
Frame level ran out of ipbs |
Frame level was unable to get a storage buffer for incoming data. |
The current link configuration is divided into two displays. One display contains information relating to the X.25 Packet Level. The other display contains all other link configuration information.
The parameters you see may not be the ones in the link parameter file that fld used when it loaded the board. Normally, they are the same, but you can modify parameters dynamically with the x25config utility. Also, Registration Packet negotiation can change your link parameters with no external indication that this has occurred. However, the use of Registration Packets is extremely rare, and they are turned off by default.
To view basic link configuration information, select the Link Configuration (non-Packet) option. A display similar to the following appears:
Enter Selection (Board 0, Link 0): 4
--------------------------------------------------------
LINK 0 CONFIGURATION
Global parameters:
Will Initiate Link Startup DXE support: 0
Max Frame = 519 Logical Gender = DCE Network ID = Vanilla 1980
Clocking = Internal at 9600 bps Reconfiguration Status = x00
Frame Level parameters:
N2 = 10, T1 = 3, k = 7, T3 = 0
Do Not Use Extended Frame Sequence Numbering
No Dial String Modem ID = 0
MLP Parameters:
Packet Level for this SLP = 0, Transmission Class = 1
MW = 10, MX = 2, MT1 = 40, MT2 = 255, MT3 = 40, MTX = 20
Interface Software Parameters:
Suppression of Automatic control of X.3 Parameters:
No Suppression - all parameters supported will be controlled
To view the packet level parameters on the same link, select the Link Configuration (Packet)option. A display similar to the following appears:
Enter Selection (Board 0, Link 0): 5
--------------------------------------------------------
LINK 0 CONFIGURATION
Packet Level parameters:
Window negotiation ON, Max/ Out/ In = 7/ 2/ 2
Size negotiation ON, Max/ Out/ In = 256/ 128/ 128
Thruput cls negotiation ON, Max/ Out/ In = 0/12/12
Timers: T20/ T21/ T22/ T23/ T28 = 30/ 30/ 30/ 30/ 30
T14/ T24/ T25 = 0/ 60/ 150
normal (0..7) packet sequence numbers Number of pvcs: 0
One-way Incoming channels: Number of/ start lci(hex,dec) 0/ 1,001
One-way Outgoing channels: Number of/ start lci(hex,dec) 0/ 1,001
Two-way logical channels: Number of/ start lci(hex,dec) 0/ 1,001
no d mod incall ok outcall ok DIAG PKTS TX 00 CAUS !fast sel
no clam no pkt rej CUG SELECT BCUG SLECT no rpoa no rx stat
FORCE NEG no reg pkt REV CHG OK REV ACCEPT !no locchg !ifce info
!call info !passive
Subnet Address begins after digit 8 of called_DNA
Our Data Network Address is: 192522293
The packet level implements level III of X.25, the "network layer", as defined by the OSI reference model. Packet level statistics are collected whenever the link is up (when it is down, there are no packets flowing through the packet layer).
The following is an example of packet level statistics. A description of each field follows.
Enter Selection (Board 0, Link 0): 6
PACKET LEVEL STATISTICAL INFORMATION
Link status msgs....up 0003 ..............down 0002
IS txcredit violations 0000 IS redundant PT_RRs 0000
No ipb count 0000 Active VCs 0002
Packets Received by type:
DATA RR INT INT CONF CLEAR CLEAR CONF
29048 18979 0 0 2 119
CALL ACCEPT RESET RESET CONF RNR REJ
122 1 0 0 0 0
RESTART RSTRT CONF DIAGNOSTIC RGSTRN REG. CONF
3 0 0 0 0
Packets Transmitted by type:
DATA RR INT INT CONF CLEAR CLEAR CONF
19213 28960 0 0 119 2
CALL ACCEPT RESET RESET CONF RNR REJ
1 122 0 0 0 0
RESTART RSTRT CONF DIAGNOSTIC RGSTRN REG. CONF
3 0 0 0 0
Last Diagnostic Packet received (in hex):
Code: 00
Explanation:
|
Field |
Description |
|
Link status msgs |
Messages from the frame level indicating a change in the status of the data link, from UP to DOWN, or vice-versa. The link must be UP in order for data transmission (packet, or I frame interchange) to occur. When the link level is initialized, it sends a LINK UP message to the packet level. Many Link DOWN messages indicate a bad link, incorrect remote system protocol implementation, or unmatched link level parameters. |
|
IS txcredit violations |
Internally, the software uses credits for transmission flow control purposes. This figure should always be 0. |
|
IS redundant PT_RRs |
Internally, the software uses PT_RRs for reception of data. This figure should always be 0. |
|
Packets received by type |
Indicates the number and types of packets that were received from the remote system. Under normal conditions, only Data and RR counts will be changing rapidly. Counts of Call, Accept, and Clear packets reflect the number of network connections (PAD users, for example) being established and disconnected. Nonzero reset counts generally indicate a configuration problem - either the configured packet window or packet sizes don't match the remote system values. Restart counts that are changing indicate some problem with the remote system. |
|
Packets transmitted by type |
Indicates the number and types of packets transmitted. |
|
Last Diagnostic Packet received |
The X.25 protocol has a mechanism which allows a DCE (network switch) to transfer diagnostic information to a DTE (Customer equipment). When it receives one of these diagnostic packets, the software stores it for further reference. |
From this menu:
a: frAme log (Ascii) e: Examine memory i: Interface log
c: device Config f: Frame log (hex) r: Reset board
d: driver DSPs g: driver Globals t: driver TTYs
most items are useful to you only if you are familiar with the software internals. They are needed for in-depth debugging only.
Entering a "c" command will provide a board configuration display similar to the following:
Enter Selection (Board 0, Link 0): c
Board Board # Usable
Number Type Links Vector Memory I/O
0 1 2 10 0x0D8000 0x000300
1 0 0 0 0x000000 0x000000
2 0 0 0 0x000000 0x000000
3 0 0 0 0x000000 0x000000
See /etc/conf/sdevice.d/x25 for a description of board types. Board type 0 (zero) is an non-configured board. "Vector" in this display is the board's interrupt vector.
The tsgtrace utility allows you to see X.25 frames exchanged between the remote system and your front end processor (FEP) in real-time as they are being transmitted.
The program's options are described fully in the tsgtrace man page.
The default is to only record 14 bytes of each frame. If you wish to have longer frames recorded, you need to start tsgtrace with the -s option. If tsgtrace is then halted, the longer frames are still being recorded.
You can use tsgtrace to capture information on disk, then provide it to protocol support groups (either The Software Group or your network provider) with the following command:
tsgtrace > /tmp/trace
When you have captured the event that you think is causing the problem, press return to stop the trace. The results of the trace are stored in /tmp/trace.
The software stores the V.25bis dialer commands as well as X.25 protocol information. V.25bis dialer commands are always stored in HDLC UI frames. The address byte of the frame is x`FF', and the bytes that follow constitute the dialer command or modem indication. Each command or indication consists of three ASCII alphabetic characters, followed optionally by command-specific information. The ASCII frame log display modes will display these frames in readable format and help you identify the problem (if any).
The following is a list of the commands or indications.
|
Command or |
Description |
|
CRN99999999 |
Call a Remote Number . This string is sent to the modem to request it to place a call to a telephone number. The 9s shown here should be what you have configured as the "dial" string in the X.25 link configuration. If the number you see in the trace is not the correct telephone number to dial, you will need to change the dial_defn and link configuration. |
|
VAL |
Valid command. The modem responds to a V.25bis command with VAL to indicate that it received and recognized the command, and is acting on it. The modem is not required to respond to every command with VAL. If you see this message, the call setup is proceeding normally. The last command sent to the modem (such as a dial command) is in a format that your modem accepts. |
|
INV99 |
Invalid command. The modem responds with INV to indicate that it did not recognize the command as valid. The two digits that may follow INV constitute a modem-specific code which indicates what is wrong. Refer to the manual that came with your modem to see if it lists the particular error code indicated by the two digits. If this is not useful, look at the trace and identify the last command sent to the modem. It will be the message in error. If this is a dialing command (CRN...), you may have included a special character in the dial_defn that your modem does not support (such as a pause character). |
|
INC |
Incoming Call. The modem may indicate that it has an incoming call to be connected by sending INC. Some modems indicate an incoming call by transiting directly to data transfer state (by raising DSR). There is no cause for concern if you do not see this message. |
|
CFI99 |
Call Failure Indication. If a modem can't connect to the remote system for some reason, it sends the CFI indication, with a two digit code indicating why. This may be a transient problem, such as a busy signal or a permanent problem such as an unconnected telephone line. Try dialing the same telephone number using a regular telephone to see if you can establish the connection. Common failure codes listed in the V.25bis specification are:
For a description of when your modem uses these error messages and for other codes, refer to your modem manual. |
The trace will also show the state of the control lines coming from the modem which are involved in setting up the telephone call:
modem has DSR off
For a description of the relationship between the state of these signals and the state of the modem, see Establishing a Connection.
The X.25 incoming call processing daemon, (/etc/X25daemon), stores what it has done with each X.25 Switched Virtual Circuit call that it receives from the remote system in
Each time it processes an incoming call, it writes a line to the end of this ASCII file which describes what the daemon did with the call. Note that a call disposed of by the daemon may still be cleared by other application software - notably, by the software responsible for handling calls from PAD-connected terminals.
The installation scripts set up your system to run this program by default, so you should see this file growing each time your machine processes an incoming call packet, whether or not the call is accepted.
You can use the daemon log to verify that you have set up /etc/x25tab properly. If calls you are expecting to be connected are being cleared, or vice-versa, use this file to find out why.
Once you've loaded the communications controller, it automatically tries to start the HDLC (Layer II) protocol, unless you are using X.32/V.25bis to run Dial-up X.25.
The first step in checking the link is to run noc and choose the frame level statistics option for the appropriate physical link. The first line of output tells you explicitly whether or not the link is up.
FRAME LEVEL STATISTICAL INFORMATION
The Link is DOWN.
Bad length frames: short 0000, long I 0000, long C 0000
Bad frames: illegal adrs 0000, unsolicited F bit 0000
Local T1 Timeouts: 2019 P bits received: 0000
Disconnected link because of:
Inability to transmit: 0403, no remote response 0000
I RR RRp RRf REJ RNR UA DISC SABM DM FRMR
rx 0 0 0 0 0 0 0 0 0 0 0
tx 0 0 0 0 0 0 0 2020 0 0 0
I field of last FRMR rx: 0 0 0 0 0
Frame level ran out of ipbs 0000 times
If the link is UP (ready to transfer Information, or I frames), you can proceed to making X.25 calls. If not, you have some more investigating to do.
The key pieces of information are in lines 3 (The Link is DOWN) and 8 (Inability to transmit...). Line 3 indicates the state of the link - operational (UP), or not operational (DOWN). In this example, the link is down. Before you can communicate with remote systems, the link needs to be UP.
The clue to the reason is in line 8, which indicates that the local system is unable to transmit. Either your modem is not providing clocks, the cable connecting the card with the modem is not passing them through, or you have configured the card for internal clocking but have not provided a non-zero value for the speed parameter in the X.25 protocol parameters.
Once you have an X.25 link that is up, you can try to make calls to other hosts to make sure that your configuration is set up correctly.
Once you have an X.25 link that is running, you can use xpad to make a PAD (X.3, X.28, or X.29) call to a network-connected host. The following is an example of the command used to initiate a call.
xpad -r -d 0302092100086 -u A
The first 0 in the address may need to be a 1 for your network's addressing scheme for making inter-network calls. The address above is that of the Datapac Information Service, a computer connected to Canada's Datapac network that provides information on the service.
When you invoke this command, a display similar to the following appears:
xpad V1.8: Copyright (c) 1991-1994 The Software Group Limited
Call Made
Awaiting Call Acceptance ..Call Connected. Outbound packet size = 256
WELCOME to the Datapac Information System.
Your previous session was 1991-02-12 11:12:23 EST
Your packet size is likely to be 128 instead of 256, but you should be able to establish a connection. If you do not, you will either receive a clearing message with an indication of why the call was cleared, or the connection attempt will "hang". When a connection hangs, you see:
Awaiting Call Acceptance ..
until T21 times out (default 30 seconds).
The most common cause of a hung call is a mismatch between the number of virtual circuits locally configured and the number that your network provider is using. Reduce the parameter bwc_num until you can connect a call.
Once you have successfully connected to a remote system, you can try and connect to your newly-installed software. You do this either by calling yourself with xpad, or by using another PAD to call your system.
If you use xpad, you might want to try
xpad -d 99999999
replacing 99999999 with your own address. A display similar to the following appears:
xpad V1.8: Copyright (c) 1991-1994 The Software Group Limited
Call Made
Awaiting Call Acceptance ..Call Connected. Outbound packet size = 128
yoursystem login:
At that point, press <Enter>, followed by <Ctrl-p> CLR to disconnect.
If you do not get connected for some reason, the clearing cause and clearing diagnostic provide clues to the problem.
Flow control parameter negotiation causes a fair number of connection problems. The clue is usually in the Clearing Diagnostic associated with the call - 41 or 42 (hexadecimal), for example. 41 indicates an invalid facility in a call setup packet, while 42 indicates an invalid value for a facility parameter. Some common solutions to facility-related problems are:
Change force_negotiate from YES to NO.
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.
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.
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. This information can be determined by tracing the line or using account (if it is running).
Copyright © 1997-2003 The Software Group
Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software
Group Limited.