Dealing with connectivity problems, several software tools come in our help. Anyway, first of all, remember that many times the impossibility to connect is caused by a phisical problem, such as a cable not well plugged in or broken. So, faceing connection problems, the first thing to do is not to panic! The second thing to do is controlling that all the cables are in the right place, they are firmly plugged in their docks, and they are active, that means, by ethernet cables, when you plug the cable into the machine's plug, a led starts to light.
Ping is the name of a computer network tool used on TCP/IP networks (such as the Internet). It provides a basic test of whether a particular host is operating properly and is reachable on the network from the testing host. Ping estimates the round-trip time and packet loss rate between hosts. It works by sending ICMP "echo request" packets to the target host and listening for replies (ICMP "echo response" packets).
Basically, ping simply asks to another machine "Hello, are you there?" and, if so, gets a response. That is very simple, but thanks to ping we can understand a lot of different things. Mainly ping helps us in the localisation of the problem: in the Local Area Network, between the local network and the Internet, between the Internet and the host we want to reach. Ping also tells us how reliable the connection is, how slow the latency, and if we face a simple DNS problem.
The Ping command is activaded by the shell (console, terminal) environement, and the usage is similar to all the operating systems.
On Microsoft operating systems, you will access it opening a "command" window and permorfming the ping command, in Macintoh and GNU/Linux OSs, we will open a normal shell (terminal) environement. To stop the ping command we simply press the Ctrl + c keys.
The only syntax difference is that, in Microsoft OS, by default ping only issues 4 ICMP requests and than stops. We will have to add a -t option, if we want ping not to stop.
(Microsoft OS) C:\>ping -t host
(Macintosh and GNU/Linux OS) user@host:~# ping host
If we ping our standard gateway:
user@host:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=62 time=5.96 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=62 time=67.6 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=62 time=6.35 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=62 time=6.60 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=62 time=6.60 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=62 time=7.65 ms
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4997ms
rtt min/avg/max/mdev = 5.968/16.799/67.604/22.726 ms
From the result we can understand:
- the host 192.168.1.1 (in this case our gateway) is on and we are able to reach it (we get a response)
- it takes approximately 6ms (milliseconds) to receive a response once we send a packet (time)
- no packet was lost (the icmp_seq grows without interruptions, in the result statistics, "packet loss" is 0%)
If you assured yourself that the IP you're pinging is effectively the gateway's own IP, and you still get no response, that means the problem has to be localized in the Local Area Network. Revise your cables, and then the connection settings of your computer, as described in the DHCP and fixed IP section!
Now let's see if the gateway forwards our requests to the Internet:
user@host:~# ping streambox.org
PING streambox.org (83.137.99.39) 56(84) bytes of data.
64 bytes from 83.137.99.39: icmp_seq=1 ttl=54 time=125 ms
64 bytes from 83.137.99.39: icmp_seq=2 ttl=54 time=35.2 ms
64 bytes from 83.137.99.39: icmp_seq=3 ttl=54 time=36.0 ms
64 bytes from 83.137.99.39: icmp_seq=4 ttl=54 time=36.9 ms
64 bytes from 83.137.99.39: icmp_seq=5 ttl=54 time=34.5 ms
64 bytes from 83.137.99.39: icmp_seq=6 ttl=54 time=37.9 ms
64 bytes from 83.137.99.39: icmp_seq=7 ttl=54 time=47.1 ms
64 bytes from 83.137.99.39: icmp_seq=8 ttl=54 time=46.2 ms
64 bytes from 83.137.99.39: icmp_seq=10 ttl=54 time=82.9 ms
64 bytes from 83.137.99.39: icmp_seq=11 ttl=54 time=35.4 ms
64 bytes from 83.137.99.39: icmp_seq=12 ttl=54 time=67.1 ms
64 bytes from 83.137.99.39: icmp_seq=13 ttl=54 time=35.9 ms
64 bytes from 83.137.99.39: icmp_seq=14 ttl=54 time=35.9 ms
--- streambox.org ping statistics ---
14 packets transmitted, 13 received, 7% packet loss, time 13009ms
rtt min/avg/max/mdev = 34.547/50.541/125.360/25.799 ms
From the result we can understand:
- the host streambox.org is on and we are able to reach it (we get a response), so our requests are forwarded to the Internet, everything is working fine!
- the latency is between 35ms and 82ms (milliseconds)
- some packets were lost (the icmp_seq has an interruption between number 8 and 10, in the result statistics, "packet loss" is 7%), but in a still acceptable margin
If you get no response, but you can ping the gateway, the first thing to do is to ping a host that is 100% reliable, such as "w3c.org".
- if you get a response that means the host you first tried to ping is "offline", but your Internet connection if working fine
- if you do not get a response, the problem still could be in the DNS area
In this last case, let's verify if we are faceing a DNS problem: to do so we will ping an IP, insted of a domain name. An easy-to-remember and reliable IP is 141.20.1.3, the one used by the Humbolt University in Berlin.
- if you get a response that means your Internet connection is working fine, you will only have to assign to your computer a new DNS IP, as we learned in the DHCP and fixed IP section
- if you do not get a response, the problem has to be localized between our Local Area Network and the Internet
In this case, contact the administrator of the LAN explain him/her the problem, that could be found in erroneous gateway settings, cables unplugged in the gateway, or, more simply, the ISP "cutted" the connection!
Another useful connection tool, based on the same principle than ping, is traceroute. Basically, traceroute not only "pings" an host, but shows you also all the machines that stay in between your computer and the computer you want to ping, the route that a packet is takeing to contact another machine. This gives you the opportunity to understand where your packets are going through and how much time they need to go from every single host to another.
To perform the traceroute command, you will have to open a shell (terminal), and write the command:
(Microsoft OS) C:\>tracert host
(Macintosh and GNU/Linux OS) user@host:~# traceroute host
More reliable traceroute variants, merging the utility of traceroute and of ping in a single tool, are the pathping command for Microsoft OS and mtr for GNU/Linux and Macintosh OSs.
mtr combines the functionality of the 'traceroute' and 'ping' programs in a single network diagnostic tool. As mtr starts, it investigates the network connection between your computer on and a destination host you specified. Then, it reveals the address of each network hop between the machines, and sends a sequence of ICMP ECHO requests to each one, in order to determine the quality of the link to each host. Meanwhile, it shows running statistics about each machine.
To perform the traceroute command, you will have to open a shell (terminal), and write the command:
(Macintosh and GNU/Linux OS) user@host:~# traceroute host
Following to the command, the screen will start to show you all the host between your computer and the machine you choosed to ping; keep an eye on the time latency and the loss percentage: these are the packets that get lost on their way, and here we can control exactly at which step they fail! If you reach the Internet via wireless, you should always have an mtr running, in order to check real time the quality of your wireless connection.
A similar utility for Microsoft OS, also accessible from the command line, is the pathping command.