This document records observed attack behaviors and the underlying vulnerability mechanisms, intended for defensive security research and responsible disclosure purposes.
Observed behavior: After running the AuthDos attack mode against a target AP, the AP's SSID became completely invisible to all wireless scanners. The AP did not respond to probe requests. A full hardware restart was required to restore service.
Attack mode: AuthDos (802.11 Authentication Request flood)
build_auth_dos_frame sends 802.11 Authentication Request frames (FC 0xB0) addressed to
the target BSSID, each from a unique spoofed locally-administered MAC address derived from a
monotonic counter. At default settings (burst_size=200, send_interval_ms=50), this
produces approximately 4,000 frames/second — the burst itself is near-instantaneous via
raw pcap injection, so instantaneous rate during a burst is significantly higher.
The AP firmware must allocate per-client state machine entries for every authentication attempt. Consumer-grade APs typically have hard limits of 32–255 concurrent association table entries. More importantly, beacon generation and management frame processing share the same CPU on consumer SoCs (MIPS/ARM ~500 MHz). Under this flood:
- Association table exhaustion — table fills in milliseconds with phantom client entries.
- Management CPU saturation — the CPU cannot drain the incoming auth queue fast enough.
- Beacon starvation — beacon frames (required every 100ms) are generated by the same CPU thread. When that thread is overwhelmed, beacons are delayed or dropped entirely. Without beacons, the SSID becomes invisible to all scanners and clients.
- Firmware watchdog — after a prolonged CPU lockup, the AP's watchdog timer fires and forces a reboot. This is why a restart restores the AP.
IEEE 802.11w (Protected Management Frames) protects only Deauthentication and Disassociation frames by requiring a Message Integrity Code (MIC). Authentication frames are explicitly excluded from PMF protection in the 802.11 standard. There is no mechanism by which an AP can cryptographically reject forged Authentication Requests — it must process every one at the firmware level. This is a fundamental gap in the 802.11 specification, not a vendor bug.
| Attack | Effect | AP beacons? | SSID visible? | Recovery |
|---|---|---|---|---|
| Deauth (broadcast) | Clients disconnect and reconnect | Yes | Yes | Automatic |
| AuthDos (auth flood) | Management CPU saturated | No (starved) | No | Requires AP restart |
A plain Deauth attack never suppresses beacons — the AP continues to advertise its SSID and clients reconnect automatically. The SSID disappearing is the distinctive fingerprint of management CPU starvation.
Most vulnerable: consumer/SOHO APs with:
- Single-core SoC sharing management frame and beacon generation tasks
- Small association tables (32–255 entries)
- No per-source rate limiting on authentication requests
Enterprise APs typically have dedicated management plane hardware and rate-limit auth requests per source MAC — they are harder to saturate but not immune.
| Mitigation | Effectiveness | Notes |
|---|---|---|
| Enable 802.11w/PMF | None against AuthDos | PMF does not cover auth frames |
| AP-side auth rate limiting | High | Limits auth requests per time window; vendor-specific setting |
| 802.11ax (Wi-Fi 6) MFP enhancements | Partial | Better resource management but auth frames still unprotected |
| WIDS/WIPS (enterprise) | Detection only | Can detect auth floods and block at controller level |
| Upgrade to enterprise AP | High | Dedicated management hardware, better queue management |
This vulnerability class falls under:
- CWE-400: Uncontrolled Resource Consumption
- Related to the broader 802.11 management frame DoS class discussed in academic literature (e.g., Bellardo & Savage, "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions", USENIX Security 2003)
- The auth-flood specifically predates and is not addressed by IEEE 802.11w-2009
Observed behavior: Targeted clients are repeatedly disconnected from the AP. The AP continues to beacon and the SSID remains visible. Clients attempt to reconnect and are immediately deauthenticated again.
Attack mode: Deauth (broadcast or targeted)
build_deauth_frame sends a broadcast 802.11 Deauthentication frame (FC 0xC0, reason
0x0007 = Class 3 frame received from nonassociated STA) spoofed as originating from the
target AP BSSID. All associated clients receiving this frame immediately drop their
association per the 802.11 state machine.
build_client_deauth_frames sends the frame in both directions (AP→client and client→AP)
for more reliable disconnection.
| Mitigation | Effectiveness |
|---|---|
| 802.11w/PMF enabled on both AP and client | High — deauth frames require MIC |
| WPA3 (mandates PMF) | High |
| Enterprise 802.1X + PMF | High |
The following known 802.11 DoS techniques were considered and explicitly excluded from smartdos. Reasons are recorded here to prevent re-evaluation of already-decided trade-offs.
| Attack | Mechanism | Reason Excluded |
|---|---|---|
| Disassoc flood | FC 0xA0 — drops association, client stays authenticated. Back-to-back with deauth. |
Marginal benefit. Modern drivers handle deauth and disassoc identically. Only edge case: very old IoT firmware that ignores deauth — too niche to justify added complexity. |
| Probe flood | Mass probe requests to overwhelm AP probe-response queue. | Low effectiveness. Most APs handle probe responses asynchronously on a separate queue from beacon generation. Does not cause beacon starvation or AP crash. |
| Beacon flood / SSID pollution | Inject thousands of fake beacon frames with random SSIDs. | Attacks clients (saturates scan tables), not the AP. Out of scope for AP-focused tooling. Also extremely visible — floods every nearby device's scan list with hundreds of fake SSIDs, immediately alerting anyone monitoring the RF environment. Contrary to the tool's low-profile design goal. Well covered by MDK3/MDK4 mode b for those who need it. |
| NAV poisoning | Inject frames with large Duration field — forces all nearby STAs to defer transmission per CSMA/CA. | Indiscriminate — affects all devices on the channel including unrelated traffic. No AP-specific targeting. Ethically out of scope for a targeted pentest tool. |
| CTS-to-Self attack | Inject CTS frames claiming the medium is busy. Similar effect to NAV poisoning. | Same reason as NAV poisoning — indiscriminate channel-wide DoS with no target specificity. |
| EAPOL flood | Send malformed/replayed EAPOL frames to clients mid-handshake. | Requires a client to be actively connecting. Timing-dependent, low reliability. Targets clients not the AP. |
| TKIP MIC DoS | Two MIC failures in 60s triggers mandatory 60s TKIP blackout on AP. | Only affects legacy WPA/TKIP. WPA2-CCMP and WPA3 are immune. Legacy WPA is effectively extinct in the field. |
| Assoc/ReAssoc flood | Flood association requests (FC 0x00/0x20) to hit AP association state machine. |
Functionally overlaps with Auth-DoS — auth flood already exhausts the association table upstream of the assoc state machine. Adding assoc flood provides no additional coverage. |
This document is maintained for defensive research purposes. All testing was performed on equipment owned and operated by the researcher.