INDIRA GANDHI DELHI TECHNICAL

UNIVERSITY FOR WOMEN

Cyber Security and Forensics Practical File

Submitted to: Dr. Gaurav

IGDTUW

Submitted by: Liza Dagar

Enrolment No: 08401022021
B.Tech ECE 7th semester
 INDEX

S.No Experiments Date Signature

1.
Wireshark Lab: HTTP

2.
Wireshark Lab: DNS

3.
Wireshark Lab: TCP

4.
Wireshark Lab: UDP

5.
Wireshark Lab: IP

6.
Wireshark Lab: NAT

7.
Wireshark Lab: DHCP

8.
Wireshark Lab: ICMP
 EXPERIMENT-1
AIM : Wireshark Lab: HTTP

STEPS:

1) The Basic HTTP GET/response interaction

• Start up your web browser.
• Start up the Wireshark packet sniffer, as described in the Introductory lab (but don’t yet
begin packet capture). Enter “http” (just the letters, not the quotation marks) in the display-
filter-specification window, so that only captured HTTP messages will be displayed later in
the packet-listing window. (We’re only interested in the HTTP protocol here, and don’t
want to see the clutter of all captured packets).
• Wait a bit more than one minute (we’ll see why shortly), and then begin Wireshark packet
capture.
• Enter the following to your browser http://gaia.cs.umass.edu/wireshark-labs/HTTP-
wireshark-file1.html Your browser should display the very simple, one-line HTML file.
• Stop Wireshark packet capture.

Your Wireshark window should look similar to the window shown in Figure 1

Figure 1: Wireshark Display after http://gaia.cs.umass.edu/wireshark-labs/ HTTP- wireshark-

file1.html has been retrieved by your browser
The example in Figure 1 shows in the packet-listing window that two HTTP messages were
captured: the GET message (from your browser to the gaia.cs.umass.edu web server) and the
response message from the server to your browser. The packet-contents window shows details of the
selected message (in this case the HTTP OK message, which is highlighted in the packet-listing
window). Recall that since the HTTP message was carried inside a TCP segment, which was carried
inside an IP datagram, which was carried within an Ethernet frame, Wireshark displays the Frame,
Ethernet, IP, and TCP packet information as well. We want to minimize the amount of non-HTTP
data displayed (we’re interested in HTTP here, and will be investigating these other protocols is
later labs), so make sure the boxes at the far left of the Frame, Ethernet, IP and TCP information
have a plus sign or a right-pointing triangle (which means there is hidden, undisplayed information),
and the HTTP line has a minus sign or a down-pointing triangle (which means that all information
about the HTTP message is displayed).

2) The HTTP CONDITIONAL GET/response interaction

• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser http://gaia.cs.umass.edu/wireshark-labs/HTTP-
wireshark-file2.html Your browser should display a very simple five-line HTML file.
• Quickly enter the same URL into your browser again (or simply select the refresh button on
your browser)

3) Retrieving Long Documents

• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser http://gaia.cs.umass.edu/wireshark-labs/HTTP-
wireshark-file3.html Your browser should display the rather lengthy US Bill of Rights.
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed.
4) HTML Documents with Embedded Objects
• Now that we’ve seen how Wireshark displays the captured packet traffic for large HTML
files, we can look at what happens when your browser downloads a file with embedded
objects, i.e., a file that includes other objects (in the example below, image files) that are
stored on another server(s).
• Do the following:
• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the Wireshark packet sniffer
• Enter the following URL into your browser http://gaia.cs.umass.edu/wireshark-labs/HTTP-
wireshark-file4.html
• Your browser should display a short HTML file with two images. These two images are
referenced in the base HTML file. That is, the images themselves are not contained in the
HTML; instead the URLs for the images are contained in the downloaded HTML file. As
discussed in the textbook, your browser will have to retrieve these logos from the indicated
web sites. Our publisher’s logo is retrieved from the gaia.cs.umass.edu web site. The image
of the cover for our 5th edition (one of our favorite covers) is stored at the caite.cs.umass.edu
server. (These are two different web servers inside cs.umass.edu).
• Stop Wireshark packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed.

5) HTTP Authentication
• Finally, let’s try visiting a web site that is password-protected and examine the sequence of
HTTP message exchanged for such a site. The URL http://gaia.cs.umass.edu/wireshark-
labs/protected_pages/HTTP-wireshark-file5.html is password protected. The username is
“wireshark-students” (without the quotes), and the password is “network” (again, without
the quotes). So let’s access this “secure” password-protected site. Do the following:
• Make sure your browser’s cache is cleared, as discussed above, and close down your
browser. Then, start up your browser
• Start up the Wireshark packet sniffer
• Type the requested user name and password into the pop up box.
Stop Wireshark packet capture, and enter “http” in the display-filter-specification window, so that
only captured HTTP messages will be displayed later in the packet-listing window
 EXPERIMENT - 2
AIM - Wireshark Lab: DNS

STEPS-

1) nslookup
In this lab, we’ll make extensive use of the nslookup tool, which is available in most Linux/Unix and Microsoft
platforms today. To run nslookup in Linux/Unix, you just type the nslookup command on the command line. To run
it in Windows, open the Command Prompt and run nslookup on the command line.

In it is most basic operation, nslookup tool allows the host running the tool to query any specified DNS server for a
DNS record. The queried DNS server can be a root DNS server, a top-level-domain DNS server, an authoritative
DNS server, or an intermediate DNS server (see the textbook for definitions of these terms). To accomplish this
task, nslookup sends a DNS query to the specified DNS server, receives a DNS reply from that same DNS server,
and displays the result.

The above screenshot shows the results of three independent nslookup commands (displayed in the Windows
Command Prompt).
nslookup www.igdtuw.acin

In words, this command is saying “please send me the IP address for the host www.igdtuw.ac.in”. As shown in the
screenshot, the response from this command provides two pieces of information: (1) the name and IP address of the
DNS server that provides the answer; and (2) the answer itself, which is the host name and IP address of
www.mit.edu. Although the response came from the local DNS server at Polytechnic University, it is quite possible
that this local DNS server iteratively contacted several other DNS servers to get the answer, as described in Section
2.4 of the textbook.
Now consider the second command:

nslookup –type=NS igdtuw.ac.in

In this example, we have provided the option “-type=NS” and the domain “igdtuw.ac.in”. This causes nslookup to
send a query for a type-NS record to the default local DNS server. In words, the query is saying, “please send me the
host names of the authoritative DNS for mit.edu”. (When the –type option is not used, nslookup uses the default,
which is to query for type A records.) The answer, displayed in the above screenshot, first indicates the DNS server
that is providing the answer (which is the default local DNS server) along with three MIT nameservers. Each of
these servers is indeed an authoritative DNS server for the hosts on the MIT campus. However, nslookup also
indicates that the answer is “non-authoritative,” meaning that this answer came from the cache of some server rather
than from an authoritative MIT DNS server. Finally, the answer also includes the IP addresses of the authoritative
DNS servers at MIT. (Even though the type-NS query generated by nslookup did not explicitly ask for the IP
addresses, the local DNS server returned these “for free” and nslookup displays the result.)

Now finally consider the third command:

nslookup www.aiit.or.kr bitsy.mit.edu

In this example, we indicate that we want to the query sent to the DNS server bitsy.mit.edu rather than to the default
DNS server (dns-prime.poly.edu). Thus, the query and reply transaction takes place directly between our querying
host and bitsy.mit.edu. In this example, the DNS server bitsy.mit.edu provides the IP address of the host
www.aiit.or.kr, which is a web server at the Advanced Institute of Information Technology (in Korea).

Now that we have gone through a few illustrative examples, you are perhaps wondering about the general syntax of
nslookup commands. The syntax is:

nslookup –option1 –option2 host-to-find dns-server

In general, nslookup can be run with zero, one, two or more options. And as we have seen in the above examples,
the dns-server is optional as well; if it is not supplied, the query is sent to the default local DNS server.

Now that we have provided an overview of nslookup, it is time for you to test drive it yourself. Do the following
(and write down the results):

Run nslookup to obtain the IP address of a Web server in Asia. What is the IP address of that server?
Run nslookup to determine the authoritative DNS servers for a university in Europe.
Run nslookup so that one of the DNS servers obtained in Question 2 is queried for the mail servers for Yahoo! mail.
What is its IP address?

2) ipconfig

ipconfig (for Windows) and ifconfig (for Linux/Unix) are among the most useful little utilities in your host,
especially for debugging network issues. Here we’ll only describe ipconfig, although the Linux/Unix ifconfig is very
similar. ipconfig can be used to show your current TCP/IP information, including your address, DNS server
addresses, adapter type and so on. For example, if you all this information about your host simply by entering
 ipconfig \all

ipconfig is also very useful for managing the DNS information stored in your host. In Section 2.5 we learned that a
host can cache DNS records it recently obtained. To see these cached records, after the prompt C:\> provide the
following command:

ipconfig /displaydns
Each entry shows the remaining Time to Live (TTL) in seconds. To clear the cache, enter ipconfig /flushdns
Flushing the DNS cache clears all entries and reloads the entries from the hosts file.

3) Tracing DNS with Wireshark

Now that we are familiar with nslookup and ipconfig, we’re ready to get down to some serious business. Let’s first
capture the DNS packets that are generated by ordinary Websurfing activity.

Use ipconfig to empty the DNS cache in your host.

Open your browser and empty your browser cache. (With Internet Explorer, go to Tools menu and select Internet
Options; then in the General tab select Delete Files.)
Open Wireshark and enter “ip.addr == your_IP_address” into the filter, where you obtain your_IP_address with
ipconfig. This filter removes all packets that neither originate nor are destined to your host.
Start packet capture in Wireshark.
With your browser, visit the Web page: http://www.ietf.org
Stop packet capture.
 EXPERIMENT - 3

AIM – Wireshark Lab: TCP

STEPS-
In this lab, we’ll investigate the behavior of the celebrated TCP protocol in detail. We’ll do so by analyzing a trace
of the TCP segments sent and received in transferring a 150KB file (containing the text of Lewis Carrol’s Alice’s
Adventures in Wonderland) from your computer to a remote server. We’ll study TCP’s use of sequence and
acknowledgement numbers for providing reliable data transfer; we’ll see TCP’s congestion control algorithm – slow
start and congestion avoidance – in action; and we’ll look at TCP’s receiver-advertised flow control mechanism.
We’ll also briefly consider TCP connection setup and we’ll investigate the performance (throughput and round-trip
time) of the TCP connection between your computer and the server.

1) Capturing a bulk TCP transfer from your computer to a remote server

Before beginning our exploration of TCP, we’ll need to use Wireshark to obtain a packet trace of the TCP transfer
of a file from your computer to a remote server. You’ll do so by accessing a Web page that will allow you to enter
the name of a file stored on your computer (which contains the ASCII text of Alice in Wonderland), and then
transfer the file to a Web server using the HTTP POST method (see section 2.2.3 in the text). We’re using the
POST method rather than the GET method as we’d like to transfer a large amount of data from your computer to
another computer. Of course, we’ll be running Wireshark during this time to obtain the trace of the TCP segments
sent and received from your computer.

Do the following:
Start up your web browser. Go the http://gaia.cs.umass.edu/wiresharklabs/alice.txt and retrieve an ASCII copy of
Alice in Wonderland. Store this file somewhere on your computer.
Next go to http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html.
You should see a screen that looks like:

Use the Browse button in this form to enter the name of the file (full path name) on your computer containing Alice
in Wonderland (or do so manually). Don’t yet press the “Upload alice.txt file” button.
Now start up Wireshark and begin packet capture (Capture->Start) and then press OK on the Wireshark Packet
Capture Options screen (we’ll not need to select any options here).
Returning to your browser, press the “Upload alice.txt file” button to upload the file to the gaia.cs.umass.edu server.
Once the file has been uploaded, a short congratulations message will be displayed in your browser window.
Stop Wireshark packet capture. Your Wireshark window should look similar to the window shown below.
2) A first look at the captured trace
Before analyzing the behavior of the TCP connection in detail, let’s take a high level view of the trace.
• First, filter the packets displayed in the Wireshark window by entering “tcp” (lowercase, no quotes, and don’t
forget to press return after entering!) into the display filter specification window towards the top of the Wireshark
window.

What you should see is series of TCP and HTTP messages between your computer and gaia.cs.umass.edu. You
should see the initial three-way handshake containing a SYN message. You should see an HTTP POST message.
Depending on the version of Wireshark you are using, you might see a series of “HTTP Continuation” messages
being sent from your computer to gaia.cs.umass.edu. Recall from our discussion in the earlier HTTP Wireshark lab,
that is no such thing as an HTTP Continuation message – this is Wireshark’s way of indicating that there are
multiple TCP segments being used to carry a single HTTP message. In more recent versions of Wireshark, you’ll
see “[TCP segment of a reassembled PDU]” in the Info column of the Wireshark display to indicate that this TCP
segment contained data that belonged to an upper layer protocol message (in our case here, HTTP). You should also
see TCP ACK segments being returned from gaia.cs.umass.edu to your computer.

Since this lab is about TCP rather than HTTP, let’s change Wireshark’s “listing of captured packets” window so that
it shows information about the TCP segments containing the HTTP messages, rather than about the HTTP messages.
To have Wireshark do this, select Analyze->Enabled Protocols. Then uncheck the HTTP box and select OK. You
should now see a Wireshark window that looks like:
This is what we’re looking for - a series of TCP segments sent between your computer and gaia.cs.umass.edu. We
will use the packet trace that you have captured (and/or the packet trace tcp-ethereal-trace-1 in
http://gaia.cs.umass.edu/wireshark-labs/wiresharktraces.zip; see earlier footnote) to study TCP behavior in the rest
of this lab.

3) TCP Basics
Identifying IP addresses and TCP port numbers.
Analyzing sequence numbers and acknowledgment fields.
Calculating Round-Trip Time (RTT) and EstimatedRTT.
Exploring TCP segment lengths and receiver buffer space.

4) TCP congestion control in action

Let’s now examine the amount of data sent per unit time from the client to the server. Rather than (tediously!)
calculating this from the raw data in the Wireshark window, we’ll use one of Wireshark’s TCP graphing utilities -
Time-Sequence-Graph(Stevens) - to plot out data.
• Select a TCP segment in the Wireshark’s “listing of captured-packets” window. Then select the menu : Statistics-
>TCP Stream Graph-> Time-SequenceGraph(Stevens). You should see a plot that looks similar to the following
plot, which was created from the captured packets in the packet trace tcp-etherealtrace-1 in
http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip (see earlier footnote ):

Here, each dot represents a TCP segment sent, plotting the sequence number of the segment versus the time at which
it was sent. Note that a set of dots stacked above each other represents a series of packets that were sent back-to-
back by the sender.
 EXPERIMENT-4
Aim- Wireshark lab : UDP

STEPS-

In this lab, we’ll take a quick look at the UDP transport protocol.
Start capturing packets in Wireshark and then do something that will cause your host to send and receive several
UDP packets. It’s also likely that just by doing nothing (except capturing packets via Wireshark) that some UDP
packets sent by others will appear in your trace. In particular, the Simple Network Management Protocol (SNMP –
see section 5.7 in the text) sends SNMP messages inside of UDP, so it’s likely that you’ll find some SNMP
messages (and therefore UDP packets) in your trace.

After stopping packet capture, set your packet filter so that Wireshark only displays the UDP packets sent and
received at your host. Pick one of these UDP packets and expand the UDP fields in the details window. If you are
unable to find UDP packets or are unable to run Wireshark on a live network connection, you can download a
packet trace containing some UDP packets.1
 EXPERIMENT-5

AIM- Wireshark Lab : IP

STEPS-
In this lab, we’ll investigate the IP protocol, focusing on the IP datagram. We’ll do so by analyzing a trace of IP
datagrams sent and received by an execution of the traceroute program (the traceroute program itself is explored in
more detail in the Wireshark ICMP lab). We’ll investigate the various fields in the IP datagram, and study IP
fragmentation in detail.

1) Capturing packets from an execution of traceroute

In order to generate a trace of IP datagrams for this lab, we’ll use the traceroute program to send datagrams of
different sizes towards some destination, X. Recall that traceroute operates by first sending one or more datagrams
with the time-to-live
(TTL) field in the IP header set to 1; it then sends a series of one or more datagrams towards the same destination
with a TTL value of 2; it then sends a series of datagrams towards the same destination with a TTL value of 3; and
so on. Recall that a router must decrement the TTL in each received datagram by 1 (actually, RFC 791 says that the
router must decrement the TTL by at least one). If the TTL reaches 0, the router returns an ICMP message (type 11
– TTL-exceeded) to the sending host. As a result of this behavior, a datagram with a TTL of 1 (sent by the host
executing traceroute) will cause the router one hop away from the sender to send an ICMP TTL-exceeded message
back to the sender; the datagram sent with a TTL of 2 will cause the router two hops away to send an ICMP message
back to the sender; the datagram sent with a TTL of 3 will cause the router three hops away to send an ICMP
message back to the sender; and so on. In this manner, the host executing traceroute can learn the identities of the
routers between itself and destination X by looking at the source IP addresses in the datagrams containing the ICMP
TTL-exceeded messages.

We’ll want to run traceroute and have it send datagrams of various lengths.

Windows. The tracert program (used for our ICMP Wireshark lab) provided with Windows does not allow one to
change the size of the ICMP echo request (ping) message sent by the tracert program. A nicer Windows traceroute
program is pingplotter, available both in free version and shareware versions at http://www.pingplotter.com.
Download and install pingplotter, and test it out by performing a few traceroutes to your favorite sites. The size of
the ICMP echo request message can be explicitly set in pingplotter by selecting the menu item Edit-> Options-
>Packet Options and then filling in the Packet Size field. The default packet size is 56 bytes. Once pingplotter has
sent a series of packets with the increasing TTL values, it restarts the sending process again with a TTL of 1, after
waiting Trace Interval amount of time. The value of Trace Interval and the number of intervals can be explicitly set
in pingplotter.
Linux/Unix/MacOS. With the Unix/MacOS traceroute command, the size of the UDP datagram sent towards the
destination can be explicitly set by indicating the number of bytes in the datagram; this value is entered in the
traceroute command line immediately after the name or address of the destination. For example, to send traceroute
datagrams of 2000 bytes towards gaia.cs.umass.edu, the command would be:
%traceroute gaia.cs.umass.edu 2000

Do the following:
Start up Wireshark and begin packet capture (Capture->Start) and then press OK on the Wireshark Packet Capture
Options screen (we’ll not need to select any options here).
If you are using a Windows platform, start up pingplotter and enter the name of a target destination in the “Address
to Trace Window.” Enter 3 in the “# of times to Trace” field, so you don’t gather too much data. Select the menu
item Edit>Advanced Options->Packet Options and enter a value of 56 in the Packet Size field and then press OK.
Then press the Trace button. You should see a
pingplotter window that looks something like this:
Next, send a set of datagrams with a longer length, by selecting Edit->Advanced Options->Packet Options and enter
a value of 2000 in the Packet Size field and then press OK. Then press the Resume button.

Finally, send a set of datagrams with a longer length, by selecting Edit-

>Advanced Options->Packet Options and enter a value of 3500 in the Packet Size field and then press OK. Then
press the Resume button.

Stop Wireshark tracing.

If you are using a Unix or Mac platform, enter three traceroute commands, one with a length of 56 bytes, one with a
length of 2000 bytes, and one with a length of 3500 bytes.

Stop Wireshark tracing.

2) A look at the captured trace

In your trace, you should be able to see the series of ICMP Echo Request (in the case of Windows machine) or the
UDP segment (in the case of Unix) sent by your computer and the ICMP TTL-exceeded messages returned to your
computer by the intermediate routers.

Select the first ICMP Echo Request message sent by your computer, and expand the Internet Protocol part of the
packet in the packet details window.
Next, sort the traced packets according to IP source address by clicking on the Source column header; a small
downward pointing arrow should appear next to the word Source. If the arrow points up, click on the Source
column header again. Select the first ICMP Echo Request message sent by your computer, and expand the Internet
Protocol portion in the “details of selected packet header” window. In the “listing of captured packets” window, you
should see all of the subsequent ICMP messages (perhaps with additional interspersed packets sent by other
protocols running on your computer) below this first ICMP. Use the down arrow to move through the ICMP
messages sent by your computer.

Next (with the packets still sorted by source address) find the series of ICMP TTLexceeded replies sent to your
computer by the nearest (first hop) router.

3) Fragmentation

Sort the packet listing according to time again by clicking on the Time column.
Find the first ICMP Echo Request message that was sent by your computer after you changed the Packet Size in
pingplotter to be 2000. Has that message been fragmented across more than one IP datagram? [Note: if you find
your packet has not been fragmented, you should download the zip file
http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip and extract the ipethereal-trace-1packet trace. If your
computer has an Ethernet interface, a packet size of 2000 should cause fragmentation.2]

.
 EXPERIMENT- 6
AIM- Wireshark lab: NAT

STEPS-

In this lab, we’ll investigate the behavior of the NAT protocol. This lab will be different from our other
Wireshark labs, where we’ve captured a trace file at a single Wireshark measurement point. Because we’re
interested in capturing packets at both the input and output sides of the NAT device, we’ll need to capture packets
at two locations

1. NAT Measurement Scenario

In this lab, we’ll capture packets from a simple web request from a client PC in a home network to a
www.google.com server. Within the home network, the home network router provides a NAT service.
Figure 1 shows our
Wireshark trace-collection scenario. As in our other Wireshark labs, we collect a
Wireshark trace on the client PC in our home network. This file is called
NAT_home_side3. Because we are also interested in the packets being sent by the NAT router into the ISP, we’ll
collect a second trace file at a PC (not shown) tapping into the link from the home router into the ISP network, as
shown in Figure 1. (The hub device shown on the ISP side of the router is used to tap into the link between the NAT
router and the first hop router in the ISP). Client-to-server packets captured by Wireshark at this point will have
undergone NAT translation. The Wireshark trace file captured on the ISP side of the home router is called
NAT_ISP_side.

Identify the client's IP address.

Filter HTTP messages for communication with the main Google server.
Analyze details of the HTTP GET and its corresponding 200 OK response.
Explore the TCP SYN/ACK handshake for connection setup.

Wireshark Analysis - NAT_ISP_side: Locate the same HTTP GET message after NAT translation. Examine
changes in the HTTP GET message fields post NAT. Identify the time of the first 200 OK HTTP message after NAT
translation. Investigate the timing of the TCP SYN and ACK segments after NAT translation.
 EXPERIMENT-7

AIM- Wireshark lab: DHCP

STEPS-
In this lab, we’ll take a quick look at DHCP. Recall that DHCP is used extensively in corporate, university and
home-network wired and wireless LANs to dynamically assign IP addresses to hosts (as well as to configure other
network configuration information).

This lab is brief, as we’ll only examine the DHCP packets captured by a host. If you also have administrative access
to your DHCP server, you may want to repeat this lab after making some configuration changes (such as the lease
time). If you have a router at home, you most likely can configure your DHCP server. Because many linux/Unix
machines (especially those that serve many users) have a static IP address and because manipulating DHCP on such
machines typically requires super-user privileges, we’ll only present a Windows version of this lab below.

DHCP Experiment

In order to observe DHCP in action, we’ll perform several DHCP-related commands and capture the DHCP
messages exchanged as a result of executing these commands. Do the following4:

1. Begin by opening the Windows Command Prompt application (which can be found in your Accessories
folder). As shown in Figure 1, enter
“ipconfig /release”. The executable for ipconfig is in C:\windows\system32. This command releases your current
IP address, so that your host’s IP address becomes 0.0.0.0.
2. Start up the Wireshark packet sniffer, as described in the introductory Wireshark lab and begin Wireshark
packet capture.
3. Now go back to the Windows Command Prompt and enter “ipconfig /renew”. This instructs your host to
obtain a network configuration, including a new IP address. In Figure 1, the host obtains the IP address
192.168.1.108
4. Wait until the “ipconfig /renew” has terminated. Then enter the same command “ipconfig /renew” again.
5. When the second “ipconfig /renew” terminates, enter the command
“ipconfig/release” to release the previously-allocated IP address to your computer.
6. Finally, enter “ipconfig /renew” to again be allocated an IP address for your computer.
7. Stop Wireshark packet capture.
Figure 1 Command Prompt window showing sequence of ipconfig commands that you should enter.

Now let’s take a look at the resulting Wireshark window. To see only the DHCP packets, enter into the filter field
“bootp”. (DHCP derives from an older protocol called BOOTP. Both BOOTP and DHCP use the same port
numbers, 67 and 68. To see DHCP packets in the current version of Wireshark, you need to enter “bootp” and not
“dhcp” in the filter.) We see from Figure 2 that the first ipconfig renew command caused four DHCP packets to be
generated: a DHCP Discover packet, a DHCP Offer packet, a DHCP Request packet, and a DHCP ACK packet.

Figure 2 Wireshark window with first DHCP packet – the DHCP Discover packet – expanded.
 EXPERIMENT-8

AIM- Wireshark Lab: ICMP

STEPS-
In this lab, we’ll explore several aspects of the ICMP protocol:

• ICMP messages generating by the Ping program; • ICMP messages generated by the
Traceroute program;
• the format and contents of an ICMP message.

ICMP and Ping

Let’s begin our ICMP adventure by capturing the packets generated by the Ping program. You may recall that the
Ping program is simple tool that allows anyone (for example, a network administrator) to verify if a host is live or
not. The Ping program in the source host sends a packet to the target IP address; if the target is live, the Ping
program in the target host responds by sending a packet back to the source host. As you might have guessed (given
that this lab is about ICMP), both of these Ping packets are ICMP packets.

Start up the Wireshark packet sniffer, and begin Wireshark packet capture.
The ping command is in c:\windows\system32, so type either “ping –n 10 hostname” or “c:\windows\system32\ping
–n 10 hostname” in the MS-DOS command line (without quotation marks), where hostname is a host on another
continent. If you’re outside of Asia, you may want to enter www.ust.hk for the Web server at Hong Kong University
of Science and Technology. The argument “-n 10” indicates that 10 ping messages should be sent. Then run the
Ping program by typing return.
When the Ping program terminates, stop the packet capture in Wireshark.

At the end of the experiment, your Command Prompt Window should look something like Figure 1. In this example,
the source ping program is in Massachusetts and the destination Ping program is in Hong Kong. From this window
we see that the source ping program sent 10 query packets and received 10 responses. Note also that for each
response, the source calculates the round-trip time (RTT), which for the 10 packets is on average 375 msec.

Figure 1 Command Prompt window after entering Ping command.

Figure 2 provides a screenshot of the Wireshark output, after “icmp” has been entered into the filter display window.
Note that the packet listing shows 20 packets: the 10 Ping queries sent by the source and the 10 Ping responses
received by the source. Also note that the source’s IP address is a private address (behind a NAT) of the form
192.168/12; the destination’s IP address is that of the Web server at HKUST. Now let’s zoom in on the first packet
(sent by the client); in the figure below, the packet contents area provides information about this packet. We see that
the IP datagram within this packet has protocol number 01, which is the protocol number for ICMP. This means that
the payload of the IP datagram is an ICMP packet.

Figure 2 Wireshark output for Ping program with Internet Protocol expanded.

Figure 3 focuses on the same ICMP but has expanded the ICMP protocol information in the packet contents
window. Observe that this ICMP packet is of Type 8 and Code 0 - a so-called ICMP “echo request” packet. (See
Figure 5.19 of text.) Also note that this ICMP packet contains a checksum, an identifier, and a sequence number.

Figure 3 Wireshark capture of ping packet with ICMP packet expanded.

ICMP and Traceroute
Let’s now continue our ICMP adventure by capturing the packets generated by the Traceroute program. You may
recall that the Traceroute program can be used to figure out the path a packet takes from source to destination.
Traceroute is discussed in Section 1.4 and in Section 5.6 of the text.

Traceroute is implemented in different ways in Unix/Linux/MacOS and in Windows. In Unix/Linux, the source
sends a series of UDP packets to the target destination using an unlikely destination port number; in Windows, the
source sends a series of ICMP packets to the target destination. For both operating systems, the program sends the
first packet with TTL=1, the second packet with TTL=2, and so on. Recall that a router will decrement a packet’s
TTL value as the packet passes through the router. When a packet arrives at a router with TTL=1, the router sends
an ICMP error packet back to the source. In the following, we’ll use the native Windows tracert program. A
shareware version of a much nice Windows Traceroute program is pingplotter (www.pingplotter.com). We’ll use
pingplotter in our Wireshark IP lab since it provides additional functionality that we’ll need there.
At the end of the experiment, your Command Prompt Window should look something like Figure 4. In this figure,
the client Traceroute program is in Massachusetts and the target destination is in France. From this figure we see
that for each TTL value, the source program sends three probe packets. Traceroute displays the RTTs for each of the
probe packets, as well as the IP address (and possibly the name) of the router that returned the ICMP TTL-exceeded
message.