प्रोब रिक्वेस्ट क्या है? समझना कि डिवाइस नेटवर्क कैसे खोजते हैं

What Is a Probe Request? Understanding How Devices Discover Networks. A Purple Technical Briefing. Introduction and Context. Welcome to this Purple technical briefing. I'm going to walk you through one of the most fundamental — and most frequently misunderstood — mechanisms in enterprise WiFi: the probe request. If you're responsible for a guest WiFi deployment, a multi-site retail network, or a venue analytics programme, understanding probe requests isn't optional. It's the foundation on which everything else sits — from footfall analytics and dwell time measurement to MAC randomisation challenges and GDPR compliance. So let's get into it. Every time a device — a smartphone, a laptop, a tablet — is not connected to a network, it's constantly scanning for one. That scanning process begins with a probe request. It's a management frame, defined under IEEE 802.11, and it's transmitted by the client device, not the access point. Think of it as the device shouting into the room: "Is anyone here I know?" The access point listens, and if it recognises the request, it responds. This happens hundreds of times a day, often without the device owner ever knowing. And for network architects and venue operators, those probe requests are a goldmine of operational data — if you know how to capture and interpret them correctly. Technical Deep-Dive. Let's go deeper into the mechanics. A probe request is a Layer 2 management frame transmitted on the 2.4 GHz or 5 GHz radio bands. Under the IEEE 802.11 standard, it's classified as a subtype 4 management frame. The frame contains several key information elements: the SSID field, the supported rates element, the extended supported rates element, and capability information including HT — that's high-throughput — and VHT capabilities for 802.11ac devices. There are two types of probe requests. The first is a broadcast probe request, sometimes called a wildcard probe. Here the SSID field is empty — the device is essentially asking any access point in range to identify itself. The second is a directed probe request, where the SSID field contains a specific network name. This happens when the device is actively looking for a network it has previously connected to and has stored in its preferred network list. The access point's response — the probe response frame — mirrors much of the beacon frame content. It includes the SSID, the BSSID, the beacon interval, the timestamp, and the full capability set. This exchange is what allows a device to build its list of available networks before the user even opens their WiFi settings. Now, there's an important distinction between active scanning and passive scanning. Active scanning is the probe request and response cycle I've just described. Passive scanning is different — the device simply listens for beacon frames that access points broadcast periodically, typically every 100 milliseconds. Passive scanning is slower but uses less power. Most modern devices use a combination of both, depending on their power state and the regulatory domain they're operating in. Here's where it gets operationally significant. In a high-density venue — a stadium, a conference centre, a large retail floor — you can have thousands of devices simultaneously sending probe requests across multiple channels. This creates what's known as probe storm conditions. Each probe request consumes airtime. In a poorly designed network, this management frame overhead can measurably degrade throughput for connected clients. This is why enterprise-grade access points implement probe request filtering and rate limiting as standard. Now let's talk about MAC addresses and why this matters enormously for analytics. Historically, every probe request carried the device's real hardware MAC address — a globally unique 48-bit identifier burned into the network interface card. This made probe-based analytics extremely reliable. You could track a device across your venue, measure dwell time, identify repeat visitors, and build footfall heatmaps with high confidence. That changed significantly with iOS 14 in 2020 and Android 10 before it. Apple and Google introduced MAC address randomisation for probe requests. Instead of broadcasting the real hardware MAC, devices now generate a randomised MAC address for scanning. On iOS, this randomisation is per-SSID — meaning the device uses a consistent randomised MAC when connecting to a specific network, but a different one when probing. On Android, the implementation varies by manufacturer. The practical impact for venue operators is significant. Probe-based footfall analytics that relied on persistent MAC addresses are now unreliable for unconnected devices. Unique device counts are inflated. Repeat visitor identification from probe data alone is no longer viable. The solution — and this is where authenticated guest WiFi becomes critical — is to move your identity layer from the MAC address to the authenticated user. When a visitor connects through a captive portal or a social login, you capture a persistent, consented identity that survives MAC randomisation. Purple's guest WiFi platform does exactly this — it ties the analytics to the authenticated session, not the hardware address, giving you accurate, GDPR-compliant footfall data regardless of the device's MAC behaviour. There's also a security dimension to probe requests that network security analysts need to understand. Because probe requests are unencrypted management frames, they're visible to anyone with a packet capture tool in monitor mode. A directed probe request reveals the SSIDs of networks a device has previously connected to — what's known as the preferred network list, or PNL. This is a genuine privacy exposure. A device walking through your venue is broadcasting the names of every network it's ever joined. This is one of the reasons MAC randomisation was introduced in the first place. From an attack surface perspective, probe requests enable evil twin attacks. An attacker who captures a directed probe request for a specific SSID can stand up a rogue access point with that SSID and wait for the device to auto-connect. WPA3's enhanced open and simultaneous authentication of equals — SAE — protocols significantly mitigate this risk, but only if your infrastructure supports and enforces them. Implementation Recommendations and Pitfalls. Right, let's move to what you actually do with this in a real deployment. First, if you're deploying or refreshing a guest WiFi network in a high-density venue, your access point placement and channel planning must account for probe request overhead. Use a minimum channel width strategy — 20 MHz on 2.4 GHz — and implement minimum RSSI thresholds to prevent distant devices from associating. Most enterprise controllers allow you to set probe response filtering so that APs only respond to devices above a certain signal strength. This reduces management frame noise significantly. Second, if you're running footfall or dwell time analytics, accept that probe-only data is no longer sufficient. Your analytics strategy needs to be built around authenticated sessions. This means your captive portal or onboarding flow needs to be frictionless enough that visitors actually connect. Purple's data shows that venues with a well-designed onboarding experience — social login, email capture, or a passwordless flow — see connection rates of 60 to 80 percent of devices in venue. That's your analytics population. Third, for GDPR compliance in the UK and EU, probe request data collection — even anonymised — requires careful legal basis assessment. If you're capturing and storing probe frames for analytics, you need to document your legitimate interest basis and ensure data minimisation. The ICO's guidance on WiFi tracking is clear: if you can identify an individual from the data, even indirectly, it's personal data. Work with your DPO before deploying any probe-based analytics system. Fourth, watch out for probe storms in dense environments. If you're seeing unexplained throughput degradation in a venue with high footfall, pull your AP logs and look at management frame rates. A probe storm is often the culprit. The fix is a combination of minimum RSSI filtering, probe response rate limiting, and ensuring your 5 GHz band is properly advertised so capable devices prefer it over 2.4 GHz. Rapid-Fire Q&A. Let me run through a few questions that come up regularly. Can I use probe requests to count footfall without a captive portal? Technically yes, but post-iOS 14 the accuracy is poor. You'll see inflated unique counts and no repeat visitor data. For anything beyond rough order-of-magnitude estimates, you need authenticated sessions. Do probe requests work on 6 GHz WiFi 6E networks? Yes, but with differences. The 6 GHz band uses a discovery mechanism called FILS — Fast Initial Link Setup — and out-of-band discovery, which changes the probe dynamics. If you're deploying WiFi 6E, check your vendor's documentation on 6 GHz scanning behaviour. What's the difference between a probe request and an association request? A probe request is pre-association — the device is discovering networks. An association request comes after authentication, when the device is formally requesting to join a specific network. They're different stages of the 802.11 connection state machine. Is MAC randomisation consistent once connected? On iOS, yes — the device uses a stable randomised MAC for a given SSID. On Android, it varies. Some implementations re-randomise on each connection. This is why session-based identity, not MAC-based identity, is the right architecture. Summary and Next Steps. To wrap up: probe requests are the heartbeat of WiFi discovery. Every device in your venue is generating them constantly. Understanding their structure, their limitations, and their security implications is fundamental to designing reliable, analytics-capable, and compliant guest WiFi deployments. The key takeaways are these. One: probe-based analytics without authentication are unreliable in a post-MAC-randomisation world. Two: authenticated guest WiFi is your identity layer — it's what makes your analytics accurate and your data GDPR-compliant. Three: probe storm management is a real operational concern in high-density venues and needs to be addressed at the infrastructure design stage. Four: directed probe requests expose your device's preferred network list — a genuine security risk that WPA3 and network hygiene practices can mitigate. If you want to go deeper, Purple's technical documentation covers how our hardware-agnostic platform captures and processes probe data alongside authenticated session data to give you accurate venue analytics. You can also explore our guides on WiFi wayfinding and trilateration, which build directly on the probe request fundamentals we've covered today. Thanks for listening. This has been a Purple technical briefing.