Modulación , codificación y cálculo del bitrate.

La idea que principal de las redes inalámbricas es pode trasmitir los datos generados o almacenados en una aplicación de un dispositivo a otro dispositivo remoto. La trasmisión de estos datos ha de ser lo más rápido posible y al ser un medio compartido que donde pueden haber interferencias, se ha de integrar algunos mecanismo que permitan recuperar los datos en caso de que parte en algún de la emisión éstos se hayas visto corrompido. 

Hemos de tener en cuenta que los datos normalmente son representados por bits (unos y ceros), pero las redes inalámbricas trabaja por señales analógicas representadas por ondas. Es por eso que para poder cumplir todo lo mencionado anteriormente, se hace meter en el juego lo que se denomina modulación y codificación.

Si nos centramos en la modulación podríamos decir que consiste en representar mediante ondas cada bits de datos que se ha de propagar de un dispositivo a otro por el aire. Las cualidades que se utilizan para modificar las ondas son las siguientes:

• Amplitud: es la fuerza con la que se emite la señal en función de si la potencia sigue constante podemos decir que el valor del bit es 0 y cuando hay cambio en la amplitud quiere decir que se envía un 1. En OFDM por ejemplo se utilizan varios intervalos de amplitud para poder representar múltiples bits.

• Fase: se utiliza en comparación con otra onda. Si la fase es la misma, esta en fase y la potencia se duplica. En cambio si están desfasado 180º la señal se suprime. Si en un momento de la señalización la fase cambia, el valor cambia, en caso contrario el valor se mantiene.

Los tipos de modulación se pueden usar de forma simultánea para poder trasmitir más bits.

Al total de bits que se permite enviar mediante los diferentes tipos de modulación se le denomina Symbols = #waveform

Mientras mas datos que queramos enviar en un determinado espacio de tiempo, más cambios en las ondas se han de poder realizar. De manera que si por ejemplo una onda permite 4 formas distintas (ya sea en cambio de fase o de amplitud) podríamos llegar a representar 16 bits. La función para saber el numero de bit en una waveform se puede obtener mediante la operación 2^x.

Ej. Si elevamos 2 a la 8 (8 formas diferentes de onda) podemos llegar a representar 256 bits.

A la cantidad de bits que se pueden representar con una waveform se le denomina "symbol"

Mientras más datos se quiere enviar más compleja debe ser la modulación y mejor la calidad de la señal. A continuación hay una captura de la constelación usada por OFDM de 64 QAM (modula modificando la fase y la amplitud simultáneamente) donde se detalla la cantidad de símbolos que se pueden combinar. Como podemos ver cada símbolo esta representado por 6 bits

A partir de este punto interviene el "Data Encoding"

Data Encoding: es el proceso que usado para convertir los datos que provienen de la aplicación en ondas de radio (waveform) para poder ser enviadas por el aire y ser descodificadas en el destino. El mecanismo que se utiliza es la modulación.

Como hemos comentado también recomendable disponer de un mecanismo para poder recuperar estos bit que se envían en caso que la señal se pueda ver afectada por alguna interferencia. Aquí entra en acción un elemento denominado Convultional Coding. Este mecanismo permite corregir errores antes de que la trama pase por el proceso de CRC y sea descartado si hay algún error. Para ello se introduce bits adicionales para poder hacer esa corrección de errores. Estos bits de añaden desde el inicio de la trasmisión y el proceso de corrección se denomina Forward Error Correction (FEC). El "coding rate" especifica del total de bits enviados representan datos útiles y el número de bits que se utilizan para recuperación de datos en caso de interferencias. En ratio se representa en forma de fracción como por ejemplo 2/3. En este ejemplo la interpretación sería que de cada 3 bits enviado sólo hay dos bits que representan datos útiles y 1 más para recuperación de datos en caso de corrupción de la señal. Mientras mas bits utilizados para la corrección de datos, menor es el data rate que se consigue.

Como hemos comentado, cuando trasmitimos mediante Wifi usamos Coding Rate para recuperar datos en caso de interferencia. Por lo que si queremos trasmitir 12000 bit el tamaño final del paquete aumenta para aplicar la codificación. En 2/3 aumentaría a 18000.

En OFDM tenemos 48 subportadoras de datos. Si modulamos en 64-QAM permitimos enviar 6 bit por símbolo. 6 bit x 48 subcarrier = 288 bit/sim . 

Para poder trasmitir los 18 000 bits necesitaríamos 63 símbolos (18000/288).

En OFDM la trasmisión de un símbolo dura 3.2 µ . Una vez realizada la trasmisión el receptor ha de esperar un tiempo antes de volver a trasmitir el siguiente símbolo para permitir que la trama anterior llegue al destino y las trasmisiones no se solapen. A este intervalo de tiempo se le denomina "Guard Interval". Existen dos intervalos, el "Short Guard Interval" SGI que tiene una duración de 0.4 microsegundos o el "Long Guard Interval" LGI que tiene una duración de 0.8 microsegundos

Si usamos LGI necesitaríamos  para trasmitir cada símbolo. En total para trasmitir los 18000 bits necesitaríamos 252 µs (63 símbolos * 4µs para trasmitir cada símbolo)

Los anchos de banda conseguidos en función del ratio de codificación se puede consulta en la tabla de MCS index. Ahí aparecen todos los valores en función de la tecnología PHY usada y amplitudes de canal.

https://mcsindex.com/

Un elemento que influye a la hora de decidir que modulación utilizada es el SNR. Mientras mas bajo es el SNR menor es el coding rate y menos bits de datos útiles se envían, pero más tolerante a corrección de errores.

Visto todo lo anterior solo quedaría un punto. ¿Cómo se calcula el data rate que aparece asociado a cada modulación?

Recordemos que OFDM cuando se modula para 802.11n y 80211ac dispone de 52 subportadoras para el envío de datos. Recordemos que cada símbolo se trasmite en 3.2µs + 0.8µs de LGI. Para obtener las transmisiones que se realizan en un µs se ha de dividir las 52 subportadoras entre 4 µs, lo que nos da un total de 13 transmisiones cada µs. Si lo pasamos a segundos, 1µs = 1.0E-6 s

13 trans/1.0E-6 s= 13*10E6 = 13000000 trans/seg (13M trans/seg)

Vamos a ver como calcularíamos el data rate para 256-QAM. Esta modulación permite enviar 8 bit por símbolo. Si tomamos como referencia un coding rate de 2/3 con LGI, tendríamos que multiplicar los 13.000 retrasmisiones que se hacen por segundo por los 8 bit que se envían por trasmisión lo que nos.

13M Tras/seg * 8bit/1 Trans = 104 Mbps

Si usamos usamos un coding rate de 3/4 nos queda los siguiente:

104 Mbps * 3/4= 78 Mbps

Si usamos SGI  tenemos que el numero de trasmisión por segundo es 14.4 (52/(3.2µs+04µs)

14.4M Tras/seg * 8 bit/1tra = 115 Mbps

Si usamos usamos un coding rate de 3/4 nos queda los siguiente:

115 Mbps * 3/4 = 86.2

Analizando Fast-roaming 802.11r

Las redes inalámbricas se crearon para para poder proporcionar conectividad de red a aquellos a los que no es posible llegar a mediante cable de red y para proporcionar conectividad a aquellos dispositivos que necesitan movilidad. Pero que ocurre cuanta un dispositivo se mueve? A medida que se aleja a del AP al que está conectado empieza a disminuir la potencia de la señal, la velocidad de conexión disminuye en cierto momento ha de empezar a escanear la red para ver si en su entorno encuentra otros APs emitiendo el mismo SSID al que poder conectarse.

El proceso de cambio de un AP a otro al inicio de los tiempos ocurría de la siguiente manera. El AP hace proceso de asociación al AP pasando por las etapas que se describen a continuación en funcion de si la autenticación es por preshared key o lo hace con WPA enterprise mediante 802.1X

A medida que el cliente se mueve y va la señal se va debilitando, se van produciendo retransmisiones y varios factores más, el cliente empieza a trasmitir probe request para sondear el entorno y detectar nuevos APs alrededor. Cuando el cliente determina que que hay otra AP mejor (según la programación del driver de la tarjeta de red del dispositivo) se intenta asociar al nuevo AP pasando de nuevo por todo el proceso anteriormente comentado. 

Este proceso es disruptivo ya que por un lado el cliente ha de ir cambiando el canal de la tarjeta de red para descubrir y posteriormente vuelve a haber una desconexión mientras se vuelve a hacer el proceso de autenticación. A continuación vemos como sería el proceso en wireshark. En la captura podemos ver los ACK correspondientes omitidos en el diagrama anterior.

Proceso de autenticación con WPA2-PSK

Como funciona 802.11r?

Cuando un cliente se mueve de un AP a otro AP con fast secure roaming, se intenta reducir el número de paquetes que se intercambian entre el cliente y los APs en el proceso de asociación.

Recordemos que para poder encriptado y desencrptar las tramas debemos disponer de una PTK, ésta viene derivada de una PMK que a su vez se crea gracias a una MSK. La MSK es igual al preshared key con WPA-2 PSK o se obtiene del proceso de EAP cuándo se trata de WPA empresarial.

Para realizar el proceso de roaming necesitamos generar dos PTK, una para cada uno de los APs a los que el cliente se vaya a conectar. Para conseguir esto el procedimiento es el siguiente. Cuando el cliente se asocia con el AP se genera la PMK y ademas se generan dos nuevas claves la PMKR-0 y la PMKR-1. La PMKR-1 se usara para generar la PTK (la clave que permite encriptar y desencrptar las tramas).La PMKR-0 se utilizará para generar las siguientes PMKR-1 en el resto de APs y se almacena la controladoras o en algún punto al que el AP pueda tener acceso. El dispositivo que va a hacer el roaming al nuevo AP ha de proporcionarle información a éste para que sepa llegar al dispositivo donde reside la PMKR-0 y generar la PMKR-1 con la que podrá generar posteriormente la PTK sin necesidad de pasar por el 4 Ways Handshake.

Existen dos formas de pasar esta información:

Over the DS. Como su nombre indica el AP se encarga de enviar esta información mediante la red cableado a los otros APs

Over the AIR en este caso es el cliente quien pasa la información al AP al que quiere hacer romain durante el proceso de autenticación.  

Para saber cual de los dos métodos se está usando lo podemos consultar en el elemento Mobility Domain si el valor del campo es 1 es Over DS si es 0 es over the AIR:

El proceso es el siguiguiente:

En los pasos 1 y 2 es el proceso de asociación inicial. Los pasos se han detallado anteriormente. El proceso de roaming comienza en el paso 3. El cliente envía un FT-Auth. Contine información sobre la ubicación de PMKR-0 y el SNOUNCE. 4. El AP responde con otro FT-Auth con informacion de los NOUNCES.

En este punto el AP tienen los elementos necesarios para encriptar y desencriptar el tráfico (SNOUNCE, ANOUNCE, Source Address, Dest. Address, PMKR-1)

5. El cliente envia un Reasociat. Req.

6 El AP envia un Reassoc. Resp.con la clave GTK para poder desencriptar el trafico broadcast y multicast.

En el campo RSN hay un elemento denominado AKM que define el tipo de fast transition.

• 3 = FT over 802.1x
• 4 = FT over PSK, 
• 9 = FT over WPA3 personal, 
• 3 = FT over WPA3 Enterprise.

Como podemos ver de conexión cuando se realiza roaming se reduce bastante.

Una forma de verificar si 802.11r esta habilitado es revisando si el  elemento mobility domain está habilitado.

Sin 802.11r

Con 802.11r activado

La información sobre el mobility domain apace en las siguientes tramas:

• Beacon
• Probe Req
• Prob Res, Auth
• (Re)Assoc.Req
• (Re)Assc. Resp

El otro campo que también proporciona es el Fast Transition Info Element (FTIE)

ID:55 

Leng: 96 Bytes

Contienen información sobre nounces,keys, IDs, MIC.

Solo hay información sobre Fast Transition en:

• Authentication Frames
• (Re)associ Req.
• (Re)assoc resp

Cuando existe un reasociation frame que decir que el cliente ha hecho roaming. 

 

 

Como usar Iperf para verificar la aplicación de QoS

En redes que pueden presentar problemas de congestión, puede ser necesaria la aplicación de políticas de Calidad de Servicio (QoS). Hay cierto tipo de tráfico como la VoIP que es más susceptible que otro tipo de tráfico a la pérdida de paquetes. Si durante una llamada hay paquetes que se pierden debido a congestión en la red o la latencia es alta, puede significar un espacio en blanco en la conversación o que se escuche robotizada.

A veces detectar si la electrónica de red está bien configurada o no para aplicar calidad QoS o no, puede ser complicado porque en determinadas ocasiones  el tráfico si viene marcado marcado con el tipo de servicio en origen pero otras aplicaciones no lo hacen.

Para verificar el envió de paquetes marcando una categoría de Qos desde origen, podemos usar la utilidad iperf para hacer las pruebas. Iperf es un programa que se instala en dos equipos. Uno hace servidor y se queda a la escucha y el otro que hace de cliente. La funcionalidad principal de iperf es obtener estadísticas de ancho de banda disponible entre los dos enlaces, pero con las opciones correctas podemos realizar test avanzados como el que haremos a continuación.

Iperf puede se descargado desde la siguiente url https://iperf.fr/. Su utilización es mediante lineal de comandos. En equipos basados en debian se puede instalar con el comando

sudo apt install iperf3

Una vez descargado lo ejecutamos en una máquina en modo escucha con el comando: 

iperf3 -s

Seguidamente en la otra maquina que hará cliente ejecutaremos el comando iperf3 -c "ip_del _servidor". Inicialmente lo ejecutaremos sin aplicar la opción para que marque los paquete con calidad de servicio para poder comparar los dos modos en Wireshark. Mientras se lanza el test, capturaremos los paquetes.

Los diferentes tipos de categoría con el valor correspondiente a cada DSCP se muestra a continuación. En la tabla hay también una columna con los valores de UP, que es método que utilizan las redes inalámbricas para categorizar el trafico.

 

Si analizamos los paquetes podemos ver que el valor DSCP asignado es 0 lo que significa no hay aplicado QoS:

Ahora vamos a realizar la prueba pero vamos a pasarle a Iperf la opción para que marque los paquetes con en DSCP 46 que suele ser el código definido para el trafico de voz. Esto lo realizamos con la opcion -S. Iperf usa los valores de ToS para marcar los paquetes. Para convertir los valores de DSCP a ToS solo hay que multiplicar el valor de DSCP * 4. Por ejemplo para voz que su valor DSCP es 46, el valor de ToS es 184

iperf3 -c "ip_del_host" -S 184

Si volvemos a analizar el paquete podemos ver que los paquetes salen marcados como EF46

Con esto ya podemos asegurar de enviar el tráfico etiquetado y si al salir del switch o del AP ya no aparece clasificado puede deberse a un problema de la configuración de la electrónica de red.

 

Análisis de A-MPDU y A-MSDU con Wireshark

En mi ruta para la certificación del CWAP me he encontrado con el punto que hace referencia a la agregación de tramas. He leído la guía oficial y varios artículos donde se hablan bastante de la teoría pero he encontrado poca información para analizar y hacer troubleshooting con Wireshark. Por este motivo me he decidido a realizar esta entrada para ayudar a aquellas persona que como yo se hayan encontrado en la misma situación.

Más adelante pasaré a explicar en detalle la teoría sobre A-MSDU y A-MPDU, pero a grandes rasgos este mecanismo permite enviar múltiples MSDU o MPDU durante a un dispositivo una vez a realizado el proceso de evaluación del medio,  verificar que está libre (CCA) y conseguir su turno para empezar a emitir (DCF Process).

Para empezar voy a empezar a explicar como agregar algunas columnas en Wireshark que me han ayudado a comprende un poco mejor el proceso.

Vamos a crear una columna que nos permitirá saber si el tipo de datos es MSDU o A-MPDU. 

 

A continuación buscamos una trama de tipo QoS Data (wlan.fc.type_subtype == 0x0028) y añadimos los siguientes campos como columnas:

Ahora buscamos un paquete del tipo BlockAck (wlan.fc.type_subtype == 0x0019) y aplicamos los siguientes campos como columnas:

Las comunas quedarán de la siguiente manera:

Para añadir las columnas a mano, estos serian los parámetros:

A continuación paso a detallar las características de A-MSDU:

 

• Encapsula múltiples MSDU (subframe) en una sola trama
• Cada MSDU contiene una dirección de destino (DA) y una dirección de origen (SA) 
• Cada A-MSDU contiene una cabecera en la que solo podemos poner 3 direcciones RA/TA, SA o DA. Pero en cada MSDU el DA puede ser distinto
• Las MSDUs que componen cada uno de los subframes tienen la siguiente información adicional. 

• Una cabecera (14 B) compuesta por la el DA y SA más la longitud del paquete. En la parte final hay un PAD. La longitud del paquete ha de ser un número múltiplo de 4.

• La última subframe es la única que no necesita PAD. 

• Una vez agregadas todas las subframe se le ha de añadir la cabecera de capa 2 al inicio y el FCS al final. A nivel de capa 1 se le añade también el PHY header para poder ser trasmitida 

• La trama en este punto se puede trasmitir.
• El CRC (trailer FCS) es calculado para cada A-MSDU
• Si una de las subframe falla al enviarse se ha de enviar de nuevo toda la A-MSDU

A-MPDU

• Esta compuesto por MPDU en vez de MSDU. Cada agregación se denomina también subframe
• Cada MPDU ya incorpora la cabecera + MSDU + Trailer
• Cada subframe tiene 3 componentes. Una cabecera denominada Delimiter que contiene la longitud y un FCS (CRC). Al final del subframe se en encuentra el PAD para conseguir que la longitud del subframe sea múltiplo de 4. La última subframe no necesita PAD.
• Al inicio de la agregación se le añade la cabecera 802.11 de nivel 2 con el TA y el RA y la cabecera PHY.
• Si uno de los FCS falla solo se descarta esa subframe y es la única que ha de ser retrasmitida.
• A-MPDU es obligatorio en 802.11ac y 802.11ax.
• 802.11n puede usar A-MSDU
• A-MSDU solo permite 1 RA y 1 TA
• En A-MPDU aunque cada subframe tiene su propia cabecera con un RA y TA. Una A-MPDU solo se puede enviar a un RA.
• Cada MPDU se encripta por separado
• Todas las MPDU ha de ser de la misma categoría de QoS
• Cada MPDU tiene su propio header y tráiler esto requiere también un mayor carga del medio.
• La corrupción de datos puede ser detectada en un MPDU individual y no hay que enviar la A-MPDU entera.

Para confirmar que las tramas se han recibido correctamente en el lado remoto, en vez de enviar un ACK individual, lo que se hace es enviar un BlockACK. En el caso de A-MPDU si alguna subframe se ha corrompido en el BlockACK aparece la información sobre el número de subframe que no ha llegado correctamente y se vuelve a trasmitir de nuevo. En el caso de A-MSDU si alguna subframe no llega correctamente, se ha de volver a trasmitir la trama completa. 

A continuación vamos a analizar  en Wireshark como sería la trasmisión de una A-MPDU, observar si alguna se ha recibido con problemas y ver la retrasmisión.

Tenemos la siguiente captura de paquetes:

Inicialmente se envían las tramas con número de secuencia 34,35,36,37. En línea 354 podemos observar como se envía un BlockACK especificando que no ha recibido los paquetes  38,39.40.41...

En la siguiente captura podemos ver el detalle de todas las tramas que no ha recibido.

Como vemos a continuación en la línea 373 se vuelve a enviar la secuencia 39 y 40 y en la línea 375 hay otro BlockACK que confirma que ha recibido el  paquete 39 y 40 (el primer missing frame es el 41)

Hay un punto que me gustaría también comentar y el como descifrar el código que aparece en el Campo Block Ack Bitmap. Mediante BlockACK podemos llegar a confirmar 64 tramas de una sola vez. Este campo lo podemos dividir en 8 bloques de 8 bits que servirá para detallar que tramas se ha recibido o cuales no. El procedimiento es el siguiente. Supongamos que el número de secuencia desde la que vamos a empezar verificar es la número 360. Como se muestra en la captura el Block Ack Bitmat tiene un valor de todos los dígitos de f"f" si convertimos todas las f de HEX a binarios tenemos que serían 64 unos. Cuando un número de secuencia tiene asociado un valor de 1 es que se ha recibido, si el valor es 0 es que no ha llegado bien. Todo unos significa que todo se ha recibido correctamente: 

Ahora vamos a analizar este otro bitmap. 

La tabla resultante seria la siguiente, he agrupado hex de 2 en dos (4 bits para representar 16 que es el valor máximo de cada HEX individual). 

Tal y como muestra Wireshark en la captura anterior,  las tramas 1569, 1571 y 1572, no han llegado correctamente.

A-MSDU

A continuación se muestra una captura de como se analizaría una A-MSDU con wireshark. Para aislar este tipo de tramas podemos aplicar el siguiente display filter:

wlan.qos.amsdupresent == 1

Para poder ver las subframes que contiene la trama se ha de desencriptar la captura.

En la captura podemos ver que la trama contiene dos subframes. Cada subframe tiene información sobre el DA y el SA más la longitud de la trama. Al final observamos el campo pading en la primera subframe, pero éste no aparece en la segunda ya que es la última. La recepción de la trama se confirma con un BlockACK

Amplío la información con la tabla con la duración de cada TxOP en función de la QoS:

 

Instalar Certificado Let's Encrypt en ISE

Para que a la hora de abrir un portal cautivo o la web de administración de ISE no recibamos el mensaje  que el certificado de seguridad no es de confianza, es necesario instalar en el sistema un certificado firmado por una Entidad Emisora de certificados de confianza. Una de estas entidades es Let's encrypt que te permite generar un certificado valido durante 90 días que va muy bien para hacer pruebas en laboratorio.

Para este tutorial, he adquirido el dominio wifilab.es. Este paso es necesario ya que la validación del certificado la realizaré validando a nivel de Dominio (DV). La creación de los certificados que se subirán a ISE los he generado con una maquina Linux y el programa cerbot.

1. Instalamos cerbot en nuestra máquina. Yo lo he realizado en una máquina linux y para instalarlos se ha de ejecutar el siguiente comando: 

sudo apt install certbot

2. Empezamos generando los certificados ejecutando el siguiente comando:

sudo certbot certonly --manual --preferred-challenges dns -d *.wifilab.es

--manual: es para especificar que lo obtendremos manualmente con las especificaciones que nosotros indiquemos de forma manual.

--preferred-challege: dns ya que la validación la haremos por este método

-d para especificar nuestro dominio si ponemos el asterisco delante vale como certificado wildcard.

3. Para la validación de DNS, me he creado un dominio en One.com. En esta web se puede adquirir un dominio por menos de 3 € al año. El dominio que he creado es wifilab.es. Creamos el registro .txt en nuestro dominio para que pueda ser validado.

Con esto podemos hacer la última parte del script donde solicita la validación del registro y se crean los certificados y la clave privada. Los archivos en mi caso se crean dentro del directorio

/etc/letsencrypt/archive/wifilab.es

Es posible que para poder acceder a los archivos y copiarlos a otra carpta para poder subirlos debas ejecutar:

 sudo -i 

para cambiar al modo privilegiado y es posible que debas cambiar los permisos de los ficheros con el comando:

chown -R usuario:grupo /etc/letsencrypt/archive/wifilab.es

(o la ruta donde hayas copiado los archivos).

4. Seguidamente quedaría configurar la parte de ISE. Si no importamos los Certificados de Let'e encrypt al importar los certificados nos da el siguiente error:

Lo que debemos hacer es lo siguiente:

De la pagina de Lets encrypt:

https://letsencrypt.org/certificates/ 

bajar e instalar los siguientes certificados:

 

Acto seguido ya podemos instalar el fullchain certificate con su clave privada en las opciones de Certificados del Sistema y definir donde lo queremos usar, en mi caso solo para el acceso al portal de administrador de ISE:

Se reiniciará la aplicación de ISE

Error al acceder por SSH desde Linux a equipos Cisco

 Recientemente me he encontrado con un problema al intentar accer por SSH desde la consola de Linux a dispositivos Cisco. Cuando intentaba hacer login recibía el siguiente error a la hora de establecer el algoritmo de encriptación.

Para corregir el problema he tenido que editar el fichero ~/ssh/config y añadir las siguientes lineas:

Host 10.5.18.98

    KexAlgorithms +diffie-hellman-group1-sha1

Aún y así me seguía dando el siguiente error:

Para corregir este error se ha de introducir las siguientes líneas:

HostKeyAlgorithms ssh-rsa

PubkeyAcceptedKeyTypes ssh-rsa 

Finalmente ya nos deja finalizar el proceso de conexión.