Beacon Frame Flooding: How WiFi AP Spam Works at the Packet Level
WiFi AP spam - the act of flooding the radio spectrum with hundreds of fake SSIDs at once - looks like a trick. You pull out a small device, tap a button, and every phone in the room suddenly shows a wall of network names in their WiFi list. But it's not a trick. It's a direct consequence of how the 802.11 WiFi standard works and what the ESP32 microcontroller can do with raw frame injection.
This article covers the mechanics at the packet level. How beacon frames are structured, why a single chip can generate hundreds of them, what actually happens on client devices when they receive them, and what the BLEShark Nano does under the hood.
What Is a Beacon Frame?
The 802.11 standard defines three categories of wireless frames: management, control, and data. Beacon frames are management frames. Their job is to advertise the existence of an access point and provide clients with the information they need to potentially connect.
Every legitimate AP in your vicinity is continuously broadcasting beacon frames - typically 10 times per second (every 100ms, the default DTIM interval). Your phone's WiFi scanner picks these up and displays them in the "Available Networks" list. The more APs nearby, the more beacon frames are filling the airwaves.
A standard beacon frame contains:
- Timestamp: An 8-byte value syncing clients to the AP's local clock
- Beacon interval: How often the AP sends beacons (usually 100 TUs - Time Units - where 1 TU = 1.024ms)
- Capability info: Flags indicating whether the network is infrastructure mode, whether it's encrypted, whether it supports QoS, etc.
- SSID element: The network name, up to 32 bytes (32 ASCII characters, or fewer with multi-byte Unicode)
- Supported rates: What data rates the AP supports
- Channel info: Which channel the AP is operating on
- RSN Information: Security capabilities (WPA2/WPA3 parameters)
Crucially, the 802.11 management frame standard has no authentication requirement. There's no signature, no cryptographic proof that this beacon came from a legitimate device. Any device that can transmit on the 2.4GHz band in the correct 802.11 format can broadcast a beacon claiming any SSID it wants. This is not a vulnerability - it's a design choice made in the original 802.11 specification when the assumption was that wireless networks would be small and somewhat trusted.
The 802.11 MAC Header
Before the beacon payload, every 802.11 frame has a MAC header. For a beacon frame:
- Frame Control: 2 bytes indicating this is a management frame, subtype 0x08 (beacon)
- Duration: 2 bytes (usually 0 for beacons)
- Destination Address: Broadcast MAC (FF:FF:FF:FF:FF:FF) - beacons go to everyone
- Source Address: The AP's BSSID (MAC address)
- BSSID: Same as source address for a basic AP
- Sequence Control: 2 bytes tracking frame order
The source address and BSSID fields are the AP's MAC address. In AP spam, these are randomized for each fake SSID. The ESP32 can write arbitrary bytes into these fields when injecting raw frames. There's no hardware check that prevents a device from claiming any MAC address it wants - again, this is a deliberate design aspect of the standard that enables legitimate use cases like virtual APs, but also makes spoofing trivial.
graph TD
subgraph "802.11 Beacon Frame - Byte-Level Breakdown"
subgraph "MAC Header (24 bytes)"
B0["Bytes 0-1: Frame Control
0x80 0x00
Protocol=0, Type=0 (Mgmt)
Subtype=8 (Beacon)"]
B2["Bytes 2-3: Duration
0x00 0x00"]
B4["Bytes 4-9: Receiver
FF:FF:FF:FF:FF:FF
(Broadcast)"]
B10["Bytes 10-15: Transmitter
Random MAC per fake AP"]
B16["Bytes 16-21: BSSID
Same as Transmitter"]
B22["Bytes 22-23: Seq Control
Incremented per frame"]
end
subgraph "Fixed Parameters (12 bytes)"
B24["Bytes 24-31: Timestamp
8-byte microsecond counter"]
B32["Bytes 32-33: Beacon Interval
0x64 0x00 (100 TU = 102.4ms)"]
B34["Bytes 34-35: Capability Info
0x21 0x04 (ESS + Short Preamble)"]
end
subgraph "Information Elements (Variable)"
IE0["IE 0: SSID
Tag=0, Len=N, Payload=SSID"]
IE1["IE 1: Supported Rates
1, 2, 5.5, 11 Mbps"]
IE3["IE 3: DS Parameter
Channel number"]
IE5["IE 5: TIM
Traffic Indication Map"]
end
end
B0 --> B2 --> B4 --> B10 --> B16 --> B22
B22 --> B24 --> B32 --> B34
B34 --> IE0 --> IE1 --> IE3 --> IE5
Byte-level anatomy of a beacon frame used in AP spam - the ESP32 constructs each field manually, with a unique random BSSID per spoofed network and the target SSID embedded in IE tag 0.
How the ESP32 Injects Raw Frames
Most WiFi chips present a managed API to the software above them. You tell the driver "connect to this network" or "send this packet," and the driver handles the 802.11 framing internally. The raw 802.11 frame structure is hidden.
sequenceDiagram
participant FW as Firmware Loop
participant BUF as Frame Buffer
(~256 bytes)
participant HAL as esp_wifi HAL
participant MAC as WiFi MAC
Hardware
participant AIR as 2.4GHz Channel
participant CLI as Nearby Clients
loop For each SSID in list
FW->>BUF: Write MAC header
(broadcast + random BSSID)
FW->>BUF: Write fixed params
(timestamp, interval, caps)
FW->>BUF: Write SSID IE
(current network name)
FW->>BUF: Write rates + channel IEs
FW->>HAL: esp_wifi_80211_tx()
(raw frame injection)
HAL->>MAC: Queue frame for TX
MAC->>AIR: Transmit beacon
(at configured TX power)
AIR->>CLI: Clients receive beacon
CLI->>CLI: Add to network list
(if SSID not seen before)
FW->>FW: Delay 10ms
(avoid MAC queue overflow)
end
Note over FW,CLI: ~100 SSIDs/second per node
Clients see dozens of fake networks
Beacon injection pipeline - firmware builds each frame in a buffer, injects it through the ESP32's raw TX API, and cycles through the SSID list with timing delays to prevent hardware queue overflow.
The ESP32 exposes a lower-level API via Espressif's ESP-IDF framework: esp_wifi_80211_tx(). This function accepts a raw 802.11 frame buffer and transmits it directly to the radio. No validation of MAC addresses. No check that the SSID is one the device legitimately owns. Just "here's a frame, transmit it."
Combined with the ability to set the WiFi interface to a mode where it doesn't need to associate with any real network, this means the ESP32 can construct arbitrary 802.11 management frames and inject them into the air. For AP spam, the process is:
- Build a beacon frame with a specific SSID, random source MAC, random BSSID
- Set the channel number in the DS Parameter Set IE
- Call
esp_wifi_80211_tx() - Increment to the next SSID in the list
- Repeat
The loop runs fast enough that the device is cycling through its SSID list many times per second. Each SSID gets a unique random BSSID (so they appear as separate networks). The beacon interval for each "fake AP" is effectively however fast the device loops through the list - which is not the standard 100ms per SSID but a much higher rate when many SSIDs are being cycled.
Why Client Devices Show Fake Networks
A phone scanning for WiFi networks doesn't verify that a beacon came from a legitimate source. It receives the frame, reads the SSID and BSSID, reads the signal strength (RSSI), and adds the entry to its network list. If it sees the same BSSID advertising the same SSID across multiple scans, the entry stays. If it sees a BSSID once and then never again, the entry may age out after a period of inactivity.
graph TD
subgraph "Why Clients Show Fake Networks"
BEACON["Received beacon frame"]
PARSE["Client parses
MAC header"]
CHECK1{"Valid frame
control field?"}
CHECK2{"Broadcast
destination?"}
CHECK3{"Valid SSID IE
present?"}
CHECK4{"Supported
rates valid?"}
ADD["Add to visible
network list"]
SHOW["Display in
WiFi settings"]
BEACON --> PARSE --> CHECK1
CHECK1 -->|"Yes"| CHECK2
CHECK1 -->|"No"| DROP1["Drop frame"]
CHECK2 -->|"Yes"| CHECK3
CHECK2 -->|"No"| DROP2["Drop frame"]
CHECK3 -->|"Yes"| CHECK4
CHECK3 -->|"No"| DROP3["Drop frame"]
CHECK4 -->|"Yes"| ADD --> SHOW
CHECK4 -->|"No"| DROP4["Drop frame"]
NOTE["802.11 spec does NOT require:
- Authentication of beacons
- Verification of AP existence
- Challenge before listing
This is by design (open discovery)"]
end
subgraph "Rate Limiting (Some APs)"
RL1["Enterprise APs may:
- Deduplicate by BSSID
- Limit scan list size
- Filter weak signals"]
RL2["Consumer devices:
- Show everything
- No filtering
- Scroll through dozens"]
end
ADD --> NOTE
SHOW --> RL1
SHOW --> RL2
Client beacon processing logic - 802.11 requires no authentication for beacon frames, so any syntactically valid beacon with a proper SSID element gets added to the visible network list.
When the BLEShark Nano is running AP spam, it's cycling through its SSID list continuously. Each SSID gets hit frequently enough that phones see each one multiple times, so the entries stay visible rather than aging out. From the phone's perspective, there are dozens or hundreds of access points in range.
The random BSSIDs are important here. If all fake SSIDs shared the same BSSID, the phone's WiFi stack would likely treat them as multiple SSIDs advertised by the same AP (which happens in real enterprise environments with multiple VAPs). Using unique BSSIDs per SSID makes each one look like a completely separate physical access point to the client.
Rate Limits and Why Some APs Handle This Better
At the hardware level, the 2.4GHz spectrum has finite capacity. Each channel has approximately 20MHz of bandwidth, and 802.11b/g/n beacons at 1 Mbps take about 100-200 microseconds each. A device cycling through 100 SSIDs at maximum possible rate is spending a significant chunk of the channel's available airtime on beacon frames alone.
This creates a measurable effect: channel congestion. The 2.4GHz band's non-overlapping channels (1, 6, and 11) are each degraded proportionally to how much AP spam is running on them. Other devices trying to communicate on the same channel contend for airtime with the beacon flood.
However, most AP spam implementations don't generate enough traffic to completely saturate a channel. They slow it down, not shut it down. Well-implemented client drivers and APs handle beacon floods by prioritizing known, associated networks over unassociated ones in the receive queue. The association to your home router is maintained. The extra noise is filtered at the driver level. This is why AP spam is disruptive in terms of UI confusion (the WiFi list is unusable) but usually doesn't completely block connectivity for associated clients.
Some enterprise APs have explicit beacon flood mitigation: they rate-limit how quickly they process management frames from unassociated devices, which reduces the CPU impact of a beacon flood. Client devices with aggressive management frame filtering handle this even more cleanly.
What the BLEShark Nano's AP Spam Mode Does
The BLEShark Nano's AP spam feature lets you broadcast a custom list of SSIDs, a preset list (including the Rickroll mode - a curated set of internet-famous WiFi names), or randomly generated names. The SSIDs cycle continuously. Each gets a randomized BSSID.
The SSID list is customizable via the File Portal. You can upload a text file with one SSID per line and the device will use your list. The Rickroll preset loads a hardcoded list of SSIDs named after classic internet references, songs, and memes - the kind of names that show up on "funny WiFi names" roundup articles.
All of this runs on 2.4GHz. The ESP32-C3 in the BLEShark handles 2.4GHz WiFi and BLE 5.0, but only 2.4GHz for WiFi. 5GHz networks are not affected by AP spam from the BLEShark. If you're in an environment where everyone has already moved to 5GHz, the spam effect is limited to users whose devices are scanning 2.4GHz - which is most of them, since 2.4GHz is still the default scanning band for many devices.
The BLEShark Nano uses its 500mAh battery to run AP spam standalone - no laptop or USB connection needed. In practice, AP spam on its own is one of the lower-power modes since it doesn't involve maintaining any associations or processing incoming traffic, just transmitting beacon frames in a loop.
The Shiver Mesh Angle
With a Shiver pack (3, 5, 7, 12, or 16 nodes), each device can run AP spam on a different WiFi channel simultaneously. A single BLEShark running AP spam hits one channel. Three BLEShark Nanos on channels 1, 6, and 11 cover the entire non-overlapping 2.4GHz spectrum simultaneously. This is relevant for authorized testing scenarios where you want to demonstrate the impact of a beacon flood across the full band - for example, showing a client how easy it is to create confusion in a physical space without any sophisticated equipment.
The mesh runs over ESP-NOW, which operates in a narrow window separate from the WiFi AP spam operation. When a node is in the mesh's communication window, it briefly pauses beacon injection, sends/receives mesh traffic, then resumes. The interruption is short enough that from a scanning client's perspective, the SSIDs just keep appearing.
Using This Responsibly
AP spam in an authorized test environment demonstrates several things clearly to security-aware clients: how easy it is to create visual noise in the RF environment, the risk of users connecting to unknown networks when their familiar one appears unavailable, and the lack of authentication in 802.11 management frames.
Running AP spam on networks or in physical spaces you don't have authorization to test is a different matter. Intentionally disrupting wireless communications, even in the limited way that AP spam does, can violate computer misuse laws in many jurisdictions. The fact that it's technically simple doesn't make it legally safe to do without authorization.
Only use AP spam features in authorized test environments or on your own networks. Unauthorized beacon flooding may violate local computer misuse, telecommunications interference, or spectrum regulations.