Passer au contenu principal
Français

Qu'est-ce qu'une requête de sonde (Probe Request) ? Comprendre comment les appareils découvrent les réseaux

Ce guide de référence technique offre une analyse approfondie des requêtes de sonde IEEE 802.11, de la distinction entre balayage actif et passif, et de l'impact de la randomisation MAC sur l'analyse des lieux. Il fournit des stratégies de mise en œuvre concrètes pour les architectes réseau afin d'optimiser les déploiements à haute densité, d'atténuer les tempêtes de sondes et d'assurer une collecte de données précise et conforme au GDPR en utilisant des couches d'identité authentifiées.

📖 6 min de lecture📝 1,416 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast
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

Résumé Exécutif

Pour les architectes de réseaux d'entreprise et les directeurs d'opérations de sites, la requête de sonde est le mécanisme fondamental de découverte des appareils sans fil. Il s'agit d'une trame de gestion de Layer 2 qui dicte comment les appareils non connectés identifient et s'associent aux points d'accès dans les environnements de Retail , d' Hospitality et de Transport . Cependant, le paysage de l'analyse basée sur les sondes a fondamentalement changé. Avec la mise en œuvre omniprésente de la randomisation MAC address sur iOS et Android, le footfall tracking et la mesure du dwell time hérités, reposant uniquement sur des données de sonde non authentifiées, ne sont plus viables ni conformes.

Ce guide décortique les mécanismes techniques du cycle de requête et de réponse de sonde, explore la distinction critique entre le balayage actif et passif, et détaille l'impact opérationnel des tempêtes de sondes dans les déploiements à haute densité. Plus important encore, il fournit une feuille de route stratégique pour la transition du suivi basé sur le matériel vers une analyse authentifiée et axée sur l'identité, en utilisant les plateformes Guest WiFi et WiFi Analytics , garantissant des performances réseau robustes et une intelligence économique exploitable.

Approfondissement Technique : Les Mécanismes de la Découverte

La Machine d'État IEEE 802.11

Avant qu'un appareil ne puisse transmettre du trafic IP, il doit traverser la machine d'état de connexion 802.11 : Discovery, Authentication et Association. La requête de sonde opère exclusivement dans la phase Discovery. Elle est classée comme une trame de gestion de Subtype 4, transmise par l'appareil client (STA) pour localiser les Basic Service Sets (BSS) disponibles.

Il existe deux méthodes principales de découverte :

  1. Balayage Passif : L'appareil client syntonise sa radio sur un canal spécifique et écoute les Beacon frames diffusées périodiquement (généralement toutes les 100 ms) par le point d'accès (AP). Cette méthode préserve la durée de vie de la batterie mais augmente la latence de découverte.
  2. Balayage Actif : L'appareil client transmet de manière proactive des Probe Request frames sur différents canaux et attend les Probe Response frames des AP. Cela accélère la découverte mais consomme du temps d'antenne et de l'énergie.

Requêtes de Sonde Broadcast vs. Dirigées

Le balayage actif utilise deux types distincts de requêtes de sonde :

  • Requête de Sonde Broadcast (Wildcard) : Le champ Service Set Identifier (SSID) est défini sur null (longueur zéro). L'appareil diffuse à tout AP à portée, demandant en substance : « Qui est là ? » Tous les AP recevant cette trame, à condition qu'ils ne soient pas configurés pour masquer leur SSID, répondront par une Probe Response.
  • Requête de Sonde Dirigée : Le champ SSID contient un nom de réseau spécifique. L'appareil interroge un réseau connu de sa Preferred Network List (PNL). Seuls les AP hébergeant ce SSID spécifique répondront. Ce mécanisme est crucial pour les appareils tentant de se connecter automatiquement à des hidden networks.

probe_request_flow_diagram.png

Anatomie d'une Trame de Requête de Sonde

Une trame de requête de sonde standard contient des Information Elements (IEs) critiques qui informent l'AP des capacités du client. Les champs clés incluent :

  • MAC Header : Contient le Frame Control, Duration, Destination Address (généralement l'adresse de diffusion ff:ff:ff:ff:ff:ff), Source Address (le MAC du client) et BSSID.
  • SSID : Le nom du réseau cible (ou null pour la diffusion).
  • Supported Rates : Définit les débits de données de base et opérationnels pris en charge par le client (par exemple, 1, 2, 5.5, 11 Mbps pour le 802.11b hérité, jusqu'aux débits OFDM modernes).
  • Extended Supported Rates : Débits de données supplémentaires pris en charge par le client.
  • HT/VHT/HE Capabilities : Indique la prise en charge des fonctionnalités High Throughput (802.11n), Very High Throughput (802.11ac) ou High Efficiency (802.11ax/WiFi 6), y compris les flux spatiaux et les largeurs de canal.

Comprendre ces capacités est essentiel pour que les AP négocient les paramètres de connexion optimaux pendant la phase d'association ultérieure.

L'Impact de la Randomisation MAC

Historiquement, la Source Address dans la requête de sonde était l'adresse MAC unique et gravée de l'appareil. Cette persistance permettait aux opérateurs de sites de suivre les appareils non connectés, de mesurer les dwell times et de créer des cartes thermiques de footfall simplement en écoutant passivement les probe requests.

Cependant, les préoccupations en matière de confidentialité concernant la diffusion d'identifiants persistants ont conduit à la mise en œuvre de la randomisation MAC. Introduits dans iOS 14 et Android 10, les systèmes d'exploitation modernes génèrent désormais une adresse MAC aléatoire et administrée localement lors de la transmission des probe requests.

La Fin du Suivi Non Authentifié

mac_randomisation_impact_chart.png

L'impact opérationnel est profond :

  • Comptes d'Appareils Gonflés : Un seul appareil peut générer plusieurs adresses MAC aléatoires au fil du temps, gonflant artificiellement les métriques de visiteurs uniques dans les legacy analytics systems.
  • Dwell Time Compromis : Suivre le parcours d'un appareil à travers un lieu est impossible si son identifiant change en cours de visite.
  • Perte de Données sur les Visiteurs Répétés : Sans identifiant persistant, distinguer un nouveau visiteur d'un visiteur récurrent via les probe data est irréalisable.

The ISolution axée sur l'identité

Pour restaurer la précision analytique, le paradigme de suivi doit passer des identifiants matériels de couche 2 aux identités authentifiées de couche 7. En mettant en œuvre un Captive Portal robuste ou un flux d'intégration fluide (tel que Comment un assistant Wi-Fi permet un accès sans mot de passe en 2026 ), les lieux capturent une identité persistante et consentie (par exemple, e-mail, profil social ou identifiant de fidélité).

Une fois qu'un utilisateur s'authentifie, la plateforme Purple corrèle l'adresse MAC actuelle (même si elle est randomisée pour ce SSID spécifique) avec le profil persistant de l'utilisateur. Cela garantit que les visites et les mouvements ultérieurs sont suivis avec précision par rapport à l'identité authentifiée, contournant entièrement les limitations de la randomisation MAC. Cette approche est fondamentale pour l'exécution des stratégies décrites dans Comment améliorer la satisfaction des clients : Le guide ultime .

Guide d'implémentation : Optimisation pour les environnements à haute densité

Dans des environnements tels que les stades ou les grands espaces de vente au détail, le volume considérable de requêtes de sondage provenant de milliers d'appareils peut gravement dégrader les performances du réseau. Ce phénomène, connu sous le nom de tempête de sondes (Probe Storm), consomme un temps d'antenne précieux, laissant moins de capacité pour la transmission réelle des données.

Atténuation des tempêtes de sondes

Les architectes réseau doivent mettre en œuvre des stratégies de configuration proactives pour gérer la surcharge des trames de gestion :

  1. Suppression des réponses de sondage : Configurez les points d'accès (AP) pour ignorer les requêtes de sondage diffusées par les appareils dont l'indicateur de force du signal reçu (RSSI) est inférieur à un seuil spécifique (par exemple, -75 dBm). Si un appareil est trop éloigné pour établir une connexion fiable, le point d'accès ne doit pas gaspiller de temps d'antenne à répondre à ses sondes.
  2. Désactiver les débits de données inférieurs : En désactivant les débits de données hérités (par exemple, 1, 2, 5.5, 11 Mbps) et en définissant le débit de base obligatoire minimum à 12 Mbps ou 24 Mbps, les trames de gestion (qui sont transmises au débit de base le plus bas) consomment significativement moins de temps d'antenne.
  3. Pilotage de bande (Band Steering) : Orientez activement les clients compatibles vers les bandes 5 GHz ou 6 GHz. La bande 2.4 GHz a des canaux non superposés limités et est très susceptible à la congestion due aux tempêtes de sondes.
  4. Limiter les SSID : Chaque SSID diffusé par un point d'accès nécessite son propre ensemble de trames Beacon et de réponses de sondage. Limitez le nombre de SSID à un minimum absolu (idéalement pas plus de trois par point d'accès) pour réduire la surcharge de gestion.

Sécurité et conformité

L'exposition à la vie privée des sondes dirigées

Les requêtes de sondage dirigées posent un risque de sécurité unique. Parce qu'elles diffusent les noms des réseaux précédemment connectés (le PNL), un attaquant capturant ces trames peut établir un profil des mouvements d'un utilisateur (par exemple, identifier son réseau domestique, son employeur ou les cafés qu'il fréquente).

De plus, cela expose l'appareil aux attaques Evil Twin. Un attaquant peut déployer un point d'accès malveillant diffusant un SSID du PNL de la victime. L'appareil de la victime, reconnaissant le SSID familier dans sa réponse de sonde dirigée, peut s'associer automatiquement au point d'accès malveillant, exposant le trafic à l'interception.

Atténuation : La mise en œuvre de WPA3-Enterprise ou WPA3-Enhanced Open (OWE) atténue le risque d'interception post-association, mais l'hygiène réseau (les utilisateurs oubliant manuellement les réseaux publics) reste la principale défense contre l'exposition du PNL.

GDPR et intérêt légitime

En vertu du GDPR britannique et du GDPR de l'UE, la collecte d'adresses MAC – même hachées ou randomisées – peut constituer un traitement de données personnelles si elles peuvent être liées à un individu. Lors du déploiement d'analyses basées sur les sondes, les organisations doivent :

  • Établir une base légale claire (généralement l'intérêt légitime pour le comptage anonyme de la fréquentation, ou le consentement pour le marketing ciblé).
  • Mettre en place une signalisation visible informant les visiteurs que le balayage WiFi est en cours.
  • Fournir un mécanisme de désinscription clair.

La transition vers un modèle Guest WiFi authentifié simplifie la conformité, car le consentement explicite est recueilli pendant le processus d'intégration.

ROI et impact commercial

Comprendre et gérer les requêtes de sondage n'est pas un simple exercice technique ; cela a un impact direct sur les résultats.

  • Performance du réseau : Une atténuation adéquate des tempêtes de sondes garantit un débit élevé et une faible latence pour les utilisateurs connectés, influençant directement la satisfaction des clients et l'efficacité opérationnelle.
  • Analyses précises : La transition d'un suivi imparfait basé sur les sondes vers des couches d'identité authentifiées garantit que les équipes marketing et opérationnelles fondent leurs décisions sur des données fiables. Ceci est essentiel pour mesurer l'attribution des campagnes, optimiser les niveaux de personnel en fonction de la fréquentation réelle et générer des revenus grâce à un engagement ciblé.
  • Atténuation des risques : La gestion proactive des trames de gestion et le respect des réglementations en matière de confidentialité protègent l'organisation contre les amendes de conformité et les atteintes à la réputation.

En maîtrisant les mécanismes de découverte des appareils, les responsables informatiques peuvent concevoir des réseaux qui sont non seulement résilients et performants, mais qui servent également d'actifs fondamentaux pour l'intelligence d'entreprise. Pour plus d'informations sur le suivi basé sur la localisation, consultez Les mécanismes de l'orientation WiFi : Trilateration et RSSI expliqués .

Définitions clés

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.

Exemples concrets

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.
Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Questions d'entraînement

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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.