Beacon Frames and Probe Requests: How WiFi Discovery Works
Every time you pull out your phone and see a list of nearby WiFi networks, you're looking at the result of a constant radio conversation happening around you. Access points broadcast their presence roughly ten times per second. Your device listens, and sometimes shouts into the void asking for networks it already knows. This happens whether you're actively looking for WiFi or not.
Understanding how this works matters for anyone doing wireless security testing. It explains why AP Spam works, what probe requests reveal about your device history, and why the passive phase of a WiFi scan picks up so much information before you've done anything active.
Quick Recap: The Three 802.11 Frame Types
The 802.11 standard divides wireless frames into three categories: management, control, and data.
- Management frames handle the setup and teardown of connections - authentication, association, beacons, probes
- Control frames handle channel access and packet acknowledgment - ACK, RTS, CTS
- Data frames carry the actual payload - your HTTP requests, video streams, DNS queries
Beacon frames and probe requests are both management frames. Neither carries user data. Both are transmitted in the clear, without encryption, even on a WPA3 network - because they happen before any security context exists.
What Is a Beacon Frame?
A beacon frame is a periodic broadcast sent by an access point to announce its existence. The default interval is 102.4 milliseconds, which works out to roughly 9.77 beacons per second. Every AP on your network is constantly doing this, on every supported channel it operates on.
The beacon frame contains:
- Timestamp - a 64-bit value used for timing synchronization in infrastructure mode
- Beacon interval - how often the AP is sending beacons (usually 100 TUs, where 1 TU = 1.024ms)
- Capability information - a 16-bit field indicating whether the AP is an infrastructure AP or IBSS (ad-hoc), whether privacy (encryption) is enabled, short preamble support, and more
- SSID - the network name. If this field is empty (zero length), the network is "hidden"
- Supported rates - what data rates the AP supports (1Mbps, 2Mbps, 5.5Mbps, 11Mbps, and the 802.11g rates up to 54Mbps)
- DSSS parameter set - which channel the AP is operating on
- RSN information element - the security capabilities (WPA2, WPA3, cipher suites, AKM suites)
- Vendor-specific elements - manufacturer extensions, often including Microsoft's WPA IE or Cisco-specific data
The BSSID in the frame header is the MAC address of the access point's radio. This is what gets captured during passive scanning and what you see in tools like airodump-ng or the BLEShark Nano's WiFi scan results.
Hidden SSIDs: Security Theater
When an SSID is "hidden," the beacon frame still goes out - it just contains an empty or zero-padded SSID field. The AP is still broadcasting its existence. The BSSID is still visible. The channel, rates, and capabilities are still there.
What actually gives away a hidden network? Probe responses. When a client that knows the hidden network sends a directed probe request (more on this shortly), the AP responds with its actual SSID. Anyone listening in monitor mode sees that response and now knows the SSID.
There's also the client side: devices that have connected to a hidden network before will broadcast its name in probe requests, even when they're not near it. More on that below.
Hidden SSIDs are not a security control. They slightly increase friction for casual observers. They provide no meaningful protection against anyone with a packet capture tool.
sequenceDiagram
participant AP1 as Access Point 1
(SSID: HomeNet)
participant CH as WiFi Channel
participant STA as Client Station
participant AP2 as Access Point 2
(SSID: CoffeeWiFi)
Note over AP1,AP2: Phase 1 - Passive Discovery (Beacons)
AP1->>CH: Beacon Frame (every ~102.4ms)
CH->>STA: SSID=HomeNet, CH=6, WPA2
AP2->>CH: Beacon Frame (every ~102.4ms)
CH->>STA: SSID=CoffeeWiFi, CH=6, Open
Note over STA: Client builds AP list from beacons
Note over AP1,AP2: Phase 2 - Active Discovery (Probes)
STA->>CH: Probe Request (SSID=SavedNetwork)
Note over AP1: SSID mismatch - ignore
STA->>CH: Probe Request (Broadcast/Wildcard)
AP1->>STA: Probe Response (HomeNet details)
AP2->>STA: Probe Response (CoffeeWiFi details)
Note over AP1,AP2: Phase 3 - Association
STA->>AP1: Authentication Request
AP1->>STA: Authentication Response
STA->>AP1: Association Request
AP1->>STA: Association Response
Complete WiFi discovery flow - passive scanning receives beacons, active scanning sends probe requests, then the client authenticates and associates with the chosen AP.
Passive Scanning: Just Listening
When a device wants to find available networks, the simplest approach is passive scanning: tune to a channel, wait for beacon frames to arrive, record what you hear, move to the next channel, repeat.
This is what the BLEShark Nano does during WiFi scanning. It hops through the 2.4GHz channels, collects beacons, and builds a list of visible access points. No frames are transmitted. The scanning device is invisible to everything around it. You get SSIDs, BSSIDs, signal strength (RSSI), channel, and security type - all from the beacon frames that are already filling the air.
Passive scanning takes longer than active scanning because you have to wait for beacon intervals. At the default 100ms interval, you need to sit on each channel long enough to catch at least one beacon. Most implementations dwell for 100-200ms per channel.
Active Scanning: Probe Requests
Rather than waiting for beacons, a device can send a probe request to ask access points to identify themselves. There are two types:
Broadcast probe requests have an empty SSID field. They're sent to the broadcast MAC address (FF:FF:FF:FF:FF:FF) and ask any AP within range to respond. Every AP that hears this sends back a probe response with its full beacon information. This is faster than passive scanning because you don't have to wait for the next beacon interval.
Directed probe requests contain a specific SSID. The device is asking "is the network called 'HomeNetwork_5G' nearby?" Only an AP with that exact SSID will respond. This is how devices reconnect quickly to known networks - instead of doing a full passive scan, they probe for the specific network they want to join.
What Probe Requests Reveal About You
This is where it gets interesting from a security perspective.
stateDiagram-v2
[*] --> PowerOn: Device boots
PowerOn --> PassiveScan: Start scanning
state PassiveScan {
[*] --> Channel1: Hop channels
Channel1 --> Channel6: Dwell ~100ms
Channel6 --> Channel11: Dwell ~100ms
Channel11 --> Channel1: Cycle repeats
}
PassiveScan --> ActiveProbe: Saved networks in PNL
state ActiveProbe {
[*] --> DirectedProbe: Known SSID
DirectedProbe --> WaitResponse: Send probe
WaitResponse --> ProbeTimeout: No response
WaitResponse --> ProbeReceived: AP responds
ProbeTimeout --> DirectedProbe: Next saved SSID
[*] --> WildcardProbe: Broadcast probe
WildcardProbe --> CollectResponses: All APs reply
}
ActiveProbe --> EvaluateAPs: Build candidate list
EvaluateAPs --> Associate: Best signal + priority
Associate --> Connected: 802.11 auth + assoc
Connected --> PassiveScan: Disconnected/roaming
Client WiFi state machine - devices cycle between passive scanning (listening for beacons) and active probing (requesting saved networks), exposing their Preferred Network List in the process.
When your phone has a list of saved networks and is trying to reconnect, it will sometimes send directed probe requests for those saved networks by name. If you're walking through an airport and your phone is probing for "CoffeeShopWifi", "HiltonHotel", "HomeNetwork", and "Work_SSID", you're broadcasting a rough history of where you've been.
Until relatively recently, devices also used their real MAC address in probe requests. This meant any passive observer could track a device across locations - you couldn't see who owned the phone, but you could see that the same device was at location A at 9am and location B at 11am.
Modern iOS and Android devices now use randomized MAC addresses for probe requests. This significantly reduces the tracking risk. However, implementation varies: some devices only randomize MACs while disconnected from networks, some randomize per-scan, some randomize per-SSID. The protection is real but not absolute.
In a monitor mode capture, you'll see probe requests constantly. BSSTs, connection attempts, authentication frames - all flowing by. This is the information environment that a passive observer (or a BLEShark Nano in deauth detection mode) is operating in.
Probe Responses
When an AP receives a broadcast probe request, it replies with a probe response. The probe response has the same structure as a beacon frame - it contains the SSID, capabilities, supported rates, security information elements, and everything else an associating client needs to know.
The key difference from a beacon: a probe response is directed to the specific client that asked. It has the client's MAC address as the destination. It's not a broadcast.
Probe responses are what expose hidden SSIDs. An AP with a hidden SSID will omit the SSID from beacons, but when it sends a probe response to a client that directed a probe at it, the SSID is in the response in plaintext.
Why AP Spam Works
Now you have the foundation to understand why AP Spam (broadcasting hundreds of fake SSIDs) is possible.
An access point is just a device that transmits beacon frames at a regular interval. The 802.11 standard does not restrict which devices can transmit management frames. There is no authentication requirement to send a beacon. Any device with a WiFi radio capable of raw frame injection can transmit beacon frames with any SSID, any BSSID, and any channel it wants.
The ESP32 used in the BLEShark Nano has raw frame injection capability. This means it can construct a 802.11 management frame from scratch and push it out the radio. A beacon frame for a fake AP called "FBI Surveillance Van" looks exactly the same at the protocol level as a beacon from a real Linksys router.
The BLEShark's AP Spam feature cycles through a list of SSIDs, crafting and transmitting a beacon frame for each one in rapid succession. Because the beacon interval is 100ms and the chip can transmit frames in microseconds, you can cycle through dozens or hundreds of SSIDs fast enough that they all appear in the nearby networks list simultaneously.
From a phone's perspective, there are just a lot of APs nearby. The phone has no way to distinguish a real AP from a spoofed beacon. They look identical at the protocol level.
What AP Spam Cannot Do on Its Own
Broadcasting fake SSIDs does not intercept traffic. A beacon frame announces a network's existence - it does not create an actual functional access point. If a client tries to associate with one of the fake SSIDs, the association will fail because there's no AP behind the beacon to complete the handshake.
AP Spam is useful for demonstrations (showing someone what it looks like when an attacker floods a WiFi list), for testing how devices handle a crowded RF environment, and for the occasional prank involving creative SSID names.
For a rogue AP attack that actually intercepts traffic, you need a functional AP with a DHCP server, a DNS server, and some form of portal or proxy - which is a different feature set entirely. The BLEShark's captive portal and evil portal features do this, but they're separate from AP Spam.
Beacon Frame Structure in Practice
To make this concrete, here's what the key fields in a beacon frame look like when captured:
graph TD
subgraph "802.11 Beacon Frame Structure"
FC["Frame Control
2 bytes
Type: 0x80 (Mgmt/Beacon)"]
DUR["Duration
2 bytes"]
DA["Destination: FF:FF:FF:FF:FF:FF
(Broadcast)"]
SA["Source Address
6 bytes (AP MAC)"]
BSSID["BSSID
6 bytes (AP MAC)"]
SEQ["Sequence Control
2 bytes"]
end
subgraph "Beacon Body (Tagged Parameters)"
TS["Timestamp
8 bytes (microseconds)"]
BI["Beacon Interval
2 bytes (default 100 TU)"]
CAP["Capability Info
2 bytes (ESS, Privacy, etc.)"]
SSID_IE["SSID IE
Tag 0 + Length + Name"]
RATES["Supported Rates
Tag 1 (1-8 rates)"]
DS["DS Parameter Set
Tag 3 (Channel #)"]
RSN["RSN/WPA IE
Tag 48 (encryption info)"]
VENDOR["Vendor Specific IEs
Tag 221 (WPS, WMM, etc.)"]
end
FC --> DUR --> DA --> SA --> BSSID --> SEQ
SEQ --> TS --> BI --> CAP --> SSID_IE --> RATES --> DS --> RSN --> VENDOR
Anatomy of an 802.11 beacon frame - the MAC header identifies it as a broadcast management frame, while tagged parameters carry network details like SSID, channel, and encryption type.
The MAC header is 24 bytes and contains the frame control field (identifying this as a management frame, subtype beacon), duration, destination (FF:FF:FF:FF:FF:FF for broadcasts), source address (the AP's BSSID), BSSID (same as source for infrastructure APs), and sequence control.
The frame body starts with the timestamp (8 bytes), beacon interval (2 bytes), and capability info (2 bytes). After that come the information elements - each with a tag number, length, and value. The SSID element is tag 0. The supported rates element is tag 1. The DS parameter set (channel) is tag 3. RSN information is tag 48. Vendor-specific elements use tag 221.
The whole frame ends with a 4-byte frame check sequence (FCS) - a CRC over the frame content used for error detection.
When you look at a Wireshark capture of 802.11 frames, you can expand any beacon and see all of these fields. It's a good exercise if you want to understand what information is publicly available about every AP in range.
Passive Monitoring and the BLEShark Nano
The BLEShark Nano's WiFi scan gives you the practical output of everything described above. When it scans, it's doing passive scanning - listening for beacon frames on each 2.4GHz channel and reporting back what it found.
What you get from a scan: SSID, BSSID (AP MAC address), RSSI (signal strength in dBm), channel, and security type (Open / WPA / WPA2 / WPA3). This information is derived entirely from the beacon frames. No probe requests sent, no interaction with the AP, no association.
For deauth detection, the BLEShark monitors management frames on a specific channel and watches for deauthentication frames. This is also passive - it's watching what's already in the air, not sending anything.
With the Shiver mesh system, you can run multiple BLEShark Nanos across different channels simultaneously, building a full picture of the 2.4GHz environment that no single device could capture alone. Each node watches its assigned channel partition and reports back to the master device.
Channel Hopping and Scan Coverage
Because the ESP32-C3 has a single 2.4GHz radio, it can only monitor one channel at a time. During a WiFi scan, the firmware hops between channels, spending enough time on each to catch beacon frames.
The downside: while it's on channel 6, it's not seeing anything on channel 1 or 11. Events on other channels are invisible. This is why multi-channel scenarios benefit from multiple devices - the Shiver mesh assigns channel partitions so each node covers a different slice of the spectrum without overlap.
For most home and small office environments, a single BLEShark scan is sufficient to find everything visible. For enterprise environments or situations where complete channel coverage matters, the mesh approach removes the blind spots.
Security Implications for Network Administrators
Beacon frames and probe requests reveal a lot about your network without any active probing:
- The SSID tells an attacker what to spoof for a rogue AP attack
- The security information elements show exactly what cipher suites you support - advertising whether you've moved to WPA3 or are still on WPA2
- The vendor-specific elements sometimes leak AP model information
- The BSSID reveals the AP manufacturer (from the OUI) and can sometimes identify the exact model
None of this requires breaking encryption. It's all in the clear, broadcast to everyone in range, before any connection exists.
The practical hardening steps: use WPA3 where possible (the RSN IE will advertise SAE support), enable Protected Management Frames (802.11w) to protect against deauth attacks, and avoid using SSIDs that reveal your organization name or location. An SSID called "CompanyName-Corporate" is useful information for an attacker scoping a target.
Probe request privacy from clients is largely handled by the OS now (MAC randomization), but your users' devices still carry probe requests for networks they've visited. Educate users to forget networks they no longer use, especially public WiFi SSIDs they joined once and never returned to.
BLEShark Nano is designed for authorized security testing and educational use. Always ensure you have explicit permission before scanning or testing any network that you do not own.