ARP and Wireshark Lab: Reconstruct the Local Conversation

This lab brings together Week 16 addressing and this week's ARP/Wireshark work.

You will reconstruct a local network conversation from the course-owned synthetic capture:

Download gsc-week17-baseline.pcapng

No live capture is required or authorized.

Scenario

The capture contains these fictional endpoints:

student workstation
IPv4: 192.0.2.25
MAC:  02:00:00:00:00:25

local server
IPv4: 192.0.2.10
MAC:  02:00:00:00:00:10

DNS resolver
IPv4: 198.51.100.53

The local conversation includes:

• ARP request/reply
• ICMP reachability traffic
• DNS lookup for server.gsc.example
• a TCP connection to the local server
• a small HTTP request/response
• normal TCP connection close

Your job is to reconstruct what the packets prove, not invent an attacker.

Phase 1: find the ARP exchange

Use:

arp

Identify:

• request packet number
• sender IPv4 address
• sender MAC address
• target IPv4 address
• reply packet number
• MAC address returned for the target

Build a request/reply table.

Phase 2: explain why ARP happened

Answer:

• Are 192.0.2.25 and 192.0.2.10 treated as local peers in this supplied scenario?
• Why does the workstation need a link-layer destination?
• Which system answers the request?
• What would change conceptually if the destination were outside the local network?

The final question is a network-model question, not something the local capture proves by itself.

Phase 3: correlate the later traffic

After the ARP exchange, identify later packets involving 192.0.2.10.

Use filters such as:

ip.addr == 192.0.2.10

icmp

tcp

Record:

• packet numbers
• source/destination IP
• source/destination MAC where visible
• protocol
• timestamps

Then explain how the ARP result supports later local Ethernet delivery.

Phase 4: inspect name resolution

Use:

dns

Find the query for:

server.gsc.example

Record:

• query packet number
• response packet number
• returned IPv4 address

Then compare the DNS result with the destination used by the later TCP conversation.

If they do not agree, your analysis should stop and flag the contradiction. In the approved course capture, the evidence is intentionally consistent.

Phase 5: build the local timeline

Create a sequence supported by packet numbers:

1. workstation needs a local destination mapping
2. ARP request is sent
3. server supplies the mapping
4. later local traffic is exchanged
5. name resolution identifies the server address
6. a TCP conversation begins

Do not skip directly from "ARP happened" to "there was an attack."

Phase 6: test an incorrect claim

Claim:

"The ARP request proves the workstation was attacked."

Refute it using:

• protocol purpose
• the request/reply evidence
• the normal traffic that follows

Then write a stronger claim beginning:

"The supplied capture shows..."

Your stronger claim must describe what the evidence demonstrates without inventing motive or identity.

Phase 7: compare packet and topology evidence

A network diagram predicts how systems should communicate.

The capture records what this synthetic scenario did communicate.

Compare:

Include at least four observations.

Analyst summary

Write:

Question

What local communication were you reconstructing?

Evidence

Which packets and fields mattered?

Mechanism

What role did ARP play?

Result

What local mapping was learned?

Limitation

What can this supplied capture not tell you?

Evidence for Lesson 3

Submit:

• ARP request/reply table
• DNS evidence note
• packet timeline
• topology-versus-capture comparison
• incorrect-claim correction
• analyst summary

Finish with:

I can prove the local mapping because packet ________ shows ________, and packet ________ shows ________.

Packet analysis becomes defensible when every sentence can point back to the evidence that supports it.