Punjab Engineering College

(Deemed to be University)

Computer Networks Lab File

Submitted by:

Name: Jasmehak

SID: 20103007
 Jasmehak 20103007

Networking Commands
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
 Jasmehak 20103007

Socket Programming
Code: TCP Client and Server
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
 Jasmehak 20103007

Code: UDP Client and Server

Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
Jasmehak 20103007
 Jasmehak 20103007

Wireshark - HTTP
1. The Basic HTTP GET

1. Is your browser running HTTP version 1.0 or 1.1?What version of HTTP is the server running?
Ans: 1.1

2. What languages (if any) does your browser indicate that it can accept to the server?

Ans: English-US

3. What is the IP address of your computer? Of the gaia.cs.umass.edu server?

Ans: Computer IP – 172.31.67.251

Server IP – 128.119.245.12

4. What is the status code returned from the server to your browser?

Ans: 200

5. When was the HTML file that you are retrieving last modified at the server?

Ans:12 April,2022

6. How many bytes of content are being returned to your browser?

 Jasmehak 20103007

Ans:569 Bytes

7. By inspecting the raw data in the packet content window, do you see any headers within the data
that are not displayed in the packet-listing window?If so name one.

Ans: No, I do not see any headers that are not displayed in the packet window.

2. The HTTP Conditional GET

8. Inspect the contents of the first HTTP GET request from your browser to the
server. Do you see an “IF-MODIFIED-SINCE” line in the HTTP GET?

Ans: No, there is no “IF-MODIFIED-SINCE” line in the HTTP GET.

9.Inspect the contents of the server response. Did the server explicitly return the contents of the file?
How can you tell?

Ans: Yes, the server explicitly returned the contents of the file. I am able to tell this because of the
Line-based text data in the OK response to the GET.

10.Now inspect the contents of the second HTTP GET request from your browser to the server. Do
you see an “IF-MODIFIED-SINCE:” line in the HTTP GET? If so, what information follows the
“IF-MODIFIED-SINCE:” header?

Ans: An “IF-MODIFIED-SINCE:” line in the HTTP GET was present. The information that followed
the “IF-MODIFIED-SINCE:” header that was not present in the other HTTP GET was the date it was
modified.
 Jasmehak 20103007

11.What is the HTTP status code and phrase returned from the server response to this second
HTTP GET? Did the server explicitly return the contents of the file? Explain.
Ans: The HTTP status code that the server responded with was a 200 OK, surprisingly. This means
that the server explicitly returned the contents of the file.

3. Retrieving Long Documents

12. How many HTTP GET request messages were sent by your browser?

Ans: My browser sent only one HTTP GET request message. Packet number 18 contained the GET
message for the Bill of Rights

13. How many data-containing TCP segments were needed to carry the single HTTP response?

Ans: Packet 23 contained the response to the HTTP GET request

14. What is the status code and phrase associated with the response to the HTTP GET request?

Ans: The status code from this packet was a 200, and the phrase was an OK.

15. Are there any HTTP status lines in the transmitted data associated with a TCP-induced
“Continuation”?
 Jasmehak 20103007

Ans: 3 data-containing TCP segments were needed to carry the single HTTP response and the
text of the Bill of Rights.

4. HTML Documents with Embedded Objects

16. How many HTTP GET request messages were sent by your browser? To which Internet
addresses were these GET requests sent?

Ans: 3 HTTP GET request messages were sent by my browser. It sent them to 128.119.245.12,
165.193.140.14, and 128.119.240.90. The last two gets are for the separate locations of the images
on the initial web page.

17. Can you tell whether your browser downloaded the two images serially, or whether they were
downloaded from the two web sites in parallel? Explain.

Ans: From the looks of it, it would appear they are downloaded serially. This is because a GET is
sent out after an OK response is seen. From a quick Google search, it appears this is not common.
The Google search suggests that these pictures were downloaded in parallel.

5. HTTP Authentication
 Jasmehak 20103007

18. What is the server’s response (status code and phrase) in response to the initial HTTP GET
message from your browser?

Ans: The server’s response to my HTTP GET message is a 401 Authorization Required status code
and phrase.

19. When your browser’s sends the HTTP GET message for the second time, what new field is
included in the HTTP GET message?

Ans: The new field included is the Authorization field. This provides the user name and password for
a secure website.
 Jasmehak 20103007

Wireshark - DNS
● Run nslookup to obtain the IP address of a Web server in Asia. What is the IP
address of that server?
ANS : I used google to find a webserver and decided to use the server for
AIT Asian Institute of Technology.

ANS:IP address 203.159.12.3 .This is a non-authoritative answer which the lab

explained means the answer came from some other server and not AIT’s
server itself. The default server is an eastern server.

● Run nslookup to determine the authoritative DNS servers for a university in

Europe.
ANS:I decided to use the Central European University. To determine the
authoritative DNS servers, -type=NS . The primary name server is the
authoritative DNS server. It is ns.ceu.hu.
 Jasmehak 20103007

● 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?
ANS:Ip address is 212.82.100.150
 Jasmehak 20103007

PART 2 – IPCONFIG

● Locate the DNS query and response messages. Are they sent over UDP or
TCP? ANS:They are sent over UDP.
● What is the destination port for the DNS query message? What is the source
port of DNS response message?
ANS:The destination port of the query is 53. The source port of the response
is also 53.
● 6. To what IP address is the DNS query message sent? Use ipconfig to
determine the IP address of your local DNS server. Are these two IP
addresses the same? ANS:As seen in the above picture, the destination of
the query is 10.40.4.44 In the ipconfig that I did and pictured earlier, it
showed that my local DNS server was 10.40.4.44, so yes they are the same.
 Jasmehak 20103007

7.Examine the DNS query message. What “Type” of DNS query is it? Does the
query message contain any “answers”?
ANS:The info section calls it a standard query, the list under queries classifies
it as type A, and flags shows that it contains no answers.

8.Examine the DNS response message. How many “answers” are provided? What
do each of these answers contain?
ANS:There was one answer containing the sites address and other information.

9. Consider the subsequent TCP SYN packet sent by your host. Does the
destination IP address of the SYN packet correspond to any of the IP addresses
provided in the DNS response message?
ANS:Yes it does.

10. This web page contains images. Before retrieving each image, does your host
issue new DNS queries?
ANS: No, there were no new queries before retrieving images.
 Jasmehak 20103007

11. What is the destination port for the DNS query message? What is the source
port of DNS response message?
ANS: The destination port of the query is 53 and the source port of the response
is 53.

12. To what IP address is the DNS query message sent? Is this the IP address of
your default local DNS server?
ANS: The ip address the query is sent to is 10.40.4.44. We already saw before
that this is the address of my local DNS server.

13. Examine the DNS query message. What “Type” of DNS query is it? Does the
query message contain any “answers”?
ANS: This is a type A standard query, and it contains no answers.

14. Examine the DNS response message. How many “answers” are provided?
What do each of these answers contain?
ANS :This contains three answers shown here:
Jasmehak 20103007
 Jasmehak 20103007

Wireshark - TCP
​The following reference answers are based on the trace files provided with the text book, which can
be downloaded from the textbook website.

TCP Basics

Answer the following questions for the TCP segments:

● What is the IP address and TCP port number used by your client computer (source) to transfer the file
to gaia.cs.umass.edu? What is the IP address and port number used by gaia.cs.umass.edu to receive
the file.

Solution: Client computer (source)

IP address: 192.168.1.102
TCP port number: 1161

Destination computer: gaia.cs.umass.edu

IP address: 128.119.245.12
TCP port number: 80
 Jasmehak 20103007

● What is the sequence number of the TCP SYN segment that is used to initiate the TCP connection
between the client computer and gaia.cs.umass.edu? What is it in the segment that identifies the
segment as a SYN segment?

Solution: Sequence number of the TCP SYN segment is used to initiate the TCP connection
between the client computer and gaia.cs.umass.edu. The value is 0 in this trace.

The SYN flag is set to 1 and it indicates that this segment is a SYN segment.
 Jasmehak 20103007

● What is the sequence number of the SYNACK segment sent by gaia.cs.umass.edu to the client
computer in reply to the SYN? What is the value of the ACKnowledgement field in the SYNACK
segment? How did gaia.cs.umass.edu determine that value? What is it in the segment that identifies
the segment as a SYNACK segment?

Solution: Sequence number of the SYNACK segment from gaia.cs.umass.edu to the client computer
in reply to the SYN has the value of 0 in this trace.

The value of the ACKnowledgement field in the SYNACK segment is 1. The value of the
ACKnowledgement field in the SYNACK segment is determined by gaia.cs.umass.edu by adding 1
to the initial sequence number of SYN segment from the client computer (i.e. the sequence number
of the SYN segment initiated by the client computer is 0.).

The SYN flag and Acknowledgement flag in the segment are set to 1 and they indicate that this
segment is a SYNACK segment.
 Jasmehak 20103007

● What is the sequence number of the TCP segment containing the HTTP POST command? Note that in
order to find the POST command, you’ll need to dig into the packet content field at the bottom of the
Wireshark window, looking for a segment with a “POST” within its DATA field.

Solution: No. 4 segment is the TCP segment containing the HTTP POST command. The sequence
number of this segment has the value of 1.
 Jasmehak 20103007

● Consider the TCP segment containing the HTTP POST as the first segment in the TCP connection.
What are the sequence numbers of the first six segments in the TCP connection (including the segment
containing the HTTP POST)? At what time was each segment sent? When was the ACK for each
segment received? Given the difference between when each TCP segment was sent, and when its
acknowledgement was received, what is the RTT value for each of the six segments? What is the
EstimatedRTT value (see page 237 in text) after the receipt of each ACK? Assume that the value
of the EstimatedRTT is equal to the measured RTT for the first segment, and then is computed
using the EstimatedRTT equation on page 249 for all subsequent segments. Note: Wireshark has a
nice feature that allows you to plot the RTT for each of the TCP segments sent. Select a TCP segment
in the “listing of captured packets” window that is being sent from the client to the gaia.cs.umass.edu
server. Then select: Statistics->TCP Stream Graph>Round Trip Time Graph.
 Jasmehak 20103007

Solution: The HTTP POST segment is considered as the first segment. Segments 1 – 6 are No. 4, 5,
7, 8, 10, and 11 in this trace respectively. The ACKs of segments 1 – 6 are No. 6, 9, 12, 14, 15, and
16 in this trace.

Segment 1 sequence number: 1

Segment 2 sequence number: 566
Segment 3 sequence number: 2026
Segment 4 sequence number: 3486
Segment 5 sequence number: 4946
Segment 6 sequence number: 6406

The sending time and the received time of ACKs are tabulated in the following table.

Sent ACK received RTT

time time (seconds)
Segmen 0.0264
0.053937 0.02746
t1 77
Segmen 0.0417
0.077294 0.035557
t2 37
Segmen 0.0540
0.124085 0.070059
t3 26
Segmen 0.0546
0.169118 0.11443
t4 90
Segmen 0.0774
0.217299 0.13989
t5 05
Segmen 0.0781
0.267802 0.18964
t6 57

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT

EstimatedRTT after the receipt of the ACK of segment 1:

EstimatedRTT = RTT for Segment 1 = 0.02746 second

EstimatedRTT after the receipt of the ACK of segment 2:

EstimatedRTT = 0.875 * 0.02746 + 0.125 * 0.035557 = 0.0285

EstimatedRTT after the receipt of the ACK of segment 3:

EstimatedRTT = 0.875 * 0.0285 + 0.125 * 0.070059 = 0.0337

EstimatedRTT after the receipt of the ACK of segment 4:

EstimatedRTT = 0.875 * 0.0337+ 0.125 * 0.11443 = 0.0438

EstimatedRTT after the receipt of the ACK of segment 5:

EstimatedRTT = 0.875 * 0.0438 + 0.125 * 0.13989 = 0.0558
 Jasmehak 20103007

EstimatedRTT after the receipt of the ACK of segment 6:

EstimatedRTT = 0.875 * 0.0558 + 0.125 * 0.18964 = 0.0725 second
Jasmehak 20103007
 Jasmehak 20103007

● What is the length of each of the first six TCP segments?

Solution: Length of the first TCP segment (containing the HTTP POST): 565 bytes
Length of each of the other five TCP segments: 1460 bytes (MSS)
 Jasmehak 20103007

● What is the minimum amount of available buffer space advertised at the received for the entire trace?
Does the lack of receiver buffer space ever throttle the sender?

Solution: The minimum amount of buffer space (receiver window) advertised at gaia.cs.umass.edu
for the entire trace is 5840 bytes, which shows in the first acknowledgement from the server. This
receiver window grows steadily until a maximum receiver buffer size of 62780 bytes. The sender is
never throttled due to lacking of receiver buffer space by inspecting this trace.
 Jasmehak 20103007

● Are there any retransmitted segments in the trace file? What did you check for (in the trace) in order
to answer this question?

Solution: There are no retransmitted segments in the trace file. We can verify this by checking the
sequence numbers of the TCP segments in the trace file. In the TimeSequence-Graph (Stevens) of this
trace, all sequence numbers from the source (192.168.1.102) to the destination (128.119.245.12) are
increasing monotonically with respect to time. If there is a retransmitted segment, the sequence
number of this retransmitted segment should be smaller than those of its neighboring segments.
 Jasmehak 20103007

● How much data does the receiver typically acknowledge in an ACK? Can you identify cases where
the receiver is ACKing every other received segment (see Table 3.2 on page 257 in the text).

Solution: The acknowledged sequence numbers of the ACKs are listed as follows.
acknowledged sequence acknowledged
number data
ACK 1 566 566
ACK 2 2026 1460
ACK 3 3486 1460
ACK 4 4946 1460
ACK 5 6406 1460
ACK 6 7866 1460
ACK 7 9013 1147
ACK 8 10473 1460
ACK 9 11933 1460
ACK
13393 1460
10
 Jasmehak 20103007

ACK
14853 1460
11
ACK
16313 1460
12
…
The difference between the acknowledged sequence numbers of two consecutive ACKs indicates
the data received by the server between these two ACKs. By inspecting the amount of
acknowledged data by each ACK, there are cases where the receiver is ACKing every other
segment. For example, segment of No. 80 acknowledged data with 2920 bytes = 1460*2 bytes.

● What is the throughput (bytes transferred per unit time) for the TCP connection? Explain how you
calculated this value.
 Jasmehak 20103007

Solution: The computation of TCP throughput largely depends on the selection of averaging time
period. As a common throughput computation, in this question, we select the average time period as
the whole connection time. Then, the average throughput for this TCP connection is computed as
the ratio between the total amount data and the total transmission time. The total amount data
transmitted can be computed by the difference between the sequence number of the first TCP
segment (i.e. 1 byte for No. 4 segment) and the acknowledged sequence number of the last ACK
(164091 bytes for No. 202 segment). Therefore, the total data are 164091 - 1 = 164090 bytes. The
whole transmission time is the difference of the time instant of the first TCP segment (i.e., 0.026477
second for No.4 segment) and the time instant of the last ACK (i.e., 5.455830 second for No. 202
segment). Therefore, the total transmission time is 5.455830 - 0.026477 = 5.4294 seconds. Hence,
the throughput for the TCP connection is computed as 164090/5.4294 = 30.222 KByte/sec.

● Use the Time-Sequence-Graph (Stevens) plotting tool to view the sequence number versus time plot of
segments being sent from the client to the gaia.cs.umass.edu server. Can you identify where TCP’s
slowstart phase begins and ends, and where congestion avoidance takes over? Solution: TCP Slow
Start begins at the start of the connection, i.e., when the HTTP POST segment is sent out.
The identification of the TCP slow start phase and congestion avoidance phase depends on
the value of the congestion window size of this TCP sender. However, the value of the
congestion window size cannot be obtained directly from the Time-Sequence-Graph
(Stevens) graph. Nevertheless, we can estimate the lower bound of the TCP window size by
the amount of outstanding data because the outstanding data is the amount of data without
acknowledgement. We also know that TCP window is constrained by the receiver window
size and the receiver buffer can act as the upper bound of the TCP window size. In this
trace, the receiver buffer is not the bottleneck; therefore, this upper bound is not quite useful
to infer the TCP window size. Hence, we focus on the lower bound of the TCP window size.

From the following table, we cannot see that the amount outstanding data increases quickly at the
start of this TCP flow; however, it never exceeds 8192 Bytes. Therefore, we can ensure that the TCP
window size is larger than 8192 Bytes. Nevertheless, we cannot determine the end of the slow start
phase and the start of the congestion avoidance phase for this trace. The major reason is that this
TCP sender is not sending data aggressively enough to push to the congestion state. By inspecting
the amount of outstanding data, we can observe that the application at most sends out a data block
of 8192 bytes. Before it receives the acknowledgement for the whole block of these 8192 bytes, the
application will not send more data. It indicates before the end of the slow start phase, the
application already stops transmission temporally.

Typ ACKed Outstanding

No. Seq.
e seq. data
Dat
4 1 565
a
Dat
5 566 2025
a
ACK 6 566 1460
 Jasmehak 20103007

Dat
7 2026 2920
a
Dat
8 3486 4380
a
ACK 9 2026 2920
Dat
10 4946 4380
a
Dat
11 6406 5840
a
ACK 12 3486 4380
Dat
13 7866 5527
a
ACK 14 4096 4917
ACK 15 6006 3007
ACK 16 7866 1147
ACK 17 9013 0
Dat
18 9013 1460
a
Dat 1047
19 2920
a 3
Dat 1193
20 4380
a 3
Dat 1339
21 5840
a 3
Dat 1485
22 7300
a 3
Dat 1631
23 8192
a 3
ACK 24 10473 6732
ACK 25 11933 5272
ACK 26 13393 3812
ACK 27 14853 2352
ACK 28 16313 892
ACK 29 17205 0
Dat 1720
30 1460
a 5
Dat 1866
31 2920
a 5
Dat 2012
32 4380
a 5
Dat 2158
33 5840
a 5
Dat 2304
34 7300
a 5
 Jasmehak 20103007

Dat 2450
35 8192
a 5
ACK 36 18665 6732
ACK 37 20125 5272
ACK 38 21585 3812
ACK 39 23045 2352
ACK 40 24505 892
ACK 41 25397 0
Dat 2539
42 1460
a 7
Dat 2685
43 2920
a 7
Dat 2831
44 4380
a 7
Dat 2977
45 5840
a 7
Dat 3123
46 7300
a 7
Dat 3269
47 8192
a 7
ACK 48 26857
ACK 49 28317
ACK 50 29777
ACK 51 31237
ACK 52 33589
Dat 3358
53 6732
a 9
Dat 3504
54 5272
a 9
Dat 3650
55 3812
a 9
Dat 3796
56 2352
a 9
Dat 3942
57 892
a 9
Dat 4088
58 0
a 9
ACK 59 35049 6732
ACK 60 37969 3812
ACK 61 40889 892
ACK 62 41781 0
Dat 4178
63 1460
a 1
 Jasmehak 20103007

Dat 4324
64 2920
a 1
Dat 4470
65 4380
a 1
Dat 4616
66 5840
a 1
Dat 4762
67 7300
a 1
Dat 4908
68 8192
a 1
ACK 69 44701 5272
ACK 70 47621 2352
ACK 71 49973 0
Dat 4997
72 1460
a 3
Dat 5143
73 2920
a 3
Dat 5289
74 4380
a 3
Dat 5435
75 5840
a 3
Dat 5581
76 7300
a 3
Dat 5727
77 8192
a 3
ACK 78 52893 5272
ACK 79 55813 2352
ACK 80 58165 0
Dat 5816
81
a 5
Note that the criteria to determine the end of slow start and the beginning of the congestion avoidance is the way
how congestion window size reacts to the arrival of ACKs. Upon an ACK arrival, if the congestion window size
increases by one MSS, TCP sender still stays in the slow start phase. In the congestion avoidance phase, the
congestion window size increases at 1/(current_congestion_window_size). By inspecting the change of the
congestion window upon the arrival of ACKs, we can infer the states of the TCP sender.

● Comment on ways in which the measured data differs from the idealized behavior of TCP that we’ve studied in the text.

Solution: The idealized behavior of TCP in the text assumes that TCP senders are aggressive in sending data. Too
much traffic may congest the network; therefore, TCP senders should follow the AIMD algorithm so that when they
detect network congestion (i.e., packet loss), their sending window size should drop down. In the practice, TCP
behavior also largely depends on the application. In this example, when the TCP sender can send out data, there are
no data available for transmission. In the web application, some of web objects have very small sizes. Before the end
of slow start phase, the transmission is over; hence, the transmission of these small web objects suffers from the
unnecessary long delay because of the slow start phase of TCP.
 Jasmehak 20103007

Wireshark - IP

​What is the IP address of your computer?

The IP address of my computer is 192.168.1.46

● Within the IP packet header, what is the value in the upper layer protocol field? Within the header, the
value in the upper layer protocol field is ICMP (0x01)

● How many bytes are in the IP header? How many bytes are in the payload of the IP datagram?
Explain how you determined the number of payload bytes. There are 20 bytes in the IP header,
and 56 bytes total length, this gives 36 bytes in the payload of the IP datagram.
 Jasmehak 20103007

● Has this IP datagram been fragmented? Explain how you determined whether or not the datagram has
been fragmented.

The more fragments bit = 0, so the data is not fragmented.

● Which fields in the IP datagram always change from one datagram to the next within this series of
ICMP messages sent by your computer?

Identification, Time to live and Header checksum always change.

● Which fields stay constant? Which of the fields must stay constant? Which fields must change?
Why?

The fields that stay constant across the IP datagrams are:

● Version (since we are using IPv4 for all packets)

● header length (since these are ICMP packets)
● source IP (since we are sending from the same source)
● destination IP (since we are sending to the same dest)
● Differentiated Services (since all packets are ICMP they use the same Type of
Service class)
● Upper Layer Protocol (since these are ICMP packets)

The fields that must stay constant are:

● Version (since we are using IPv4 for all packets)

● header length (since these are ICMP packets)
● source IP (since we are sending from the same source)
● destination IP (since we are sending to the same dest)
● Differentiated Services (since all packets are ICMP they use the same Type of
Service class)
● Upper Layer Protocol (since these are ICMP packets)

The fields that must change are:

● Identification(IP packets must have different ids)

● Time to live (traceroute increments each subsequent packet)
● Header checksum (since header changes, so must checksum)
● Describe the pattern you see in the values in the Identification field of the IP datagram

The pattern is that the IP header Identification fields increment with each ICMP Echo (ping)
request.
 Jasmehak 20103007

● What is the value in the Identification field and the TTL field?

Identification: 30767
TTL: 64

● Do these values remain unchanged for all of the ICMP TTL-exceeded replies sent to your computer
by the nearest (first hop) router? Why?

The identification field changes for all the ICMP TTL-exceeded replies because the
identification field is a unique value. When two or more IP datagrams have the same
identification value, then it means that these IP datagrams are fragments of a single large IP
datagram.

The TTL field remains unchanged because the TTL for the first hop router is always the
same.
 Jasmehak 20103007

● 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?

Yes, this packet has been fragmented across more than one IP datagram

● Print out the first fragment of the fragmented IP datagram. What information in the IP header indicates
that the datagram been fragmented? What information in the IP header indicates whether this is the
first fragment versus a latter fragment?
 Jasmehak 20103007

How long is this IP datagram?

The Flags bit for more fragments is set, indicating that the datagram has been fragmented.
Since the fragment offset is 0, we know that this is the first fragment. This first datagram
has a total length of 1500, including the header.

● Print out the second fragment of the fragmented IP datagram. What information in the IP header
indicates that this is not the first datagram fragment? Are the more fragments? How can you tell?

We can tell that this is not the first fragment, since the fragment offset is 1480. It is the last
fragment, since the more fragments flag is not set.
 Jasmehak 20103007

● What fields change in the IP header between the first and second fragment? The IP header fields
that changed between the fragments are: total length, flags, fragment offset, and checksum.

● How many fragments were created from the original datagram? After switching to 3500, there are
3 packets created from the original datagram.
● What fields change in the IP header among the fragments?
● The IP header fields that changed between all of the packets are: fragment offset, and
checksum. Between the first two packets and the last packet, we see a change in total
length, and also in the flags. The first two packets have a total length of 1500, with the more
fragments bit set to 1, and the last packet has a total length of 540, with the more fragments
bit set to 0.
 Jasmehak 20103007

Wireshark - ICMP

1. What is the IP address of your host? What is the IP address of the destination host?

The IP address of my host is 192.168.1.101. The IP address of the destination host is 143.89.14.34.

2. Why is it that an ICMP packet does not have source and destination port numbers?

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.
 Jasmehak 20103007

3. Examine one of the ping request packets sent by your host. What are the ICMP type and code
numbers? What other fields does this ICMP packet have? How many bytes are the checksum, sequence
number and identifier fields? The ICMP type is 8, and the code number is 0. The ICMP packet also has
checksum, identifier, sequence number, and data fields. The checksum, sequence number and identifier
fields are two bytes each.
 Jasmehak 20103007

4. Examine the corresponding ping reply packet. What are the ICMP type and code numbers? What other
fields does this ICMP packet have? How many bytes are the checksum, sequence number and identifier fields?

The ICMP type is 0, and the code number is 0. The ICMP packet also has checksum, identifier, sequence
number, and data fields. The checksum, sequence number and identifier fields are two bytes each.

5. What is the IP address of your host? What is the IP address of the target destination host?

The IP address of my host is 192.168.1.101. The IP address of the destination host is 138.96.146.2.

6. If ICMP sent UDP packets instead (as in Unix/Linux), would the IP protocol number still be 01 for the
probe packets? If not, what would it be?

No. If ICMP sent UDP packets instead, the IP protocol number should be 0x11
 Jasmehak 20103007

7. Examine the ICMP echo packet in your screenshot. Is this different from the ICMP ping query packets in
the first half of this lab? If yes, how so?
The ICMP echo packet has the same fields as the ping query packets.
 Jasmehak 20103007

8. Examine the ICMP error packet in your screenshot. It has more fields than the ICMP echo packet. What is
included in those fields?
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.
 Jasmehak 20103007

9. Examine the last three ICMP packets received by the source host. How are these packets different from the
ICMP error packets? Why are they different?
The last three ICMP packets are message type 0 (echo reply) rather than 11 (TTL expired). They are different
because the datagrams have made it all the way to the destination host before the TTL expired.
 Jasmehak 20103007

10. Within the tracert measurements, is there a link whose delay is significantly longer than others? Refer to
the screenshot in Figure 4, is there a link whose delay is significantly longer than others? On the basis of the
router names, can you guess the location of the two routers on the end of this link?
There is a link between steps 11 and 12 that has a significantly longer delay.
This is a transatlantic link from New York to Aubervilliers, France. In figure 4 from the lab, the link is from
New York to Pastourelle, France.
 Jasmehak 20103007

Wireshark - DHCP
 Jasmehak 20103007

● DHCP messages are sent over UDP (User Datagram Protocol).

Frame 2 (342 bytes on wire, 342 bytes captured)

Ethernet II, Src: 192.168.243.92 (00:90:4b:69:dd:34), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68) Destination port: bootps (67)

Length: 308
Checksum: 0xd1a1 [correct] Bootstrap Protocol

● The port numbers are the same as the example in the Lab.

● The Link Layer address of my workstation is: 00:90:4b:69:dd:34

Frame 1 (342 bytes on wire, 342 bytes captured)

Ethernet II, Src: 192.168.243.92 (00:90:4b:69:dd:34), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff) Source: 192.168.243.92 (00:90:4b:69:dd:34)
Type: IP (0x0800)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) User Datagram

Protocol, Src Port: bootpc (68), Dst Port: bootps (67)

Bootstrap Protocol
 Jasmehak 20103007

● The values which differentiate the Discover message from the Request message are in
“Option 53: DHCP Message Type”.

Frame 1 (342 bytes on wire, 342 bytes captured)

Ethernet II, Src: 192.168.243.92 (00:90:4b:69:dd:34), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol Message type: Boot Request (1)

Hardware type: Ethernet

Hardware address length: 6 Hops: 0

Transaction ID: 0xe6746a7d Seconds elapsed: 1280

Bootp flags: 0x0000 (Unicast)

Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0)

Next server IP address: 0.0.0.0 (0.0.0.0)

Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: 192.168.243.92

(00:90:4b:69:dd:34)

Server host name not given Boot file name not given

Magic cookie: (OK)

Option 116: DHCP Auto-Configuration (1 bytes) Option 53: DHCP Message Type = DHCP
Discover
Option 61: Client identifier
Option 50: Requested IP Address = 192.168.243.92 Option 12: Host Name =

"homelt"

Option 60: Vendor class identifier = "MSFT 5.0" Option 55: Parameter Request

List

End Option
Padding Frame 3 (350 bytes on wire, 350 bytes captured)
Ethernet II, Src: 192.168.243.92 (00:90:4b:69:dd:34), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

Message type: Boot Request (1)

Hardware type: Ethernet Hardware address length: 6

Hops: 0
Transaction ID: 0xe6746a7d Seconds elapsed: 1280

Bootp flags: 0x0000 (Unicast) Client IP address: 0.0.0.0 (0.0.0.0)

Your (client) IP address: 0.0.0.0 (0.0.0.0)

 Jasmehak 20103007

Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0

(0.0.0.0)

Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)

Server host name not given Boot file name not given

Magic cookie: (OK) Option 53: DHCP Message Type = DHCP Request
Option 61: Client identifier
Option 50: Requested IP Address = 192.168.243.92 Option 54: Server

Identifier = 192.168.243.1

Option 12: Host Name = "homelt"

Option 81: FQDN Option 60: Vendor class identifier = "MSFT
5.0" Option 55: Parameter Request List End Option

● The value of the Transaction ID is 0xe6746a7d. The second Transaction ID is 0xe4eff25f. A

Transaction ID is used so that the DHCP server can differentiate between client requests
during the request process.

No. Time Source Destination

Protocol Info

3 5.000175 0.0.0.0 255.255.255.255 DHCP

DHCP Discover - Transaction ID 0xe6746a7d 27 12.075229
192.168.243.92 192.168.243.1 DHCP DHCP Request -
Transaction ID 0xe4eff25f

● The DHCP client and server both use 255.255.255.255 as the destination address. The
client uses source IP address 0.0.0.0, while the server uses its actual IP address as the
source.

No. Time Source Destination

Protocol Info

● 0.000000 0.0.0.0 255.255.255.255 DHCP

DHCP Discover - Transaction ID 0xe6746a7d
● 0.020995 192.168.243.1 255.255.255.255 DHCP
DHCP Offer - Transaction ID 0xe6746a7d 3 0.021346
 Jasmehak 20103007

0.0.0.0 255.255.255.255 DHCP DHCP Request

- Transaction ID 0xe6746a7d

4 0.124018 192.168.243.1 255.255.255.255 DHCP

DHCP ACK - Transaction ID 0xe6746a7d

● The IP address of the DHCP server is 192.168.243.1

No. Time Source Destination

Protocol Info 4 0.124018 192.168.243.1
255.255.255.255 DHCP DHCP ACK - Transaction ID
0xe6746a7d

● The DHCP server offered the IP address 192.168.243.92 to my client machine. The DHCP
message with “DHCP Message Type = DHCP Offer” contained the offered IP.

Frame 2 (590 bytes on wire, 590 bytes captured)

Ethernet II, Src: 192.168.243.1 (00:08:da:50:49:c5), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 192.168.243.1
(192.168.243.1), Dst: 255.255.255.255 (255.255.255.255) User Datagram
Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet Hardware address length: 6
Hops: 0
Transaction ID: 0xe6746a7d Seconds elapsed: 1280
Bootp flags: 0x0000 (Unicast) Client IP address: 0.0.0.0
(0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0) Your (client) IP
address: 192.168.243.92 (192.168.243.92)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Offer
Option 1: Subnet Mask = 255.255.255.0 Option 54: Server
Identifier = 192.168.243.1
 Jasmehak 20103007

Option 51: IP Address Lease Time = 3 days Option 6: Domain

Name Server = 192.168.243.1
Option 5: Name Server = 24.29.103.10 Option 15: Domain Name =
"nyc.rr.com" Option 31: Perform Router Discover = Enabled
End Option Padding

● The “Relay agent IP address” is 0.0.0.0, which indicates that there is no DHCP Relay used.
There was no Relay Agent used in my experiment.

Frame 4 (590 bytes on wire, 590 bytes captured)

Ethernet II, Src: 192.168.243.1 (00:08:da:50:49:c5), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 192.168.243.1
(192.168.243.1), Dst: 255.255.255.255 (255.255.255.255) User Datagram
Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet Hardware address length: 6
Hops: 0
Transaction ID: 0xe6746a7d Seconds elapsed: 1280
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.243.92 (192.168.243.92)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK Option 54: Server
Identifier = 192.168.243.1
Option 51: IP Address Lease Time = 3 days
Option 1: Subnet Mask = 255.255.255.0
Option 3: Router = 192.168.243.1
Option 6: Domain Name Server = 192.168.243.1
Option 5: Name Server = 24.29.103.10 Option 15: Domain Name =
"nyc.rr.com"
Option 31: Perform Router Discover = Enabled End O ption
 Jasmehak 20103007

● The router line indicates to the client what its default gateway should be. The subnet mask
line tells the client which subnet mask it should use.

Frame 4 (590 bytes on wire, 590 bytes captured)

Ethernet II, Src: 192.168.243.1 (00:08:da:50:49:c5), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 192.168.243.1
(192.168.243.1), Dst: 255.255.255.255 (255.255.255.255) User Datagram
Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xe6746a7d
Seconds elapsed: 1280
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.243.92 (192.168.243.92)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 1: Subnet
Mask = 255.255.255.0
Option 3: Router =
192.168.243.1
Option 54: Server Identifier = 192.168.243.1 Option 51: IP
Address Lease Time = 3 days

Option 6: Domain Name Server = 192.168.243.1

Option 5: Name Server = 24.29.103.10
Option 15: Domain Name = "nyc.rr.com"
Option 31: Perform Router Discover = Enabled End Option

● In my experiment, the host requests the offered IP address in the DHCP Request message.
 Jasmehak 20103007

Frame 3 (350 bytes on wire, 350 bytes captured)

Ethernet II, Src: 192.168.243.92 (00:90:4b:69:dd:34), Dst: Broadcast
(ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255
(255.255.255.255) User Datagram Protocol, Src Port: bootpc (68), Dst
Port: bootps (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet Hardware address length: 6
Hops: 0
Transaction ID: 0xe6746a7d Seconds elapsed: 1280
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address:
0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP
address: 0.0.0.0 (0.0.0.0)
Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 61: Client identifier
Option 50: Requested IP Address = 192.168.243.92
Option 54: Server Identifier = 192.168.243.1
Option 12: Host Name = "homelt"
Option 81: FQDN
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List End O ption

● The lease time is the amount of time the DHCP server assigns an IP address to a client.
During the lease time, the DHCP server will not assign the IP given to the client to another
client, unless it is released by the client. Once the lease time has expired, the IP address
can be reused by the DHCP server to give to another client. In my experiment, the lease
time is 3 days.
 Jasmehak 20103007

Frame 4 (590 bytes on wire, 590 bytes captured)

Ethernet II, Src: 192.168.243.1 (00:08:da:50:49:c5), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 192.168.243.1
(192.168.243.1), Dst: 255.255.255.255 (255.255.255.255) User Datagram
Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xe6746a7d
Seconds elapsed: 1280
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.243.92 (192.168.243.92)
Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP
address: 0.0.0.0 (0.0.0.0)
Client MAC address: 192.168.243.92 (00:90:4b:69:dd:34)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 54: Server Identifier = 192.168.243.1
Option 51: IP Address Lease Time = 3 days
Option 1: Subnet Mask = 255.255.255.0
Option 3: Router = 192.168.243.1
Option 6: Domain Name Server = 192.168.243.1
Option 5: Name Server = 24.29.103.10
Option 15: Domain Name = "nyc.rr.com"
Option 31: Perform Router Discover = Enabled End Option

● The client sends a DHCP Release message to cancel its lease on the IP address given to it
by the DHCP server. The DHCP server does not send a message back to the client
acknowledging the DHCP Release message. If the DHCP Release message from the client
is lost, the DHCP server would have to wait until the lease period is over for that IP address
until it could reuse it for another client.

● Yes, there are ARP requests made by the DHCP server. Before offering an IP address to a
client, the DHCP server issues an ARP request for the offered IP to make sure the IP
address is not already in use by another workstation.
 Jasmehak 20103007

Frame 2 (60 bytes on wire, 60 bytes captured)

Ethernet II, Src: 192.168.243.1 (00:08:da:50:49:c5), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4 Opcode: request (0x0001)
Sender MAC address: 192.168.243.1 (00:08:da:50:49:c5) Sender
IP address: 192.168.243.1 (192.168.243.1)
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.243.92 (192.168.243.92)