It happens to all of us. You try to visit a website, and all you get is a blank page, with a slowly spinning wheel of death in the browser tab. Why can’t you connect? The cause of your problem could lie at any of several locations between you and the website. Here, I will tell you how to find exactly where it is. (The following commands are available in both Unix/Linux and Windows/DOS, so they will probably be applicable with whatever operating system you are using.)
Let’s say you’re trying to get to wordpress.com and you encounter connectivity problems. First, you need to test your network interface card (NIC) to see if it’s working. You do this by testing the loopback interface, which is represented by the IP address 127.0.0.1.
# ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.065 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.051 ms --- 127.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.051/0.056/0.065/0.005 ms
Looks like the interface is working. If you ping an address and you get a message than says
network timeout or something similar, you know you’ve encountered a dead link. Remember that there are several links, several components, that must work, and if just one of them fails, the entire connection fails.
The next step is to ping the local gateway. To do this, we can take advantage of the fact that on most home and SOHO networks, the local gateway is also the default DNS server. We find the IP address of the local DNS server with the
nslookup is an interactive program for interacting with DNS servers. It is a simple program with only a handful of commands. The only commands we will need here are
# nslookup > host Server: 126.96.36.199 Address: 188.8.131.52#53 > exit
Now we ping the local DNS server to see if we can connect to it. If we can’t, one of two things is happening: either the default gateway isn’t working properly, or the connection between our computer and the default gateway is not working.
# ping 184.108.40.206 PING 220.127.116.11 (18.104.22.168): 56 data bytes 64 bytes from 22.214.171.124: icmp_seq=0 ttl=58 time=25.159 ms 64 bytes from 126.96.36.199: icmp_seq=1 ttl=58 time=29.576 ms 64 bytes from 188.8.131.52: icmp_seq=2 ttl=58 time=20.783 ms 64 bytes from 184.108.40.206: icmp_seq=3 ttl=58 time=20.518 ms --- 220.127.116.11 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 20.518/24.009/29.576/3.705 ms
So that’s working. Now what we have to do is see if the default gateway can connect to the Internet. We do this by pinging one or more websites that are not the website we tried to visit, like say, google.com, yahoo.com, amazon.com, etc. If these are working, we proceed to the next step.
The next step is to ping the host we are trying to reach. If this is not working, we know that there’s a problem with that server.
# ping wordpress.com
Let’s say that works. Now we proceed to the final step. If all of these links work, then we know it’s probably a problem with the particular port we are trying to access. Let’s say we are trying to go through HTTP. The port number for HTTP is 80. To test a port we need a different tool – the Telnet protocol. Telnet can be used to access any port on a remote host. In this case we are using it to test that port. The command is as follows:
# telnet wordpress.com 80 wordpress.com:80: nodename nor servname provided, or not known
Okay, maybe it wouldn’t look exactly like that, but I couldn’t completely replicate the problem to get the proper error message.
Anyway, now we have found our problem. Port 80 isn’t working. We can either wait for it to start working again, or write to the owners of the server to inform them of the problem.