Common Problems

This section lists various symptoms of common problems and the associated solutions.

• The number of the configured X.25 interfaces displayed by X25CON is incorrect.

  Cause 1 ---Board is misconfigured.

  • In NIASCFG under Configure NIAS > Protocols and Routing > Boards, verify that each board is configured and enabled.
  • In NIASCFG under Configure NIAS > Protocols and Routing > Network Interfaces, verify that the media type of a specific board is X.25-HOST.

  Cause 2 ---Board driver did not load.

  To determine whether a problem occurred while loading the WAN driver (SYNCPLUS.LAN, NW2000.LAN, ARTIC.LAN), check the console log using NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing >View Configuration > Console Messages). The driver is not loaded under the following circumstances:

  • A particular WAN driver is not installed.
  • There is a conflict in the board configuration, such as interrupt level, base I/O address, and memory base address.
  • A port registration failed because the version number of the configuration record is not the one expected by X25TSM. In this case, you need to re-create a specific configuration record.

  Correct the problem and issue the REINITIALIZE SYSTEM command. Attempt the connection again.

• The port status shows unavailable after Novell Internet Access Server 4.1 is running.

  Verify that AIOPAD.NLM is loaded.

• The number of active X.25 interfaces displayed by X25CON is less than the number of X.25 interfaces configured. The number of active X.25 interfaces represents X.25 interfaces whose Link layer is up and running. Therefore, if this number is less than the number of the X.25 interfaces configured, the Link layer of some X.25 interfaces failed to initialize.

  Load X25CON, select X.25 Interface, identify the interface whose Link layer is in the Down state, and take corrective actions, as described in The Link layer is in the Down state.

• The Physical layer is in the Down state.
  • Check the cabling. Make sure the cable from the adapter to the modem is seated correctly.
  • Check the configuration as follows:

    Clock Source

    Check whether the clock source is configured correctly. When the transmit and receive clocks are supplied externally (that is, from a DSU/CSU or DCE), then Interface Speed should be configured as External.

    To supply the transmit and receive clocks internally in the back-to-back testing environment, you must use the appropriate crossover cables, as described in Back-to-Back Testing in the Overview documentation. When these cables are used, only one side should be configured to generate the transmit and receive clocks.

    Port Connection

    If a leased line is used for connection between the NetWare server and the DCE, the Port Connection option should be configured as Hard-wired. When a DTR dialed modem is used, the Port Connection option should be configured as DTR Dialed.

  • Check whether the correct cable is used for the specific revision of the Synchronous/+ adapter board. Different cables are required for Rev. D and Rev. E of the Synchronous/+ adapter board.
  • Check the modem as follows:

    CSU/DSU

    Check whether the hardware options are set correctly.

    Perform local and remote loopback tests and verify that the CSU/DSU is functional.

    DTR Dialed

    Check whether the modem dials when the DTR is raised. If it does not, then you used the wrong type of modem.

    Check whether the modem is programmed with the correct phone number.

    Verify the phone number.

• The Link layer is in the Down state.

  • Cause 1 ---Link Layer Address is not properly configured.

    Load X25TRACE and select Decode mode for the display of frames. Make sure that the Set Asynchronous Balanced Mode (SABM) frames transmitted and received contain two different Link-layer addresses (03 or 01). If the same address is included in the SABM frames transmitted and received, reconfigure the Link-layer address with the correct one and issue the REINITIALIZE SYSTEM command.

  • Cause 2 ---Two different values are configured for the Link-layer modulo at the DTE and DCE (for example, modulo 8 and modulo 128). This prevents the Link layer from initializing.

    Make sure that both the DTE and DCE are configured with the same modulo.

  • Cause 3 ---No response from the DCE.

    Load X25TRACE and select Decode mode for the display of frames. Check whether the local DTE is receiving any frames from the DCE. If the local DTE does not receive any frames from the DCE, then you should notify the network administrator of the problem.

• The Packet layer is in the Down state.

  The Packet layer enters the Up state on completion of a restart procedure. This procedure is initiated when the Link layer is reinitialized. Therefore, if the Packet layer is in the Down state for an extended period of time after the Link layer is initialized, this usually indicates that one of the following Packet-layer parameters is not configured properly.

  Suppress Restart Packet

  When the Suppress Restart Packet option is enabled, the Packet layer does not transmit a Restart Request packet on completion of the Link-layer reinitialization. Instead, it waits until the DCE or remote DTE initiates the restart procedure. Make sure that the Suppress Restart Packet option is not enabled on both sides. Typically, it is the DTE that initiates the restart procedure.

  Packet Sequencing Modulo

  Check whether both the DTE and DCE are configured with the same packet sequencing modulo. Because the format of the Restart Request packet of modulo 8 is different from that of modulo 128, the incoming Restart Indication packet is ignored if the DTE and DCE are configured incorrectly.

  Extensive Restart Request Timer (T20)

  When a Restart Request packet collision occurs, the station that transmits the Restart Request packet last must retransmit the Restart Request packet on expiration of the T20 timer. Therefore, we recommend that you do not configure the T20 timer timeout value for longer than three minutes. This is the ITU-T recommended default.

• There is call connection failure. When a call setup procedure fails, an error message is displayed on the console.

  The corrective actions that need to be taken are dependent on the circuit type, the cause code, and the diagnostic code, as described in the following sections.

  Permanent Virtual Circuits

  • Check whether the protocol is properly bound to the WAN interface. You can verify this by entering the CONFIG command at the console.
  • Check whether the WAN call destination is specified for both ends. Unlike when an SVC is used, the call setup procedure should be initiated by both ends when the associated circuit is a PVC. If the call setup procedure is initiated at one side only and there is an attempt to transmit data, the virtual circuit is reset. A cause code of zero (DTE originated) and a diagnostic code of D1 in hexadecimal are included in the Reset Request packet.
  • Check whether the PVC number specified in the associated WAN call destination is within the PVC range configured for the associated interface.
  • Check whether the PVC range assignment is the one agreed on with the network or the remote DTE in the DTE-to-DTE environment.
  • Check whether the destination of a specific PVC is the one specified when you subscribed to the network.

  Switched Virtual Circuits

  • Check whether the protocol is properly bound to the WAN interface. You can verify this by entering the CONFIG command at the console.
  • Check whether the LCN range assignment is the one agreed on with the network or remote DTE in the DTE-to-DTE environment. The incoming call is ignored by the called DTE when it is received with an LCN assigned to a PVC or with an unassigned LCN.

    Therefore, if the calling DTE does not receive any response (either a Call Connected packet or a Clear Indication packet) until the Call Response timer (T21) is expired, this usually indicates that the LCN range assignment is not compatible between either the local DTE and remote DTE or the local DCE and remote DTE in the DTE-to-DTE environment. The calling DTE transmits a Clear Request packet with the cause code of 0x13 and the diagnostic code of 0x31 when the Call Response Timer (T21) expires.

  • Examine the entries of the X.25 Cleared Circuit Table using X25CON (parameter path: Select Cleared Circuit Summary). Take corrective actions, as described in Table 5 and Table 6, depending on the cause and the diagnostic codes included in the Clear Request/Indication packets.

• There are failures during the data transfer. These failures result from a Link-layer problem.

  Cause 1 ---Excessive number of Receive Not Ready (RNR) frames are transmitted. The NetWare Link/X.25 Link layer transmits an RNR frame on detection of a local busy condition. In the Novell Internet Access Server 4.1 and NetWare Link/X.25 environment, if the X.25 software cannot allocate a packet receive buffer (ECB), this is considered as a local busy condition.

  Therefore, if the local DTE transmits an excessive number of RNR frames, it is imperative that the maximum number of packet receive buffers be increased.

  Cause 2 ---Excessive number of RNR frames are received. If the local DTE receives a large number of RNR frames, this indicates that the DCE or remote DTE cannot handle the traffic generated by the local DTE.

  Therefore, if this problem is observed, reduce the Link-layer window size, the Packet-layer window size, or both.

  Cause 3 ---Excessive number of reject frames are transmitted. The DTE/DCE transmits a reject frame when it receives an I frame that is out of sequence. When a large number of reject frames are transmitted, this indicates that incoming I frames are lost or discarded. The frames can be lost because of one of the following reasons:

  • MONITOR shows a large number for the No ECB Available Count statistic. The reason is that the driver is discarding the incoming I frames because it cannot allocate an ECB. In this case, increase the Maximum Packet Receive Buffer value to correct the problem.
  • MONITOR shows a value of zero for the No ECB Available Count statistic. The reason is that there is a misconfiguration of the Maximum I Frame Size (N1). When the driver receives a frame whose size is greater than the configured Maximum Physical Receive Packet Size, it discards the frame. Reconfigure the DCE's N1 value so that it is less than the Maximum Physical Receive Packet Size of the server.
  • MONITOR shows a value of zero for the No ECB Available Count statistic. The reason is that there are CRC errors due to a noisy link, which is caused by malfunctioning hardware. In this case, MONITOR also displays a high number of checksum errors. Contact your ISP to solve the problem.

  Cause 4 ---Frame Reject (FRMR) frame is transmitted or received. When the DTE or DCE detects an error condition that is not recoverable by the retransmission of the identical frame, it transmits an FRMR frame. Upon receipt of an FRMR frame, the DTE or DCE reinitializes the Link layer by transmitting an SABM frame. In this case, all SVCs are cleared and all PVCs are reset.

  When the link is reset during the data transfer, check whether the local DTE receives or transmits an FRMR frame; you can do this by selecting the Link Layer Flow Table option of X25CON. The error condition that results in a link reset is specified in the third byte (or fifth byte for modulo 128) of the FRMR Information field, as follows:

  01---The DTE/DCE received an unidentified frame. This problem can occur when the Link-layer sequencing modulo is not configured properly.

  02---DTE/DCE received a frame with an information field that is not permitted, or it received a supervisory or unnumbered frame with an incorrect length.

  04---The information field received exceeded the specified N1.

  08---An I frame with an invalid N(R) was received.

  Cause 5 ---Excessive value for the T1 Timer Expired statistic. The DTE or DCE retransmits a frame when the T1 timer expires before it receives an acknowledgment. Therefore, if the X25CON Link Layer Flow Table displays a large number of T1 expirations, either the data link is noisy or an insufficient T1 timeout value is set.

  Reconfigure the T1 value or contact your ISP.

  Cause 6 ---Over Queue Limit has been exceeded. One transmit queue is provided for each X.25 interface. The X.25 software (X25TSM) discards the user message when the total number of transmit messages exceeds the specified queue limit. MONITOR displays the number of messages that have been discarded because of a queue overflow condition (Over Queue Limit).

  Increase the Interface Queue Limit value for the associated X.25 interface in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select a specific X.25 interface).

  Cause 7 ---User Data Size value is too large. The X.25 software discards the message when a user attempts to transmit a message whose size is greater than the configured User Data Size or the Maximum Physical Receive Packet Size. In this case, the console displays the following error message:

  Attempt to transmit a packet that is greater than maximum packet size configured on the board X25_1(packet size = 2048, maximum packet size = 1507). Packet will be discarded.
  • Increase the User Data Size value or the Maximum Physical Receive Packet Size value. You can reconfigure the User Data Size with NIASCFG and the Maximum Physical Receive Packet Size with the SET command.
  • Reduce the User Data Size value.

• The virtual circuit has been reset. The console displays the following error message: Virtual circuit reset on the board board_name LCN lcn. Cause: 0x13, Local Procedure Error. Diagnostic: 0XA6, D-bit Procedure not Supported.

  The appropriate corrective action depends on the cause code and diagnostic code that is displayed. Refer to Table 5 and Table 6.

• There is no apparent cause for an error message that is received after WSM.NLM is automatically loaded. The following message appears: SERVER-4.10-30: This modulo is using 6 outdated API calls. You should upgrade to a newer modulo when it becomes available.

  No action is necessary. This message is erroneous.

• A permanent WAN call destination has the Retry Mode option set to Never Retry; however, when the link goes down, there is one attempt to reestablish the link.

  This is normal operation. The Retry Mode option does not influence the operation of the network protocol stacks. Therefore, when a permanent link goes down, the network protocols make one attempt to reestablish the link.