Zum Hauptinhalt springen
Deutsch

Was ist eine Probe Request? Verstehen, wie Geräte Netzwerke entdecken

Dieser technische Leitfaden bietet einen tiefen Einblick in IEEE 802.11 Probe Requests, aktives versus passives Scannen und die Auswirkungen der MAC randomisation auf Standortanalysen. Er liefert umsetzbare Implementierungsstrategien für Netzwerkarchitekten zur Optimierung von High-Density-Bereitstellungen, zur Minderung von Probe Storms und zur Sicherstellung einer genauen, GDPR-konformen Datenerfassung mithilfe authentifizierter Identitätsschichten.

📖 6 Min. Lesezeit📝 1,416 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
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.

header_image.png

Executive Summary

Für Netzwerkarchitekten von Unternehmen und Betriebsleiter von Veranstaltungsorten ist die Probe Request der grundlegende Mechanismus der drahtlosen Geräteerkennung. Es handelt sich um einen Layer 2 Management Frame, der festlegt, wie nicht verbundene Geräte Access Points in Einzelhandel , Gastgewerbe und Transport Umgebungen identifizieren und sich mit ihnen verbinden. Die Landschaft der Probe-basierten Analysen hat sich jedoch grundlegend verändert. Mit der allgegenwärtigen Implementierung der MAC address randomisation in iOS und Android sind herkömmliche Besucherstromzählungen und Verweildauermessungen, die sich ausschließlich auf unauthentifizierte Probe-Daten verlassen, nicht mehr praktikabel oder konform.

Dieser Leitfaden erläutert die technischen Mechanismen des Probe Request- und Response-Zyklus, untersucht den kritischen Unterschied zwischen aktivem und passivem Scannen und beschreibt die betrieblichen Auswirkungen von Probe Storms in High-Density-Bereitstellungen. Noch wichtiger ist, dass er einen strategischen Fahrplan für den Übergang von hardwarebasiertem Tracking zu authentifizierten, identitätsgesteuerten Analysen mithilfe von Guest WiFi und WiFi Analytics Plattformen bietet, um eine robuste Netzwerkleistung und verwertbare Business Intelligence zu gewährleisten.

Technischer Deep-Dive: Die Mechanismen der Erkennung

Die IEEE 802.11 Zustandsmaschine

Bevor ein Gerät IP-Verkehr übertragen kann, muss es die 802.11 Verbindungszustandsmaschine durchlaufen: Discovery, Authentication und Association. Die Probe Request operiert ausschließlich in der Discovery-Phase. Sie wird als Subtype 4 Management Frame klassifiziert, der vom Client-Gerät (STA) gesendet wird, um verfügbare Basic Service Sets (BSS) zu lokalisieren.

Es gibt zwei primäre Erkennungsmethoden:

  1. Passive Scanning: Das Client-Gerät stimmt sein Radio auf einen bestimmten Kanal ab und lauscht auf Beacon frames, die periodisch (typischerweise alle 100ms) vom Access Point (AP) gesendet werden. Diese Methode spart Batterielebensdauer, erhöht aber die Erkennungslatenz.
  2. Active Scanning: Das Client-Gerät sendet proaktiv Probe Request frames auf verschiedenen Kanälen und wartet auf Probe Response frames von APs. Dies beschleunigt die Erkennung, verbraucht aber Sendezeit und Strom.

Broadcast vs. Directed Probe Requests

Active Scanning verwendet zwei verschiedene Arten von Probe Requests:

  • Broadcast (Wildcard) Probe Request: Das Service Set Identifier (SSID) Feld ist auf null (Länge null) gesetzt. Das Gerät sendet an jeden AP in Reichweite und fragt effektiv: „Wer ist da draußen?“ Alle APs, die diesen Frame empfangen, sofern sie nicht so konfiguriert sind, dass sie ihre SSID verbergen, antworten mit einer Probe Response.
  • Directed Probe Request: Das SSID Feld enthält einen spezifischen Netzwerknamen. Das Gerät fragt nach einem bekannten Netzwerk aus seiner Preferred Network List (PNL). Nur APs, die diese spezifische SSID hosten, werden antworten. Dieser Mechanismus ist entscheidend für Geräte, die versuchen, sich automatisch mit versteckten Netzwerken zu verbinden.

probe_request_flow_diagram.png

Anatomie eines Probe Request Frames

Ein standardmäßiger Probe Request Frame enthält kritische Information Elements (IEs), die den AP über die Fähigkeiten des Clients informieren. Zu den wichtigsten Feldern gehören:

  • MAC Header: Enthält Frame Control, Duration, Destination Address (normalerweise die Broadcast-Adresse ff:ff:ff:ff:ff:ff), Source Address (die MAC des Clients) und BSSID.
  • SSID: Der Zielnetzwerkname (oder null für Broadcast).
  • Supported Rates: Definiert die grundlegenden und operativen Datenraten, die der Client unterstützt (z. B. 1, 2, 5.5, 11 Mbps für älteres 802.11b, bis hin zu modernen OFDM-Raten).
  • Extended Supported Rates: Zusätzliche vom Client unterstützte Datenraten.
  • HT/VHT/HE Capabilities: Zeigt die Unterstützung für High Throughput (802.11n), Very High Throughput (802.11ac) oder High Efficiency (802.11ax/WiFi 6) Funktionen an, einschließlich Spatial Streams und Kanalbreiten.

Das Verständnis dieser Fähigkeiten ist für APs unerlässlich, um die optimalen Verbindungsparameter während der nachfolgenden Assoziationsphase auszuhandeln.

Die Auswirkungen der MAC randomisation

Historisch gesehen war die Source Address in der Probe Request die global eindeutige, fest eingebrannte MAC address des Geräts. Diese Persistenz ermöglichte es Betreibern von Veranstaltungsorten, nicht verbundene Geräte zu verfolgen, Verweildauern zu messen und Besucherstrom-Heatmaps zu erstellen, indem sie passiv auf Probe Requests lauschten.

Datenschutzbedenken hinsichtlich der Übertragung persistenter Identifikatoren führten jedoch zur Implementierung der MAC randomisation. Eingeführt in iOS 14 und Android 10, generieren moderne Betriebssysteme nun eine randomisierte, lokal verwaltete MAC address, wenn sie Probe Requests senden.

Das Ende des unauthentifizierten Trackings

mac_randomisation_impact_chart.png

Die betrieblichen Auswirkungen sind tiefgreifend:

  • Inflated Device Counts: Ein einzelnes Gerät kann im Laufe der Zeit mehrere randomisierte MAC addresses generieren, was die Metriken für eindeutige Besucher in älteren Analysesystemen künstlich aufbläht.
  • Broken Dwell Time: Die Verfolgung der Reise eines Geräts durch einen Veranstaltungsort ist unmöglich, wenn sich dessen Identifikator während des Besuchs ändert.
  • Loss of Repeat Visitor Data: Ohne einen persistenten Identifikator ist es unmöglich, einen neuen Besucher von einem wiederkehrenden Besucher über Probe-Daten zu unterscheiden.

Die IIdentitätsbasierte Lösung

Um die analytische Genauigkeit wiederherzustellen, muss sich das Tracking-Paradigma von Hardware-Identifikatoren der Schicht 2 zu authentifizierten Identitäten der Schicht 7 verlagern. Durch die Implementierung eines robusten Captive Portal oder eines nahtlosen Onboarding-Flows (wie How a wi fi assistant Enables Passwordless Access in 2026 ) erfassen Veranstaltungsorte eine persistente, zugestimmte Identität (z. B. E-Mail, soziales Profil oder Kunden-ID).

Sobald sich ein Benutzer authentifiziert, korreliert die Purple Plattform die aktuelle MAC-Adresse (auch wenn sie für die spezifische SSID randomisiert wurde) mit dem persistenten Profil des Benutzers. Dies stellt sicher, dass nachfolgende Besuche und Bewegungen genau anhand der authentifizierten Identität verfolgt werden, wodurch die Einschränkungen der MAC-Randomisierung vollständig umgangen werden. Dieser Ansatz ist grundlegend für die Umsetzung der Strategien, die in How To Improve Guest Satisfaction: The Ultimate Playbook beschrieben sind.

Implementierungsleitfaden: Optimierung für hohe Dichte

In Umgebungen wie Stadien oder großen Einzelhandelsflächen kann das schiere Volumen von Probe Requests von Tausenden von Geräten die Netzwerkleistung erheblich beeinträchtigen. Dieses Phänomen, bekannt als ein Probe Storm, verbraucht wertvolle Sendezeit und lässt weniger Kapazität für die eigentliche Datenübertragung übrig.

Probe Storms mindern

Netzwerkarchitekten müssen proaktive Konfigurationsstrategien implementieren, um den Overhead von Management Frames zu verwalten:

  1. Probe Response Suppression: Konfigurieren Sie APs so, dass sie Broadcast-Probe-Requests von Geräten mit einem Received Signal Strength Indicator (RSSI) unterhalb eines bestimmten Schwellenwerts (z. B. -75 dBm) ignorieren. Wenn ein Gerät zu weit entfernt ist, um eine zuverlässige Verbindung herzustellen, sollte der AP keine Sendezeit damit verschwenden, auf seine Probes zu antworten.
  2. Disable Lower Data Rates: Durch das Deaktivieren älterer Datenraten (z. B. 1, 2, 5,5, 11 Mbps) und das Festlegen der minimalen obligatorischen Basisrate auf 12 Mbps oder 24 Mbps verbrauchen Management Frames (die mit der niedrigsten Basisrate übertragen werden) deutlich weniger Sendezeit.
  3. Band Steering: Lenken Sie fähige Clients aktiv auf die 5 GHz- oder 6 GHz-Bänder. Das 2,4 GHz-Band verfügt über begrenzte nicht überlappende Kanäle und ist sehr anfällig für Überlastungen durch Probe Storms.
  4. Limit SSIDs: Jede von einem AP ausgestrahlte SSID erfordert einen eigenen Satz von Beacon Frames und Probe Responses. Beschränken Sie die Anzahl der SSIDs auf ein absolutes Minimum (idealerweise nicht mehr als drei pro AP), um den Management-Overhead zu reduzieren.

Sicherheit und Compliance

Die Datenschutzrisiken von Directed Probes

Directed Probe Requests stellen ein einzigartiges Sicherheitsrisiko dar. Da sie die Namen zuvor verbundener Netzwerke (das PNL) übertragen, kann ein Angreifer, der diese Frames abfängt, ein Profil der Bewegungen eines Benutzers erstellen (z. B. dessen Heimnetzwerk, Arbeitgeber oder häufig besuchte Cafés).

Darüber hinaus setzt dies das Gerät Evil Twin Attacks aus. Ein Angreifer kann einen Rogue AP einsetzen, der eine SSID aus dem PNL des Opfers sendet. Das Gerät des Opfers, das die bekannte SSID in seiner Directed Probe Response erkennt, kann sich automatisch mit dem Rogue AP verbinden, wodurch der Datenverkehr dem Abfangen ausgesetzt wird.

Minderung: Die Implementierung von WPA3-Enterprise oder WPA3-Enhanced Open (OWE) mindert das Risiko des Abfangens nach der Assoziation, aber die Netzwerkhygiene (Benutzer, die öffentliche Netzwerke manuell vergessen) bleibt die primäre Verteidigung gegen PNL-Exposition.

GDPR und berechtigtes Interesse

Gemäß der UK GDPR und EU GDPR kann das Sammeln von MAC-Adressen – selbst wenn sie gehasht oder randomisiert sind – die Verarbeitung personenbezogener Daten darstellen, wenn sie einer Einzelperson zugeordnet werden können. Beim Einsatz von Probe-basierten Analysen müssen Organisationen:

  • Eine klare Rechtsgrundlage schaffen (typischerweise berechtigtes Interesse für anonymisierte Besucherzahlen oder Einwilligung für gezieltes Marketing).
  • Auffällige Beschilderung anbringen, die Besucher darüber informiert, dass WiFi-Scanning durchgeführt wird.
  • Einen klaren Opt-out-Mechanismus bereitstellen.

Der Übergang zu einem authentifizierten Guest WiFi -Modell vereinfacht die Compliance, da die explizite Einwilligung während des Onboarding-Prozesses erfasst wird.

ROI & Geschäftsauswirkungen

Das Verstehen und Verwalten von Probe Requests ist nicht nur eine technische Übung; es wirkt sich direkt auf das Geschäftsergebnis aus.

  • Netzwerkleistung: Eine ordnungsgemäße Minderung von Probe Storms gewährleistet hohen Durchsatz und niedrige Latenz für verbundene Benutzer, was sich direkt auf die Gästezufriedenheit und die betriebliche Effizienz auswirkt.
  • Genaue Analysen: Der Übergang von fehlerhaftem Probe-basiertem Tracking zu authentifizierten Identitätsschichten stellt sicher, dass Marketing- und Betriebsteams Entscheidungen auf zuverlässigen Daten basieren. Dies ist entscheidend für die Messung der Kampagnenzuordnung, die Optimierung des Personalbestands basierend auf echten Besucherzahlen und die Steigerung des Umsatzes durch gezieltes Engagement.
  • Risikominderung: Proaktives Management von Management Frames und die Einhaltung von Datenschutzbestimmungen schützen die Organisation vor Compliance-Strafen und Reputationsschäden.

Durch die Beherrschung der Mechanismen der Geräteerkennung können IT-Führungskräfte Netzwerke entwerfen, die nicht nur widerstandsfähig und leistungsfähig sind, sondern auch als grundlegende Assets für die Unternehmensintelligenz dienen. Weitere Einblicke in das standortbasierte Tracking finden Sie unter The Mechanics of WiFi Wayfinding: Trilateration and RSSI Explained .

Schlüsseldefinitionen

Probe Request

A Layer 2 management frame transmitted by a client device to discover available 802.11 networks in its vicinity.

The fundamental mechanism for network discovery before a device authenticates or associates.

Probe Response

A management frame transmitted by an Access Point in reply to a Probe Request, containing network capabilities and configuration parameters.

Provides the client with the necessary information to initiate the association process.

MAC Randomisation

A privacy feature where a device generates a temporary, locally administered MAC address instead of its permanent hardware address when scanning for networks.

Renders legacy, unauthenticated footfall analytics inaccurate by inflating unique device counts.

Probe Storm

A condition in high-density environments where the sheer volume of probe requests and responses consumes a significant percentage of available airtime.

Causes severe network performance degradation, requiring specific AP configuration mitigations.

Preferred Network List (PNL)

A list maintained by a client device containing the SSIDs of networks it has previously connected to.

Devices broadcast these SSIDs in Directed Probe Requests, creating potential privacy and security risks.

RSSI (Received Signal Strength Indicator)

A measurement of the power present in a received radio signal.

Used in Probe Response Suppression to filter out requests from distant devices.

Management Frame

802.11 frames used to establish and maintain communications between clients and APs (e.g., Beacons, Probes, Authentication frames).

Unlike data frames, they carry network control information and must be carefully managed to preserve airtime.

Band Steering

A technique used by APs to encourage dual-band clients to connect to the less congested 5 GHz or 6 GHz bands rather than 2.4 GHz.

A key strategy for mitigating the impact of probe storms on legacy bands.

Ausgearbeitete Beispiele

A 400-store retail chain is experiencing severe WiFi performance degradation during peak weekend hours. The IT dashboard shows high channel utilisation on the 2.4 GHz band, but data throughput is low. How should the network architect address this?

  1. Conduct a packet capture to confirm the presence of a probe storm. 2. Implement Probe Response Suppression, configuring APs to ignore probe requests with an RSSI weaker than -75 dBm. 3. Disable legacy 802.11b data rates (1, 2, 5.5, 11 Mbps) to force management frames to transmit at higher speeds, consuming less airtime. 4. Enable aggressive band steering to push dual-band clients to 5 GHz.
Kommentar des Prüfers: This scenario highlights the classic symptoms of management frame overhead. By addressing the root cause (excessive low-rate probe responses), the architect reclaims airtime for actual data payloads without requiring hardware upgrades.

A marketing director at a large conference centre reports that their footfall analytics dashboard shows 50,000 unique visitors, but ticket sales indicate only 15,000 attendees. What is causing this discrepancy and how can it be resolved?

The discrepancy is caused by MAC address randomisation. Unconnected devices are transmitting probe requests with rotating MAC addresses, causing the legacy analytics platform to count single devices multiple times. The solution is to deploy an authenticated Guest WiFi portal. By requiring users to log in (e.g., via email or social SSO), the venue ties analytics to a persistent identity rather than a rotating hardware identifier.

Kommentar des Prüfers: This demonstrates the critical business impact of iOS 14/Android 10 changes. It underscores the necessity of moving from passive Layer 2 tracking to active Layer 7 authenticated analytics for reliable business intelligence.

Übungsfragen

Q1. You are designing the WiFi network for a 50,000-seat stadium. During a test event, you observe 60% channel utilisation on 2.4 GHz, but very little actual data traffic. Which configuration change will have the most immediate positive impact?

Hinweis: Consider how management frames are transmitted and how to reduce their footprint on the airtime.

Musterlösung anzeigen

Disable the lowest mandatory basic data rates (1, 2, 5.5, 11 Mbps) and implement Probe Response Suppression for clients with an RSSI weaker than -75 dBm. This forces management frames to transmit faster (taking up less airtime) and stops the APs from responding to devices too far away to connect reliably.

Q2. A client requests a footfall tracking solution that does not require users to connect to the WiFi, citing a desire for 'frictionless analytics'. How should you advise them?

Hinweis: Factor in modern mobile OS privacy features and the limitations of Layer 2 tracking.

Musterlösung anzeigen

Advise the client that unauthenticated, probe-based footfall tracking is no longer reliable due to MAC address randomisation in iOS 14+ and Android 10+. Unconnected devices will appear as multiple unique visitors, severely inflating the data. The recommended architecture is to deploy a seamless, authenticated Guest WiFi portal to capture persistent Layer 7 identities, ensuring accurate data and GDPR compliance.

Q3. An executive is concerned about the security implications of devices broadcasting their Preferred Network Lists (PNL). What is the specific attack vector they are worried about, and how is it executed?

Hinweis: Think about how an attacker might use the information contained in a Directed Probe Request.

Musterlösung anzeigen

The executive is concerned about an Evil Twin attack. An attacker captures a Directed Probe Request containing an SSID from the device's PNL. The attacker then stands up a rogue access point broadcasting that exact SSID. Because the device trusts the network name, it may automatically associate with the rogue AP, allowing the attacker to intercept traffic or launch man-in-the-middle attacks.