Packet, Protocol, and Wi-Fi Analyzers
Key Takeaways
- Packet captures reveal the actual traffic and are useful when logs or symptoms are not enough.
- Protocol analyzers decode conversations such as DNS, DHCP, TCP, TLS, HTTP, and wireless management frames.
- The capture point must be chosen carefully because switched networks, VLANs, tunnels, and encryption affect visibility.
- Wi-Fi and spectrum analyzers evaluate SSIDs, channels, signal, noise, interference, roaming, and authentication symptoms.
- Captured traffic can include sensitive data, so access, storage, and sharing must be controlled.
Packet, Protocol, and Wireless Analysis
When counters, logs, and command-line tests are not enough, look at the traffic itself. Packet analyzers (such as Wireshark or tcpdump) record raw frames; protocol analyzers decode those frames into readable conversations. Wi-Fi analyzers and spectrum analyzers reveal radio conditions that no wired tool can see. N10-009 objective 5.3 calls out protocol analyzers and Wi-Fi analyzers explicitly, so expect questions on where to capture and what a capture can and cannot prove.
Packet Capture Basics
| Concept | Meaning |
|---|---|
| Packet capture | Recorded frames/packets from an interface, TAP, SPAN port, or sensor |
| Protocol analyzer | Decodes captured traffic into protocols and fields |
| Capture filter | Limits what is collected (e.g., tcp port 443) |
| Display filter | Limits what is shown after capture (does not reduce stored data) |
| TAP | Hardware device that passively copies traffic in the path |
| SPAN / mirror port | Switch feature copying selected port/VLAN traffic to an analyzer port |
Capture placement is the most-tested concept here. A laptop on one access port normally sees only its own unicast, plus broadcasts and multicasts; a switch does not flood unicast frames to every port. To inspect server-to-firewall traffic you must capture on the server itself, configure a SPAN/mirror port, insert a TAP in the path, or capture from a device already in the path such as the firewall. A common PBQ trap shows a capture from an unrelated port returning nothing useful.
What Captures Can Prove
| Symptom | Capture evidence |
|---|---|
| DHCP failure | DHCPDISCOVER leaves the client, but no DHCPOFFER returns |
| DNS problem | Query returns NXDOMAIN, a wrong record, a timeout, or an unexpected resolver |
| TCP service failure | SYN sent with no SYN-ACK, an RST returned, or the handshake completes then the app fails |
| MTU/black-hole | "Fragmentation needed" ICMP, retransmissions, or large packets silently dropped |
| TLS issue | Handshake alert, certificate name mismatch, unsupported version, or cipher mismatch |
| Intermittent loss | Retransmissions, duplicate ACKs, sequence gaps, or path-specific drops |
Captures show whether a packet left the client, reached the server, and got a reply. Capturing at both ends distinguishes client-side, network-path, and server-side faults, the single most powerful technique for intermittent problems. Reading a capture follows a logic: confirm the request left the source, confirm it arrived at the destination, then confirm the destination answered.
If the SYN appears on the client capture but never on the server capture, the fault is in the path or firewall; if the SYN arrives but the server sends an RST, the service is refusing the connection; if the handshake completes but the application stalls, the issue is above transport. Capture and display filters serve different roles: a capture filter such as host 10.1.1.5 and port 53 reduces stored volume on a busy link, while a display filter such as dns.flags.rcode != 0 narrows a large file to just the failures.
Encryption Limits
Encryption protects confidentiality but limits visibility. A capture of TLS or VPN traffic still shows source/destination IPs, ports, packet sizes, timing, the TLS handshake metadata (SNI, certificate, cipher), unencrypted DNS, and connection resets. It will not show the encrypted application payload of HTTPS, SSH, or an IPsec/SSL VPN. Never assume a capture will hand you the cleartext contents of an encrypted session.
Wi-Fi and Spectrum Analysis
| Wireless issue | Analyzer evidence |
|---|---|
| Co-channel congestion | Many APs/clients sharing the same channel contending for airtime |
| Adjacent-channel interference | Overlapping channels (e.g., 2.4 GHz channels 1, 4, 8) causing errors |
| Weak signal | Low RSSI or poor SNR near the client |
| Authentication failure | Failed association, 802.1X, or WPA2/WPA3 handshake events |
| Roaming problem | Client sticks to a distant AP (sticky client) or roams too aggressively |
| Hidden interference | Non-Wi-Fi RF (microwaves, Bluetooth, cordless) seen only on spectrum analysis |
A Wi-Fi analyzer reports SSID, BSSID, channel, channel width (20/40/80/160 MHz), signal strength, encryption type, and neighboring APs. On 2.4 GHz, only channels 1, 6, and 11 are non-overlapping in North America, a frequent exam fact. A spectrum analyzer detects non-Wi-Fi energy that a normal Wi-Fi scan cannot classify, so high RSSI with poor throughput points toward interference or contention rather than coverage.
Capture Safety
Captures may contain credentials on legacy cleartext protocols, session cookies, internal IPs and hostnames, email, file data, and personal information. Treat them as sensitive: store them in approved locations, restrict access, and follow chain-of-custody/evidence procedures when the capture relates to a suspected incident.
Common Traps
- Capturing from the wrong switch port misses the traffic entirely.
- A display filter only hides packets; it does not reduce what was collected.
- Encrypted traffic still reveals metadata and timing, never the cleartext payload.
- A Wi-Fi analyzer is not a cable certifier and will not test copper.
- High signal strength alone does not prove good Wi-Fi if noise or channel contention is high.
A technician needs to inspect traffic between a server and a firewall on a switched network, but a capture from an unrelated access port shows nothing useful. What should be done?
Which problems can a packet or protocol analyzer help identify? Select three.
Select all that apply
Users report poor wireless performance even though they are standing near an access point with strong signal. Which tool best checks channel contention and non-Wi-Fi interference?