Lab Exercise – ICMP
Objective
To see how ICMP (Internet Control Message Protocol) is used. ICMP is a companion protocol to IP that
helps IP to perform its functions by handling various error and test cases.
The trace is here: http://scisweb.ulster.ac.uk/~kevin/com320/labs/wireshark/trace-icmp.pcap
The text file is here: http://scisweb.ulster.ac.uk/~kevin/com320/labs/wireshark/trace-icmp.txt
Requirements
Wireshark: This lab uses the Wireshark software tool to capture and examine a packet trace. A packet
trace is a record of traffic at a location on the network, as if a snapshot was taken of all the bits that
passed across a particular wire. The packet trace records a timestamp for each packet, along with the
bits that make up the packet, from the lower-layer headers to the higher-layer contents. Wireshark runs
on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the
sequence of packets and the meaning of the bits when interpreted as protocol headers and data. It color-codes packets by their type, and has various ways to filter and analyze packets to let you investigate
the behavior of network protocols. Wireshark is widely used to troubleshoot networks. You can download it from www.wireshark.org if it is not already installed on your computer. We highly recommend
that you watch the short, 5 minute video “Introduction to Wireshark” that is on the site.
traceroute / tracert: This lab uses “traceroute” to find the router level path from your computer to a
remote Internet host. traceroute is a standard command-line utility for discovering the Internet paths
that your computer uses. It is widely used for network troubleshooting. It comes pre-installed on Window and Mac, and can be installed using your package manager on Linux. On Windows, it is called
“tracert”. It has various options, but simply issuing the command “traceroute www.uwa.edu.au”
will cause your computer to find and print the path to the remote computer (here www.uwa.edu.au).
ping: This lab uses “ping” to send and receive messages. ping is a standard command-line utility for
checking that another computer is responsive. It is widely used for network troubleshooting and comes
pre-installed on Window, Linux, and Mac. While ping has various options, simply issuing the command
“ping www.bing.com” will cause your computer to send a small number of ICMP ping requests to
the remote computer (here www.bing.com), each of which should elicit an ICMP ping response.
A quick help guide to Wireshark display filters is here: http://openmaniak.com/wireshark_filters.php
How to Start - Launch Wireshark
You can type Wireshark in the run box of main Windows 8 start screen. It should load but there can be a
problem with the new lab configuration for Wireshark and npf driver. Therefore if this is not working…..
then please do the next step after this.
Figure 1: Wireshark in lab
Alternative way to launch Wireshark: Click the desktop icon on the main windows screen and
use the file explorer to browse to C:\local Disk (C)\Program Files\Wireshark
Next, RIGHT CLICK on Wireshark as “Run as administrator”.
You will then get a startup screen, as shown next:
Figure 2: Initial Wireshark Screen
Take a look at the upper left hand side of the screen – you’ll see an “Interface list”. This is the list
of network interfaces on your computer. Once you choose an interface, Wireshark will capture
all packets on that interface. Click on the network card on the particular machine you are working on. In the example above, it is the Ethernet Driver to start packet capture (i.e., for Wireshark
to begin capturing all packets being sent to/from that interface).
Step 1: Capture a Trace
Proceed as follows to capture a trace of ICMP traffic that results from ping and traceroute; alternatively, you may use a supplied trace.
Please note that for security purposes - you cannot ping any external machine to the university. You can
only ping your neighbours machine in the lab.
1. Pick a remote computer belonging to a friend such, e.g., 193.61.191.72. To run ping, simply
bring up a command line and type, e.g., “ ping 193.61.191.88” for our choice of computer. You
may have to stop the ping program from endlessly sending pings by pressing ctrl-C. You are
looking at the ping output to see that the remote computer replies to your ping requests. A
successful example is shown in the figure below. If you are not seeing ping replies then pick another remote computer to try.
Figure 3: Pinging a remote computer (on Mac)
2. Check to see that you can traceroute to the same computer while invoking traceroute
with options to send ICMP traffic rather than other traffic such as UDP. To do this, run it as
“tracert 193.61.191.72" (Windows, uses ICMP). It may take a little while to run, printing
the next line of output after a pause of several seconds or more. You are looking at the output
to see that you can find most of the path to the remote computer.
Each line of output gives information about the next segment of the network path. When part of
the path cannot be found, then the traceroute output will be a “*” entry that denotes unanswered probes; it is common to have some “*” entries, and this is OK, but for an interesting
trace they should not be the majority of the path. A successful example is shown in the figure
below. If you are not seeing some information about the path to the remote computer, then
pick another remote computer to try and repeat this step starting with ping.
Remember, that Traceroute is also limited in our labs so you will not see a proper traced route to
a remote computer (only your colleagues computer in the lab).
Figure 4: Traceroute, with ICMP probes, to a remote computer (Mac)
3. Launch Wireshark and start a capture with a filter of “icmp“. Make sure to check “enable network name resolution”. This will translate the IP addresses of the computers and routers sending
packets into names, which will help you to recognize the organizations on the network path taken by your packets. Your capture window should be similar to the one pictured below, other
than our highlighting. Select the interface from which to capture as the main wired or wireless
interface used by your computer to connect to the Internet. If unsure, guess and revisit this step
later if your capture is not successful. Uncheck “capture packets in promiscuous mode”. This
mode is useful to overhear packets sent to/from other computers on broadcast networks. We
only want to record packets sent to/from your computer. Leave other options at their default
values. The capture filter, if present, is used to prevent the capture of other traffic your computer may send or receive.
Figure 5: Setting up the capture options
4. When the capture is started, repeat the ping command you tested, wait a few seconds, and
then repeat the traceroute command as well. This time, the ICMP packets sent and received
by these two programs will be recorded by Wireshark.
5. After the commands are complete, return to Wireshark and use the menus or buttons to stop the
trace. You should have a short trace similar to that shown in the figure below. We have expanded the detail of the ICMP header for a ping request packet in our view. You can save the
output from the ping and traceroute commands or use the supplied trace for later steps.
Figure 6: Trace of ping/traceroute traffic showing details of the ICMP header for a ping request.
Answer the following: (Answers are on following page).
1. Why is it that an ICMP packet does not have source and destination port numbers?
2. Examine one of the ping request packets sent by your host. How many bytes are the checksum, sequence number and identifier fields?
3. Examine an ICMP error packet (where Time-to-live is exceeded).Note it has more fields than the ICMP
echo packet. What is included in those fields?
Answers to Step 1: Capture a trace
1. The ICMP packet does not have source and destination port numbers because it was designed to
communicate network-layer information between hosts and routers, not between application layer processes. Each ICMP packet has a "Type" and a "Code". The Type/Code combination identifies the specific
message being received. Since the network software itself interprets all ICMP messages, no port numbers are needed to direct the ICMP message to an application layer process.
2. The checksum, sequence number and identifier fields are two bytes each.
3. The ICMP error packet is not the same as the ping query packets. It contains both the IP header and
the first 8 bytes of the original ICMP packet that the error is for.
Step 2: Echo (ping) Packets
Start your exploration by selecting an echo (ping) request and reply packet at the start of the trace. Expand the ICMP block (by using the “+” expander or icon) to see the ICMP header and payload details:

The ICMP header starts with a Type and Code field that identify the kind of ICMP message. Look
to see the values for an echo request and an echo reply and how they compare.

The Type/Code is followed by a 16-bit checksum over the complete ICMP message, to check that
it was received correctly.

Next comes an Identifier and Sequence Number field. These fields are used to link echo request
and reply packets together. Look at the Identifier and Sequence Number values for several requests and replies. Compare the values of a request and matching reply, and of successive replies. Note that Wireshark may show these fields in two ways: as a Big Endian (BE) value and a
Little Endian (LE). The difference is the order in which the bits are organized into bytes, e.g.,
00000001 on the wire might represent “1” or “256” depending on whether the first bit transmitted is the least (LE) or most (BE) significant bit.

Finally, there is a Data field as the ICMP payload. This field is variable length.
Answer the following questions to demonstrate your understanding of ICMP echo messages. Answers
are displayed in the next page.
1. What are the Type/Code values for an ICMP echo request and echo reply packet, respectively?
2. How do the Identifier and Sequence Number compare for an echo request and the corresponding
echo reply?
3. How do the Identifier and Sequence Number compare for successive echo request packets?
4. Is the data in the echo reply the same as in the echo request or different?
Answers to Step 2: Echo (ping) Packets
The solutions below are based on the provided trace capture. Your answers might differ in the details if
they are based on your own capture.
Answers to the questions:
1. Echo request has Type/Code of 8/0. Echo reply has Type/Code of 0/0.
2. Each echo request and corresponding echo reply have the same Identifier value and the same
Sequence Number value. The values are used to match the echo request to the right echo reply.
3. Typically, the Identifier is kept the same and the Sequence Number is incremented. This ensures
that as a pair, successive echo requests will have different Identifier/Sequence Number values
so they (and their corresponding replies) can be distinguished.
4. The data is the same. The echo request sender can use any convenient data, and the echo reply
sender will copy its data from the request so that the payload returns to the original sender.
Step 3: TTL Exceeded (traceroute) Packets
Next, explore traceroute traffic by selecting any Time Exceeded ICMP packet in your trace. Expand
the ICMP block (by using the “+” expander or icon) to see the ICMP header and payload details:

The ICMP header starts with a Type and Code field that identify the kind of ICMP message, just
as for echo packets. Look to see the values for a TTL Exceeded packet and how they compare to
the echo packets.

The Type/Code is followed by a 16-bit checksum over the complete ICMP message to check that
it was received correctly, just as for echo packets.

The next structure you will see (apart from a possible length field that is part of modern implementations of ICMP) is an IP header! How can this be? For ICMP error messages that are produced by an error during forwarding, such as TTL Exceeded, the start of the packet that triggered the error is included in the payload of the ICMP packet. That is why there is an IP header
inside the ICMP packet. Depending on how much of the packet that caused the error is included
in the ICMP payload, you may see its headers beyond IP. In the case of our traceroute traffic, this will be an ICMP header of the echo request packet.
Draw a picture of one ICMP TTL Exceeded packet to make sure that you understand its nested structure.
On your figure, show the position and size in bytes of the IP header, ICMP header with details of the
Type/Code and checksum subfields, and the ICMP payload. Within the ICMP payload, draw another rectangle that shows the overall structure of the contents of the payload. As usual, your figure can simply
show the packet as a long, thin rectangle. To work out sizes, observe that when you click on a protocol
block in the middle panel (the block itself, not the “+” expander) then Wireshark will highlight the bytes
it corresponds to in the packet in the lower panel and display the length at the bottom of the window.
Answer the following questions. Answers are displayed on the next page.
What is the Type/Code value for an ICMP TTL Exceeded packet?
1. Say how the receiver can safely find and process all the ICMP fields if it does not know ahead of
time what kind of ICMP message to expect. The potential issue, as you have probably noticed, is
that different ICMP messages can have different formats. For instance, Echo has Sequence and
Identifier fields while TTL Exceeded does not.
2. How long is the ICMP header of a TTL Exceeded packet? Select different parts of the header in
Wireshark to see how they correspond to the bytes in the packet.
3. The ICMP payload contains an IP header. What is the TTL value in this header? Explain why it has
this value. Guess what it will be before you look.
Answers to Step 3: TTL Exceeded (traceroute) Packets
Figure 5: Format of an ICMP TTL Exceeded Message
There are several features to note:

The length of 20 bytes is for a typical IPv4 header with no IP option fields.

The Type and Code values are for an ICMP TTL Exceeded in transit message.

The ICMP header is given as 8 bytes, yet the fields only add up to 4 bytes. There are an extra
four bytes after the checksum that are historically unused. They are not shown in the figure because they are not shown in most versions of Wireshark.

The size of the ICMP payload depends on the router implementation. The value of 28 bytes is
what we saw in practice. The start of an IP packet is shown in these bytes, including an IP header
and ICMP header for the echo request packet that triggered the ICMP TTL Exceeded message.
Answers to the questions:
1. Type=11 (Time Exceeded) and Code=0 (TTL Exceeded in transit)
2. All ICMP messages start with the same Type/Code (and Checksum) fields, so the receiver can
process these fields. Their value tells the receiver the kind of ICMP message, and hence what
fields follow.
3. The Type/Code and Checksum fields take up 4 bytes. However, the ICMP header is actually 8
bytes long. These fields are followed by 4 bytes that are unused (except for recent ICMP extensions) and hence do not show up in Wireshark as named fields. You can still see that they are
there by selecting the ICMP block and the payload, and observing that they differ by 8 bytes.
4. The inner IP packet has TTL=1 in our case, but depending on the router implementation it is possible that you will see TTL=0. It must be one of these values for the case of an ICMP TTL Exceeded message because the message is triggered when the TTL is decremented during processing
and reaches 0, i.e., the TTL held a value of 1 when the packet arrived at the router.
Step 4: Internet Paths
The source and destination IP addresses in an IP packet denote the endpoints of an Internet path, not
the IP routers on the network path the packet travels from the source to the destination. traceroute
is a utility for discovering this path. It works by eliciting ICMP TTL Exceeded responses from the router 1
hop away from the source towards the destination, then 2 hops away from the source, then 3 hops, and
so forth until the destination is reached. The responses will identify the IP address of the router. The
output from traceroute normally prints the information for one hop per line, including the measured round trip times and IP address and DNS names of the router. The DNS name is handy for working
out the organization to which the router belongs. Since traceroute takes advantage of common
router implementations, there is no guarantee that it will work for all routers along the path, and it is
usual to see “*” responses when it fails for some portions of the path.
Look at the traceroute portion of the trace, which will have a series of ICMP echo request packets followed by ICMP TTL Exceeded packets. The echo requests are sent from the source (your computer) to
the destination whose path is being probed. The TTL Exceeded packets are coming from routers along
the path back to your computer, triggered by the TTL field counting down to zero.
By looking at the details of the packets, answer the following questions:
1. How does your computer (the source) learn the IP address of a router along the path from a TTL
exceeded packet? Say where on this packet the IP address is found. You might proceed by looking at an echo packet to see the source and destination IP addresses. The routers along the path
will have a different IP address, and this address will be present on the TTL Exceeded packet. If
you are unsure, you can examine the traceroute text output to see the IP addresses of routers and look for these addresses on the TTL Exceeded packets.
2. How many times is each router along the path probed by traceroute? Look at the TTL Exceeded responses and see if you can discern a pattern.
3. How does your computer (the source) craft an echo request packet to find (by eliciting a TTL Exceeded response) the router N hops along the path towards the destination? Describe the key attributes of the echo request packet. The echo request packets sent by traceroute are probing successively more distant routers along the path. You can look at these packets and see how
they differ when they elicit responses from different routers.
4. Now that you have an understanding of the ICMP packets involved, let us look at the output of the
traceroute program. If you are using the supplied trace, note that we have provided the corresponding traceroute output as a separate file. The output describes the path from your computer to the
remote destination using information gleaned from the TTL Exceeded responses.
Using the traceroute output, sketch a drawing of the network path. Show your computer (lefthand
side) and the remote server (righthand side), both with IP addresses, as well as the routers along the
path between them numbered by their distance on hops from the start of the path. You can find the IP
address of your computer and the remote server on the echo packets in the trace that you captured. The
output of traceroute will tell you the hop number for each router. To finish your drawing, label the
routers along the path with the name of the real-world organization to which they belong. To do this,
you will need to interpret the domain names of the routers given by traceroute. If you are unsure, label the routers with the domain name of what you take to be the organization. Ignore or leave blank any
routers for which there is no domain name (or no IP address).
(Note, this is quite difficult and only here for reference.
You will not get asked something like this in class test).
This is not an exact science, so we will give some examples. Suppose that traceroute identifies a
router along the path by the domain name arouter.cac.washington.edu. Normally, we can ignore at least the first part of the name, since it identifies different computers in the same organization
and not different organizations. Thus we can ignore at least “arouter” in the domain name. For generic top-level domains, like “.com” and “.edu”, the last two domains give the domain name of the organization. So for our example, it is “washington.edu”. To translate this domain name into the realworld name of an organization, we might search for it on the web. You will quickly find that washington.edu is the University of Washington. This means that “cac” portion is an internal structure in the
University of Washington, and not important for the organization name. You would write “University of
Washington” on your figure for any routers with domain names of the form *.washington.edu.
Alternatively, consider a router with a domain name like arouter.syd.aarnet.net.au. Again, we
ignore at least the “arouter” part as indicating a computer within a specific organization. For countrycode top-level domains like “.au” (for Australia) the last three domains in the name will normally give
the organization. In this case the organization’s domain name is aarnet.net.au. Using a web search,
we find this domain represents AARNET, Australia’s research and education network. The “syd” portion is internal structure, and a good guess is that it means the router is located in the Sydney part of
AARNET. So for all routers with domain names of the form *.aarnet.net.au, you would write
“AARNET” on your figure. While there are no guarantees, you should be able to reason similarly and at
least give the domain name of the organizations near the ends of the path.
Answers to Step 4: Internet Paths
1. The IP source address of the TTL Exceeded packet is the IP address of the router. This is because
the router created the TTL Exceeded packet, putting its own IP address in the source field.
2. Traceroute probes each hop along the path more than once, in case of packet loss. Typically it
probes three times, in which case you will see a pattern of triples of echo / TTL exceeded from a
given router. This pattern will not be exact because some TTL Exceeded packets may be lost, and
some routers may not reply with TTL exceeded. These lost TTL Exceeded packets correspond to
the “*” entries in the traceroute text output.
3.
The echo request packet should have an IP source of your computer, an IP destination of the far
end of the path, and a TTL value set to N. The last part is the key; routers will decrement the TTL
and it will reach zero N hops away from the source towards the destination. The ICMP TTL Exceeded message will be sent back to the source. Note that the contents of the ICMP fields in the
echo request packet do not matter. They are there only in case the packet reaches the destination (which would then send an echo reply).
4. Traceroute
Figure 6: Path from computer to www.cs.vu.nl found by traceroute
There are several features to note:

The start of the path is not named because it starts within a home; the address 192.168.xx.xx is
in private address space that is NATed to reach the public Internet. This will likely be the case if
you run the traceroute from a home.

as6453.net is Tata Communications, comcast.net is Comcast, surf.net is SURFnet, and vu.nl is
Vrijie Universitiet Amsterdam. You can often find names like this with a Web search and an educated guess, or by using a WhoIS lookup service such as whois.net to consult domain registration records.