Wireshark Packet Capture Practice: Read Network Traffic and Find the Failure

What a packet capture can—and cannot—prove

A packet capture records traffic observed at a particular point in a network. It can show which packets arrived, their timestamps, source and destination addresses, protocol fields and, where unencrypted, portions of their payloads. It cannot automatically reveal packets that never reached the capture point, or decrypted application content from ordinary encrypted TLS traffic.

After the guided capture reading here, use the AP Networking Packet Capture Analysis Practice Test for a scored diagnostic of collection scope and inference. The 75 questions include one-direction filters, mirror limits, checksum offload, encrypted-content visibility, and paired observations that bracket a missing exchange.

For a second pass after annotating a capture, use the AP Networking TCP and UDP Transport Troubleshooting Practice Test to assess the transport inference itself. Compare request and reply tuples, identify the last completed stage, and account for offload or missing earlier capture context before declaring a fault.

In this free lab, all packet records are fictional training examples. No live traffic is collected, no installation is required, and no student answers are transmitted to our server.

Seven steps for an evidence-led packet investigation

1. Write down the user’s original failed operation.
2. Identify the capture interface, time window and network location.
3. Record the client, server and expected protocol or service.
4. Filter to the relevant conversation without losing context.
5. Find the first request and trace the expected response.
6. Compare the failure with a working control and state what remains uncertain.
7. Propose a narrow repair and specify an end-to-end verification test.

Do not upload real captures containing student data, credentials, internal addresses or private application content to public tools. Use synthetic captures or follow your school’s approved data-handling procedures.

DNS responds—but the website still fails

Incident: A student says the learning portal cannot open. A DNS query for portal.school.example succeeds, but the HTTPS connection fails. The capture was taken on the student device.

Swipe horizontally to see the rest of the packet table.

A DHCP exchange stops before the lease arrives

Incident: A laptop joins the school wireless network but does not receive a usable IPv4 lease. The capture is from the affected client.

Swipe horizontally to see the rest of the packet table.

Explain why retransmissions are evidence—not an automatic diagnosis

When a TCP sender does not observe the acknowledgment it expects, it may retransmit. But retransmissions seen in a trace can also reflect where the capture was taken, asymmetric traffic visibility, capture loss or other timing conditions. Have students compare the original segment’s sequence number, later retransmissions, acknowledgments and the endpoint’s view before declaring “the network dropped packets.”

Ask: “What would a simultaneous server-side capture show if the SYN never arrived? What if the SYN arrived and the SYN-ACK never returned?” These competing predictions turn a symptom into a testable hypothesis.

A 20-point rubric for student packet investigations

Use the same rubric for any of the three cases: 4 points for correctly identifying the request and response pattern; 4 points for accurate packet-field evidence; 4 points for a supported inference; 4 points for stating a meaningful limitation or competing explanation; and 4 points for a discriminating next test and verification plan.

For partial credit, separate a student who noticed the correct packet but overclaimed the root cause from a student who ignored the trace entirely. Ask students to revise one unsupported sentence into an observation-plus-inference statement.

Five packet-analysis errors worth catching early

1. “No reply means the server is down.” The response might have been filtered, routed elsewhere or missed by the capture point.
2. “DNS works, so the site must work.” DNS and application delivery are different stages.
3. “Every RST proves the application crashed.” Direction and network middleboxes matter.
4. “A display filter proves other traffic did not exist.” Clear filters before making absence claims.
5. “One successful ping proves HTTPS is fine.” ICMP and TCP/443 have different paths and policies.

Build each correction around an observable packet field and one follow-up test rather than a memorized troubleshooting slogan.