Whether you have a dial up connection to an internet service provider or you have built your own home network, there will be occasions where you have problems communicating with a remote location. This may be due to a number of different factors, the other computer may not be switched on, the application server is down, there is a fault in the communications link somewhere, or one of any number of other factors. When the other computer is connected to your home network you have control of the situation and can rectify things once you figure out what is wrong. If the computer you are trying to access is located elsewhere then you probably can't fix things yourself but you can at least determine where the problem is.
Two commands that are useful to know about are ping and tracert. If you open a command prompt on your computer and use these commands you can determine whether the problem is that you can't communicate with the other computer or whether the problem is with the application that you are trying to access on the remote computer. Some ISPs block access to one or both of these commands so a failed result from either of these commands does not necessarily mean that their communication link is down but if both of these commands and your application (web server, ftp program or whatever) all fail to connect then chances are that their system is down.
Both of these commands are used the same way. You type in the command followed by the ip address of the site that you want to check. (You can use the domain name instead of the ip address if you have added it to your local domain name table.) For example if I want to test the connection to an imaginary web site called www.xyz.com that has an ip address of 22.214.171.124 I can type in:
and the response that I should get if the remote computer is answering will be something like this:
Pinging 126.96.36.199 with 32 bytes of data: Reply from 188.8.131.52: bytes=32 time<10ms TTL=128 Reply from 184.108.40.206: bytes=32 time<10ms TTL=128 Reply from 220.127.116.11: bytes=32 time<10ms TTL=128 Reply from 18.104.22.168: bytes=32 time<10ms TTL=128
If the remote system is down or has been set up to ignore the ping command then the result will be like this:
Pinging 22.214.171.124 with 32 bytes of data: Request times out. Request times out. Request times out. Request times out.
To test the link using tracert you do similarly. To test the link to the computer on your local network located at ip address 192.168.0.3 you would type in:
If that computer is running and the network link between the two computers is working then the result that you get back should be something like this:
Tracing route to YOUR-COMPUTER [192.168.0.3] over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms YOUR-COMPUTER [192.168.0.3] Trace complete.
If you run this command against a remote address then you can get up to thirty lines of output showing you the path that your request to that computer has followed through a number of other computers. For example if we use tracert on our imaginary web site from before we might get the following result:
Tracing route to 126.96.36.199 over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms YOUR-COMPUTER [192.168.0.3] 2 <10 ms <10 ms <10 ms WWW.ISP.COM [188.8.131.52] 3 <10 ms <10 ms <10 ms WWW.XYZ.COM [184.108.40.206] Trace complete.
If the link to our local computer is not working then we will get a result similar to the following:
Tracing route to 192.168.0.1 over a maximum of 30 hops 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. . . . 29 * * * Request timed out. 30 * * * Request timed out. Trace complete.
If the tracert is being used to check a remote computer then the first few entries may show that there is a connection but subsequent entries may show request timed out. Where this happens you then know how far your request is getting before the communication link failure is occurring.
If one or both of the ping and tracert commands shows that you do have communications working properly with the remote site then you know that the problem is not in the actual network communication between the two computers. If it is a remote site over the internet that you are trying to access then this means that there is a different problem such as: they have their application server program stopped at the moment, they don't offer the particular application you are trying to access, or your firewall is set to block that application.
This article written by Stephen Chapman, Felgall Pty Ltd.