Before investing GPU time, an assessor reviews a municipal capture in Wireshark to validate handshake quality. What should that QA step confirm?
Select an answer to reveal the explanation.
Short Explanation
Wireshark QA is checking you filmed the whole handshake scene with the right AP in frame—not a teaser trailer of beacons only. Confirm EAPOL completeness and BSSID before lighting up the GPU. Bad captures waste good wordlists.
Full Explanation
Before investing GPU time, reviewing a municipal capture in Wireshark or equivalent to validate handshake quality is a cost-control and correctness step: confirm EAPOL message completeness and that the correct BSSID are present before cracking time is spent. Civic labs lose hours feeding incomplete files to hashcat. Packet review is professional wireless methodology, not optional polish.
'That every beacon on the channel uses WEP so cracking will be faster.' fails because checking for WEP on every beacon is the wrong pre-crack validation for a WPA2-PSK job. 'That the SSID string alone appears, even if EAPOL messages are missing.' fails because seeing the SSID string alone is insufficient when EAPOL messages are missing. 'That PMKID cleartext already contains the passphrase, making cracking unnecessary.' fails because PMKID material does not present the passphrase in cleartext or make cracking unnecessary by revelation.
Exam caveat: a pretty SSID in the beacon list is not the same as a complete handshake for the in-scope BSSID. Operational check: filter the city capture on the authorized BSSID, verify EAPOL completeness for a usable handshake, export only validated material, then start the cracker. If incomplete, recapture under RoE rather than tuning wordlists against garbage input. In municipal wireless operations, record the rationale in the engagement notes so future assessors know which control or technique class was chosen and which failure modes the rejected options would create for city services.