Introduction
A service name or port report summarizes a network observation. A packet capture lets you examine the actual traffic behind that summary, including endpoints, connection control, and application messages.
You will capture one small, authorized HTTP exchange on the Kali loopback interface. Save a real pcap and inspect it with tcpdump, using the process-control and HTTP skills from earlier labs.
Capture a Small Local HTTP Exchange
In this step, you will capture a bounded set of packets for an HTTP request to the supplied training service.
Enter Kali and choose the shared workspace:
kali
cd /home/labex/project
The HTTP endpoint is http://127.0.0.1:8080/capture.txt. Because the address is loopback inside Kali, its traffic uses the lo interface rather than the host's network interface. Packet capture requires elevated permissions in this environment; use sudo only for the capture and analysis commands that need it.
tcpdump captures packets. -i lo selects loopback, -c 8 stops after eight matching packets, and -w training.pcap writes a binary capture file. The quoted filter tcp port 8080 selects TCP traffic involving the training service's port. The trailing & starts the capture in the background so you can generate the request in the same terminal:
sudo tcpdump -i lo -c 8 -w training.pcap 'tcp port 8080' &
The shell prints a job number. Tcpdump may print a message that it is listening. Give the capture one second to initialize with the sleep command you practiced previously:
sleep 1
Now make the already taught curl request and save its response body:
curl -sS http://127.0.0.1:8080/capture.txt > captured-response.txt
The request and response create multiple TCP packets, including connection establishment and application data. wait waits for background jobs in this shell to finish:
wait
Tcpdump should stop after its configured packet count and print a capture summary. A binary pcap is a structured packet file; do not read it with cat as if it were text. Inspect the application response separately:
cat captured-response.txt
Expected output:
Local capture practice.
The pcap and response body describe the same local exchange in different forms. Keep this capture limited to the provided interface and endpoint.
Read and Interpret the Saved Packets
In this step, you will read the capture and connect packet endpoints to the HTTP request and response.
-r reads a saved capture instead of listening live. -nn keeps both addresses and ports numeric, preventing name lookups from obscuring the actual endpoints:
sudo tcpdump -nn -r training.pcap
Each line includes a timestamp, endpoints, and transport information. Look for 127.0.0.1 on both sides and port 8080 at the service end. The other TCP port belongs to the client and can vary. TCP flags describe connection control as well as application-data packets, so not every line contains an HTTP message.
Add -A to display packet content as ASCII text:
sudo tcpdump -nn -A -r training.pcap
Among binary-looking protocol fields, look for the request GET /capture.txt HTTP/1.1 and a successful HTTP response status. This is plain HTTP; encrypted HTTPS would not expose the same readable application content in a basic packet dump.
Save that readable analysis separately from the original pcap:
sudo tcpdump -nn -A -r training.pcap > packet-details.txt
Tcpdump's capture-file description may still appear on standard error. The packet details go to the redirected file. Use grep to locate the request line:
grep 'GET /capture.txt' packet-details.txt
The matching line ties the packet evidence to the request you generated. You retained the binary capture for later tools and a readable view for quick inspection.
Summary
You selected a capture interface and filter, limited packet count, coordinated a background capture with an HTTP request, and read the resulting pcap. You related numeric endpoints and TCP packets to a real request and response.
