Posted by Star | Posted in | Posted on 20:23
Durante estas últimas semanas este foro ha estado ha estado “animado”, también he recibido muchos mensajes privados acerca del comportamiento las redes WiFi protegidas (WEP/WPA) y me he dado cuenta , que si bien mas o menos todos conocemos “la práctica” de cómo atacar redes inalámbricas, la práctica totalidad de las preguntas que me habéis hecho se resuelven con un BUEN CONOCIMIENTO teórico de cómo es el comportamiento de las mismas.
Es decir, muchos de nosotros “ sabemos” usar herramientas del tipo aricrack-aireplay-airodump-etc--- pero pocos tienen claro por qué funcionan y por qué resulta (a veces sencillo, a veces no tanto) obtener una clave wep o wpa.
Por eso, he tirado de mis apuntes (aquellos con los que sufren mis queridos alumnos) y les he dado una aspecto algo informal, espero que el resultado sea bueno .
Voy a seguir la misma iniciativa de nuestro “ querido” Taller TCP/IP esperando que este nuevo se convierta en un Taller WiFi.
Este hilo permanecerá cerrado , los comentarios y dudas las resolveremos en otro (como en el Taller TCP/IP)
Si prestáis atención a todo lo que voy a ir comentado y cuando tengáis una duda repasáis los contenidos que vamos a esbozar seguro que además de “ usar” esas herramientas, comprenderéis cómo funcionan y cómo podemos modificarlas para realizar ataques “mas refinados” o por pura “curiosidad”
Deberíamos comenzar por la capa física, esto es, señales, antenas, bandas de radiofrecuencia, dispositivos, tarjetas…. Ufff, un sin fin de conceptos y conocimientos que (para lo que se trata en este momento) diremos que “ sobra”.
Por tanto, nos hemos de creer dos cosas para saltarnos la capa física de un plumazo:
Si entendemos bien la capa 2 en las comunicaciones inalámbricas, entenderemos, comprenderemos y seremos capaces de escenificar los ataques contra las vulnerabilidades en redes inalámbricas, incluidos los ataques a cifrados y otros como la denegación de servicios, hombre en medio, despliegue de puntos de acceso ilícitos o reinyección de tráfico en la red.
El tráfico en la capa 2 se le llama tramas (frames en inglés) no es que sea muy importante saber el nombrecito… pero mejor llamar a cada cosa por su nombre.
Un Punto de Acceso tiene:
Es importante señalar que la forma de comunicarse en redes inalámbricas (WiFi) está estandarizado, de ahí tenemos el archiconocidos 802.11, junto con sus “variantes” a,b,c,d,e,g,h,i,n etc… cuando encontremos documentos o información relativa a 802.11b u 802.11e, etc debemos de asumir que la comunicación está “ordenada”, “regulada”, “estandarizada”, “definida” mediante esos estándares.
No obstante, existen fabricantes que además de “soportar” el estándar , también implementan cambios y modificaciones de “cosecha propia”, es decir, pequeñas o grandes variaciones sobre el protocolo de comunicaciones que dicho fabricante añade.
Ni que decir tiene, que esos “añadidos” al ser particulares de un determinado fabricante, podrán sólo usarse entre equipamientos del mismo fabricante.
Esos añadidos (que a la postre deberían convertirse en mejoras) pueden ser un obstáculo cuando entran en escena otro hardware de diferente fabricante, sin embargo, y a menos que el administrador de la red inalámbrica así lo decida, siempre serán compatibles con los estandarizados.
Está muy claro, pero con un ejemplo quedará todo cristalino (si es que hay algo que aclarar):
Aunque son documentos “muy técnicos” (y de eso precisamente quiero huir en esta explicación) quien lo desee puede consultar libremente los modelos para 802.11, 802.11a, 802.11b, …. En:: http://standards.ieee.org/getieee802/
Después de esta breve introducción vamos a desmenuzar cómo es una trama de datos en 802.11.
Explicamos (de derecha a izquierda)
FCS es un campo de 4 bytes que se añade como control de Secuencia, no debemos preocuparnos de ello por ahora.
Cuerpo. Es el contenido de la comunicación (los datos a transmitir), si no usamos seguridad alguna lo podremos ver “en texto plano” como si tal cosa, si es un icmp, un intercambio TCP, etc… Si está cifrado mediante WEP o WPA pues “de momento” no tiene sentido lo que “vemos”.
Cabecera MAC: Lo primero que nos llama la atención es que su tamaño “puede variar”.
Variar? Por qué?
Porque dependiendo del tipo de mensaje y de otras funcionalidades (por ejemplo si se utiliza QoS o no) puede ser de un tamaño u otro, lo que siempre existe en la cabecera MAC es esto:
Y cuando son 26 ó 30 ó 32??
Cuando concurra alguna de estas circunstancias:
Si la comunicación es "entre” puntos de acceso, se añade una cuarta dirección MAC (la del otro punto de acceso) inmediatamente después del número de secuencia, como ya sabemos una dirección MAC tiene 6 bytes.
Por eso podemos tener cabeceras MAC de varias “longitudes”, por ejemplo:
24 bytes -> Comunicación entre cliente y punto de acceso, sin QoS
26 Bytes -> Comunicación entre cliente y punto de acceso, con QoS
30 bytes -> Comunicación entre puntos de acceso, sin QoS
32 bytes -> Comunicación entre puntos de acceso, con QoS
También hay que hacer una salvedad en cuanto a las 3 direcciones MAC que hablaba… en el ejemplo puse origen-destino-bssid, no es así realmente…. Todo dependerá de si se trata de una trama de administración, de datos o de la dirección del tráfico.
Es decir, la dirección MAC1 (los bytes 4-5-6-7-8-9-10) pueden representar el bssid, la dirección MAC origen e incluso la dirección MAC destino. Lo mismo ocurre con las otras dos direcciones MAC, MAC2 y MAC3.
Todavía es pronto para “comprender” bien este “baile” de direcciones MAC, de momento nos quedamos que MAC1, MAC2 y MAC3 representan las direcciones origen, destino y bssid de la comunicación PERO NO PRECISAMENTE Y SIEMPRE EN ESE ORDEN!!!!!
Llegados a este punto, Cómo se sabe si se trata de una trama de control, de administración o de datos???
Por los dos primeros bytes de la cabecera MAC, esto es, el FC o Frame Control
Al ser un campo de dos bytes contiene 16 bits de información correspondiente al tipo de trama, al subtipo, a si la comunicación ve “hacia” el punto de acceso, si va “hacia” el cliente, si está fragmentada, si hay mas datos, si se trata de una trama retransmitida, y otros… como si los datos van o no cifrados, si se utiliza “power management” (administración de energía)….
Tenemos que leer esos bits de derecha a izquierda, por ejemplo, supongamos que el campo frame control contiene el valor 08 41 en hexadecimal… en binario son:
Los interpretaremos de “derecha a izquierda” y por parejas, esto es, leemos los bits de derecha a izquierda:
08 = 0000 1000
41 = 0100 0001
Observa que los bits están “rotados” de forma que el “mas significativo” es el que está mas a la izquierda, vamos que no hay que interpretarlo (según el ejemplo) así:
Ahora pasemos a explicar cada campo (al menos los mas significativos)
Versión del Protocolo: bit 0 y 1
Serán siempre cero. Otros valores significarán que no se corresponde con el estándar (por ejemplo una versión propia de un fabricante)
Tipo de Trama (bits 2 y 3)
Identifican el tipo de trama, es decir, si es de administración, de control o de datos.
Subtipo (bits 4,5,6 y 7)
Es una descripción mas detallada del tipo.
ToDS (bit 8 )
Este bit está a uno cuando la trama viaja hacia el sistema de distribución, por ejemplo si la trama la envía un punto de acceso a otro punto de acceso o si una estación envía la trama al punto de acceso.
FromDS (bit 9)
Este bit está a uno si la trama viaja desde el sistema de distribución, por ejemplo cuando un punto de acceso envía tramas a las estaciones. También está a uno cuando la trama viaja de un punto de acceso a otro.
WEP (bit 14)
Este bit se activa (a uno) si los datos están cifrados, en caso contrario los datos viajan en texto plano.
El resto de bits (por ahora) no tienen mucho significado en esta explicación, eso sí, conviene aclarar o ampliar los valores de tipo, subtipo, ToDS y FromDS, unas tablas ayudarán a ello.
Seguro que sino estás pensando que esto es un rollo, al menos pensarás que de momento es fácil… vamos a plantear tres preguntas (con trampa, claro, de lo contrario no tiene gracia)
1.- Según lo expuesto…. Si nos encontramos con una trama y los bits 8 y 9 de FC están a cero… ¿podemos asegurar que se trata de una comunicación ad-hoc?
R: Si consultamos la tabla que os puse antes, es tajante la respuesta es SI. Pero no es oro todo lo que reluce… La respuesta correcta es NO.
Si bit 8 y bit 9 son cero, efectivamente puede ser una comunicación ad-hoc siempre y cuando la trama sea de DATOS!!!
Si, por ejemplo, la trama es de administración (por ejemplo un beacon o señalización) bit 8 y bit 9 son cero y por supuesto… no es una comunicación entre estaciones.
2.- Otra… Es posible encontrarnos con una trama en la que la cabecera MAC tiene menos de 24 bytes???
R: Al igual que antes, si repasamos lo dicho, la respuesta es NO, puesto que len la cabecera MAC exite un FC de 2 bytes, una duración de 2 bytes. al menos 3 direcciones MAC de 6 bytes cada una (18 en total) y un número de secuencia/fragmento de otros 2 bytes, o sea, un mínimo de 24 bytes… pero la respuesta correcta debería haber sido SI!!!!
SI, por ejemplo una trama de control con subtipo Clear-to-Send (permitido para transmitir) tiene únicamente una longitud de 10 bytes: 2 para FC, 2 para la duración y 6 para la MAC del punto de acceso quien la envía.
3.- Al analizar una trama descubrimos que el bit 14 (Wep) está activado… ¿Es realmente una trama cifrada con WEP?
R: NO. Ciertamente los datos (el cuerpo de la trama) estarán cifrados, pero no tiene que ser obligatoriamente con WEP. Bien puede ser WPA o WPA2, este bit indica que los datos están protegidos, pero no te dejes engañar por el nombre del campo, el bit wep a uno indica cifrado, pero no necesariamente un cifrado WEP.
Estas tres preguntas aunque no te lo parezca por ahora, son importantes… Primero porque si nos decidimos a lanzar “un ataque” contra una red WiFi, dependiendo de lo que queramos conseguir habrá que realizarlo sobre tramas de datos, administración o control y en el caso de atacar un cifrado, pues contra el mismo…
Ahora que ya somos capaces de “ identificar” los diferentes tipos de tramas, vamos a representar “la coreografía” de cómo funciona todo el mecanismo:
Primero conocer los “estados” en los que nos podemos encontrar:
Un cliente puede estar:
Como ves en la figura, un cliente asociado puede dejar de estarlo y permanecer autenticado.
Normalmente son los puntos de acceso quienes envían tramas de disociación y des-autenticación.
Son los clientes (las estaciones) los que envían tramas de autenticación, asociación y/o reasociación, también de disociación cuando abandona la red.
La reasociación es un caso especial, es aquel en el que una estación estaba asociada y recibió una trama de disociación… entonces queda en estado autenticado y reinicia la asociación mediante una solicitud de reasociación.
Resumiendo:
Un cliente asociado (completó todo el proceso de incorporación a la red) puede ser desasociado o des-autenticado por el punto de acceso
Un cliente autenticado puede ser des-autenticado por el punto de acceso.
Un cliente que fue desautenticado podrá solicitar una reasociación
Un cliente no asociado ni autenticado, primero solicitará autenticación y luego asociación.
Un cliente autenticado solicitará asociación o reasociación dependiendo del estado anterior al momento de la autenticación.
Por supuesto que un cliente también puede abandonar la red sin necesidad que sea el punto de acceso quien lo haga, a los efectos, sería igual que lo descrito anteriormente.
Es decir, muchos de nosotros “ sabemos” usar herramientas del tipo aricrack-aireplay-airodump-etc--- pero pocos tienen claro por qué funcionan y por qué resulta (a veces sencillo, a veces no tanto) obtener una clave wep o wpa.
Por eso, he tirado de mis apuntes (aquellos con los que sufren mis queridos alumnos) y les he dado una aspecto algo informal, espero que el resultado sea bueno .
Voy a seguir la misma iniciativa de nuestro “ querido” Taller TCP/IP esperando que este nuevo se convierta en un Taller WiFi.
Este hilo permanecerá cerrado , los comentarios y dudas las resolveremos en otro (como en el Taller TCP/IP)
Si prestáis atención a todo lo que voy a ir comentado y cuando tengáis una duda repasáis los contenidos que vamos a esbozar seguro que además de “ usar” esas herramientas, comprenderéis cómo funcionan y cómo podemos modificarlas para realizar ataques “mas refinados” o por pura “curiosidad”
Deberíamos comenzar por la capa física, esto es, señales, antenas, bandas de radiofrecuencia, dispositivos, tarjetas…. Ufff, un sin fin de conceptos y conocimientos que (para lo que se trata en este momento) diremos que “ sobra”.
Por tanto, nos hemos de creer dos cosas para saltarnos la capa física de un plumazo:
- 1.- Un Punto de Acceso es un aparato que permite conectar estaciones inalámbricas entre sí o incluso estaciones inalámbricas con estaciones por cable.
También un Punto de acceso puede comunicarse con otros puntos de acceso extendiendo la zona inalámbrica o creando un perímetro inalámbrico mas grande, es lo que se conoce con el nombre de WDS.
2.- Una estación inalámbrica es un dispositivo que puede comunicarse con un punto de acceso y por consiguiente, con el resto de estaciones inalámbricas o con estaciones con cable.
También una estación inalámbrica puede comunicarse directamente con otra sin necesidad de punto de acceso, es lo que conocemos como comunicación ad-hoc.
Si entendemos bien la capa 2 en las comunicaciones inalámbricas, entenderemos, comprenderemos y seremos capaces de escenificar los ataques contra las vulnerabilidades en redes inalámbricas, incluidos los ataques a cifrados y otros como la denegación de servicios, hombre en medio, despliegue de puntos de acceso ilícitos o reinyección de tráfico en la red.
El tráfico en la capa 2 se le llama tramas (frames en inglés) no es que sea muy importante saber el nombrecito… pero mejor llamar a cada cosa por su nombre.
Un Punto de Acceso tiene:
- • Un nombre al que llamamos SSID (o essid)
• Una Dirección MAC que llamamos BSSID
• Un modo de distribución: Infraestructura, Repetidor, Cliente y algún otro mas.
• Seguridad y/o cifrado: WEP, WAP, WPA2, sin seguridad (OPEN)
• Clientes: Las estaciones inalámbricas que se conectan a ellos
• Enrutamiento: Capa2 y también los hay de Capa3 (no todos)
• Una fuerza de la señal aplicada a cada paquete
• Un alcance que depende de factores como la antena, el entorno, obstáculos, etc.
- • Tramas de Administración: Beacons, Probes y Request
• Tramas de Datos: Cifrados o en “texto plano”
• Tramas de Control: RTS, ACK’s y CTS
Es importante señalar que la forma de comunicarse en redes inalámbricas (WiFi) está estandarizado, de ahí tenemos el archiconocidos 802.11, junto con sus “variantes” a,b,c,d,e,g,h,i,n etc… cuando encontremos documentos o información relativa a 802.11b u 802.11e, etc debemos de asumir que la comunicación está “ordenada”, “regulada”, “estandarizada”, “definida” mediante esos estándares.
No obstante, existen fabricantes que además de “soportar” el estándar , también implementan cambios y modificaciones de “cosecha propia”, es decir, pequeñas o grandes variaciones sobre el protocolo de comunicaciones que dicho fabricante añade.
Ni que decir tiene, que esos “añadidos” al ser particulares de un determinado fabricante, podrán sólo usarse entre equipamientos del mismo fabricante.
Esos añadidos (que a la postre deberían convertirse en mejoras) pueden ser un obstáculo cuando entran en escena otro hardware de diferente fabricante, sin embargo, y a menos que el administrador de la red inalámbrica así lo decida, siempre serán compatibles con los estandarizados.
Está muy claro, pero con un ejemplo quedará todo cristalino (si es que hay algo que aclarar):
- Ya es conocido que existe un tipo de tramas “especial” que al enviarlas de forma “mal intencionada” los clientes que están asociados a un punto de acceso se “desconectan” del mismo, es lo que llamamos disociación.
¿Por qué es esto posible? Porque las tramas del tipo disociación que un punto de acceso envía a un cliente o a todos no están protegidas ni cifradas de forma alguna. Esto ocurre siempre, tanto si usamos WEP-WPA como si no.
CISCO, incorpora un “añadido” especial a este tipo de tramas… el llamado CCX que no es otra cosa que un control de integridad de las tramas de disociación (y no sólo de ellas) de forma que el ataque de disociación no sería efectivo.
Aunque son documentos “muy técnicos” (y de eso precisamente quiero huir en esta explicación) quien lo desee puede consultar libremente los modelos para 802.11, 802.11a, 802.11b, …. En:: http://standards.ieee.org/getieee802/
Después de esta breve introducción vamos a desmenuzar cómo es una trama de datos en 802.11.
Explicamos (de derecha a izquierda)
FCS es un campo de 4 bytes que se añade como control de Secuencia, no debemos preocuparnos de ello por ahora.
Cuerpo. Es el contenido de la comunicación (los datos a transmitir), si no usamos seguridad alguna lo podremos ver “en texto plano” como si tal cosa, si es un icmp, un intercambio TCP, etc… Si está cifrado mediante WEP o WPA pues “de momento” no tiene sentido lo que “vemos”.
Cabecera MAC: Lo primero que nos llama la atención es que su tamaño “puede variar”.
Variar? Por qué?
Porque dependiendo del tipo de mensaje y de otras funcionalidades (por ejemplo si se utiliza QoS o no) puede ser de un tamaño u otro, lo que siempre existe en la cabecera MAC es esto:
Y cuando son 26 ó 30 ó 32??
Cuando concurra alguna de estas circunstancias:
- * QoS (Calidad de Servicio) protocolo 802.11e está habilitado
* La comunicación se realiza entre puntos de acceso.
Si la comunicación es "entre” puntos de acceso, se añade una cuarta dirección MAC (la del otro punto de acceso) inmediatamente después del número de secuencia, como ya sabemos una dirección MAC tiene 6 bytes.
Por eso podemos tener cabeceras MAC de varias “longitudes”, por ejemplo:
24 bytes -> Comunicación entre cliente y punto de acceso, sin QoS
26 Bytes -> Comunicación entre cliente y punto de acceso, con QoS
30 bytes -> Comunicación entre puntos de acceso, sin QoS
32 bytes -> Comunicación entre puntos de acceso, con QoS
También hay que hacer una salvedad en cuanto a las 3 direcciones MAC que hablaba… en el ejemplo puse origen-destino-bssid, no es así realmente…. Todo dependerá de si se trata de una trama de administración, de datos o de la dirección del tráfico.
Es decir, la dirección MAC1 (los bytes 4-5-6-7-8-9-10) pueden representar el bssid, la dirección MAC origen e incluso la dirección MAC destino. Lo mismo ocurre con las otras dos direcciones MAC, MAC2 y MAC3.
Todavía es pronto para “comprender” bien este “baile” de direcciones MAC, de momento nos quedamos que MAC1, MAC2 y MAC3 representan las direcciones origen, destino y bssid de la comunicación PERO NO PRECISAMENTE Y SIEMPRE EN ESE ORDEN!!!!!
Llegados a este punto, Cómo se sabe si se trata de una trama de control, de administración o de datos???
Por los dos primeros bytes de la cabecera MAC, esto es, el FC o Frame Control
Al ser un campo de dos bytes contiene 16 bits de información correspondiente al tipo de trama, al subtipo, a si la comunicación ve “hacia” el punto de acceso, si va “hacia” el cliente, si está fragmentada, si hay mas datos, si se trata de una trama retransmitida, y otros… como si los datos van o no cifrados, si se utiliza “power management” (administración de energía)….
Tenemos que leer esos bits de derecha a izquierda, por ejemplo, supongamos que el campo frame control contiene el valor 08 41 en hexadecimal… en binario son:
Los interpretaremos de “derecha a izquierda” y por parejas, esto es, leemos los bits de derecha a izquierda:
08 = 0000 1000
41 = 0100 0001
Observa que los bits están “rotados” de forma que el “mas significativo” es el que está mas a la izquierda, vamos que no hay que interpretarlo (según el ejemplo) así:
Ahora pasemos a explicar cada campo (al menos los mas significativos)
Versión del Protocolo: bit 0 y 1
Serán siempre cero. Otros valores significarán que no se corresponde con el estándar (por ejemplo una versión propia de un fabricante)
Tipo de Trama (bits 2 y 3)
Identifican el tipo de trama, es decir, si es de administración, de control o de datos.
Subtipo (bits 4,5,6 y 7)
Es una descripción mas detallada del tipo.
ToDS (bit 8 )
Este bit está a uno cuando la trama viaja hacia el sistema de distribución, por ejemplo si la trama la envía un punto de acceso a otro punto de acceso o si una estación envía la trama al punto de acceso.
FromDS (bit 9)
Este bit está a uno si la trama viaja desde el sistema de distribución, por ejemplo cuando un punto de acceso envía tramas a las estaciones. También está a uno cuando la trama viaja de un punto de acceso a otro.
WEP (bit 14)
Este bit se activa (a uno) si los datos están cifrados, en caso contrario los datos viajan en texto plano.
El resto de bits (por ahora) no tienen mucho significado en esta explicación, eso sí, conviene aclarar o ampliar los valores de tipo, subtipo, ToDS y FromDS, unas tablas ayudarán a ello.
Seguro que sino estás pensando que esto es un rollo, al menos pensarás que de momento es fácil… vamos a plantear tres preguntas (con trampa, claro, de lo contrario no tiene gracia)
1.- Según lo expuesto…. Si nos encontramos con una trama y los bits 8 y 9 de FC están a cero… ¿podemos asegurar que se trata de una comunicación ad-hoc?
R: Si consultamos la tabla que os puse antes, es tajante la respuesta es SI. Pero no es oro todo lo que reluce… La respuesta correcta es NO.
Si bit 8 y bit 9 son cero, efectivamente puede ser una comunicación ad-hoc siempre y cuando la trama sea de DATOS!!!
Si, por ejemplo, la trama es de administración (por ejemplo un beacon o señalización) bit 8 y bit 9 son cero y por supuesto… no es una comunicación entre estaciones.
2.- Otra… Es posible encontrarnos con una trama en la que la cabecera MAC tiene menos de 24 bytes???
R: Al igual que antes, si repasamos lo dicho, la respuesta es NO, puesto que len la cabecera MAC exite un FC de 2 bytes, una duración de 2 bytes. al menos 3 direcciones MAC de 6 bytes cada una (18 en total) y un número de secuencia/fragmento de otros 2 bytes, o sea, un mínimo de 24 bytes… pero la respuesta correcta debería haber sido SI!!!!
SI, por ejemplo una trama de control con subtipo Clear-to-Send (permitido para transmitir) tiene únicamente una longitud de 10 bytes: 2 para FC, 2 para la duración y 6 para la MAC del punto de acceso quien la envía.
3.- Al analizar una trama descubrimos que el bit 14 (Wep) está activado… ¿Es realmente una trama cifrada con WEP?
R: NO. Ciertamente los datos (el cuerpo de la trama) estarán cifrados, pero no tiene que ser obligatoriamente con WEP. Bien puede ser WPA o WPA2, este bit indica que los datos están protegidos, pero no te dejes engañar por el nombre del campo, el bit wep a uno indica cifrado, pero no necesariamente un cifrado WEP.
Estas tres preguntas aunque no te lo parezca por ahora, son importantes… Primero porque si nos decidimos a lanzar “un ataque” contra una red WiFi, dependiendo de lo que queramos conseguir habrá que realizarlo sobre tramas de datos, administración o control y en el caso de atacar un cifrado, pues contra el mismo…
Ahora que ya somos capaces de “ identificar” los diferentes tipos de tramas, vamos a representar “la coreografía” de cómo funciona todo el mecanismo:
Primero conocer los “estados” en los que nos podemos encontrar:
Un cliente puede estar:
- • No asociado ni autenticasdo: Es decir, ni tan siquiera intentó “conectarse” a la red inalámbrica
• Autenticado: El cliente desea participar de la red pero todavía no finalizó la asociación por completo.
• Asociado: El cliente se asoció y al proporcionar una clave correcta “disfruta” de los recursos de la red.
Como ves en la figura, un cliente asociado puede dejar de estarlo y permanecer autenticado.
Normalmente son los puntos de acceso quienes envían tramas de disociación y des-autenticación.
Son los clientes (las estaciones) los que envían tramas de autenticación, asociación y/o reasociación, también de disociación cuando abandona la red.
La reasociación es un caso especial, es aquel en el que una estación estaba asociada y recibió una trama de disociación… entonces queda en estado autenticado y reinicia la asociación mediante una solicitud de reasociación.
Resumiendo:
Un cliente asociado (completó todo el proceso de incorporación a la red) puede ser desasociado o des-autenticado por el punto de acceso
Un cliente autenticado puede ser des-autenticado por el punto de acceso.
Un cliente que fue desautenticado podrá solicitar una reasociación
Un cliente no asociado ni autenticado, primero solicitará autenticación y luego asociación.
Un cliente autenticado solicitará asociación o reasociación dependiendo del estado anterior al momento de la autenticación.
Por supuesto que un cliente también puede abandonar la red sin necesidad que sea el punto de acceso quien lo haga, a los efectos, sería igual que lo descrito anteriormente.
Comments (0)
Publicar un comentario