A city hall WLAN analyst reviewing a capture from the council chamber sees MCS and signal strength in the radiotap/PPI pseudo-header that the 802.11 MAC decode alone does not show. What should the analyst conclude about that metadata?
Select an answer to reveal the explanation.
Short Explanation
Think of radiotap like the sticky note a meter reader leaves on the envelope—the MAC letter is still inside, but the note tells you signal, MCS, and channel the stamp alone never shows. City hall captures get a lot smarter when you read that PHY sticky note instead of pretending the MAC decode has everything.
Full Explanation
When a city hall WLAN analyst reviewing a council-chamber capture sees MCS and signal strength in the radiotap or PPI pseudo-header that the 802.11 MAC decode alone does not show, the correct conclusion is that radiotap/PPI carries PHY-side fields—MCS, signal, channel, and related metadata—that the MAC header decode cannot supply. Those fields come from the capturing adapter’s view of the PPDU, enabling capacity and RF troubleshooting beyond addresses and frame types. Expert analysis enables radiotap columns when assessing civic chamber performance.
Claiming radiotap/PPI only duplicates the Destination Address so it can be ignored during capacity troubleshooting discards the PHY metrics needed for MCS/SNR work. Saying MCS and signal in radiotap prove the frame failed FCS and must be discarded before any MAC analysis confuses optional PHY metadata with FCS validity. Asserting those fields are injected by the AP controller after association and never appear on over-the-air captures misattributes capture metadata to controller post-processing.
Exam caveat: protocol analysis for CWNE includes PHY metadata literacy, not only MAC frame diagrams. Operational check: open the council-chamber pcap with radiotap/PPI columns visible, confirm MCS and signal populate on data frames, and correlate low MCS with chamber RF conditions rather than MAC addressing alone.