Before enabling monitor mode, a municipal playbook says to check for interfering processes. Why does that step matter?
Select an answer to reveal the explanation.
Short Explanation
NetworkManager and friends will yank the steering wheel while you try to park in monitor mode. Checking—and when authorized, stopping—those grabby services keeps the interface from flipping back to client mode mid-lab. Calm the cockpit before takeoff.
Full Explanation
NetworkManager and similar services often seize or reconfigure wireless interfaces, fighting airmon-ng or iw when enabling monitor mode. Municipal playbooks that check for interfering processes before monitor mode reduce flapping, unexpected managed-mode resets, and failed mon interface creation. Stabilizing the interface ownership is a practical pre-flight step, not bureaucracy. Saying interfering processes only affect Bluetooth and never Wi-Fi is incorrect. Claiming process checks exist solely to renew DHCP on the management VLAN misses the monitor-mode conflict issue. Asserting airmon-ng requires a running printer spooler invents a dependency. Exam caveat: On exam systems, kill or stop conflicting managers carefully so you do not lose unrelated connectivity you still need. Operational check: Before airmon-ng, list processes touching wlan interfaces, stop NetworkManager or use checked playbook steps, enable monitor mode, and confirm the mon interface remains stable for five minutes of capture. In civic WLAN stewardship, keep authorization boundaries explicit, prefer the least disruptive technique class allowed by RoE, and record BSSID, channel, band, and security mode beside every conclusion so another assessor can reproduce the observation.