Analyze Ethernet Frames with tcpdump in Linux

Introduction

In this lab, you will learn the fundamentals of network traffic analysis on a Linux system using the powerful tcpdump command-line tool. The primary goal is to capture and inspect Ethernet frames at the data link layer, providing hands-on experience with how data is structured for transmission across a local network. You will gain practical skills in identifying and interpreting low-level network communications.

You will start by preparing your environment, which includes installing tcpdump and identifying your active network interface. Next, you will initiate a live packet capture to monitor network activity in real-time. To understand different communication patterns, you will generate both unicast traffic using the ping command and broadcast traffic via ARP. By examining the captured output, you will learn to analyze Ethernet frame headers and distinguish between unicast and broadcast MAC addresses.

Install tcpdump and Identify Your Network Interface

In this step, you will prepare your environment for network analysis. This involves two key actions: installing tcpdump, a powerful command-line packet sniffer, and identifying the name of your primary network interface. A packet sniffer allows you to "see" the data traveling across the network, and tcpdump needs to know which specific network connection to monitor.

First, let's ensure tcpdump is installed. While it's a standard tool, it's good practice to confirm its presence. We'll use the apt package manager. The command sudo apt update synchronizes your package list with the software repositories, and sudo apt install tcpdump -y installs the tool, with -y automatically confirming the installation.

Execute the following commands in your terminal:

sudo apt update
sudo apt install tcpdump -y

After the installation is complete, you can verify it by checking the version of tcpdump.

tcpdump --version

You should see output similar to this, confirming that the tool is ready to use. The version numbers may vary.

tcpdump version 4.99.x
libpcap version 1.10.x
OpenSSL 3.0.x [Date]

Next, you need to find the name of the network interface you'll be monitoring. A computer can have multiple interfaces (e.g., for wired Ethernet, Wi-Fi, or virtual networks). We will use the ip addr command to list all available network interfaces and their configurations.

Run this command:

ip addr

The output will list several interfaces. You are looking for your primary active interface. It is often named eth0 or enp0s3. Look for an entry that has an inet address (your IP address) and is in the UP state.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:16:3e:01:be:b3 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    altname ens5
    inet 172.16.50.8/24 metric 100 brd 172.16.50.255 scope global dynamic eth0
       valid_lft 1892159786sec preferred_lft 1892159786sec
    inet6 fe80::216:3eff:fe01:beb3/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:8a:88:cd:da brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

From the example output above, the interface name is eth0. Take note of your specific interface name, as you will need it in the next step.

Start a Broad Capture and Observe Traffic

In this step, you will begin capturing live network traffic. The fundamental unit of data at the Data Link Layer (Layer 2) is the Ethernet frame. Each frame acts as a digital envelope, containing not only the data being sent but also crucial addressing information like the source and destination MAC addresses. We will use tcpdump with the -e option to specifically view these Layer 2 details. This initial capture will be unfiltered to give you a sense of all the activity on your network.

Now, let's start the capture process. You will need the interface name you identified in the previous step (e.g., eth0). Capturing network packets requires administrative privileges, which is why we use sudo. We will also add the -n flag to prevent tcpdump from resolving IP addresses to hostnames, and -q to make the output cleaner.

In your terminal, run the tcpdump command. Remember to replace eth0 with your actual interface name.

## Replace eth0 with your actual interface name from Step 1
sudo tcpdump -i eth0 -e -n -q

Let's break down this command:

• sudo: Executes the command with superuser privileges, which are necessary to access network interfaces in this way.
• tcpdump: The packet capture tool itself.
• -i eth0: The -i flag specifies the network interface to listen on.
• -e: This option is crucial for our lab. It tells tcpdump to print the link-level (Ethernet) header for each packet, which includes the source and destination MAC addresses.
• -n: Prevents hostname resolution, showing raw IP addresses.
• -q: "Quiet" mode, which reduces the amount of protocol-specific output.

After running the command, tcpdump will start listening. You'll see an initial message, and then your terminal will begin displaying any packets it captures. Depending on your network, you may see a lot of traffic that isn't relevant to what we want to do. This could include ARP requests, background services, etc.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:24:00.123456 ARP, Request who-has 172.16.50.1 tell 172.16.50.254, length 28
10:24:01.567890 IP6 fe80::... > ff02::...: ICMP6, router advertisement, length 80

Let this run for a few seconds to observe the activity, then stop the capture by pressing Ctrl+C. This demonstrates the challenge of finding specific information in a busy environment.

Refine Capture with an ICMP Filter

As you saw in the last step, an unfiltered capture can be noisy. To focus on the specific traffic we want to analyze, we can use a capture filter. Since we will be using the ping command, which uses the ICMP protocol, we will tell tcpdump to only capture ICMP packets. We will also add the -n flag to stop tcpdump from resolving IP addresses to hostnames and -q to make the output cleaner. This makes the output much easier to analyze.

Now, start tcpdump again, but this time add the icmp filter and the new flags.

## Replace eth0 with your actual interface name from Step 1
sudo tcpdump -i eth0 -e -n -q 'icmp'

The 'icmp' part of the command is the filter. It instructs tcpdump to ignore all packets except for those using the ICMP protocol.

After running this command, tcpdump will be listening again, but the terminal should now be quiet, as it's waiting specifically for ICMP traffic.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

Important: Leave this terminal running! tcpdump needs to stay active to capture the traffic we will generate in the next step. You will need to open a new terminal tab or window for the subsequent commands. You can do this by clicking the + icon in the terminal panel.

Generate Unicast Traffic with 'ping' and Analyze Frame Headers

In this step, you will generate and observe unicast traffic. Unicast is a one-to-one communication method where a frame is sent from a single source to a single destination on the network. To do this, you'll use the common ping utility, which sends ICMP (Internet Control Message Protocol) packets to a target host to check for connectivity. These packets are encapsulated within Ethernet frames for transmission.

With tcpdump (with the icmp filter) still running in your first terminal, you need to generate some network activity.

Open a new terminal by clicking the + icon in the terminal panel. In this new terminal, use the ping command to send a few packets to google.com. We'll use the -c 4 option to automatically send exactly four packets and then stop.

ping -c 4 google.com

You will see output in your second terminal similar to this, showing the replies from Google's server:

PING google.com (142.250.191.174) 56(84) bytes of data.
64 bytes from fra16s51-in-f14.1e100.net (142.250.191.174): icmp_seq=1 ttl=115 time=1.58 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.191.174): icmp_seq=2 ttl=115 time=1.55 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.191.174): icmp_seq=3 ttl=115 time=1.62 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.191.174): icmp_seq=4 ttl=115 time=1.51 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.510/1.565/1.621/0.040 ms

Now, switch back to your first terminal where tcpdump is running. You will see several new lines of output that were captured while you were pinging.

Let's analyze one of the outgoing "echo request" packets. It will look something like this (MAC and IP addresses will differ on your system):

10:25:01.123456 00:16:3e:01:be:b3 > de:ad:be:ef:00:01, ethertype IPv4 (0x0800), length 98: 172.16.50.8 > 142.250.191.174: ICMP echo request, id 123, seq 1, length 64

Here's what this line means:

• 10:25:01.123456: The timestamp of when the frame was captured.
• 00:16:3e:01:be:b3: The source MAC address (your VM's MAC).
• >: A separator indicating the direction of traffic (from source to destination).
• de:ad:be:ef:00:01: The destination MAC address. Note that this is likely your local network's gateway (router), not Google's server. Your VM sends the frame to the gateway, which then forwards it toward the internet.
• ethertype IPv4: This field indicates that the data payload of the Ethernet frame is an IPv4 packet.
• 172.16.50.8 > 142.250.191.174: This is the Layer 3 (IP) information, showing the source and destination IP addresses.
• ICMP echo request: This identifies the packet as part of a ping request.

You will also see the corresponding "echo reply" frames coming back. Notice how the source and destination MAC addresses are swapped.

Finally, go back to the tcpdump terminal and press Ctrl+C to stop the capture.

Generate Broadcast Traffic via ARP and Identify the Broadcast MAC Address

In this step, you will contrast unicast traffic with broadcast traffic. While unicast is a one-to-one message, a broadcast is a one-to-all message sent to every device on the local network segment. A primary example of this is the Address Resolution Protocol (ARP), which is used to discover the MAC address associated with a specific IP address. To do this, a device sends out a broadcast frame asking, "Who has this IP address?"

First, let's start a new tcpdump capture. This time, we will add a filter to only show us ARP packets. We'll also use the -n flag to prevent tcpdump from resolving IP addresses to hostnames, and -q to make the output cleaner.

In a terminal, run the following command, remembering to replace eth0 with your interface name from Step 1.

## Replace eth0 with your actual interface name
sudo tcpdump -i eth0 -e -n -q 'arp'

tcpdump is now listening, but only for ARP traffic.

Next, we need to trigger an ARP request. A reliable way to do this is to clear your system's ARP cache and then try to contact another device on the local network, like your gateway router. Clearing the cache forces your system to re-discover the gateway's MAC address using ARP.

Open a new terminal. First, find your gateway's IP address with the ip route command.

ip route | grep default

The output will show your default route, and the IP address listed after "via" is your gateway.

default via 172.16.50.1 dev eth0

Note: Your gateway IP address will likely be different. It is critical to use the IP address from this command in the steps below. A common mistake is to use a different IP like 172.17.0.1, which is often the gateway for a local Docker network and will not produce the correct result for this exercise.

In this example, the gateway is 172.16.50.1. Now, clear your ARP cache using the ip neigh flush command. This will remove known MAC address mappings, forcing your system to use ARP to find them again.

sudo ip -s -s neigh flush dev eth0

You may see output confirming that entries were deleted. Finally, ping the gateway just once to trigger the ARP lookup.

## Replace 172.16.50.1 with your actual gateway IP
ping -c 1 172.16.50.1

Now, switch back to your first terminal where tcpdump is running. You will see the ARP traffic that was generated. Look for the "Request" line:

10:30:01.123456 00:16:3e:01:be:b3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: ARP, Request who-has 172.16.50.1 tell 172.16.50.8, length 28

Let's analyze this broadcast frame:

• 00:16:3e:01:be:b3: The source MAC address (your VM).
• ff:ff:ff:ff:ff:ff: This is the special broadcast MAC address. When a switch sees a frame with this destination address, it forwards it out of all its ports to every connected device.
• ethertype ARP: This indicates the frame's payload is an ARP packet.
• ARP, Request who-has 172.16.50.1 tell 172.16.50.8: This is the ARP message itself, a broadcast question to the entire network asking for the MAC address of 172.16.50.1.

You will also see the "Reply" packet, which is a unicast frame sent directly back from the gateway to your VM's MAC address.

You can now stop the tcpdump capture by pressing Ctrl+C in its terminal.

Summary

In this lab, you learned the fundamental process of analyzing Ethernet frames using tcpdump in a Linux environment. You began by preparing your system, which involved installing the tcpdump utility with the apt package manager and identifying your primary network interface using the ip addr command. You then learned how to initiate a packet capture, first by running an unfiltered capture to observe all network traffic and appreciate the need for filtering. After stopping the initial capture, you learned to apply an icmp filter with sudo tcpdump -i eth0 -e -n -q 'icmp' to focus specifically on the traffic you wanted to analyze.

The lab then guided you through generating and analyzing two primary types of network traffic. You used the ping command to create unicast traffic and examined the filtered tcpdump output to identify the specific source and destination MAC addresses in the Ethernet frame headers. Subsequently, you generated broadcast traffic by initiating an ARP request with a separate, arp-filtered capture, and learned to recognize the distinct broadcast MAC address, ff:ff:ff:ff:ff:ff, which signifies a frame intended for all devices on the local network segment.