Traceroute - every packet has TTL == 1

Question

I'm working on Wireshark lab-IP in Computer networking - A top down approach and I don't understand why every packet that normally expired has a TTL of 1.

Here is my Wireshark capture file. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

I captured the execution of the traceroute program in Linux (with the option of 56 bytes), as executed with the following command:

traceroute http://gaia.cs.umass.edu 56

You can see that most of the packet's TTL == 1 and I don't know why, since I learned that every subsequent hop has a TTL of +1 (or more).

P.S.:

• I'm using Lubuntu on VMware with bridged network to the host.
• I captured it with wireshark on host machine (Windows)
• I'm connected to a wireless AP using it's own DHCP server on top of NAT protocol

Answer 1

Let me try to answer this, because it's a little more complicated that it may look initially.

It seems that you already know the basic operation of traceroute but before anything else here is a very small recap:

traceroute tries to determine all the in-between steps from your host to a destination host, or just the distance, i.e. number of hops, from your host to a destination host. To do that it starts sending packets to the destination host with a "random" destination port number and a TTL that starts from 1 and keeps increasing.
The idea is that each router in between decreases the TTL by 1. Thus, if TTL reaches 0 (in reality it never does since the router that is about to decrease it to 0 produces an error before that), the router will return an ICMP "Time-to-live exceeded" error message, e.g. packet number 24 in your capture file. What you get from that is that your destination is further away and this is why you keep increasing the TTL.
When your packet has a TTL that is big enough to reach the destination, you will get a different ICMP error message: "Destination Unreachable (Port Unreachable)", e.g. packet number 208 in your capture file. What you get from that is that the last used TTL is indeed the number of hops between you and the destination node. The reason that you get an error is simply because you are sending a message to a "random" port that the destination node (hopefully) is not listening to.

Now going into specifics for your capture file:
From the manual page of traceroute we can see that each TTL is used 3 times (option '-q') and the default protocol used is UDP (option '-P'). By examining the first 3 UDP packets, i.e. packets 8-9-10, we can see indeed that the TTL is 1. The next 3, i.e. 11-12-13, have a TTL 2 and so on. So from the source perspective everything seems to go fine.

Then, after some time dependent on the delay of the network, we start getting the anticipated error messages. Thus we can see that packets 24-25-26 are "Time to live exceeded" error packets and thus meaning that the destination is further away.

This back-and-forth of attempts and errors continues, until, finally, packet 208 and on you can see "Port Unreachable" error messages, meaning that your destination has been reached.

By counting the packets you send and the responses you can actually find out even from the trace which TTL actually worked but its a tedious task :)

Hope that helped

Answer 2

Your client is only sending the first three packets with a TTL of 1. The next three are sent with a TTL of 2. The next three are sent with a TTL of 3. And so on and so forth.

An easier way to view this is to set the IP TTL field as its own column in Wireshark. Simply right click on the TTL value in any packet, and select "Apply as Column":

From there, you can see that packets 8,9,10 have a TTL of 1. And packets 11,12,13 have a TTL of 2. And so on and so forth.

This is happening because this is how Traceroute works. It takes advantage of what a Router does when it decreases a TTL to 0. Rather than continue forwarding the packet, it sends back to the original client a "ICMP TTL Expired in Transit message" (see packet #24 in your capture).

So as a client, when you send the first set of packets with a TTL of 1, the first router in the path responds with the TTL Expired message. You then measure how long it took to receive the TTL Expired message against when you sent the initial messages, and that gives you your first three values in the Traceroute output.

Then you send another set of three packets with a TTL of 2. The first router in the path decrements this to 1, and then forwards it to the next router in the path. Upon reception, when that second router gets it, it decrements the TTL to 0, which prompts it to drop the packet and send you the TTL Expired in transit.

The process continues until your client has received a (well, three) TTL Expired message from every router in transit between you and the final destination you are running your traceroute against.