A county kit documents driver module names for supported Wi-Fi cards. Why does that runbook exist?
Select an answer to reveal the explanation.
Short Explanation
When monitor mode flakes, the runbook’s module list is the quick “which engine is under this hood?” card. Matching adapter to driver cuts down on guesswork. It is troubleshooting fuel, not just inventory paperwork.
Full Explanation
County kits document driver module names because knowing which kernel module binds to which adapter dramatically speeds troubleshooting when monitor mode, injection, or regulatory features fail. If the wrong module loads, or none loads, RF tools fail in ways that look mysterious until lsmod and the runbook align. Civic wireless playbooks treat module identity as operational metadata tied to supported chipsets, not as decorative inventory text. Saying module names are recorded only for asset tags and never used technically fails by concept: the runbook exists to guide live troubleshooting and support decisions. Claiming driver modules are optional on Linux once USB power is applied fails by concept: without a working driver stack the adapter cannot expose wireless interfaces for assessment use. Asserting that documenting modules replaces verifying chipset injection support fails by concept: module docs aid diagnosis but do not substitute capability validation under RoE. Exam caveat: module names can change across kernel versions—verify the binding on the actual engagement image rather than assuming last year’s string still applies. Operational check: plug the county adapter, note the loaded module, compare it to the kit runbook, attempt monitor-mode bring-up, and if it fails, reload or blacklist conflicting modules per the documented procedure before escalating hardware replacement.