Capturing at the Right Point

The most common packet-analysis failure is not misreading the capture. It is capturing somewhere that cannot see the problem.

A capture on a laptop shows what the laptop sent and received. A capture on the gateway shows what crossed the gateway. Neither shows what happened on the wire between the access point and the switch, which is where the drops usually are.

The five places you can tap

Choose by question:

• "Does the server respond?" → endpoint capture on the server.
• "Is the packet reaching the server?" → tap or mirror near the server.
• "Is the firewall dropping it?" → gateway capture plus policy logs.
• "Is the client even transmitting?" → wireless monitor mode.

Mirroring, and its limits

A SPAN port copies frames to a destination port. Two things routinely go wrong:

1. Oversubscription. Mirroring a 10 Gbps link to a 1 Gbps port drops frames silently. The capture looks like packet loss that the network is not experiencing.
2. VLAN tags. Some switches strip tags on mirror destinations, so your capture cannot tell you which VLAN a frame belonged to. Configure the mirror to preserve tags.

On UniFi, port mirroring is configured per switch under the port's settings. Mirror the uplink of the AP or switch you suspect, not the whole switch, unless you can afford the bandwidth.

Capturing from the command line

tcpdump is the tool that exists on every Linux box, including servers and small appliances.

# everything on one interface, full packets, written to a ring buffer
tcpdump -i eth0 -s 0 -w /var/tmp/cap-%H%M.pcap -G 300 -W 12

# only one conversation, without writing a file
tcpdump -i any -nn 'host 10.40.12.57 and port 443'

# DNS queries only, with names resolved
tcpdump -i any -nn -v 'udp port 53'

Two flags matter more than the rest:

• -s 0 captures the whole packet. The default snaplen can truncate payloads and hide the very data you need.
• -w writes binary. Piping to -A for ASCII is convenient and lossy; capture to a file, then read it.

Time, privacy, and scope

• Synchronize clocks before correlating captures from two devices. A 200 ms offset will make a normal handshake look delayed.
• Capture the smallest scope that answers the question: one host, one port, one VLAN.
• Treat captures as sensitive. They can contain credentials, student data, and internal hostnames. Retain them only as long as needed, and store them somewhere access-controlled.

In a district, a capture of student traffic is a student record in some interpretations. Get the scope in writing before you start, especially if the capture leaves your machine.

Worked example: "this classroom is slow"

1. Question: is the AP dropping frames, or is the client failing to transmit?
2. Mirror the AP's uplink for ten minutes during the complaint window.
3. Filter to the affected client's MAC.
4. Look for retransmissions, duplicate ACKs, and long inter-frame gaps.
5. If the capture shows clean server responses and repeated client retransmits, the problem is on the wireless side — go to monitor mode, not deeper into the wired capture.

The capture did not solve the problem. It eliminated half of the network, which is what a good capture does.

What breaks in production

• Capturing on the wrong interface. eth0 when the traffic uses a VLAN subinterface or a bridge.
• Snaplen too short. You see headers and no payload, and TLS handshake details are gone.
• Dropped frames at the mirror. The capture shows loss that does not exist.
• No timestamps or unsynchronized clocks, so two captures cannot be correlated.
• A capture filter that excludes the evidence, such as port 53 when the failure is DoH on 443.

Checklist

1. The capture point can see both directions of the flow.
2. Snaplen is 0 (full packets).
3. The mirror is not oversubscribed.
4. Clocks are synchronized across capture points.
5. Scope is minimal, documented, and stored securely.
6. You wrote down the question before you pressed start.

Next

You have packets. Continue with Reading a TCP Handshake and Its Failures to interpret them.