A municipal rules of engagement document bans deauthentication entirely during a wireless assessment. Which approach remains appropriate for observing handshake-class traffic?
Select an answer to reveal the explanation.
Short Explanation
If the city says no deauth, put the cattle prod away. Sit on the right channel and wait for someone to reconnect the honest way. Passive waiting still gets handshake-class frames when clients return on their own.
Full Explanation
When municipal RoE bans deauthentication entirely, appropriate handshake observation means waiting passively for natural client reconnects while capturing on the authorized AP channel. Clients eventually reauthenticate through roam, sleep, or reconnect events, yielding EAPOL without forced disruption. Civic assessors honor the ban rather than inventing equivalent injection under another name. Ignoring RoE to send brief deauths because labs always allow forcing reconnects fails by concept: this engagement’s RoE explicitly bans deauth; lab generalizations do not override written rules. Switching to continuous injection floods without labeling them deauth fails by concept: banned disruption is still banned if relabeled. Disabling monitor mode and relying only on DHCP lease exports fails by concept: DHCP logs are not EAPOL handshake proof for offline PSK testing. Exam caveat: passive waiting may lengthen the capture window—plan schedule with the city rather than violating RoE to save time. Operational check: lock to the in-scope channel, capture continuously during known busy periods, verify when a complete handshake appears naturally, and document that no deauth was used per RoE. In civic practice, write the decision and the verification command into the engagement notes so another assessor can repeat the check on the next shift without rediscovering the same pitfall under time pressure.