Lab 1: Getting started

1. List the different protocols that appear in the protocol column in

the unfiltered packet-listing window in step 7 above.
Answer:

The different protocols that appear in the protocol column in the

unfiltered packet-listing window in step 7 above: DNS, TCP,
HTTP
2. How long did it take from when the HTTP GET message was sent
until the HTTP OK reply was received? (By default, the value of
the Time column in the packetlisting window is the amount of
time, in seconds, since Wireshark tracing began. To display the
Time field in time-of-day format, select the Wireshark View pull
down menu, then select Time Display Format, then select Time-of-
day.)
Answer:
0.786984 – 0.5307423 = 0.256561s
3. What is the Internet address of the gaia.cs.umass.edu (also known
as wwwnet.cs.umass.edu)? What is the Internet address of your
computer?
Answer:
The Internet address of gaia.cs.umass.edu is : 128.119.245.12
The Internet address of my computer is : 192.168.1.6
4. Print the two HTTP messages displayed in step 9 above. To do so,
select Print from the Wireshark File command menu, and select
“Selected Packet Only” and“Print as displayed” and then click
OK.
Lab 2: HTTP

1. Is your browser running HTTP version 1.0 or 1.1? What version of

HTTP is the server running?
Answer:
My browser’s running HTTP version 1.1. The server’s running
HTTP version 1.1

2. What languages (if any) does your browser indicate that it can
accept to the server?
Answer:
English – United state.

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

server?
Answer:
 The IP address of my computer: 192.168.1.6
The IP address of gaia.cs.umass.edu sever : 128.119.245.12

4. What is the status code returned from the server to your browser?
Answer:
200 OK
5. When was the HTML file that you are retrieving last modified at
the server?
Answer:
Saturday, 08th December 2018

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

Answer:
128 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.
In the GET message content there are headers within the data that
are not displayed in the packet-listing window :

Raw data:
 In the response message content there are headers within the data
that are not displayed in the packet-listing window :

Raw data:

2. The HTTP CONDITIONAL GET/response interaction

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?
Answer:
The “IF-MODIFIED-SINCE” line does not exist in the first HTTP
GET message.
9. Inspect the contents of the server response. Did the server
explicitly return the contents of the file? How can you tell?
Answer:
The server did explicitly return the contents of the file, because
We can see the the text which was showed on the Browser in the
packet content window of the response message.
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?
Answer:
If-Modified-Since: Saturday, 08th December 2018

11. What is the HTTP status code and phrase returned from the server
in response to this second HTTP GET? Did the server explicitly
return the contents of the file? Explain
HTTP/1.1 304 Not Modified\r\n.

The server didn’t explicitly return the contents of the file, since the
browser loaded it from it cache
3. Retrieving Long Documents

12. How many HTTP GET request messages were sent by your
browser?
Answer:
There are 1 GET request messages as seen in the screen shot
13. How many data-containing TCP segments were needed to carry the
single HTTP response?
Answer:
5 data-containing TCP segments were needed to carry the single
HTTP response.
14. What is the status code and phrase associated with the response to
the HTTP GET request?
Answer:
200 OK

15. Are there any HTTP status lines in the transmitted data associated
with a TCP induced “Continuation”?
Answer:
No
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?
Answer:
There are 3 GET message were sent from my Browser. These
messages were sent to address: 128.119.245.12

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.
Answer:
By checking the TCP ports we can see if our files were downloaded
serially or in parallel. In this case the 2 images were transmitted
over 2 TCP connections therefore they were downloaded serially.
Pearson.png

Cover_5th_ed.jpg
 5. HTTP Authentication

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

Response to the first GET message:

Status code: 401

Phrase: Unauthorized
19. When your browser’s sends the HTTP GET message for the
second time, what new field is included in the HTTP GET message?
Answer:
As seen on the screen shot, the new field is:
Authorization: Basic
d2lyZXNoYXJrLXN0dWRlbnRzOm5ldHdvcms=
Lab3: TCP

1. What is the IP address and TCP port number used by the client
computer (source) that is transferring the file to gaia.cs.umass.edu?
To answer this question, it’s probably easiest to select an HTTP
message and explore the details of the TCP packet used to carry this
HTTP message, using the “details of the selected packet header
window” (refer to Figure 2 in the “Getting Started with Wireshark”
Lab if you’re uncertain about the Wireshark windows.
Answer:
The IP address is 192.168.1.102
TCP port number is 1161
2. What is the IP address of gaia.cs.umass.edu? On what port number
is it sending and receiving TCP segments for this connection?
Answer:
Depend on the question 1 we have answered and the pictures were
showed above, the IP address of gaia.cs.umass.edu is:
128.119.245.12, the port number of gaia.cs.umass.edu for sending
and receiving TCP segments for this connection is: 80

3. If you have been able to create your own trace, answer the following
question: What is the IP address and TCP port number used by your
client computer (source) to transfer the file to gaia.cs.umass.edu?
Answer:
 IP address used by my client computer : 192.168.1.7
TCP port number used by my client computer: 57048

4. 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?
The sequence number of the TCP SYN segment is: 0

The SYN flag is set to 1 and it identifies the segment as a SYN

segment
5. 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?
Answer:
 The sequence number of the SYNACK segment is: 0

 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
 The SYN and ACK flags is set to 1 and they identify the
segment as a SYNACK segment
6. 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.
The sequence number of the TCP segment containing the HTTP
POST command is: 1

7. 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 249 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
Answer:
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 in the following
table.
 Sent time ACK received RTT (seconds)
time
Segment 1 0.026477 0.053937 0.02746
Segment 2 0.041737 0.077294 0.035557
Segment 3 0.0.54026 0.124185 0.070059
Segment 4 0.054690 0.169118 0.11443
Segment 5 0.077405 0.217299 0.13989
Segment 6 0.078157 0.268702 0.18964

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
EstimatedRTT after the receipt of the ACK of segment 6:
EstimatedRTT = 0.875 * 0.0558 + 0.125 * 0.18964 = 0.0725
8. What is the length of each of the first six TCP segments?
Answer:
Length of the first TCP segment (containing the HTTP POST): 619
bytes
Length of each of the other five TCP segments: 1514 bytes (MSS)
9. 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?
Answer:
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.

10. Are there any retransmitted segments in the trace file? What did you
check for (in the trace) in order to answer this question?
Answer:
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 Time-Sequence-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.

11. 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).
Answer:
The acknowledged sequence numbers of the ACKs are listed as
follows
 Acknowledged sequence Acknowledged data
number
ACK 1 No.6 566 566
ACK 2 No.9 2026 1460
ACK 3 No.12 3486 1460
ACK 4 No.14 4946 1460
ACK 5 No.15 6406 1460
ACK 6 No.16 7866 1460
… … …

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 from two another segments: No.76 and No.77.
Therefore, it acknowledged data with 1460 + 892 = 2352 bytes
12. What is the throughput (bytes transferred per unit time) for the
TCP connection? Explain how you calculated this value
Answer:
The total amount data transmitted can be computed by the
difference between the sequence number of the first TCP segment
( 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 ( 0.026477 second for No.4 segment) and the
time instant of the last ACK ( 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.
13. 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? Comment on ways in which the measured
data differs from the idealized behavior of TCP that we’ve studied
in the text
Answer:
TCP Slow Start begins at the start of the connection, 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.
14. Answer each of two questions above for the trace that you
have gathered when you transferred a file from your computer to
gaia.cs.umass.edu
Answer:
Uploaded file “Alice.txt” to gaia.cs.umass.edu
Time-Sequence-Graph(Stevens)

TCP Slow Start begins at the start of the connection, 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.
Lab4: IP

1. 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. What is the IP address of your computer?
Answer:
IP address of my computer is : 192.168.1.6
2. Within the IP packet header, what is the value in the upper layer
protocol field?
Answer:
Within the header, the value in the upper layer protocol field is
ICMP (1)

3. 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.
Answer:
There are 20 bytes in the IP header, and 56 bytes total length, this
gives 36 bytes in the payload of the IP datagram.
4. Has this IP datagram been fragmented? Explain how you determined
whether or not the datagram has been fragmented.
Answer:
The more fragments bit = 0, so the data is not fragmented.

5. Which fields in the IP datagram always change from one datagram

to the next within this series of ICMP messages sent by your
computer?
Answer:
Identification, time to live and Header checksum are always change.
 Example:
The ICMP message no.6 with its identification, time to live and
Header check sum:

The The ICMP message no.8 which is below no.6 with its
identification, time to live and Header check sum:

6. Which fields stay constant? Which of the fields must stay constant?
Which fields must change? Why?
Answer:
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)
7. Describe the pattern you see in the values in the Identification field
of the IP datagram
Answer:
The pattern is that the IP header Identification fields increment with
each ICMP Echo (ping) request.
8. What is the value in the Identification field and the TTL field?
Answer:
 The value of Identification field is: 13961.

The value of TTL field is: 64.

9. Do these values remain unchanged for all of the ICMP TTL-

exceeded replies sent to your computer by the nearest (first hop)
router? Why?
Answer:
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.
10. 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?
Answer:
 Yes, that message has been fragmented across more than one IP
datagram, because the more fragment bit = 1

11. 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? How long is this
IP datagram?
Answer:
 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.

12. 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?
Answer:
 We can tell that this is not the first fragment, since the fragment
offset is 185. It is the last fragment, since the more fragments flag is
not set.

13. What fields change in the IP header between the first and second
fragment?
Answer:
The IP header fields that changed between the fragments are: total
length, flags, fragment offset, and checksum.
Now find the first ICMP Echo Request message that was sent by your computer after you
changed the Packet Size in pingplotter to be 3500
14. How many fragments were created from the original datagram?
Answer:

After switching to 3500, there are 3 packets created from the

original datagram.

15. What fields change in the IP header among the fragments?

Answer:
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.
The first fragment:

The second fragment:

The last fragment:

Lab5: Ethernet and ARP
1. What is the 48-bit Ethernet address of your computer?
Answer:
The 48-bit Ethernet address of my computer is:
d8:cb:8a:a2:09:0e

2. What is the 48-bit destination address in the Ethernet frame? Is

this the Ethernet address of gaia.cs.umass.edu? (Hint: the answer
is no). What device has this as its Ethernet address?
Answer:
The destination address a0:65:18:81:a0:9d is not the Ethernet
address of gaia.cs.umass.edu. It is the address of my VnptTech
router, which is the link used to get off the subnet.

3. Give the hexadecimal value for the two-byte Frame type field.
What do the bit(s) whose value is 1 mean within the flag field?
Answer:
The hex value for the Frame type field is 0x0800.

4. How many bytes from the very start of the Ethernet frame does
the ASCII “G” in “GET” appear in the Ethernet frame?
Answer:
The ASCII “G” appears 54 bytes from the start of the ethernet
frame.There are 14 bytes Ethernet frame, and then 20 bytes of
IP header followed by 20 bytes of TCP header before the HTTP
data is encountered.
5. What is the hexadecimal value of the CRC field in this Ethernet
frame?
Answer:
The hex value for the CRC field is 0x 0d0a 0d0a.
 Next, answer the following questions, based on the contents of the Ethernet frame
containing the first byte of the HTTP response message.
6. What is the value of the Ethernet source address? Is this the
address of your computer, or of gaia.cs.umass.edu (Hint: the
answer is no). What device has this as its Ethernet address?
Answer:
 The value of the Ethernet source address is: a0:65:18:81:a0:9d
This is neither the Ethernet address of gaia.cs.umass.edu nor the
address of my computer. It is the address of my VnptTech
router, which is the link used to get onto my subnet.
7. What is the destination address in the Ethernet frame? Is this the
Ethernet address of your computer?
Answer:
The destination address: d8:cb:8a:a2:09:0e
8. Give the hexadecimal value for the two-byte Frame type field.
What do the bit(s) whose value is 1 mean within the flag field?
Answer:
The hexadecimal value of the two-byte Frame type field is:
0x0800.

9. How many bytes from the very start of the Ethernet frame does
the ASCII “O” in “OK” (i.e., the HTTP response code) appear
in the Ethernet frame?
Answer:
The ASCII “O” appears 54 bytes from the start of the ethernet
frame. There are 14 bytes Ethernet frame, and then 20 bytes of
IP header followed by 20 bytes of TCP header before the HTTP
data is encountered.
10. What is the hexadecimal value of the CRC field in this Ethernet
frame?
Answer:
In this case, the CRC field is supposed to be at the end of the
HTTP data, but there is no value for this field to be showed
right after the final byte of HTTP data.
11. Write down the contents of your computer’s ARP cache. What
is the meaning of each column value?
Answer:
The Internet Address column contains the IP address, the
Physical Address column contains the MAC address, and the
type indicates the protocol type
12. What are the hexadecimal values for the source and destination
addresses in the Ethernet frame containing the ARP request
message?
Answer:
The hexadecimal values for the source is: a0:65:18:81:a0:9d
The hexadecimal values for the destination is: d8:cb:8a:a2:09:0e
13. Give the hexadecimal value for the two-byte Ethernet Frame
type field. What do the bit(s) whose value is 1 mean within the
flag field?
Answer:
The hex value for the Ethernet Frame type field is 0x0806, for
ARP.
14. Download the ARP specification from ftp://ftp.rfc-
editor.org/innotes/std/std37.txt. A readable, detailed discussion
of ARP is also at
http://www.erg.abdn.ac.uk/users/gorry/course/inet-
pages/arp.html.
a) How many bytes from the very beginning of the Ethernet
frame does the ARP opcode field begin?
The ARP opcode field begins 20 bytes from the very beginning
of the Ethernet frame.
b) What is the value of the opcode field within the ARP-payload
part of the Ethernet frame in which an ARP request is made?
The hex value for opcode field within the ARP-payload of the
request is 0x0001, for request.
c) Does the ARP message contain the IP address of the sender?
Yes, the ARP message containing the IP address 192.168.1.1 for
the sender.
d) Where in the ARP request does the “question” appear – the
Ethernet address of the machine whose corresponding IP
address is being queried?
The field “Target MAC address” is set to 00:00:00:00:00:00 to
question the machine whose corresponding IP address
(192.168.1.6) is being queried.
15. Now find the ARP reply that was sent in response to the ARP
request.
a) How many bytes from the very beginning of the Ethernet
frame does the ARP opcode field begin?
The ARP opcode field begins 20 bytes from the very beginning
of the Ethernet frame.
b) What is the value of the opcode field within the ARP-payload
part of the Ethernet frame in which an ARP response is made?
The hex value for opcode field within the ARP-payload of the
request is 0x0002, for reply.
c) Where in the ARP message does the “answer” to the earlier
ARP request appear – the IP address of the machine having the
Ethernet address whose corresponding IP address is being
queried?
The answer to the earlier ARP request appears in the “Sender
MAC address” field, which contains the Ethernet address
d8:cb:8a:a2:09:0e for the sender with IP address 192.168.1.6.
16. What are the hexadecimal values for the source and destination
addresses in the Ethernet frame containing the ARP reply
message?
Answer:
The hex value for the source address is d8:cb:8a:a2:09:0e and
for the destination is a0:65:18:81:a0:9d .

17. Open the ethernet-ethereal-trace-1 trace file in

http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip.
The first and second ARP packets in this trace correspond to an
ARP request sent by the computer running Wireshark, and the
ARP reply sent to the computer running Wireshark by the
computer with the ARP-requested Ethernet address. But there is
yet another computer on this network, as indicated by packet 6 –
another ARP request. Why is there no ARP reply (sent in
response to the ARP request in packet 6) in the packet trace?
Answer:
There is no reply in this trace, because we are not at the
machine that sent the request. The ARP request is broadcast, but
the ARP reply is sent back directly to the sender’s Ethernet
address.