ICMP echo-reply packets with a much lower TTL (-190) than ICMP time-exceeded packets

icmpnetworkingpingttl

When I ping the last three hops of a traceroute path to facebook.com from my location, the ICMP echo-reply packets I get back all have a TTL of respectively 58, 57 and 56. The hops in question are the 6th, 7th and 8th hops from my machine.

On the other hand, the TTLs of ICMP time-exceeded messages for packets expiring on those three hops, have all a reasonable value: 246, 248, 249.

Now, the return path might well not be the same as the forward path and it might not be the same for ICMP messages of different types.

But where could such a difference come from? A 200-hop cycle along path? Or ICMP echo-reply packets being generated with a low TTL (much lower than 255: does this even happen?)?

Best Answer

As suggested by the user kwaio, the default (or a common) TTL value to use when generating ICMP echo-request and echo-reply packets is 64.

In my case, the first routers along my selected path responded with an echo-reply message with TTL=255 (at the source), while the last ones with TTL=64.

It appears instead that ICMP time-exceeded messages were created in all cases with a TTL of 255.

After some digging, I found out that different vendors and different OS's adopt different initial TTLs for different protocols: binbert.com/blog/2009/12/default-time-to-live-ttl-values

An interesting implication of this is that you can take identify the manifacturer of a given router by letting a packet expire on it and by sending it a ping. More details here: TTL-based Fingerprinting and MPLS and the full article: "Network Fingerprinting: TTL-Based Router Signatures".

Related Solutions

Wireshark Display Filtered for Unreplied ICMP Echo Packets

In Wireshark, you can use the MATE plugin to achieve this functionality. I just tested with the latest version (1.6.0) and it's included in the default installation package.

First, create a text file to house the following configuration for MATE:

Pdu ping_pdu Proto icmp Transport ip {
    Extract addr From ip.addr;
    Extract icmp_type From icmp.type;
    Extract icmp_seq From icmp.seq;
};

Gop ping_pair On ping_pdu Match (addr, addr, icmp_seq) {
    Start (icmp_type=8);
    Stop (icmp_type=0);
};

Within Wireshark, go to the Preferences and find MATE in the protocol list. It has one configuration parameter, which is the location of the configuration file. Point it to where ever you saved the file you created with the content above.

At this point, you can restart Wireshark and make sure that MATE parses the configuration properly.

Now you can open up a capture and all of the ping requests and responses should have a bit of extra data titled "MATE" in the details pane. Each "ping_pdu" is grouped with it's counterpart as a "ping_pair".

Now apply the following filter:

mate.ping_pair.NumOfPdus==1

This will single out the "ping_pairs" which have only 1 member (i.e. a request with no response).

Linux router – how to send icmp unreachable messages to LAN clients

ICMP Unreachable packets are a special breed; they'll only be thrown back at your systems when a router cannot route for that destination, if the router's behaving correctly; you'll also need to make sure they aren't getting discarded by an overzealous firewall.

In the case of 10.0.0.1, the ISP is probably not filtering the RFC 1918 ranges out until hop 3 - but if the discard is due to an ACL filter, it'll just throw the packets away without sending an Unreachable response.

To get your linux router to drop the packets and throw unreachables, add a reject route:

route add -net 10.0.0.0 netmask 255.0.0.0 reject

You'll want to make this persistent - where you need to do this depends on your router's flavor of linux.

Best Answer

Related Solutions

Wireshark Display Filtered for Unreplied ICMP Echo Packets

Linux router – how to send icmp unreachable messages to LAN clients

Related Topic