Other Configuration Problems

The following symptoms may indicate that there may be a mistake in the configuration:

• Network does not come up

• X.25 link layer does not come up, or does not stay up

• Inability to establish a packet level connection--for example PAD calls fail

• Link is up but not responding correctly

• Repeated Resets are being received

Check the following:

1. Make sure you specified the correct serial port when you ran x25tool or edited the configuration file. Refer to "Configuring a Single WAN Link" for how to configure this using x25tool.

2. For LAPB links, check that the link is configured as a DTE if communicating over a PSDN.

3. Facilities and other parameter mismatches, between your machine and the PSDN, can prevent the establishment of virtual circuits. Check the Negotiate Toward Defaults item in the Link Editor, Throughput window. For the majority of PSDNs this should be set to No.

4. Check where calls are being cleared from. If you receive an error code of the form 00 nn, the leading zeroes indicate the call-clearing request originated with the remote host. If the first two digits are not 00,the call-clearing request originated in the PSDN.

5. If you receive an error code of 0x00 43, check that your X.121 address is specified correctly. If it is, check to see whether there is a process listening for an incoming call.

6. If you receive error code 0x00 42, it is likely that your maximum I-frame size, an LAPB-layer parameter, is set incorrectly for your link. The maximum I-frame size is a subscription option to the PSDN. When LAPB is in extended mode, set this parameter eight bytes larger than the default packet size parameter at the packet level.When LAPB is in normal mode, set it five bytes larger. If Solstice X.25 receives a Call Request with a packet size that is within eight bytes (or five bytes) of the maximum I-frame size parameter, the X.25 software clears the call with the 0x00 42 diagnostic. Modify your LAPB parameters as necessary.

7. If you receive error code 0x00 70, check your console to see if you have a licensing problem.

8. If you can find out about the remote host, check that it is still up.

9. If you are running IP over X.25, run ifconfig commands to check on your ixe device (for example, zsh0). Use of ifconfig is described in "Checking the Protocol Status ". If the response from ifconfig is UP, POINTOPOINT, and RUNNING, check with your PSDN to see if there is a problem at the network end.

10. Run x25trace to trace the exchange of X.25 packets across the link. People who are familiar with the X.25 Packet Layer Protocol can interpret the output from x25trace to determine where errors are occurring. The x25trace command is described in "Obtaining Packet and Link-Level Traces".

11. If you receive a message from PAD such as, i/o error, open /dev/x25 failed, it might indicate that the X.25 network daemon is down. Check the status of the daemon in x25tool. This message may also indicate that there are two many simultaneous PAD calls for the software to cope with. Wait a moment, then try again.

12. If you experience intermittent disconnections or resets, check for configuration errors in your link configuration file. At the packet level, make sure that the window and packet size parameters agree, between your machine and the PSDN.

13. If you receive repeated RESETS with error code 0x0092, there may be a window size mismatch.

14. Perform a loopback test, to check your local configuration down to the link layer.

15. Perform a back-to-back test, to test your configuration against that of another machine.

For error code descriptions, refer to Appendix C, Error Messages and Error Codes.