Guest

Asynchronous Connections

Interpreting NextPort Disconnect Reason Codes

Document ID: 9502

Updated: Feb 04, 2010

   Print

Introduction

This document describes how to interpret the call disconnect reason codes reported by Cisco NextPort universal digital signal processor (DSP) modules. NextPort is the next generation DSP used by Cisco to implement either voice, data, or fax on a given port. AS5350, AS5400, AS5850 platforms and new models of modem cards for AS5800 all employ digital modems with NextPort DSPs. For digital modems in C3600, AS5200, AS5300 and older models of cards for AS5800, check Mica Modem States and Disconnect Reasons : no modem firmware upgrade can make NextPort DSP out of Mica DSP or vice versa.

Prerequisites

Requirements

This document has no specific requirements.

Background Information

Whenever a call using the NextPort DSPs is cleared or disconnected, the NextPort module records the reason for the disconnect. This disconnect reason code can be used to determine whether the disconnect was normal or an error occurred. This reason code can be used to track down possible sources of failure. Modems can be disconnected due to a variety of factors such as client disconnects, telco errors, and call drops at the network access server (NAS). A "good" disconnect reason is that the DTE (client modem or NAS) at one end or the other wanted to terminate the call. Such "normal" disconnects indicate that the disconnect was not a result of modem or transmission level errors. For more information on determining whether the disconnect reason is "normal", refer to Overview of General Modem and NAS Line Quality

Note: The disconnect reason is managed in a first-come-first-serve fashion. This means that the first disconnect reason generated is the only disconnect reason recorded. If the modem and the NAS attempt to terminate the session simultaneously and the modem happens to save the disconnect reason before the LINK_TERMINATE message from the NAS is processed, then the NAS disconnect reason is ignored.

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Determining the Disconnect Reason

When evaluating whether you are experiencing good or bad disconnects, it is important to obtain the history of disconnects that a particular port has experienced. In most environments, the disconnect reason is obtained using modem call records or call tracker syslog messages. This disconnect code can then be interpreted using the table provided in this document (or check the /images/exit.gif for modem analysis tools). Use the following commands to determine the disconnect reason:

  • The show spe modem disconnect-reason command does not display the disconnect reason code as a hexadecimal value. However, it does indicate the disconnect reason as a name. The name and class of the disconnect reason can be found in and respectively.

  • The show port modem log command displays the Disconnect Reason Code as a hexadecimal value. Refer to the :

0x0..   0x001 0x002 0x003 0x004 0x005 0x006 0x007 0x008 0x009 0x00C 0x00D 0x00E 0x00F
0x010 0x011 0x012                      
0x1.. 0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107 0x108 0x109        
0x1F00 0x1F01 0x1F02 0x1F03 0x1F04 0x1F05 0x1F06 0x1F07 0x1F08          
                          0x1FFF
0x2   0x201 0x202 0x203 0x204 0x205 0x206              
0x210 0x211 0x212                      
0x220 0x221 0x222   0x224 0x225                
0x3.. 0x3xx    
0x4..   0x401   0x403 0x404       0x408          
0x5..   0x501 0x502 0x503 0x504 0x505 0x506              
                          0x5FF

The next section looks at some examples.

Using the show port modem log Command

Use the show port modem log slot/port command to obtain the disconnect cause code (in Hex) for a particular call on a specific port. This disconnect code is identical to the cause code obtained from modem call-record and call-tracker syslog outputs. An example is shown:

*Jan  1 00:53:56.867: Modem State event: State: Terminate
*Jan  1 00:53:56.879: Modem End Connect event: 
  Call Timer                              :   195  secs
  Disconnect Reason Info                  :   0x220
      Type (=0  ):  
     Class (=2  ):  EC condition - locally detected
    Reason (=32 ):  received DISC frame -- normal LAPM termination

From the example above, note that the disconnect code is 0x220.

Using the show spe modem disconnect-reason Command

Use the show spe modem disconnect-reason {summary | slot | slot/spe} command to determine the distribution of disconnect reasons that the particular port has experienced. A sample summary output of all the ports is shown below:

NAS>show spe modem disconnect-reason summary
===CLASS OTHER====  =====CLASS DSP====  ===CLASS EC LCL===  ==CLASS EC FRMR===
Software Rst     0  No Carrier     341  No LR            0  Frmr Bad Cmd     0
EC Termntd       0  No ABT dtctd     0  LR Param1        0  Frmr Data        0
Bad MNP5 Rx      0  Trainup flr    328  LR Incmpt        0  Frmr Length      0
Bad V42B       110  Retrain Lt       0  Retrns Lt      226  Frmr Bad NR      0
Bad COP stat     0  ABT end flr      0  Inactivity       0  
ATH              0                      Protocol Err     1  ===CLASS EC LD====
Aborted          0  ====CLASS HOST====  Fallbck Term    74  LD No LR         0
Connect Tout   198  Hst NonSpec      0  No XID          67  LD LR Param1     0
Reset DSP        0  HST Busy         0  XID Incmpt       0  LD LR Incmpt     0
                    HST No answr     0  Disc         21448  LD Retrns Lt     0
===CLASS EC Cmd===  HST DTR       3615  DM               5  LD Inactivty     0
Bad Cmd          0  HST ATH          0  Bad NR           0  LD Protocol      0
                    HST NoDialTn     0  SABME Online     0  LD User          0
=====N O N E======  HST No Carr   5276  XID Online       0  
None            39  HST Ack          0  LR Online        0  TOTAL        31728 
HST NoDialTn     0  SABME Online     0  LD User          0=====N O N E======
HST No Carr   5276  XID Online       0  None            39  HST Ack          0
LR Online        0  TOTAL        31728

From the example above, let us say that we are interested in the disconnect category "Disc" within CLASS EC LCL. To determine what the disconnect reason Disc means, go to the entry corresponding to the class (CLASS EC LCL ) and the disconnect reason name (Disc) which shows a hex code of 0x220 and is a normal disconnect.

  • CLASS OTHER

  • CLASS DSP

  • CLASS EC LCL

  • CLASS EC Cmd

  • CLASS EC FRMR

  • CLASS EC LD

  • CLASS HOST

NextPort Disconnect Reason Code Summary Table

Disconnect Reason Type Disconnect Reason: Name Disconnect Reason Code (Hex) Description
CLASS OTHER
2 Software Rst 0x001 Cisco IOS® software disconnected the call for some indeterminate reason (SOFTWARE_RESET).
2 EC Termntd 0x002 Error Correction (EC) layer termination
2 Bad MNP5 Rx 0x003 The Microcom Network Protocol 5 (MNP5) decompression task received an illegal token in the data stream. There is probably a logic error in the implementation of compression, decompression or error correction by the modem or partner. (There is also the possibility of a transient line or RAM memory error.)
2 Bad V42B 0x004 The V.42bis or V.44 decompression task received an illegal token in the data stream. There is probably a logic error in either the modem's or partner's implementation of compression, decompression or error correction. (There is also the possibility of a transient line or RAM memory error.)
2 Bad COP stat 0x005 <reserved>
6,7 ATH 0x006 ATH command detected by local modem. The "ATH" (Hangup) AT command is detected by the local modem (NextPort). For example, following a dialout from IOS, the IOS DTE interface clears the call (by transmitting an inband "ATH" AT command), after the call is connected.
3 Aborted 0x007 AT mode "any key" abort of dial command The AT dial command was aborted by the "any key" abort command. For example, the host modem originates a call. During connection establishment, pressing "any key" will cause the AT dial command to be aborted.
3 Connect Tout 0x008 The call took too long to complete the connection. Notice that the S7 timer (wait for carrier after dial) expired for this disconnect. The causes include:
  • Difficulty choosing (negotiating) a Layer I standard,
  • A combination of Layer I and Layer II establishment taking too long.
For example: error correction negotiation takes an extended amount of time on top of a retrain or because of bit-errors introduced when the client modem tries to connect at an "aggressive" rate (for example, the client modem receiver tries to connect at a rate it can't sustain). This disconnect could also happen if the answer modem heard no tone from the channel (for example, the originator was not a modem).
2 Reset DSP 0x009 DSP was reset (command/internal/spontaneous). The DSP within the host modem was reset by the Control Processor (CP) or Signal Processor (SP). The CP resets the DSP if mail messages from the CP to SP are not being acknowledged. The SP resets itself if it gets an internal inconsistency error.
4,6   0x00C V.42bis or V.44 codeword size exceeded negotiated maximum.
4,6   0x00D V.42bis or V.44 received codeword equal to next empty dictionary entry.
4,6   0x00E V.42bis or V.44 received codeword greater than the next empty dictionary entry.
4,6   0x00F V.42bis or V.44 received reserved command code.
4,6   0x010 V.42bis or V.44 ordinal size exceeded eight.
4,6   0x011 V.42bis or V.44 negotiation error.
4,6   0x012 V.42bis or V.44 compression error.

CLASS DSP
    0x1xx DSP conditions reported by SPE
4,5 No Carrier 0x100 The SPE carrier signal is lost. NextPort detected a client modem carrier drop. The NextPort DSP stopped hearing carrier for a period greater than the value specified in Register S10 (hang-up delay after carrier loss). This could mean that the talk path went away or that the client stopped transmitting. If a layer II protocol (V.42 and/or V.42bis) is in effect, it is abnormal to see such a disconnect. Common causes are users "aborting" the call before a connection takes place. Incidental dialing, aborted starts, and client applications timing out when calls take too long to connect (due to multiple retrains during Layer 1 negotiation.) The carrier lost condition can also occur during normal data mode when the client abruptly drops carrier. The common cause is a non-negotiated or "dirty" disconnect on the part of the client modem (for example, the client modem just drops the carrier signal). This can occur if the link is abruptly dropped (network error), or power is shut off to the client modem disconnecting the call. This can also occur with "cheaper" client modems that do not implement the Layer I and/or Layer II clear-down protocols on a DTR drop. For a large number of client modems, this is considered a normal disconnection.
3 No ABT dtctd 0x101 No answer-back tone detected -- caller is probably not a modem
3 Trainup flrv 0x102 Call failure while modem training up due to incompatible modulation or bad line. This may be indicative of attempts to negotiate an unsupported modulation such as a legacy Rockwell proprietary modulation (K56Plus, V.FC, and so on). Other possible causes are DSP failures to train-up due to severe line impairments, impulse noises, interrupting training, incompatible modulation parameters, and perhaps the inability to properly select a Layer I standard.
4,5 Retrain Lt 0x103 Too many consecutive retrains or speed-shifts. The retrain limit is specified with Register S40. During the progress of a call, too many retrains occurred which rendered the call ineffective since the data rate would be so poor as to be useless. Other possible conditions are the client modem does not complete the clear-down protocol (for example, the Telco tore down the call in the middle of the connection) and NextPort (NP) attempts to recover the call by issuing retrains. Once the retrain limit is reached, NP will drop the call and report this disconnect reason.
3 ABT end flr 0x104 Problem detecting end of Answer-Back Tone(ABT). Negotiation failure or excessive noise during V.34 training. Host modems answer and send out V.8bis and modulated 2100Hz answer back tones (ABTs) with phase reversals, but encounter excessive noise during the trainup sequence. Look for errors on the path from the calling modem to the answering modem in either one or both directions. Similar behavior occurs when there is latency in the Public Switched Telephone Network (PSTN) for dial up that exceeds one second and causes the modems to be unable to train up the echo cancellers. Other possible causes are:
  • The actual TX power levels are incorrect and the tones are then not handled by the remote side.
  • There is too much excessive noise in Phase III and IV during V.34 training.
  • There is operator error.
  • There is network interference during V.34 training (someone picks up the extension).
3   0x105 SS7/COT (Continuity Test) operation completed successfully.
3   0x106 SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for "tone on".
3   0x107 SS7/COT (Continuity Test) operation failed: T8/T24 timeout waiting for "tone off".
4   0x108 Modem On Hold (MOH) cleardown by NextPort. V.92 specifies that the cleardown reason can be:
  • Cleardown due to incoming call
  • Cleardown due to outgoing call
  • Cleardown due to other reason
4   0x109 MOH timeout value reached. This value can be adjusted using Register S62 (V.92 Maximum MOH time).

CLASS EC LCL: EC condition, locally detected
    0x2xx Local Error Correction (EC)conditions.
3 No LR 0x201 During negotiation a Link Request (LR) frame was not received. Peer may not support MNP.
3 LR Param1 0x202 The Received MNP LR frame had bad/unexpected PARAM1. For more information on PARAM1 refer to the V.42 specification.
3 LR Incmpt 0x203 The received MNP LR frame is incompatible with the host modem's settings for EC.
4,5 Retrns Lt 0x204 Too many consecutive retransmissions in EC. This disconnect reason can be caused by noise on the line. For instance, the host modem transmits data to the client modem, but noise on the line causes the data to be received incorrectly (or not at all) by the client side. So excessive noise can lead to excessive retransmissions. The client modem could also have disconnected without the host modem realizing this. So the host modem continuously retransmits, without knowing that the client modem is no longer present. Sometimes, when the call connects in LAPM or MNP, NextPort is unable to transmit a frame to the client modem. The client modem fails to acknowledge NextPort's initial transmission, then fails to respond to Register S19 (Error Correction Retransmission Limit) polls (the default is 12), so NP disconnects the call. One cause could be that the carrier in the transmit path degraded substantially while the client failed to downshift. Another cause could be a problem with the client's EC engine (as would happen on a Winmodem system if Windows stops responding).
6,7 Inactivity 0x205 Inactivity timeout, MNP Link Disconnect (LD) sent. The host modem sends the client modem a LD frame indicating an inactivity timeout has occurred.
4,5 Protocol Err 0x206 EC protocol error. This is a general catch-all protocol error. It indicates that a LAPM or MNP EC protocol error has occurred.
3 Fallbck Term 0x210 No EC fallback protocol available. Error correction negotiation has not been successful. The call is terminated because there is no error correction fallback protocol available. S-register S25 (link protocol fallback ) determines the available fallback protocol. The options are asynchronous framing, synchronous framing, or disconnect (hangup).
3 No XID 0x211 Never received eXchange IDentification (XID) frame during negotiation. Peer may not support MNP.
3 XID Incmpt 0x212 The received XID frame is incompatible with local settings. The client modem may not support LAPM within V.42.
3,4,5 Disc 0x220 Received Disconnect (DISC) frame. This is the normal LAP-M disconnect. The call terminated normally with a proper clear down from the client side. (For example, a V.42 disconnect packet was sent from the client modem to the host modem). The client modem dropped DTR and cleanly negotiated a clear-down protocol.
3,4,5 DM 0x221 Received DM frame. Peer is possibly disconnecting. The client modem indicates that it is disconnecting. During call setup, this reason indicates that the client modem is giving up on negotiating error correction.
4,5 Bad NR 0x222 Bad receive sequence number or ACK number was received. An MNP LD or LAP-M FRMR is sent. The host modem received a LAPM or MNP error correction frame with a bad sequence number or acknowledgment number. An LD or Frame Reject (FRMR) frame is sent to the client modem indicating that the host modem is disconnecting.
4,5 SABME Online 0x224 Received MNP XID frame in steady-state. This is interpreted as a LAPM error correction protocol error in steady state. It means that the client modem may have reset due to receiving a FRMR.
4,5 XID Online 0x225 Received MNP LR frame while in steady-state. This is interpreted as an MNP error correction protocol error in steady state. It means that the client modem has reset.

CLASS EC Cmd: EC detected bad command code
4,5 Bad Cmd 0x3xx EC detected bad command code. The received unknown command is in the last 2 digits. An MNP LD or LAP-M FRMR frame is sent in response.

CLASS EC FRMR: EC detected FRMR from peer
4,5 0x4xx EC conditions indicated by client in LAP-M FRMR frame. The bit-mapped reason is in the last two digits.
4,5 Frmr Bad Cmd 0x401 LAPM: peer reports bad command. The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad command.
4,5 Frmr Data 0x403 LAPM: peer reports that data field is not permitted or is incorrect length (U frames). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a data field that is not permitted or contained a data field with an incorrect length (that is, U frame).
4,5 Frmr Length 0x404 LAPM: peer reports data field length is greater than N401 (the maximum information field length specified in V.42), but has good Frame Check Sequence(FCS). The NextPort modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from NextPort that contained a data field length that is greater than the maximum number of octets that can be carried in the information field (N401) of an I frame, an SREJ frame, an XID frame, a UI frame, or a TEST frame. The frame check sequence is good.
4,5 Frmr Bad NR 0x408 LAPM: peer reports bad receive sequence number or N(R). The host modem received a FRMR frame from the client modem. The received FRMR frame indicates that the client modem received an error correction frame from the host modem that contained a bad receive sequence number.

CLASS EC LD: Error Correction (EC) detected Link Disconnect (LD) from peer
4,5   0x5xx EC conditions indicated by client in MNP LD frame. Reason field is in the last 2 digits
3 LD No LR 0x501 MNP: peer never received LR frame. The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem never received a link request from the host modem.
3 LD LR Param1 0x502 MNP: peer reports Link Request (LR) frame has bad parameter #1 The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem received a link request frame from the host modem that contained a bad (i.e. unexpected) PARAM1. For more information on PARAM1 refer to the V.42 specification.
3 LD LR Incmpt 0x503 MNP: peer reports LR frame is incompatible with its configuration The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem received a link request (LR) frame from the host modem that is incompatible with the configuration of the client modem.
4,5 LD Retrns Lt 0x504 MNP: peer reports too many consecutive EC retransmissions The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received too many consecutive retransmissions.
4,5 LD Inactivty 0x505 MNP: peer reports inactivity timer expired The host modem received a Link Disconnect (LD) frame from the client modem. The received LD frame indicates that the client modem's host (DTE) hasn't passed data to the client modem within a period of time.
3 LD Protocol 0x506 MNP: peer reports error The host modem received a LD frame from the client modem. The received LD frame indicates that the client modem received a MNP protocol error.
3 LD User 0x507 Normal MNP disconnect The host modem received a LD frame from the client modem. The received LD frame indicates a normal MNP termination.

CLASS HOST: Requested by host
6,7 0x1Fxx Host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the other host terminate reason. The host reason is indicated in the low order bytes "xx".
3,6,7 HST NonSpec 0x1F00 Non-specific host initiated disconnect. Value is a sum of 0x1F00 and SessionStopCommand value. This is the "catch all" IOS initiated disconnect reason. It is used for all non-standard disconnects. For example, this could be a result of modem management software deciding to terminate the call. One possible explanation is a higher-level authentication failure RADIUS, TACACS, or another application issuing a DTR drop to the host modem. This type of disconnect will not count towards CSR when the host modem is in data mode.
3 HST Busy 0x1F01 Dialed number was busy. Disconnection has occurred because the host is indicating that the dialed number is busy.
3 HST No answr 0x1F02 Dialed number did not answer. Disconnection has occurred because the host is indicating that the dialed number didn't answer.
3,6,7 HST DTR 0x1F03 "Virtual" DTR dropped. This status is "reflected" from the "I/O port redirector" which is currently using the modem. Disconnection has occurred because the host dropped the "virtual" DTR line. This generic disconnect cause is initiated by the Cisco IOS software. Example causes are idle timeout, PPP LCP TERMREQ received, authentication failure, Telnet hangup, and so on. To determine the reason for the hang up, examine the "Radius" disconnect reason from the modem call-record terse command or from Authentication, Authorization, and Accounting (AAA).
6,7 HST ATH 0x1F04 "ATH" (hangup) command was detected by local host.
3 HST NoDialTn 0x1F05 No access to telco network. Disconnection has occurred because the host couldn't access the network (such as ISDN).
3,4,5 HST NoCarr 0x1F06 Network indicated disconnect. This is a client side triggered disconnect that is not a graceful call termination. It can occur during call set-up. A common cause is when users of Windows 95 or Windows 98 Dial Up Networking (DUN) hit "cancel" before the call reaches steady state. Another common reason is any client instigated DTR drop before steady state. During data mode, this is also a client side triggered disconnection that is not a graceful call termination (that is, a "dirty" disconnect). One very common cause is authentication failures.
3 0x1F07 NAS terminated SS7/COT operation. Disconnection has occurred because the NAS has terminated the SS7/COT (Continuity Test) operation.
3 0x1F08 The SS7/COT operation was terminated by the router because of a T8/T24 timeout.
- 0x1FFF Unsolicited TERMINATING. The host sends this disconnect reason when it receives a unsolicited terminating message.

Disconnect Reason Types

Disconnect Type Description
0 (unused)
1 - 0x2... (unused)
2 - 0x4... Other situations
3 - 0x6... Condition occurred during call setup
4 - 0x8... In data mode. Rx (line to host) data flushing OK
5 - 0xA... In data mode. Rx (line to host) data flushing not OK (at present, applications should not be concerned about the "not OK")
6 - 0xC... In data mode. Tx (host to line) data flushing OK
7 - 0xE... In data mode. Tx (host to line) data flushing not OK (at present, applications should not be concerned about the "not OK")

Related Information

Updated: Feb 04, 2010
Document ID: 9502