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 steps below:

• 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 2^nd router and responds through ICMP error message time exceeds.
• Traceroute keeps on doing this, and records the IP address and name of every router until the UDP packets reach to the destination address. Once it reaches at the destination address, the Time Exceeded ICMP message is NOT sent back to the source.
• Since Traceroute uses a random port for sending UDP packets, as a result destination machine will drop the packet and send a new ICMP error message- Destination Unreachable to the source, which indicates the UDP packets have reached the destination address.

Tracert with Wireshark

 As discussed above, tracert is a CLI utility for Windows systems to trace the path of a packet from source to destination. So, herewith the help of the following command, we can observe the path of the packet that 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 5^th 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 6^th 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 7^th 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 8^th 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 79^th 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 uses a UDP packet, but with help of the -I option, you can make it work as tracert, which uses an 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 the 30^th hop we didn’t find a desirable output. TCP traceroute follows TCP half communication and waits for the sys-ack packet from the 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 results 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 similar to above, the source sent the TCP-SYN packet to the destination machine on port 80 and received an ICMP error message from the router for a time exceeded, and repeated the process till it received 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
• The router sent the response to the 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