Working of Traceroute using Wireshark
In this Post, we are going to discuss working with traceroute using UDP/ICMP/TCP packets with the help of Wireshark.
Traceroute or Tracert: It is a CUI based computer network diagnostic tools used in UNIX and Windows-like system respectively. It traces the path of a packet from the source machine to an Internet host such as Google.com by calculating the average time taken each hop. Traceroute sends a UDP packet to the destination by taking benefit of ICMP’s messages. It uses the ICMP error-reporting messages –Destination Unreachable and Time exceeded.
TTL: The time-to-live value, also known as the hop limit, is a mechanism that limits the lifespan or lifetime of data in a computer or network.
Hop: A hop is one portion of the path between source and destination. Data packets pass through bridges, routers, and gateways as they travel between source and destination. On the internet, before the data reaches its final destination, it goes through several routers and a hop occurs when an incoming packet is forwarded to the next router.
The asterisk (*): Denotes probe timeout which means that the router at that hop doesn’t respond to the packet received from the source used for the traceroute due to firewall filter.
Working of Traceroute
Read the below steps:
- Traceroute sends a UDP packet with a TTL = 1 from the source to destination.
- When the first router receives the UDP packet it reduces the TTL value by 1 (1-1=0) then drop the packet and sends an ICMP message “Time exceeded” to the source. Thus Traceroute makes a list of the router’s address and the time taken for the round-trip.
The TTL time exceeded ICMP message is sent after the TTL value of a UDP packet gets zero. In typical condition, a network doesn’t have such a diameter that lead the TTL=0. This could be possible when there is a routing loop. In this case, as the packet is sent back and forth between the looping points, the TTL keeps getting decrement until it becomes zero. And at last, the source receives ICMP error message sent by the router.
- Again source device sends two more packets, in the same way, to get an average value of the round-trip time and again TTL gets zero when it reaches to the 2nd router and response through ICMP error message time exceeds.
- Traceroute keeps on doing this, and record the IP address and name of every router until the UDP packets reach to the destination address. Once it reaches at the destination address, Time exceeded ICMP message is NOT sent back to the source.
- Since Traceroute uses the random port for sending UDP packets as result destination machine will drop the packet and send a new ICMP error message-Destination Unreachable to the source which indicates the UDP packets has reached to the destination address.
Tracert with Wireshark
As discussed above tracert is CLI utility for windows system to trace the path of a packet from source to destination. So herewith help of the following command, we can observe the path of the packet which travels to reach Google DNS.
Syntax: tracert [options] Host IP
tracert 8.8.8.8
or
tracert -d 8.8.8.8
Traceroute generates a list of each hop by entering IP of routers that traversed between source and destination and average round-trip time. As a result hop 22 denotes entry of destination i.e. Google DNS.
In order to notice the activity of traceroute, we have turned on Wireshark in the background.
Note: Result of tracert can vary each time for hop count but does not go beyond 30 hops because it is the maximum hop limit.
At Wireshark we notice the following points:
- ICMP echo request packet is used instead of UDP to send DNS query.
- The packet first goes from source 192.168.1.101 to first router 192.168.1.1 having ICMP echo request packet with TTL=1
- The router will drop that packet and send ICMP Time Exceeded error message to the source.
- All this happens 3 times before the source machine sends next packet by incrementing TTL value by 1 i.e. TTL=2.
Form this image we can observe ICMP echo reply message is sent from 8.8.8.8 (destination) to 192.168.1.101 (source) for TTL 22.
Traceroute with Wireshark (via UDP packets)
As discussed above traceroute in utility for Unix -like the system to trace the path of a packet from source to destination. So here with the help of the following command, we can observe the path of packet travels to reach Google DNS.
Syntax: traceroute [options] Host IP
traceroute 8.8.8.8
Traceroute generates a list of each hop by entering IP of routers that comes between source and destination and average round-trip time. As a result hop 21 denotes entry of destination i.e. Google DNS.
In order to notice the activity of traceroute, we have turned on Wireshark in the background.
Note: Result of traceroute can vary each time for hop count but does not go beyond 30 hops because it is maximum hop limit.
At Wireshark we notice the following points:
- UDP packet is used to send DNS query with help of 32-bit payload.
- The packet first goes from source 192.168.1.101 to first router 192.168.1.1 having ICMP request packet with TTL=1
- The router will drop that packet and send ICMP Time Exceeded error message to the source.
- All this happens 3 times before the source sent next packet with increment TTL value by 1 i.e. TTL=2.
In tracert we have seen that each TTL value between source to the first router proceeds 3 times, similarly, same technique is followed by UDP. To demonstrate this we have explored UDP packets 5,6,7 and 8th continuously.
In the 5th packet, we observe the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33435 and count as Hop #1, attempt #1.
In the 6th packet, we observe the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33436 and count as Hop #1, attempt #2.
Similarly, in the 7th packet, we observe the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33437 and count as Hop #1, attempt #3.
In the 8th packet, we observe the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33436 and count as Hop #2, attempt #1 and repeat so on process till reaches the destination.
In packet 79th we observe that the last hop captured was hop #10 attempt #3 when the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33464 and Time exceeded ICMP message is NOT sent back to the source after this.
As a result, at last, source received ICMP message Destination Port Unreachable which means our UDP packet reaches on the destination address.
At last from given below image we observed the following:
- Source sent DNS query to the router for DNS lookup 8.8.8.8
- Router sent a response to source as the answer of DNS Name Google-Public-DNS-google.com
Traceroute with Wireshark (via ICMP packets)
As you know by default traceroute use UDP packet but with help of -I option you can make it work as tracert which uses ICMP request packet.
traceroute -I 8.8.8.8
It generates a list of each hop by entering IP of routers that comes between source and destination and average round-trip time. As a result hop 22 denotes entry of destination i.e. Google DNS. In order to notice the activity of traceroute, we have turned on Wireshark in the background.
At Wireshark we notice the following points:
First ICMP echo request packet will be sent to the first router with TTL 1 and it will send back an ICMP error message time exceed which follow the same technique as explained above in tracert with Wireshark.
At last from given below image we observed the following:
- ICMP echo reply message is sent from 8.8.8.8 (destination) to 192.168.1.101 (source) for TTL 22.
- Source sent DNS query to the router for DNS lookup 8.8.8.8
- Router sent the response to source as the answer of DNS Name Google-Public-DNS-google.com
Traceroute with Wireshark (via TCP packets)
As you know by default traceroute use UDP packet with the use of ICMP error message for generating a response but with the help of -T option, you can use TCP packet, which uses syn request packet via port 80. It is most useful in diagnosing connection issues to a specific service eg. Web server.
tcptraceroute - 8.8.8.8 or traceroute -T 8.8.8.8
As we know the maximum hop limit is 30 and but here till 30th hop we didn’t find desirable output. TCP traceroute basically follow TCP half communication and waits for the sys-ack packet from destination till the last hop.
In order to notice the activity of tcp traceroute, we have turned on Wireshark in the background where we noticed that it works same as UDP but here the syn packets are used to send the requests to the destination. Tcptraceroute does not measure the time it takes to complete the three-way handshake because that never occurs in such a situation. It only measures the time from the initial SYN to the SYN/ACK.
Since Wireshark also didn’t notice any syn-ack packet from destination to source, therefore, Tcptraceroute didn’t edit destination response in its record list this is due to because it is useful while diagnosing web server.
Therefore let’s check the path of Google.com and notice the behavior of tcptraceroute. And you compare both result and behaviour of TCP in case of Google DNS server and Google web server.
tcptraceroute google.com
Here we can clearly observe the response of destination machine through SYN, ACK and a complete entry recorded by traceroute.
It is as similar as above, the source sent the TCP-SYN packet to the destination machine on port 80 and received ICMP error message from the router for a time exceeded and repeat the process till it receives ACK_SYN from the destination.
Here we can observe ACK-SYN packet from the destination (172.168.161.14) is sent to source (192.1681.103) from port 80 and source again sent RST packet to the destination via port 80.
At last from given below image we observed the following:
- Source sent DNS query to the router for DNS lookup 172.161.217.14
- Router sent the response to source as the answer of DNS Name del03s10-in-f14.1e100.net
This entry will get recorded by traceroute in its record list.
Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here
Nice article
It looks like there is some typo n the line- “In the 8th packet, we observe the UDP packet sent by source (192.168.1.102) to destination 8.8.8.8 on port 33436 and count as Hop #2, attempt #1 and repeat so on process till reaches the destination.
I guess the port should be 33438.
Kindly correct me if i am wrong.
Regards
Dear Raj,
What will happen with the traceroute (implemented using UDP) if all the ports are opened in the destination host? (I guess port unreachable message will not be sent coz all the ports are made to be in open state)
Does the sender get any ICMP message from the destination host for the final probe?
Regards
Very informative. Keep up the good work.