This note discusses, in a step by step manner, the methods for finding TCP/IP and NetcomRouter Configuration Problems. Many of the issues are not NetcomRouter specific, but rather are encountered when a second IP interface is added to a machine. This is frequently the situation when adding NetcomRouter.
This application note assumes that you are testing the link with a ping to the remote host.
Make sure the X.25 line is functional.
Use the xpad program provided with Netcom II to call a remote host such as the test number provided by your network provider or tsgfred, the gateway machine at The Software Group. If you can not successfully make calls with xpad, you will not likely get any further with NetcomRouter. The Netcom II Administrator's Guide contains a section on Troubleshooting.
Does ping print error messages on the screen?
Since NetcomRouter is "down the stream" from applications like ping, it doesn't directly print messages on the user's screen. Therefore, if you see messages on the screen, you can probably ignore the NetcomRouter configuration files and utilities and concentrate on the TCP/IP setup.
Pay particular attention to error messages like:
sendtohost: No route to networksendtohost: No route to hostHost is unreachable
This indicates that IP does not know how to get to the remote host. Most likely this is a problem with the local IP addresses. See step 5 below.
Determine whether the problem is with the local host or the remote.
On one session (or in the background if necessary)
run xtrace -s80 -p -I > /tmp/tracefile
On another session, ping the remote host. After letting it try for a few seconds, stop xtrace and take a look at tracefile. The first thing to look for is a Call Request. If you do not see one, it means that the remote host is not yet involved, so the problem must be in the local configuration. Continue with step 4 below.
If you do see a call request, then the next thing to look for is a Call Accept. If you get a Call Clear instead, verify the calling (if it is filled in) and the called addresses. Next, look at the diagnostic code and whether the clear was transmitted or received. The Netcom II Administrator's Guide has a complete list of diagnostic bytes in an appendix, but here are a few common ones encountered with NetcomRouter:
A9 or AC
These diagnostics are used when the remote host is also a NetcomRouter installation and the remote host does not have your machine in its configuration table. For security reasons, the configuration table must contain the hosts that you wish to accept calls from (not just who you want to place calls to). See the discussion of x25route in step 4 below.
31
This diagnostic is used in transmitted call clears when the local machine times out waiting for a call accept. Usually this problem occurs when the number of virtual circuits (bwc_num) in the link configuration file is larger than that assigned by the network provider.
If you get a call accept, the next thing to look at is IP datagrams. As soon as the call is accepted, you should see data packets containing IP information being transmitted to the remote host. Does the remote host send any IP data back? If not, then the problem is likely with the IP address setup on the remote machine. See step 5 below and refer to the addresses and interfaces on the remote machine. If the remote host does respond with IP datagrams (but ping is not getting them), then they are being discarded as they go back up the stream to IP. Most likely this is a problem with the IP address in the datagrams. Check to make sure that the source and destination addresses shown in tracefile are correct.
No attempt to send anything to the other host.
Now we have to determine if it is in the IP configuration or in the NetcomRouter configuration. First, run:
x25route dump
Make sure that the host that you are trying to reach is in the table. If it is not, then NetcomRouter will not know what X.25 address to call to deliver the data. Also, make sure that the X.25 address is correct and that the correct network has been selected. If it is not, then you will have to change /etc/x25hosts or delete/add an entry. Next, check that the network is associated with the right board and link number (or device in the case of Netcom II/Streams) in the file /etc/x25networks. If this is incorrect, NetcomRouter may be placing a call, but on the wrong wire. If you make any changes to these configuration files, you will have to rerun "x25route add all" to bring them into effect.
If the information displayed by the dump is all correct, continue with step 5.
Proper IP address selection.
Depending on where you have determined the problem to be in the previous steps, you may need to look at the IP configuration on the local machine or in the remote. Run the command: netstat -in and look at the address of each IP interface and determine the IP class:
| Network type |
First byte is |
Network portion |
|---|
| Class A |
0 to 127 |
first byte |
| Class B |
128 to 191 |
first two bytes |
| Class C |
192 and up |
first three bytes |
Note that the above rules can be overridden by netmasks that extend the network portion of the address, but the following discussion still applies.
The reason for the importance of understanding the network portion of each address is that IP uses this to select the interface used to deliver the IP information. For example, if I which to send data to address 192.52.238.5 (a class C address), then IP will choose the interface that has been assigned an IP address starting with 192.52.238 (one with the first three bytes the same). If no interface with this address exists (and not explicit routes have been added) then IP will discard the data. If more than one interface matches this (such as the ethernet interface and an xinet interface), then IP does not know which interface to choose. The data may either be discarded or it may be sent to the wrong interface.
Stated as a rule: the network portion of the IP address of every interface in your machine must be different.
If the network portion if the address you are trying to reach matches exactly one interface in the configuration, then make sure it is a NetcomRouter device, xinetN.
Finally, run the command:
netstat -rn
and check the routes to the network corresponding to the host you wish to contact. The class rules outlined above form the "default" methods of determining how to reach a host. These rules can be overridden by routes either run explicitly (perhaps in a boot script) or setup invisibly by the TCP/IP daemons routed and gated.
The above is a very quick overview on choosing good IP addresses. The NetcomRouter User's Guide contains a much more complete description of how to design a network.