Saltar al contenido principal
Español

¿Qué es una solicitud de sondeo (Probe Request)? Entendiendo cómo los dispositivos descubren redes

Esta guía de referencia técnica ofrece un análisis en profundidad de las solicitudes de sondeo IEEE 802.11, el escaneo activo frente al pasivo y el impacto de la aleatorización de MAC en el análisis de ubicaciones. Proporciona estrategias de implementación prácticas para que los arquitectos de red optimicen las implementaciones de alta densidad, mitiguen las 'tormentas de sondeo' y garanticen una recopilación de datos precisa y compatible con GDPR utilizando capas de identidad autenticadas.

📖 6 min de lectura📝 1,416 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 8 definiciones clave

Escuchar esta guía

Ver transcripción del 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

Resumen Ejecutivo

Para los arquitectos de redes empresariales y los directores de operaciones de recintos, la solicitud de sondeo es el mecanismo fundamental para el descubrimiento de dispositivos inalámbricos. Es una trama de gestión de Capa 2 que dicta cómo los dispositivos no conectados identifican y se asocian con los puntos de acceso en entornos de Retail , Hostelería y Transporte . Sin embargo, el panorama del análisis basado en sondeos ha cambiado fundamentalmente. Con la implementación ubicua de la aleatorización de direcciones MAC en iOS y Android, el seguimiento de afluencia y la medición del tiempo de permanencia heredados que se basaban únicamente en datos de sondeo no autenticados ya no son viables ni conformes.

Esta guía desglosa la mecánica técnica del ciclo de solicitud y respuesta de sondeo, explora la distinción crítica entre el escaneo activo y pasivo, y detalla el impacto operativo de las 'tormentas de sondeo' en implementaciones de alta densidad. Más importante aún, proporciona una hoja de ruta estratégica para la transición del seguimiento basado en hardware a un análisis autenticado y basado en la identidad utilizando plataformas Guest WiFi y WiFi Analytics , asegurando un rendimiento de red robusto e inteligencia de negocio procesable.

Análisis Técnico Detallado: La Mecánica del Descubrimiento

La Máquina de Estados IEEE 802.11

Antes de que un dispositivo pueda transmitir tráfico IP, debe atravesar la máquina de estados de conexión 802.11: Descubrimiento, Autenticación y Asociación. La solicitud de sondeo opera exclusivamente en la fase de Descubrimiento. Se clasifica como una Trama de Gestión de Subtipo 4, transmitida por el dispositivo cliente (STA) para localizar Conjuntos de Servicios Básicos (BSS) disponibles.

Existen dos métodos principales de descubrimiento:

  1. Escaneo Pasivo: El dispositivo cliente sintoniza su radio a un canal específico y escucha las tramas Beacon transmitidas periódicamente (normalmente cada 100 ms) por el Punto de Acceso (AP). Este método conserva la vida útil de la batería pero aumenta la latencia del descubrimiento.
  2. Escaneo Activo: El dispositivo cliente transmite proactivamente tramas de Solicitud de Sondeo en varios canales y espera tramas de Respuesta de Sondeo de los AP. Esto acelera el descubrimiento pero consume tiempo de emisión y energía.

Solicitudes de Sondeo de Difusión vs. Dirigidas

El escaneo activo utiliza dos tipos distintos de solicitudes de sondeo:

  • Solicitud de Sondeo de Difusión (Comodín): El campo Service Set Identifier (SSID) se establece en nulo (longitud cero). El dispositivo está transmitiendo a cualquier AP dentro del alcance, preguntando eficazmente: "¿Quién está ahí fuera?". Todos los AP que reciban esta trama, siempre que no estén configurados para ocultar su SSID, responderán con una Respuesta de Sondeo.
  • Solicitud de Sondeo Dirigida: El campo SSID contiene un nombre de red específico. El dispositivo está consultando una red conocida de su Lista de Redes Preferidas (PNL). Solo los AP que alojen ese SSID específico responderán. Este mecanismo es crucial para los dispositivos que intentan conectarse automáticamente a redes ocultas.

probe_request_flow_diagram.png

Anatomía de una Trama de Solicitud de Sondeo

Una trama de solicitud de sondeo estándar contiene Elementos de Información (IEs) críticos que informan al AP sobre las capacidades del cliente. Los campos clave incluyen:

  • Cabecera MAC: Contiene el Control de Trama, Duración, Dirección de Destino (normalmente la dirección de difusión ff:ff:ff:ff:ff:ff), Dirección de Origen (la MAC del cliente) y BSSID.
  • SSID: El nombre de la red de destino (o nulo para difusión).
  • Tasas Soportadas: Define las tasas de datos básicas y operativas que el cliente soporta (por ejemplo, 1, 2, 5.5, 11 Mbps para 802.11b heredado, hasta tasas OFDM modernas).
  • Tasas Soportadas Extendidas: Tasas de datos adicionales soportadas por el cliente.
  • Capacidades HT/VHT/HE: Indica soporte para High Throughput (802.11n), Very High Throughput (802.11ac) o High Efficiency (802.11ax/WiFi 6), incluyendo flujos espaciales y anchos de canal.

Comprender estas capacidades es esencial para que los AP negocien los parámetros de conexión óptimos durante la fase de asociación posterior.

El Impacto de la Aleatorización de MAC

Históricamente, la Dirección de Origen en la solicitud de sondeo era la dirección MAC única global y grabada del dispositivo. Esta persistencia permitía a los operadores de recintos rastrear dispositivos no conectados, medir los tiempos de permanencia y construir mapas de calor de afluencia simplemente escuchando pasivamente las solicitudes de sondeo.

Sin embargo, las preocupaciones sobre la privacidad relacionadas con la difusión de identificadores persistentes llevaron a la implementación de la aleatorización de MAC. Introducidos en iOS 14 y Android 10, los sistemas operativos modernos ahora generan una dirección MAC aleatoria y administrada localmente al transmitir solicitudes de sondeo.

El Fin del Seguimiento No Autenticado

mac_randomisation_impact_chart.png

El impacto operativo es profundo:

  • Recuentos de Dispositivos Inflados: Un solo dispositivo puede generar múltiples direcciones MAC aleatorias con el tiempo, inflando artificialmente las métricas de visitantes únicos en los sistemas de análisis heredados.
  • Tiempo de Permanencia Roto: Rastrear el recorrido de un dispositivo por un recinto es imposible si su identificador cambia a mitad de la visita.
  • Pérdida de Datos de Visitantes Recurrentes: Sin un identificador persistente, distinguir un nuevo visitante de uno recurrente a través de los datos de sondeo es inviable.

La ISolución Basada en la Identidad

Para restaurar la precisión analítica, el paradigma de seguimiento debe pasar de los identificadores de hardware de Capa 2 a las identidades autenticadas de Capa 7. Al implementar un Captive Portal robusto o un flujo de incorporación sin interrupciones (como Cómo un asistente de WiFi habilita el acceso sin contraseña en 2026 ), los establecimientos capturan una identidad persistente y consentida (por ejemplo, correo electrónico, perfil social o ID de lealtad).

Una vez que un usuario se autentica, la plataforma Purple correlaciona la dirección MAC actual (incluso si está aleatorizada para ese SSID específico) con el perfil persistente del usuario. Esto asegura que las visitas y movimientos posteriores se rastreen con precisión contra la identidad autenticada, eludiendo por completo las limitaciones de la aleatorización de MAC. Este enfoque es fundamental para ejecutar las estrategias descritas en Cómo mejorar la satisfacción del cliente: el manual definitivo .

Guía de Implementación: Optimización para Alta Densidad

En entornos como estadios o grandes espacios comerciales, el gran volumen de solicitudes de sonda de miles de dispositivos puede degradar gravemente el rendimiento de la red. Este fenómeno, conocido como Tormenta de Sondas, consume un valioso tiempo de emisión, dejando menos capacidad para la transmisión de datos real.

Mitigación de Tormentas de Sondas

Los arquitectos de red deben implementar estrategias de configuración proactivas para gestionar la sobrecarga de tramas de gestión:

  1. Supresión de Respuesta de Sonda: Configure los AP para ignorar las solicitudes de sonda de difusión de dispositivos con un Indicador de Intensidad de Señal Recibida (RSSI) por debajo de un umbral específico (por ejemplo, -75 dBm). Si un dispositivo está demasiado lejos para establecer una conexión fiable, el AP no debe desperdiciar tiempo de emisión respondiendo a sus sondas.
  2. Deshabilitar Tasas de Datos Bajas: Al deshabilitar las tasas de datos heredadas (por ejemplo, 1, 2, 5.5, 11 Mbps) y establecer la tasa básica mínima obligatoria en 12 Mbps o 24 Mbps, las tramas de gestión (que se transmiten a la tasa básica más baja) consumen significativamente menos tiempo de emisión.
  3. Dirección de Banda: Dirija activamente a los clientes capaces a las bandas de 5 GHz o 6 GHz. La banda de 2.4 GHz tiene canales no superpuestos limitados y es altamente susceptible a la congestión por tormentas de sondas.
  4. Limitar SSIDs: Cada SSID emitido por un AP requiere su propio conjunto de tramas Beacon y Respuestas de Sonda. Restrinja el número de SSIDs a un mínimo absoluto (idealmente no más de tres por AP) para reducir la sobrecarga de gestión.

Seguridad y Cumplimiento

La Exposición a la Privacidad de las Sondas Dirigidas

Las solicitudes de sonda dirigidas plantean un riesgo de seguridad único. Debido a que transmiten los nombres de redes previamente conectadas (la PNL), un atacante que capture estas tramas puede construir un perfil de los movimientos de un usuario (por ejemplo, identificando su red doméstica, empleador o cafeterías frecuentadas).

Además, esto expone el dispositivo a ataques Evil Twin. Un atacante puede desplegar un AP malicioso que transmita un SSID de la PNL de la víctima. El dispositivo de la víctima, al reconocer el SSID familiar en su respuesta de sonda dirigida, puede asociarse automáticamente con el AP malicioso, exponiendo el tráfico a la interceptación.

Mitigación: La implementación de WPA3-Enterprise o WPA3-Enhanced Open (OWE) mitiga el riesgo de interceptación post-asociación, pero la higiene de la red (los usuarios que olvidan manualmente las redes públicas) sigue siendo la principal defensa contra la exposición de la PNL.

GDPR e Interés Legítimo

Según el UK GDPR y el EU GDPR, la recopilación de direcciones MAC —incluso si están cifradas o aleatorizadas— puede constituir un procesamiento de datos personales si se pueden vincular a un individuo. Al implementar análisis basados en sondas, las organizaciones deben:

  • Establecer una base legal clara (típicamente Interés Legítimo para el recuento de personas anonimizado, o Consentimiento para marketing dirigido).
  • Implementar señalización destacada informando a los visitantes que se está realizando un escaneo WiFi.
  • Proporcionar un mecanismo claro de exclusión voluntaria.

La transición a un modelo de Guest WiFi autenticado simplifica el cumplimiento, ya que el consentimiento explícito se captura durante el proceso de incorporación.

ROI e Impacto Empresarial

Comprender y gestionar las solicitudes de sonda no es meramente un ejercicio técnico; impacta directamente en los resultados.

  • Rendimiento de la Red: Una mitigación adecuada de la tormenta de sondas asegura un alto rendimiento y baja latencia para los usuarios conectados, influyendo directamente en la satisfacción del cliente y la eficiencia operativa.
  • Análisis Precisos: La transición del seguimiento basado en sondas defectuoso a capas de identidad autenticadas asegura que los equipos de marketing y operaciones basen sus decisiones en datos fiables. Esto es fundamental para medir la atribución de campañas, optimizar los niveles de personal basándose en el recuento de personas real y generar ingresos a través de un compromiso dirigido.
  • Mitigación de Riesgos: La gestión proactiva de las tramas de gestión y el cumplimiento de las normativas de privacidad protegen a la organización de multas por incumplimiento y daños a la reputación.

Al dominar la mecánica del descubrimiento de dispositivos, los líderes de TI pueden diseñar redes que no solo sean resilientes y de alto rendimiento, sino que también sirvan como activos fundamentales para la inteligencia empresarial. Para obtener más información sobre el seguimiento basado en la ubicación, consulte La mecánica de la orientación WiFi: trilateración y RSSI explicadas .

Definiciones clave

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.

Ejemplos prácticos

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.
Comentario del examinador: 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.

Comentario del examinador: 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.

Preguntas de práctica

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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?

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

Ver respuesta modelo

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.