14.2 Protocol Analyzers, Spectrum Analyzers and Monitoring

Objective 6.5 is not a shopping list. It is a matching skill: given a symptom, which instrument can actually see the failure. Harborline's NOC keeps four classes of tool on the cart. Using the wrong class wastes hours. This OpenExamPrep section teaches protocol analyzers, spectrum analyzers, management / monitoring / logging systems, and wireless LAN scanners the way CWNA-109 expects you to choose them. Independent OpenExamPrep material here is study teaching from OpenExamPrep; it does not claim CWNP approval, partnership, or exact equivalence with CWNP training.

Chapter 12 already used protocol and spectrum analyzers as security visibility (RSN IEs, rogue energy). Chapter 13 used them in validation (prove the design). Here the same hardware answers why it broke on Tuesday.

Protocol analyzers: the conversation on the air

A protocol analyzer (packet capture in monitor mode, or a vendor equivalent that records 802.11 MPDUs) sees frames. It does not see a magnetron. It does not see a duplex mismatch on the switch. It sees what stations actually transmitted.

What 6.5 wants you to read in those frames:

Retry bit. The Frame Control retry flag marks a retransmission. A capture full of retry=1 data frames with the same sequence numbers is a loss story: collisions, hidden nodes, interference, or a client at the edge. Combine it with RSSI in radiotap headers. Strong RSSI plus retries points back to 14.1 (CCC/ACI/non-Wi-Fi) or to 14.3 (hidden node). Weak RSSI plus retries is coverage or a client Tx limit.

Reason and status codes. Deauthentication and Disassociation frames carry a reason code. Association Response and Authentication frames carry a status code. Harborline's helpdesk says "Wi-Fi kicked me off." The capture says reason 2 (previous authentication no longer valid), 6 (Class 2 frame from nonauthenticated STA), 7 (Class 3 from nonassociated STA), 8 (leaving BSS), 15 (4-way handshake timeout — common after a PSK mismatch), or an Association status 18 (denied due to AP's inability to handle additional STAs) or 30/31 (association denied because of RSN/PMF mismatch, depending on the amendment wording in the capture's decode). You do not memorize every IEEE table on CWNA-109, but you do know to open the frame instead of guessing from RSSI.

DHCP failures in frames. After 802.11 association and, for Enterprise, after 802.1X, the station still needs an address. A protocol analyzer that can see the client VLAN (monitor mode plus decryption if the session is encrypted, or a wired SPAN on the AP uplink, or an unencrypted guest SSID) shows Discover / Offer / Request / ACK. Patterns:

• Discovers with no Offer — helper, pool, or server.
• Offers the client ignores — bad server, wrong giaddr, Option 82 policy.
• Repeated Discovers while the 802.11 session stays associated — not an RF hole.

If the WLAN is encrypted and you cannot decrypt, you still see 802.11 Data frames with growing retry counts after association, then the client roam or DHCP-renew behavior in management frames. Pair the air capture with a wired capture at the DHCP relay. Objective 6.5's point is that DHCP is visible in packets, so you should look there before you reshoot the survey.

EAP failures in frames. WPA2-Enterprise and WPA3-Enterprise run EAP after association. The analyzer shows EAP Identity, method (PEAP, EAP-TLS, and so on), TLS alerts, Access-Challenge versus Access-Reject as RADIUS-encapsulated EAP-Failure, and then the 4-way handshake only if EAP succeeded. A client that associates and immediately Deauthenticates may be failing EAP, not RF. Harborline ticket: "New badge scanners cannot join HL-CORP." Capture: Association success, EAP Identity, then EAP-Failure, reason-coded teardown. RADIUS log: unknown user. The protocol analyzer told you which phase died; the AAA log told you why.

Protocol analyzer limits: encrypted payloads hide DHCP unless you have the PTK/GTK or a wired tap. A single adapter sees one channel unless you use multiple radios. You will not identify a Bluetooth hopper from MPDUs alone.

Spectrum analyzers: energy that is not a frame

A spectrum analyzer (dedicated, USB, or AP-based FFT) plots RF power versus frequency versus time. It answers 6.2's non-802.11 question and 6.5's "identify the interference source."

Signatures you should recognize at CWNA depth:

Look at duty cycle and center frequency, not only peak dBm. A radar pulse can be strong and still rare. A Bluetooth mouse can be weak and still raise retries next to a scanner. Harborline's analog yard camera sat on 2.412 GHz at 80 percent duty cycle; scanners on channel 1 never listed it as an SSID. The spectrum analyzer named it in minutes; three days of protocol captures had shown only retries.

AP-based spectrum views are convenient for after-hours and for many floors. A walk-around analyzer is better when you must locate a source by watching the signature grow as you approach the break room. Either way, spectrum is how you identify the interferer; protocol analysis is how you prove 802.11 is the victim.

Management, monitoring, and logging systems

A laptop capture is a flashlight. The controller, wireless network management system (WNMS), and syslog are the building's lighting panel.

Controller / WNMS stats (objective 6.5 grouping: management, monitoring, and logging) that actually close tickets:

• Retry percentage and channel utilization per radio — CCC versus a quiet cell.
• Client count and failed associations — capacity, PSK, or 802.1X.
• SNR / RSSI distributions — coverage versus a single sticky client.
• Radio resets, DFS events, PoE power-draw changes — the AP is crashing or vacating, not "Windows is slow."
• Roam graphs — sticky clients versus missing neighbor coverage.

Syslog (and equivalent streaming telemetry) timestamps AP join, image download, radio state, DFS CAC, and often 802.1X fails if the controller logs them. Harborline ticket "the west IDF Wi-Fi dies every night at 02:15" was a switch reboot in syslog, not RF. Without logs you would have surveyed at noon and found nothing.

WNMS does not replace a capture. Averages hide a 30-second microwave. Use monitoring to narrow the radio, time window, and client, then drop a protocol or spectrum analyzer on that window.

Wireless LAN scanners

A WLAN scanner (survey-in-a-pocket, inSSIDer-class, or the scanner view inside survey software) lists what 802.11 networks are present: SSID, BSSID, channel, width, security, RSSI, sometimes 802.11k neighbor hints. It is the fastest way to answer:

• Are we accidentally on channel 3 next to 1 and 6?
• How many OBSS share 36?
• Is HL-GUEST still TKIP somewhere?
• Did a rogue AP appear with our SSID?

Scanners do not decode DHCP. They do not show a microwave. They do not show switch duplex. They do prevent Harborline from spending a day on spectrum when the overlay is simply four SSIDs on 2.4 GHz channel 1 from the same IDF.

How to pick a tool for a symptom

Match the question to the instrument:

Worked Harborline NOC picks

• Ticket 1902, break room, noon only: spectrum first. Protocol capture at 09:00 would have been a clean cell.
• Ticket 2055, associated / 169.254.1.17: protocol analyzer on Discover, plus the Layer 3 helper. Scanner RSSI was −52 dBm and irrelevant.
• Ticket 1847, four APs on 36: scanner + WNMS utilization. Spectrum would have shown 802.11-shaped energy you already knew was Wi-Fi.
• Ticket 2119, EAP-Failure: protocol analyzer + syslog/RADIUS. Spectrum cannot see an Access-Reject.

On the exam

• Retries, reason codes, DHCP, EAP → protocol analyzer.
• Interferer signatures → spectrum analyzer.
• Estate trends, DFS, AP reboots → controller / WNMS / syslog.
• Who is on which channel → WLAN scanner.
• Choose from the symptom, not from the tool you like.

Key Takeaways

• Frames carry retries, reason codes, and DHCP/EAP outcomes.
• Spectrum carries signatures that never become MPDUs.
• Monitoring systems give time and estate context.
• Scanners map SSIDs and channels quickly.
• The exam item is which tool can see that symptom.