LAB 2: TRANSPORT LAYER

Lab 2: Transport Layer

Objective
In this lab, you will continue to use Wireshark, but now you will explore Transport Layer
protocols. You will examine and analyze various UDP and TCP transmissions under multiple
conditions (e.g., packet loss scenarios). Once again, you will use the hardware in the network
testbeds (the “Racks”) to create the tra c you will capture, observe, and analyze. For some
sections of this lab, you will need to use the Racks’ computers to CAPTURE the data and then
download it to a USB Flash Drive for your future analysis. Make sure to bring a Flash Drive (or
other USB storage device) with you to the testbeds (the “Racks”)!
Before going to the testbeds (the “Racks”), please read this handout COMPLETELY and make
sure that you understand all the steps and questions being asked1. This will help you to be better
prepared for Lab # 2. This will also help you better manage your time at the testbeds.
Write a report, to show you have executed the lab procedures. In this report, answer the
questions that are interleaved among the procedures. Feel free to also include questions,
ponderings, and any interesting stu you observed. Do not forget to include your generated
evidence to support your answers (e.g., annotated screenshots, calculations, annotations, etc.)

Procedures
1. Verify that power switch nine (9) (on the power rail behind the rack) is turned on.

1A good idea would be to read the lecture slides or the corresponding textbook sections regarding the Transport
Layer to fully understand the concepts you will use and test in this Lab.

PAGE 1 OF 12 VERSION 3.5 | OCTOBER 10, 2024




ff
ffi
 LAB 2: TRANSPORT LAYER

2. Verify that the Netgear switches inside the rack display the numbers one (1) and two (2).

3. Turn on (Restart if it is already on) the PC by powering on/o switch eight (8) (on the
power rail behind the rack). BE CAREFUL! The PC must be rebooted between
students, as they are set up to clear out the memory and lesystem.
4. Login to the Rack’s PC with the following credentials:
Username: student
Password: 740Rocks$
5. If power switch two (2) is ON (Lab 2), turn it OFF and wait for ve (5) seconds before
proceeding with the next step (Static charge can keep the device on for a couple of seconds)2.
6. Turn on power switch number two (2) (on the power rail behind the rack) and wait up to
two (2) minutes for the hosts to boot up3.
7. Open the Lab 2 user interface (Lab 2 application) on the desktop of the testbeds’ computer
and make sure that the status line at the bottom reads Status: All hosts are up!
If not, wait for a few more seconds and reopen the Lab 2 user interface (Lab 2 application)
on the testbed’s computer.

2 On the power rail behind the rack, only power switches two (2), eight (8), and nine (9) should be ON. All other
power switches should be powered OFF to avoid any issues with your captures.
3 Sorry, but one of the servers being used in Lab # 2 takes a while to start!

PAGE 2 OF 12 VERSION 3.5 | OCTOBER 10, 2024





fi
ff
fi
 LAB 2: TRANSPORT LAYER

8. Repeat steps ve (5) to seven (7) if any hosts are still down (check the status in the Lab 2
application). You can also repeat these steps to reset the lab components at any point while
completing this assignment.
9. Connect the Ethernet cable to your laptop and open Wireshark (on your connected laptop).
10. When you are done with the lab, shut down the computer and turn o all the power switches
(on the power rail behind the rack) EXCEPT switch nine (9)!

The User Interface

For this Lab, the custom-built Application Interface (“user interface”) is di erent from Lab 1. See
the screenshot below. The Lab 2 application or user interface mostly has a bunch of buttons
(e.g., Open RFC, Start Video Stream, Download Image, Run IPERF test, etc.)
that you will click on during each part of this Lab. Each button will cause some tra c to be
generated, which you will observe using Wireshark.
There is also a slider on the second row of the application interface, that will control (simulate)
packet loss in the network inside the testbed for di erent applications. Be careful that you apply
packet loss only when speci ed in this handout and select the correct option in the drop-down
menu when applying packet loss values (e.g., Packet Loss on Stream).
The last button in the interface, labeled Start Censor is used in Part 4 of this handout.
Please also make sure NOT to click on it until indicated in the handout.

Part 1: A Basic TCP Stream

Let’s begin our exploration of the Transport Layer by creating similar tra c to our Lab 1. In
other words, we will generate HTTP connections between a Client and a Server, but this time,
we will examine what is happening at the Transport Layer (not the Application Layer tra c).
We will use HTTP to request a web object (a le containing a Request For Comment (RFC)
document). Please, complete the following steps:
• Start a Wireshark capture on your laptop (physically connected to the Rack), as you have
done so many times before, your capture should be done in the Ethernet connection that you
have with the Rack. I am not going to tell you what capture lters or display lters to use to
lter out the “noise” -- you are now experienced Wiresharkers! Do whatever you need to

PAGE 3 OF 12 VERSION 3.5 | OCTOBER 10, 2024

fi


fi
fi
fi
ff
fi
ff
ffi
ff
fi
ffi
ffi
 LAB 2: TRANSPORT LAYER

examine this tra c. But, keep in mind that we are interested in the Transport Layer (i.e.,
TCP and/or UDP), not the Application layer (e.g., HTTP).
• Using the Lab 2 interface, click the Open RFC button.
• Wait for the resulting pop-up window to load completely (load all the pages in the RFC
document (slide down to verify that the document was correctly loaded)).
• Stop the Wireshark packet capture and save the PCAP le for your future analysis4.
• Close the pop-up window that displays the RFC document in the Lab 2 user interface.

Answer the following questions:

1. What are the IP address and TCP port number used by the Client (i.e., the Lab 2
Application Interface running on the Rack’s computer) to receive the le? What is the IP
address of the Server? On what port number is the Server sending and receiving TCP
segments for this transfer of the le? Think about the port number classi cation we
discussed in class, does the Server port number match your expectations, and why? Does
the Client port number match your expectations, and why? (5 points)
2. What are the sequence and acknowledgment numbers of each of the segments used to
establish (start) the TCP connection (the sequence numbers exchanged during the "3-way
Handshake")? What are the values (zero (0) or one (1)) of the di erent ags that indicate
each step of the three (3) steps in the handshake? Do these initial segments match your
expectations, and why? Do the acknowledgment numbers in this process (3-way handshake)
match your expectations, why or why not? Make sure to describe how you got your answers
(e.g., in what part of the packet did you nd these answers). Wireshark uses relative
sequence numbers by default5. Can you obtain absolute sequence numbers instead to answer
this question? How did you do that? What are the absolute (raw) sequence numbers being
used by the Sender and the Client? (5 points)
You may use Wireshark’s Relative Sequence Numbers to answer the remaining questions in
this lab.
3. Create a table to calculate the Sample RTT and EstimatedRTT used in TCP. Consider
the TCP segment containing the HTTP GET as the rst segment in the non-overhead part
of the TCP connection (after the “3-Way Handshake”) and measure the corresponding RTT.
For some segments that follow, put together a table with one row per segment (and columns
for whatever data you think is useful to Estimate the RTT) until you have enough segments
to calculate four (4) SampleRTT values. Calculate what those SampleRTT values are, as
well as the EstimatedRTT after each Sample is collected. Discuss this calculation,

4We advise you to save a di erent PCAP le for each part/question in this Lab. For some, questions, it would be
even better if you save individual PCAP les for the di erent permutations that are asked in some questions (e.g.,
di erent packet loss rates). This will help you to have a more organized collection of PCAP les that will be handy
when analyzing them and minimize the ltering of information and the time trying to nd the correct interactions.
5You can learn more about TCP Relative Sequence Numbers in Wireshark in this link: https://wiki.wireshark.org/
TCP_Relative_Sequence_Numbers

PAGE 4 OF 12 VERSION 3.5 | OCTOBER 10, 2024

ff


ffi
ff
fi
fi
fi
fi
fi
ff
fi
fi
ff
fi
fl
fi
fi
fi
 LAB 2: TRANSPORT LAYER

including what your initial EstimatedRTT was, your choice of parameters (columns), any
segments that were not used in the calculation, and the formula that you used. (5 points)
4. Complete your previous table with some additional calculations. Using the information that
you collected in the previous table, calculate the RTT deviation for each of the samples that
you gathered (DevRTT). In other words, complete your table with the DevRTT values for
your Sample RTT and EstimatedRTT. Make sure to explain your choice of parameters
that you used for these calculations and how you calculated them (e.g., the formula and
process that you follow). Finally, calculate the value of the Timeout Interval
(TimeoutInterval) that TCP could use considering each of your values for
EstimatedRTT and its corresponding DevRTT in your table. What formula did you use?
How did you calculate these values? How did the value of the Timeout Interval change for
each sample that you gathered? (5 points)
5. Let’s analyze TPC’s Flow Control by studying the information being sent by the Client at
the beginning of the TCP connection. What is the amount of available (free) bu er space
advertised by the Client?6 Does the lack of receiver bu er space advertised by the Client ever
throttle (i.e., reduce) the send rate of the Server (Explain how or why not)? What is the
Maximum Segment Size being advertised? Based on only the numbers you obtained for the
receiver window and the MSS, approximately, calculate how many segments of MSS size
could be stored by the Client7. Make sure to explain your calculations and answers. (5 points)
6. How much data (amount of bytes and number of segments) does the Client typically
acknowledge in a single ACK? Can you identify cases where the Client uses Delayed
ACKs? Explain how or why not. What is the most typical length of the TCP Payload when
the Server is sending data to the Client? What is the most typical length of the TCP Header
when the Server is sending data to the Client? Based on the size of the TCP payload and
TCP header that you found for the Server and assuming an IP header of twenty (20) bytes,
calculate the MTU of this connection. Make sure to explain your calculations and answers.
(5 points)

Part 2: TCP vs UDP

In this section, you will transfer an image two times, once using TCP and once using UDP. You
will then compare and explain the di erences.
Due to the Rack’s Maximum Transmission Unit (MTU) and other restrictions, the capture for
Part 2 of the lab can only be done on the testbed’s Next Unit of Computing (NUC) (i.e., the
Windows computers in the Racks that you have been using to generate the network tra c).
Open and use the Wireshark application on the testbed’s NUC (Computer) to examine tra c
and capture PCAP les. You may then use the extension USB port (next to the screen) to
transfer your les from the NUC to a USB ash drive (that you need to bring to the lab!).

6 You should report the value Calculated Window Size by Wireshark.

7You can ignore the size of the TCP header for this calculation. You only need to consider the advertised bu er
space and the size of the MSS.

PAGE 5 OF 12 VERSION 3.5 | OCTOBER 10, 2024



fi
fi
ff
fl
ff
ff
ffi
ff
ffi
 LAB 2: TRANSPORT LAYER

Note: You should only use Wireshark on the NUC (Rack’s computer) for questions seven (7) to
twelve (12) of this lab. The NUC's promiscuous mode is not as reliable as the switch tap (i.e., the
Ethernet wire you connect to your computer) and you might miss some critical packets.
Please, complete the following steps:
• Start up Wireshark packet capture on the testbed’s NUC using the Ethernet interface.
Remember that you want to be able to see UDP and TCP segments.
• Make sure the Packet Loss slider in the Lab 2 application interface is set to zero percent
(0%).
• Click the Download Image button on the Lab 2 application interface.
• An image will be displayed twice on pop-up windows, once via a UDP transfer and once via a
TCP connection.
• Stop the Wireshark packet capture and save the PCAP le. Transfer the PCAP le to your
USB ash drive and delete it from the NUC.
• Close the pop-up windows that display both images (TCP transfer and UDP transfer).

Answer the following questions:

7. Measure the total time and total number of bytes needed to transfer the image using TCP
(including all the necessary steps that are required to manage the connection). Measure the
total time and total number of bytes needed to transfer the image using UDP. What
di erence did you notice between the total number of bytes and the total time between TCP
and UDP? Was the di erence in the total time, between TCP and UDP, something you
expected, why or why not? Was the di erence in the total number of bytes, between TCP
and UDP, something you expected, why or why not (Hint: Probably not!)? (7 points)

Let's see what happens when the network loses some packets (and consequently some segments
at the Transport Layer). Continue by doing the following:
• Start up Wireshark packet capture on the testbed’s NUC using the Ethernet interface.
Remember that you want to be able to see UDP and TCP segments.
• On the Lab 2 Application interface, change the packet loss slider to a value greater than zero
percent (0%). Make sure the drop-down menu next to the slider says Packet loss on
Stream and click Apply8.
• Click the Download Image button again and wait for the two images to be displayed (one
via a UDP transfer and one via a TCP connection).

8To be sure that the loss value is set, we recommend clicking the Apply button a couple of times, you know just to
be sure!

PAGE 6 OF 12 VERSION 3.5 | OCTOBER 10, 2024

ff

fl

ff
ff
fi
fi
 LAB 2: TRANSPORT LAYER

• Repeat the download process of the image with another packet loss value greater than zero
percent (0%) (two loss values in total)9. Note that at very high packet loss rates (e.g., 20%),
the UDP image might not load at all. In such a case, reduce the packet loss rate. You want
to see the images transferred (displayed) to the application interface.
• Stop Wireshark packet capture and save the PCAP le(s). Transfer the PCAP le(s) to your
USB ash drive and delete it from the NUC.
• Close the pop-up windows that display both images (TCP transfer and UDP transfer)

Answer the following questions:

For the following questions (eight (8) to ten (10)), explain your captured data as best as you can.
8. What packet loss rates did you use? What did you see in each window displaying the image?
Indicate the total time and total number of bytes needed to transfer the image using TCP for
the two di erent packet loss values. Indicate the total time and total number of bytes needed
to transfer the image using UDP for the two di erent packet loss values. Did you notice a
di erence between the total number of bytes for UDP for each of the experiments (no loss,
rst loss value, and second loss value (question 7 and question 8)? Make a hypothesis
regarding the di erence in the total number of bytes in UDP and what you observed when
loading the image using UDP. (8 points)
9. Are there any retransmitted segments? What did you check for (in the packet trace) to
answer this question? (6 points)
10. How many segments were sent in each case (TCP and UDP) in each packet loss rate that
you used? (4 points)

What if instead of downloading a static image, the tra c would be a live video stream (e.g., some
YouTube video, Net ix video, Twitch live stream, a videoconference call, etc.)? Let's nd out.
Please, complete the following steps:
• We will use the NUC’s web camera for this section10.
• Start with a zero percent (0%) packet loss in the Lab 2 application interface (make sure to
click the Apply button (you know a couple of times to be sure!)).
• Click the Start Video Stream button in the Lab 2 Application interface. You should
see two small windows displaying the camera feed (one for TCP and one for UDP).
• Be creative! Pop a dance move or wave your arms around to check that the video stream is
working correctly.

9A little tip (that you can disregard if wanted): You probably want to have each packet loss experiment saved in a
di erent PCAP le to simplify your future analysis (e.g., an individual PCAP le for each scenario in these
questions: no loss, loss value 1, and loss value 2).

The camera is located on top of the testbed’s screen. If the camera is not there, please look around the Racks as it
10

might have fallen and put it back in its intended position (on top of the screen).

PAGE 7 OF 12 VERSION 3.5 | OCTOBER 10, 2024

fi
ff
ff

fl

ff
fi
ff
fl
ff
fi
ffi
fi
fi
fi
 LAB 2: TRANSPORT LAYER

Note: The stream might behave erratically due to some programming issues. More than the
quality of the image, you are looking for which one (the TCP window or UDP window) gets
stuck (“freezes”) more often. You could assume we had cool software that would make
corrections in the Application Layer so that it would look stable to the nal users (once the
application is in production).
• Gradually increase packet loss (using the slider) and observe how the video streams behave.
Note: You have to hit the Apply button to activate any changes you have made to the packet
loss slider (Make sure the drop-down menu next to the slider says Packet loss on
Stream).
• Close the pop-up windows with the camera feed (one for TCP and one for UDP).
• Leave the web camera in its intended position.

Answer the following questions:

11. How do the TCP and UDP video streams change as you vary the packet loss slider for both
TCP and UDP connections? Is this the expected behavior and why? At high packet loss
rates, did either of the streams stop? Why do you think that happened? (5 points)
12. Now that you have analyzed both Image download and Video stream services, comment on
the overall behavior of TCP and UDP for both scenarios that you tested (images and video
streams). Which of the two protocols would you pick for your favorite online activities (e.g.,
gaming, streaming, web browsing, etc.) and why? Make sure to comment on any other
observations you have. (8 points)

Note: For the following parts of Lab 2 you will be using Wireshark on your computer again
(connected to the testbed’s Ethernet cable).

Part 3: Congestion Control

Network Congestion Control (CC) is a crucial part of the TCP protocol. Let's take this
opportunity to explore and compare various TCP CC algorithms (versions) that we have studied
in class.
To generate TCP connections using di erent CC algorithms simultaneously, we will be using a
program called iperf (check out the tool page, it does some cool stu ). We use iperf to
create multiple TCP connections (a.k.a streams in Wireshark), where each connection uses a
di erent CC mechanism/version, to port numbers between 20,000 and 40,000.
On each port (between 20,000 and 40,000), a TCP connection is started using a di erent
TCP CC version (e.g., TCP Reno). In addition, two back-to-back TCP connections are
established in each port. The rst TCP connection is mostly ignorable, though if you dig
through it, you will nd out which TCP congestion control algorithm is used for each port
(hmm. That sounds useful!).

PAGE 8 OF 12 VERSION 3.5 | OCTOBER 10, 2024

ff


fi
fi
ff
fi
ff
ff
 LAB 2: TRANSPORT LAYER

The second TCP connection on each port is the one we are interested in, as it probes for
additional bandwidth/throughput using di erent congestion control algorithms (TCP versions).
Wireshark's TCP stream lters may be handy for this section.
Please, complete the following steps:
• Start up Wireshark capture on your laptop, NOT the testbed’s NUC.
• Make sure the packet loss slider on the Lab 2 application interface is back at zero percent
(0%) and Click Apply.
• Click the Run IPERF test button on the Lab 2 Application Interface.
• Wait for around fteen (15) to thirty (30) seconds. The Application Interface will not pop up
any information (The script window of the Lab 2 application might provide some additional
information about the process. However, you should see a lot of TCP packets popping up in
your Wirehsar capture!
• Stop the Wireshark packet capture and save the PCAP le for your future analysis.

Answer the following questions:

Once again, remember that for each congestion control test being initiated by iperf (in each
particular port), two TCP connections are established. First, a TCP connection that contains
metadata about the process and setups the test, but does not test the available bandwidth/
throughput. After these initial TCP connections, a second TCP connection is established in
each port, where the actual bandwidth/throughput for each TCP CC version is tested.
13. Which TCP network congestion control algorithm is used on each port? How did you nd
this information? Explain the main theoretical di erences between these congestion control
algorithms (e.g., are they loss- or delay-based) (5 points).
14. What average throughput (in Mbits/s) did each TCP network congestion
connection achieve? What TCP network congestion connection achieved the highest
and lowest average throughput (in Mbits/s)? Do these results match your
expectations and why? (Hint: To calculate/observe the throughput (average number
of bits/s), you might want to use the statistics tool that you learned/used in Lab 0)
(5 points)
15. Use the Time-Sequence-Graph(Stevens) plotting tool to view the sequence number
versus the time plot of segments being sent for each congestion control algorithm
that you identified. If possible for each stream, identify (show) where TCP’s slow
start phase (if any) begins and ends, where congestion avoidance takes over,
response to losses, and any other similar changes (Hint: You might need to zoom in
the graph for the bandwidth test stream to differentiate the different TCP CC
phases. In addition, remember where these phases can start)11. (7 points)

You might need to click on the Switch Direction button to get the correct orientation in the Time-Sequence
11

graph and other TCP graphs that you might need to use.

PAGE 9 OF 12 VERSION 3.5 | OCTOBER 10, 2024



fi
fi
ff
ff
fi
fi
 LAB 2: TRANSPORT LAYER

Let's see what happens when the network loses some packets (and consequently some
segments at the Transport Layer). Continue by doing the following:
• In the Lab 2 application interface, use the drop-down menu to change the type of
packet loss to Packet loss on IPERF. Then, pick a packet loss value greater than
zero percent (0%) (using the slider) and hit the Apply button. Then, run the iperf
test, by clicking on the Run IPERF test button on the Lab 2 Application Interface.
• In total, run the iperf test at least five (5) different times with five (5) different
packet loss values in each run (use the slider and remember to hit the Apply button
between each of the five (5) runs that you need to complete).

Answer the following question:

16. Show a table and plot the relationship between packet loss rate (the percentage of
packet losses you chose) and the percentage of maximum throughput achieved by
each of the TCP congestion control algorithms in a single scatter graph.12 (Hint:
Use the sum of the maximum achieved throughputs for each TCP CC version in
each packet loss value to calculate the percentage of throughput achieved by each
congestion control algorithm compared to the total sum. The following table might
help you as a reference13. After you create your table, you should be able to plot the
relationship between the packet loss rate and the maximum throughput
percentage of each TCP CC at each of these packet loss rates). Analyze the results of
your plot and what they are telling you about packet losses in the network and the
different CC algorithms. (7 points)

TCP CC # 1 % TCP CC # 2 % TCP CC # 3 % Total Throughput

Throughput CC1 +
(Throughput CC1/ (Throughput CC2/ (Throughput CC3/
Throughput CC2 +
Lost Rate # 1 Total Lost Rate # Total Lost Rate # Total Lost Rate #
Throughput CC3 =
1)*100 1)*100 1)*100
Total Lost Rate # 1

Throughput CC1 +
(Throughput CC1/ (Throughput CC2/ (Throughput CC3/
Throughput CC2 +
Lost Rate # 2 Total Lost Rate # Total Lost Rate # Total Lost Rate #
Throughput CC3 =
2)*100 2)*100 2)*100
Total Lost Rate # 2

Throughput CC1 +
(Throughput CC1/ (Throughput CC2/ (Throughput CC3/
Throughput CC2 +
Lost Rate # 3 Total Lost Rate # Total Lost Rate # Total Lost Rate #
Throughput CC3 =
3)*100 3)*100 3)*100
Total Lost Rate # 3

The TCP Throughput graph might be useful to calculate/observe the maximum achievable throughput for each
12

TCP stream.
13The table is only meant to provide you with a reference on how to create and calculate the required values that you
can use to create the graph. Please feel free to modify the table in any form you need or to use a di erent table (or
resource) to create the graph.

PAGE 10 OF 12 VERSION 3.5 | OCTOBER 10, 2024



ff
 LAB 2: TRANSPORT LAYER

TCP CC # 1 % TCP CC # 2 % TCP CC # 3 % Total Throughput

Throughput CC1 +
(Throughput CC1/ (Throughput CC2/ (Throughput CC3/
Throughput CC2 +
Lost Rate # 4 Total Lost Rate # Total Lost Rate # Total Lost Rate #
Throughput CC3 =
4)*100 4)*100 4)*100
Total Lost Rate # 4

Throughput CC1 +
(Throughput CC1/ (Throughput CC2/ (Throughput CC3/
Throughput CC2 +
Lost Rate # 5 Total Lost Rate # Total Lost Rate # Total Lost Rate #
Throughput CC3 =
5)*100 5)*100 5)*100
Total Lost Rate # 5

Part 4: On-Path Censors

Let's examine the behavior of another network bad actor and see if you can determine how an
attack is carried out.
• Start up Wireshark on your laptop, NOT the testbed’s NUC.
• Make sure the packet loss slider on the Lab 2 application interface is back at zero percent
(0%) and Click Apply.
• In the Lab 2 Application Interface, click the Start Censor button. Then, carefully read
the disclaimer, and accept by clicking Yes.
• Wait for twenty (20) seconds for the application interface to start the script.
• Try to open the RFC you opened in Part 1 of this lab (click the Open RFC button). You
should see something di erent than before!
• Stop Wireshark packet capture and save the PCAP le for your future analysis.

Answer the following question:

17. What did you observe? The attack is similar to the attack from Lab 1, but it does so by
manipulating the TCP state. To e ectively block the connection to the RFC website, what
ags and elds in TCP did the attacker have to set? Why is the attacker successful? (Hint:
The attacker spoofs IP addresses, but all the reset segments are from the attacker.) Look
closely at the TCP trace and report on anything else you found interesting. Just think, if
someone on your network does not want you to read the “RFC”, it is pretty easy for them to
stop you. (8 points)

Turn-in
Write a report of your interactions and answer ALL the questions. Make sure to include
enough details to ensure we understand that you understand what is going on. For instance,
screenshots should probably be annotated to show where a number came from. Do not
assume that because you know how to read a Wireshark screen, we know that you know it.

PAGE 11 OF 12 VERSION 3.5 | OCTOBER 10, 2024

fl

fi

ff
ff
fi
 LAB 2: TRANSPORT LAYER

Our graders will not make that assumption. So, prove it to us by describing/annotating
every value you nd from Wireshark.
Turn in your answers in a single PDF le and submit it to the Lab2 Assignment on
Gradescope.
In Gradescope, Map the questions to all the corresponding page(s) in your
document. Students who fail to map a question correctly will lose all the points
for that question.
Do not forget to save (and name) all your PCAP les for your future analysis14.

14For the PCAP les generated in the NUC of the testbed, please do not forget to fully delete them after nishing
your lab!

PAGE 12 OF 12 VERSION 3.5 | OCTOBER 10, 2024



fi
fi
fi
fi
fi