Adapter Chipsets, Drivers and the mac80211 Framework
The exam expects you to choose hardware that can actually do the job and to diagnose why an adapter that "supports monitor mode" still refuses to inject.
Two capabilities, tested separately
Monitor mode receives every frame in the air; injection transmits forged frames. They are independent. aireplay-ng --test wlan0mon exercises both.
Chipsets and drivers
- Atheros AR9271 →
ath9k_htc, 2.4 GHz only (Alfa AWUS036NHA, TP-Link TL-WN722N v1). - Atheros AR9280/AR9285 →
ath9k, dual-band. - Ralink RT3070/RT2770 →
rt2800usb; RT2770 is dual-band. - Realtek RTL8187 →
rtl8187, 2.4 GHz with strong transmit power. - Realtek RTL8812AU/8821AU → out-of-tree driver, 5 GHz capable.
mac80211 and cfg80211
mac80211 is the kernel softMAC framework implementing the 802.11 state machine for drivers such as ath9k, rt2x00 and iwlwifi. cfg80211 is the configuration layer, exposed to userspace through nl80211, which iw speaks. FullMAC drivers like brcmfmac run the MAC in firmware and frequently expose neither monitor mode nor injection. iw list shows "Supported interface modes"; then iw dev wlan0 set type monitor, ip link set wlan0 up, iw dev wlan0 set channel 6. airmon-ng check kill removes processes that would flip the mode back.
Worked example
iw list reports monitor mode for an adapter, but after airmon-ng start, aireplay-ng --test reports no injection. Reasoning: the driver accepted the monitor flag, yet firmware may refuse to transmit frames it did not build itself. Check dmesg for firmware-load errors, confirm with a second interface name, and fall back to a known-good AR9271 or RT3070 adapter.
Traps
- Assuming monitor mode implies injection support.
- Taking a 2.4 GHz-only AR9271 against a 5 GHz target.
- Letting NetworkManager reset the interface to managed mode mid-capture.
- Losing track of the interface name after
airmon-ng check kill; re-check withiw dev.