Viewing Network Traffic

1. Introduction to DynamiteLab

Network communication can seem abstract when viewed only as diagrams and models. In this lesson, you will begin working with real network data to see how those concepts look in practice.

By using DynamiteLab, you can open and explore packet capture files—snapshots of actual network activity—to observe how data moves between devices. This experience will help you connect theory to reality and build the foundational skills used by network technicians and analysts to verify connections and diagnose problems.

DynamiteLab is like a powerful microscope for network communications. With it, you can open packet capture (pcap) files, which record the collected network traffic, including individual conversations between devices. Instead of only reading about protocols such as TCP or ICMP, you’ll actually see them in action.

In the workplace, analyzing packet captures is an important skill for troubleshooting problems, spotting security threats, and understanding how applications behave on a network. In this course, DynamiteLab will help you gain hands-on experience by examining real network traffic in a safe environment, build analytical skills by learning how to follow data flows and interpret raw traffic, and visualize abstract ideas by using graphs and timelines to see processes such as a TCP handshake or a DNS query.

It’s easy to get started.

Step 1: Create an account.

Go to the DynamiteLab website and sign up for a free account. You can register with your email and a password or use a Microsoft or Google account to connect directly.

Step 2: Explore the dashboard.

When you log in, you’ll see your main dashboard (screenshot provided). This is where you organize and access packet capture files in the following links:

• Upload: Allows you to add new pcap files
• PCAPs: Access all publicly available files on DynamiteLab.
• My Uploads: See the files you’ve uploaded.
• Starred: Mark favorite files for quick access.
• Recent: Return to the most recent files you’ve analyzed.

Step 3: Learn the analysis tools.

When you select a pcap file, six analysis options appear on the left (screenshot provided). Each tool highlights a different view of the traffic.

• Network Graph: Visualizes communications between IP addresses
• Timeline Analysis: Shows how traffic occurred over time
• Suspicious Traffic: Highlights risks and threats in the capture
• Hosts: Displays communications by individual devices
• Communication: Summarizes protocol interactions
• Artifacts: Groups and visualizes observed file transfers

Step 4: Upload a packet capture file.

For most assignments, you’ll receive a pcap file from the course materials. Follow these steps to upload:

1. Download the provided file (e.g., EXAMPLE.pcap).
2. Select Upload in DynamiteLab (see the screenshot provided).
3. Select the file from your computer.

For most assignments, you will be provided a pcap file, which you will need to upload to DynamiteLab.

Follow these steps to get started:

1. Get the pcap file from the course materials and save it to your local computer. For this, we can use this EXAMPLE.pcap.
2. Select the Upload button in DynamiteLab as seen in the given image.
3. To add the file you just downloaded to your lab environment, select it.

Since we are going to be working with standard pcap files, you may receive an alert when uploading a file that another file with the same MD5 already exists in the workspace. If you see this alert (screenshot provided), simply select the blue link to open the existing file.

Step 5: Open the Analysis view

Once uploaded, select the file to open it. You’ll see the Analysis view (screenshot provided), which contains all the tools needed for exploring network traffic.

Throughout the course, you’ll receive specific directions on how to use these tools for different activities.

terms to know

DynamiteLab

A web-based packet capture analysis tool.

Packet Capture (pcap)

A file that stores network traffic data collected during packet sniffing. These files can be opened with analysis tools to inspect individual packets and communication patterns.

---

2. Network Traffic

So far, you’ve explored the models that explain how networks are built, how data is structured, and how devices communicate. You’ve also learned how data is prepared for travel and how devices such as network adapters and routers move it along.

Now it’s time to go deeper. Instead of just imagining how data flows through a network, you’ll observe it in action.

When something goes wrong, professionals often use a technique called packet sniffing to view the data moving between devices. Packet sniffing uses special tools to capture and examine the small units of data that travel across a network. These units are stored in a pcap file, which records the collected traffic.

By reviewing a capture, you can inspect details such as source and destination addresses, the protocols being used, and whether responses were received. This makes packet sniffing one of the most powerful ways to investigate how data moves across a network.

term to know

Packet Sniffing

The process of capturing and analyzing data packets as they travel across a network, often used for troubleshooting or monitoring traffic.

---

3. TCP

When analyzing network traffic, one of the most common and important protocols you’ll see is Transmission Control Protocol (TCP). Recall that TCP is part of the Transport Layer in the TCP/IP model, and it is responsible for making sure data is delivered accurately, in the correct order, and without duplication. It supports many everyday activities, such as loading webpages, sending emails, or downloading files.

Unlike faster but less reliable protocols such as UDP , TCP is connection oriented. This means it creates a stable, two-way link between devices before any data is exchanged. This initial setup, known as the TCP handshake, is the first sign of a reliable connection and something you’ll learn to identify in a packet capture.

To keep communication reliable, TCP breaks up the data into smaller parts called segments . As you learned earlier, a segment is a unit of data created at the Transport Layer that includes part of the original message, along with control information, such as a sequence number. These sequence numbers help the receiving device reassemble the data in the correct order, even if the segments arrive separately or out of order. If segments are missing or duplicated, TCP can detect the issue and request retransmission.

A key part of this reliability is error checking. Each segment includes a checksum, a calculated value based on the data in the segment. The receiving device recalculates the checksum and compares it to the one sent. If the values do not match, the segment has likely been corrupted, and TCP discards it and requests that it be sent again.

TCP also helps manage the speed of communication using a method called flow control. It adjusts the amount of data sent based on how much the receiving device can process at one time. If the receiver is processing data slowly, TCP slows the sending rate to prevent overload.

In addition to flow control, TCP uses congestion control to respond to network conditions. Network congestion happens when too much data is sent at once, overwhelming routers or links and causing delays or lost packets. TCP detects signs of congestion, such as missing acknowledgments or increased delays, and reduces its sending rate to ease the pressure on the network. It then gradually increases the rate again once conditions improve.

Together, these mechanisms make TCP a reliable, flexible, and self-correcting protocol. When you analyze a network capture, you can often tell whether a connection succeeded or failed just by examining how TCP behaved, especially during the handshake.

Before two devices can exchange data using TCP, they go through a structured process called the TCP handshake. This process confirms that both sides are ready to communicate and agree on how to exchange data. It also helps establish a reliable, stateful connection, meaning the devices will track their communication and respond to each other in order.

1. The client sends a TCP Synchronize (SYN) segment to initiate a connection with the server. This segment includes a starting sequence number and a flag indicating that it is a synchronization request. It is the first step in the TCP three-way handshake, which establishes a reliable connection between two devices.
2. The server responds with a Synchronize-Acknowledge (SYN-ACK) segment, which acknowledges the client’s SYN and includes the server’s own SYN with its initial sequence number. This response confirms that the server received the client’s request and is ready to establish a connection.
3. The client completes the handshake by sending an ACK segment, acknowledging the server’s SYN. At this point, the TCP connection is established, and data transfer can begin. The three-way handshake ensures that both devices are synchronized and helps prevent issues such as replayed or delayed SYN segments from being accepted.

TCP also uses port numbers to direct traffic to the right application on a device. Think of an IP address as the street address of a building and ports as room numbers inside it. Here are a few examples:

• Port 80 is used for insecure web traffic (HTTP).
• Port 443 is used for secure web traffic (HTTPS).

Each connection has a source port (chosen by the client) and a destination port (used by the server’s service). This combination helps match outgoing and incoming data to the right apps on each device.

Even if your packet sniffing tool does not label the handshake steps with terms such as SYN or ACK, you can still confirm that a TCP handshake occurred by looking at three key signs in the traffic:

1. A TCP stream is established between two devices using unique source and destination ports.
2. Data is successfully sent and received on that connection.
3. The connection stays open long enough to allow meaningful communication (not instantly reset or refused).

These clues tell you that the handshake is completed and the devices are communicating reliably. When you analyze the packet capture, you’ll use these observations to verify that TCP was used to set up and maintain a working connection.

EXAMPLE

• Open DynamiteLab and upload this file: 00.pcap.
• Go to the Communications tab. You’ll see a summary of TCP flows in a table.
• Look at the State column:
  • SF means the TCP three-way handshake completed successfully.
  • S1 means the handshake failed.
  • RSTO/REJ means the connection was reset or rejected, and no handshake was successful.

Let’s first examine a successful connection.

• Client: 183.105.164.99 (source)
• Server: 118.42.26.13 on port 80
  • Port 80 is the well-known port for HTTP (web traffic).
  • This shows the client was connecting to a web service.
• State = SF: Handshake completed and closed normally

By examining the content of the History column, we can learn more. Client activity appears in uppercase and server activity in lowercase.

History = ShAFaf

• S = SYN from client
• h = SYN-ACK from server
• A = ACK from client (completes the handshake)
• F = FIN from client (initiates termination)
• a = ACK from server (acknowledges the FIN)
• f = FIN from server (completes termination)

In this screenshot, the History column has been moved next to the State column for easier viewing. In DynamiteLab, the History column normally appears about eight columns to the right, so you may need to scroll over to find it.

Next, let’s look at an unsuccessful connection.

• Upload the file handshake.pcap to DynamiteLab.
• Go to the Communications tab. You’ll see a summary of TCP flows.

Here is a connection summary that shows what happens when a client tries to connect to a port where no service is listening.

• Client: 127.0.0.1 using port 50992
• Server: 127.0.0.1 on port 4444
• State = REJ
  • The connection was rejected. No handshake was completed.
• History = Sr
  • S = SYN from the client, trying to start the handshake
  • r = Reset from the server, refusing the request

What is port 4444?

• Port 4444 is not one of the common “well-known” ports such as 80 (web) or 443 (secure web).
• It’s just a high-numbered port often used for testing or sometimes by certain tools or malware.
• In this example, nothing was listening on port 4444, so the connection was refused. Therefore, a handshake never happened, and no data was exchanged.

try it

Use DynamiteLab to examine a 1.1.4_2.pcap file with TCP traffic. Use the TCP connection summary to answer the following questions:

1. Count how many TCP connections were successful. How do you know?

In this capture, there are 11 successful TCP connections. They are marked with State = SF, meaning the TCP three-way handshake completed successfully and the session ended normally. The History column confirms this with sequences such as ShADadFf and ShAFf, both showing the expected pattern of S (SYN), h (SYN-ACK), and A (ACK) that completes the handshake, followed by F/f to close the connection politely.

2. Count how many TCP connections were unsuccessful. How do you know?

There are 9 unsuccessful TCP connections. These are marked with State = RSTO or REJ, which indicate that the connection was reset or refused before the handshake could finish. For example, History = Sr shows a SYN from the client followed by a reset from the server, meaning the service was not available.

3. In your own words, explain the difference between a successful connection and an unsuccessful one.

A successful connection means the client reached a listening service and completed the handshake. An unsuccessful connection means the handshake failed because the destination refused or reset the request.

watch

TCP Handshake Analysis With DynamiteLab

In real life, this happens in milliseconds. For example, when you open Netflix, your app handshakes with servers to stream reliably. TCP connections are designed to be made and broken down quickly and efficiently so that necessary information can be passed to systems with as little downtime as possible.

terms to know

Flow Control

A method used by TCP to prevent the sender from overwhelming the receiver by adjusting how much data can be sent at a time.

Congestion

A network condition where too much data is transmitted at once, causing delays or dropped packets because devices or links are overloaded.

TCP Handshake

The initial setup process (SYN, SYN-ACK, and ACK) that creates a reliable, two-way connection between devices before data is exchanged.

Synchronize (SYN)

A TCP segment sent by a client to request a connection and share its starting sequence number.

Synchronize-Acknowledge (SYN-ACK)

A TCP segment sent by a server that acknowledges the client’s SYN and provides its own sequence number.

Acknowledge (ACK)

A TCP segment used to confirm the receipt of a SYN or other data, completing the handshake and supporting reliable communication.

Port Number

A numerical identifier that directs traffic to the correct application on a device, such as port 80 for HTTP or port 443 for HTTPS.

Source Port

A port number chosen by the client to identify its side of a TCP connection.

Destination Port

A port number used by the server’s service to receive traffic and match it to the correct application.

Successful Finish (SF)

A state in packet capture analysis that shows a TCP handshake completed successfully and the session ended normally.

Rejected Connection (REJ)

A state in packet capture analysis that shows a TCP handshake attempt was refused, usually because no service was listening on the destination port.