Redes Mesh con Routers Wi-Fi de bajo costo · Las redes de telecomunicaciones en malla, ... 1.1...

Redes Mesh con Routers Wi-Fi de bajo costoBanda de 2.4 GHz

Descripción Técnica

Índice de contenido1. Introducción.....................................................................................................................................3

1.1 Protocolos de Ruteo..................................................................................................................3

1.2 Batman-adv...............................................................................................................................4

1.2.1 Tipos de paquetes .............................................................................................................4

1.2.2 Descubrimiento de los Nodos ..........................................................................................5

1.2.3 Estimación de la calidad de enlace ...................................................................................5

1.2.4 Propagación de la calidad de transmisión ........................................................................6

1.2.5 Selección de rutas .............................................................................................................6

1.2.6 Anuncio de hosts vecinos .................................................................................................6

1.3 Optimización con multi-enlaces en Batman-adv......................................................................6

1.3.1 Detección de distintos enlaces .........................................................................................7

1.3.2 Selección de candidatos ...................................................................................................7

1.3.3 Uso de los candidatos .......................................................................................................7

1.4 Selección de un Router inalámbrico adecuado.........................................................................7

1.5 Compilación e instalación de Openwrt en el Router................................................................8

2. Mediciones en el Laboratorio........................................................................................................10

2.1 Sensibilidad.............................................................................................................................10

2.2 Modulaciones..........................................................................................................................10

2.3 Análisis Detallado de tasas de datos.......................................................................................11

2.3.1 Atenuación 75.4 dB, PTx 17 dBm .................................................................................14

2.3.2 Atenuación 75.4 dB, PTx 5 dBm ...................................................................................15

2.3.3 Atenuación 82.4 dB, PTx 5 dBm ...................................................................................16

2.4 Conclusiones...........................................................................................................................16

3. Configuración de Nodos Dobles...................................................................................................18

3.1 Descripción.............................................................................................................................18

3.2 Interferencia en Nodos Dobles...............................................................................................20

3.3 Archivos de configuración......................................................................................................22

3.3.1 Villapompa. Equipo con Batman....................................................................................22

3.3.1.1 /etc/config/network..................................................................................................22

1

3.3.1.3 /etc/config/wireless..................................................................................................23

3.3.1.4 /etc/init.d/inicio.sh...................................................................................................24

3.3.2 Villapompa. Equipo Repetidor........................................................................................24

3.3.2.1 /etc/config/network..................................................................................................24

3.3.2.2 /etc/config/wireless..................................................................................................25

3.3.2.3 /etc/init.d/inicio.sh...................................................................................................25

3.3.3 Comentarios....................................................................................................................25

4. Armado Físico de Nodos Dobles ..................................................................................................27

4.1 Lista de materiales: ................................................................................................................27

4.1.1 Caja Estanca IP-65:.........................................................................................................27

4.1.2 Placa Router....................................................................................................................28

4.1.3 Antena Externa:...............................................................................................................29

4.1.4 Tornillos y Accesorios.....................................................................................................30

4.1.5 Roseta RJ45.....................................................................................................................31

4.2 Construcción...........................................................................................................................32

4.2.1 Como agujerear el gabinete:............................................................................................32

4.2.2 Armado del conector de la extensión de antena superior:...............................................32

4.2.3 Armado de la extensión de antena superior:...................................................................33

4.2.4 Armado del conector de la antena inferior:.....................................................................34

4.2.5 Cómo agujerear chapa interna para colocar las placas de los routers:............................34

4.2.6 Pasos para la colocación de los routers en la chapa interna:..........................................35

4.2.7 Puesta del RJ45 en el gabinete:.......................................................................................36

4.2.8 Pasos para el armado final del nodo:...............................................................................36

5. Pruebas de campo en Delta Libre..................................................................................................38

5.1 Ubicación de los Nodos..........................................................................................................38

5.2 Algunos resultados..................................................................................................................39

5.2.1 Esquemas de desempeño de los nodos............................................................................39

5.2.2 Análisis de las transferencias obtenidas y comparación con pruebas de laboratorio......40

5.2.2.1 Enlace Villapompa-Ponderosa wlan........................................................................40

5.2.2.2 Enlace Villapompa-Ponderosa br-eth......................................................................42

5.2.2.3 Enlace Moni-Ponderosa wlan .................................................................................43

5.2.2.4 Enlace Moni-Ponderosa br-eth ...............................................................................44

5.3 Conclusiones...........................................................................................................................45

2

1. Introducción

Las redes de telecomunicaciones en malla, o mesh, son aquellas en las que cada nodo no sólo debe transmitir y recibir sus propios datos, sino que también debe servir de intermediario para otros nodos. Cuando la comunicación entre los nodos se realiza sin cables se habla de Redes Mesh Inalámbricas o Wireless Mesh Networks (WMN). Dada la masividad de Wi-Fi (redes inalámbricas basadas en los protocolos IEEE 802.11x), esta tecnología es casi la única utilizada para la conexión de WMNs. Generalmente, se usan dos topologías de las redes Wi-Fi para generar WMNs, infraestructura, y ad-hoc. La topología de infraestructura permite la conexión de clientes (estaciones) a los nodos (Acces Points), mientras que la topología ad-hoc se utiliza para conectar a los diferentes nodos entre sí. De esta forma cada nodo que se agrega permite extender la red brindando conectividad a más clientes. La topología mesh, a diferencia de otras, no requiere de un servidor o nodo central, con lo que se reduce el mantenimiento (un error en un nodo, sea importante o no, no implica la caída de toda la red). Para saber hacia dónde enviar cada paquete, los nodos utilizan protocolos de ruteo, que pueden trabajar en la segunda o tercer capa del modelo OSI. La red puede funcionar incluso cuando un nodo desaparece o la conexión falla, ya que el resto de los nodos evitan el paso por ese punto. En consecuencia, la red malla, es una red con redundancias, y por lo tanto confiable. Vale aclarar que en muchas ocasiones, la topología en malla se utiliza junto con otras topologías para formar una topología híbrida. A su vez, es muy común usar redes mesh para extender con eficacia una red, compartiendo el acceso a una infraestructura de mayor porte.

1.1 Protocolos de Ruteo

En el ámbito de las redes cableadas algunos de los protocolos de ruteo más conocidos son OSPF, IGRP, RIP, y BGP. Se los suele dividir entre protocolos distance-vector y link-state, dependiendo del tipo de algoritmo que usan para determinar los mejores caminos. En el primer caso se usa una medida de distancia, que suele ser la cantidad de saltos, para elegir la mejor ruta hacia un destino, pero los routers no conocen los caminos completos, sino simplemente los próximos saltos. En el caso de link-state en cambio cada router descubre a qué vecinos está conectado y envía esa información a todos los demás routers (flooding), junto con valores de costo calculados para cada link, donde se suele tener en cuenta latencia, throughput, etc. Con la información que llega de los distintos routers cada uno arma un mapa completo de la red, por lo que en general se necesita más memoria y procesamiento que para correr algoritmos distance-vector.

En el ámbito de las WMNs los protocolos de ruteo deben tener en cuenta el problema adicional de que las rutas no son tan estáticas como en el caso cableado, por lo que es importante mantener actualizada la información de ruteo. En estos protocolos se suele usar una clasificación que los divide entre proactivos y reactivos. En los primeros la información contenida en las tablas se va actualizando constantemente para todos los nodos, mientras que en los protocolos reactivos la información se actualiza cuando es necesario utilizar una ruta determinada. Los proactivos producen menos retardos pero necesitan más tráfico para mantener actualizadas las rutas. Algunos de los protocolos de ruteo más utilizados en WMNs son AODV, BATMAN, Babel y OLSR. También existe en desarrollo una serie de protocolos y arquitecturas englobados en 80211.s.

3

1.2 Batman-adv

El protocolo de ruteo que usamos en nuestros equipos es batman. Por la forma en que decide las mejores rutas, sin conocer el mapa completo de la red, se asemeja a un protocolo distance-vector, y a su vez, por cómo genera las tablas constantemente se comporta en forma proactiva.

Hay distintas implementaciones de este protocolo. Las primeras trabajaban en capa 3, sobre UDP, pero a partir de 2007 existe una versión llamada batman-adv que es la que usamos nosotros, que trabaja en capa 2. El algoritmo de ruteo que utiliza es similar, pero trabaja directamente usando tramas Ethernet, y provee una interfaz virtual que se encarga de transportar los paquetes y hace que toda la red se comporte como un switch virtual.

En el siguiente paper, que es en realidad sobre la implementación de una codificación de red que funciona sobre batman-adv, está muy bien explicado el funcionamiento de este protocolo (capítulo 3.1):

Network Coding for WMN

A continuación se resumen algunos puntos de ese texto:

1.2.1 Tipos de paquetes

En el punto 3.1.1 del paper se describen los 6 tipos de paquetes que usa batman-adv.

• Paquete originador (OGM): cumple con dos funciones importantes, anunciar la presencia de un nodo y los posibles próximos saltos para llegar a ese nodo, y por otro lado, medir la calidad de las diferentes rutas hacia el nodo anunciado. Estos paquetes originadores cuentan con los siguientes campos:

• Dirección del Originador (MAC de la interfaz del nodo que originó el mensaje)

• Número de secuencia: usado para medir la calidad de un enlace y detectar posibles mensajes duplicados

• TQ (calidad de transmisión): describe la calidad total del enlace hacia el originador

• Dirección del previous sender: para saber por qué nodo pasó el originador antes de que lo reenviara el vecino

• TTL (Time to Live): para limitar el número de nodos que un OGM puede atravesar

• Host Neighbour Announcement (HNA): describe los nodos no batman que pueden alcanzarse a través del originador

• Gateway Flags: usadas si el originador provee conexiones a otras redes

Conviene aclarar que como todos los paquetes de batman, los de originador viajan en tramas Ethernet, por lo que además de todos los campos anteriores, en la trama figuran las direcciones MAC de destino y origen. Batman usa la dirección de origen para saber qué nodo está enviando el originador. Además, también registra por qué interfaz ingresó. Así, cada vez que llega un originador se analiza quien lo envió (dirección de origen trama Ethernet), por dónde entró, quién es el originador (campo Dirección del originador) y quién se lo envió al que lo está enviando (campo Dirección del previous sender)

• Paquetes ICMP: como el protocolo funciona en capa 2, no siempre se puede acceder a un nodo con una dirección IP, por lo tanto batman implementa pings y otras herramientas en

4

http://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.pdf

capa 2

• Paquetes Unicast: son para encapsular paquetes unicast de capas superiores. Además del payload contienen un campo de TTL y uno con la dirección de destino

• Paquetes Unicast fragmentados: como batman encapsula paquetes de capas superiores, puede pasar que se exceda el MTU del enlace, y haya que fragmentar. Contienen campos para poder rearmar los paquetes en el destino.

• Paquetes Broadcast: son reenviados a toda la red, no sólo a los vecinos. Tienen un número de secuencia, la dirección del originador y un TTL.

• Paquetes de visualización: sirven para crear gráficos del mapa de la red. Se configura un nodo en servidor y los demás le envían la información correspondiente.

1.2.2 Descubrimiento de los Nodos

En el punto 3.1.2 se explican en forma resumida los pasos que se realizan en un cierto nodo A cuando se recibe un OGM:

• Comprobar si el originador es el propio nodo A. Si es así, quien lo reenvió es un vecino directo con comunicación en ambos sentidos.

• Comprobar si el previous sender es el propio nodo A. Esto implicaría que un OGM proveniente de algún nodo ya fue reenviado por A, llegó a algún vecino, y este vecino lo reenvió poniendo en el campo previous sender la dirección de A. Por lo tanto como ya había sido reenviado este paquete se descarta.

• Determinar el originador. Si no existe en la tabla de ruteo, crear una nueva entrada.

• Actualizar la calidad para llegar al originador (ver en el siguiente punto cómo se hace)

• Actualizar los campos de TQ y TTL en el OGM y y reenviarlo por broadcast (muchas veces los OGM se descartan antes de llegar a este punto por ser repetidos u otros motivos)

1.2.3 Estimación de la calidad de enlace

En el punto 3.1.3 se explica cómo se estima la calidad de enlace. Para eso el campo TQ de los OGM se va cambiando a medida que va recorriendo la red reenviado por los diferentes nodos, con valores que van entre 0 y 255. La calidad TQ se calcula en base a las calidades de recepción y de eco:

• Calidad de recepción (RQ): cuando un nodo A recibe OGMs de un nodo B, calcula la calidad de recepción desde B en base a una ventana de tiempo. RQ se calcula como un porcentaje de OGMs recibidos en esa ventana de tiempo.

• Calidad de eco (EQ): cuando un nodo A transmite OGMs, y estos llegan al vecino B, éste los vuelve a transmitir llegando de nuevo a A. Como en el caso anterior, se usa una ventana de tiempo para calcular EQ en base a la cantidad de OGMs que fueron y volvieron.

• Calidad de transmisión (TQ): En el nodo A, TQ es la probabilidad estimada de que un paquete llegue correctamente al nodo B. Como la calidad de eco incluye las probabilidades de que un paquete llegue de A a B y luego de B a A, se puede plantear:

EQ=RQ.TQ => TQ=EQ/RQ

Por lo tanto dividiendo EQ con RQ se obtiene TQ 5

1.2.4 Propagación de la calidad de transmisión

En el punto 3.1.4 se describe el mecanismo para propagar la calidad de una ruta entre varios nodos. Cuando un nodo A envía un originador suyo, pone un valor de 255 en el campo de TQ (el máximo valor posible). A su vez B, que es vecino de A, ya tiene un valor interno de TQ para llegar a A, llamado TQBA calculado de acuerdo al punto anterior. Por lo tanto, cuando reenvía el OGM de

A, lo hace reemplazando el valor del campo TQ por la multiplicación entre el valor original y TQBA. Así, a C, vecino de B, pero no de A, le llega el originador de A con la calidad para llegar a él

vista desde B. Entonces para calcular su propio valor de calidad para llegar a A, multiplica el valor del campo TQ que llega en el OGM por su propia calidad para llegar a B, TQCB. De esta forma se

van propagando las calidades para llegar a los distintos nodos, a partir de los valores que tienen los vecinos.

1.2.5 Selección de rutas

En el punto 3.1.5 se explica el mecanismo que usa batman para elegir las rutas. Mientras que otros protocolos tienen en cuenta la topología completa de la red para seleccionar el camino, batman sólo guarda información acerca del mejor next-hop para llegar a un nodo. A su vez ese next-hop tiene su propio next-hop para llegar al destino, y así sucesivamente. De este forma los nodos van direccionando los paquetes sin saber por donde van a viajar después de llegar al next-hop

1.2.6 Anuncio de hosts vecinos

Finalmente en el punto 3.1.6 se menciona el mecanismo de anuncio de hosts vecinos o HNA (Host Neighbour Announcements) que hace que cuando un equipo no batman se conecta a un equipo batman (ya sea a través de un acces point, cableado, etc) éste último anuncie que tiene conectado un host cuando envía los originadores para que el host sea conocido en toda la red.

1.3 Optimización con multi-enlaces en Batman-adv

Existen dos mecanismos usados por batman-adv para optimizar el uso de múltiples enlaces, en caso de haberlos. El primero se llama bonding, y consiste en ir mandando los paquetes de un flujo de datos por los distintos enlaces posibles. El segundo, llamado interface alternating funciona cambiando la interfaz de salida de un paquete con respecto a la de entrada, de manera que si las dos están en diferentes canales no cae tanto la transferencia en los distintos saltos.

El proceso de optimización puede dividirse en estos pasos:

1. Detectar que un vecino se puede alcanzar por medio de distintas interfaces 2. Elegir candidatos apropiados entre las posibles interfaces 3. Usar las múltiples interfaces para realizar la optimización

Es importante notar que estos procesos se dan luego de que batman ya eligió un next-hop. En la sección anterior se mencionó que batman no conoce las rutas completas hacia los diferentes nodos, sino simplemente los próximos saltos. Por lo tanto es después de elegir un próximo salto y darse cuenta de que hay más de una interfaz para llegar a ese salto que se aplican estos métodos.

6

1.3.1 Detección de distintos enlaces

Cuando un nodo con batman-adv tiene varias interfaces, una se elige como primaria (generalmente la primera en agregarse) y las demás como secundarias. Desde la interfaz primaria se mandan originadores con la MAC de la interfaz, con un TTL alto para que viajen por toda la red, y se envían por todas las interfaces que tenga el nodo, mientras que desde las secundarias se mandan OGMs exclusivamente por la interfaz correspondiente, y con un TTL de 2 para que únicamente lleguen a los vecinos y vuelvan (para poder calcular calidades). De esta forma para que un nodo se de cuenta de que está conectado a un mismo vecino por varias interfaces diferentes, alcanzaría el hecho de recibir el originador de la interfaz primaria del vecino por distintas interfaces. Así llegarían OGMs con la misma dirección de originador, pero ingresando por distintas interfaces propias y enviados a nivel físico por distintas interfaces del vecino. Sin embargo, podría pasar que el OGM de la interfaz primaria llegara a través de otro vecino, y no de otra interfaz del mismo vecino, y se confundiera el caso. Para que esto último no ocurra, se usa un flag de PRIMARIES_FIRST_HOP, que indica que el OGM es de una interfaz primaria, y que no fue reenviado por ningún nodo, ya que en caso de ser reenviado se debe bajar el flag. Así si un nodo recibe OGMs con la misma dirección de originador a través de interfaces diferentes, y con el flag anterior activado, se puede asegurar que tiene más de un enlace con el vecino en cuestión.

1.3.2 Selección de candidatos

Una vez que se detectan distintos enlaces para llegar a un vecino, se arma una lista de bonding candidates, o sea, enlaces candidatos para realizar interface alternating o bien bonding. Los requisitos que deben cumplir los enlaces son:

1. La calidad del enlace candidato no debe ser mucho peor que la calidad del mejor enlace. Si es menor en 50 unidades, no se tiene en cuenta.

2. El destino del enlace debe ser diferente de los destinos de los otros enlaces candidatos. Así se asegura que los enlaces trabajan en distintas frecuencias y por lo tanto no se interfieren.

1.3.3 Uso de los candidatos

Finalmente, luego de que batman-adv ya haya elegido un vecino como mejor salto con su método habitual, de que haya detectado enlaces adicionales para ese vecino y haya verificado que los candidatos cumplan los requisitos, se aplica interface alternating, que está activado por defecto, o bonding, que está desactivado por defecto.

1.4 Selección de un Router inalámbrico adecuado

Para trabajar con Batman-adv es necesario usar algún sistema operativo basado en Linux; en nuestro caso utilizamos Openwrt. La primer condición es entonces que el router que elijamos esté soportado por ese sistema operativo. Para eso se puede revisar la lista de hardware soportado en la página correspondiente.

También es importante saber quién es el fabricante del CPU y del chip wireless que usa el router, ya que de eso depende el driver que se va a utilizar. En nuestro caso usamos chips Atheros, con el driver ath9k.

A su vez de todas las posibilidades tratamos de seleccionar equipos fáciles de conseguir en el mercado y de precio accesible. Si tenemos alguna referencia adicional acerca del comportamiento

7

de un equipo dado con Openwrt mejor.

El presente documento se basa en trabajos realizados utilizando el Router TL-WR741ND, que cuenta con una única radio en la banda de 2.4 GHz y puede trabajar en 802.11n.

1.5 Compilación e instalación de Openwrt en el Router

Una vez elegido el hardware procedemos a compilar una imagen adecuada para el equipo con todos los paquetes necesarios. Otra posibilidad sería bajar una imagen directamente, sin necesidad de compilar, pero así no podríamos seleccionar paquetes específicos. También hay formas más automatizadas de generar imágenes, como por ejemplo usando el chef de AlterMundi. A continuación se describe una forma manual.

Dentro de Openwrt hay distintas ramas o branches que pueden utilizarse. La rama principal y más avanzada se llama trunk. Hay otra más atrasada pero a su vez más estable llamada backfire.

Para descargar el código fuente del repositorio de la rama seleccionada con la que realizaremos la imagen usamos la herramienta svn, así por ejemplo si vamos a trabajar con trunk ejecutamos desde un terminal en Linux:

svn co svn://svn.openwrt.org/openwrt/trunk/

Una vez que se termina la descarga entre otras cosas podemos leer qué versión del sistema operativo acabamos de descargar. Con el comando anterior ya tenemos entonces las fuentes para el sistema operativo y una gran cantidad de paquetes. Pero hay muchos otros paquetes que pueden no estar, como por ejemplo el de batman-adv. Para incluirlo, debemos bajar algunos paquetes adicionales de los feeds de la siguiente forma:

scripts/feeds update

Para bajar los paquetes, y:

scripts/feeds install kmod-batman-adv

Para instalar batman-adv. Sino con:

scripts/feeds install -a

Instalamos todos. En este caso instalar se refiere únicamente a tener los paquetes disponibles para poder seleccionarlos en la compilación de la imagen.

Una vez que tenemos las fuentes del sistema operativo y de los paquetes adicionales, podemos usar al menos dos formas para compilar la imagen:

1. Generando una imagen única para un hardware específico

2. Compilando un Image Builder que luego realizará cada imagen específica.

En los dos casos empezamos usando menuconfig:

make menuconfig

Para el primer caso seleccionamos con el menú el Target System, por ejemplo Atheros AR7xxx para el router WR-741ND. También seleccionamos el Target Profile, donde podemos encontrar nuestra versión exacta de hardware o una muy parecida, y luego vamos eligiendo todos los paquetes que necesitamos usando la letra "y". Hay muchos paquetes que se encuentran seleccionados por defecto, por el solo hecho de haber elegido un Target Profile, tal es el caso del driver ath9k para

8

nuestro ejemplo. El paquete de batman-adv que instalamos antes se encuentra en Kernel Modules ---> Network Support.

Una vez que seleccionamos todos los paquetes de interés, podemos guardar toda esta información en un archivo .config. Luego salimos con Esc guardando los cambios y ya estamos listos para la compilación. Con el comando:

make clear

Borramos compilaciones anteriores en caso de haberlas, y luego:

make V=99

Comienza la nueva compilación. La opción V=99 habilita el debug. Si usamos:

make V=99 -j 3

Aprovechamos dos procesadores en caso de tenerlos. Luego de unas horas la imagen termina de compilarse, y la buscamos en /bin/.../

Dependiendo las opciones que hayamos seleccionado en el menú dentro de Target Images tendremos imágenes de tipo squashfs o jffs2. Siempre usamos las primeras. A su vez hay imágenes que sirven para instalar el firmware por primera vez, que llevan en el nombre la palabra factory y otras que sirven para actualizar la imagen, que llevan la palabra sysupgrade.

La otra opción para generar la imagen es compilar un Image Builder, seleccionando esa opción en el menuconfig, y en lugar de incluir todos los paquetes necesarios usando la letra "y", podemos usar la letra "m" para precompilar paquetes. Así podemos precompilar los paquetes que podemos llegar a usar, pero luego sólo incluiremos en la imagen algunos en particular. La compilación del Image Builder toma un tiempo parecido a la de una imagen final, pero luego si queremos hacer otras imágenes cambiando sólo algunas opciones, éstas se compilan muy rápidamente. Al usar el Image Builder no hace falta seleccionar un target profile, sino que podemos elegir uno genérico y luego cuando compilemos la imagen definitiva seleccionaremos el profile que queramos. Así el Image Builder nos da un poco más de versatilidad. Una vez compilado el Image Builder, lo podemos encontrar en el directorio /bin/ar71xx/OpenWrt-ImageBuilder-ar71xx_generic....

Finalmente entrando en ese directorio y usando el comando:

make image PROFILE= PACKAGES=" "

Con el profile y los paquetes que queramos se generará la imagen. Cabe aclarar que los paquetes seleccionados deben haber sido precompilados en el paso anterior.

9

2. Mediciones en el Laboratorio

Usando dos routers TP-Link WR741ND, E10 y E13, con sus interfaces inalámbricas cableadas entre sí (sacando las antenas y colocando atenuadores intermedios) se realizaron distintas mediciones.

2.1 Sensibilidad

Se fue variando la atenuación entre los dos equipos y se leyeron los valores de señal obtenidos con el comando iw. Pese a no tener sus antenas conectadas, una parte de la señal transmitida por los routers se irradiaba de todas formas, por lo que se colocaron a una distancia tal que el nivel de señal leído con los cables desconectados, era suficientemente bajo, de -88 dBm. Estos fueron los resultados:

2.2 Modulaciones

Luego se analizaron las modulaciones utilizadas y tasas obtenidas con diferentes valores de atenuación. Según las tablas teóricas de la norma los valores para cada valor de señal en el receptor deberían ser los siguientes:

Para medir niveles de señal bajos se configuró la potencia de los equipos en 0dBm, para evitar interferencias inalámbricas. Luego a medida que fue subiendo el nivel de señal deseado se aumentaron las potencias. Los equipos estaban configurados con batman-adv sobre una interfaz ad-hoc, y además tenían una interfaz en modo ap.

10

Se obtuvieron los siguientes resultados:

2.3 Análisis Detallado de tasas de datos

Con el mismo set-up, pero agregando una PC transmitiendo cableada desde E10 para no sobrecargarlo, y con E13 recibiendo, se registraron las salidas de los comandos iw station dump, iw survey dump (en ambos equipos) y del archivo rc_stats en E10, donde se ve la tabla que usa el algoritmo minstrel para seleccionar la modulación a utilizar. A continuación se muestran las salidas de esos comandos:

root@E13:/# while true; do date; cat /proc/uptime; iw dev wlan0-1 station dump; sleep 1; doneThu Nov 29 19:44:07 UTC 2012 15501.35 14640.39 Station fa:d1:11:24:59: 07 (on wlan0-1) inactive time: 10 rx bytes: 2350461570 rx packets: 1864606 tx bytes: 1718254718 tx packets: 1131021 tx retries: 5768609 tx failed: 18 signal: -62 dBm signal avg: -61 dBm tx bitrate: 65.0 MBit/s MCS 7 rx bitrate: 65.0 MBit/s MCS 7

Los valores que se ven se van acumulando, por lo tanto para obtener los datos para cada ciclo del comando while utilizado basta con restar cada valor con el del ciclo anterior. Así se pueden obtener los bytes y paquetes recibidos y transmitidos por ciclo (de aproximadamente un segundo), y también los paquetes retransmitidos y fallidos.

11

root@E10:/# while true; do date; cat /proc/uptime; iw dev wlan0-1 station dump; sleep 1; doneThu Nov 29 19:44:08 UTC 2012 15499.12 14426.35 Station fa:d1:11:24:53: 47 (on wlan0-1) inactive time: 30 rx bytes: 1737997714 rx packets: 1444821 tx bytes: 2329548597 tx packets: 1532410 tx retries: 5550 tx failed: 7 signal: -59 [-59] dBm signal avg: -59 [-59] dBm tx bitrate: 65.0 MBit/s MCS 7 rx bitrate: 65.0 MBit/s MCS 7 authorized: yes authenticated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no

Este comando es el mismo que el anterior pero ejecutado en E10, el equipo transmisor.

root@E13:/# while true; do date; cat proc/uptime; iw dev wlan0-1 survey dump; sleep 1; done Thu Nov 29 19:44:11 UTC 2012 15505.44 14644.35 Survey data from wlan0-1 frequency: 2412 MHz Survey data from wlan0-1 frequency: 2417 MHz Survey data from wlan0-1 frequency: 2422 MHz Survey data from wlan0-1 frequency: 2427 MHz Survey data from wlan0-1 frequency: 2432 MHz Survey data from wlan0-1 frequency: 2437 MHz Survey data from wlan0-1 frequency: 2442 MHz Survey data from wlan0-1 frequency: 2447 MHz Survey data from wlan0-1 frequency: 2452 MHz Survey data from wlan0-1 frequency: 2457 MHz Survey data from wlan0-1 frequency: 2462 MHz [in use] noise: -94 dBm channel active time: 15338641 channel busy time: 1631041 channel receive time: 896155 channel transmit time: 616845

Con este comando la información que se puede obtener es el tiempo que el canal estuvo ocupado, recibiendo y transmitiendo, de acuerdo a la información suministrada por el driver.

12

root@E10:/# while true; do date; ca t proc/uptime; iw dev wlan0-1 sur vey dump; sleep 1; done Thu Nov 29 19:44:13 UTC 2012 15503.53 14430.43 Survey data from wlan0-1 frequency: 2412 MHz noise: -85 dBm channel active time: 15 channel busy time: 5 channel receive time: 0 channel transmit time: 0 Survey data from wlan0-1 frequency: 2417 MHz Survey data from wlan0-1 frequency: 2422 MHz Survey data from wlan0-1 frequency: 2427 MHz Survey data from wlan0-1 frequency: 2432 MHz Survey data from wlan0-1 frequency: 2437 MHz Survey data from wlan0-1 frequency: 2442 MHz Survey data from wlan0-1 frequency: 2447 MHz Survey data from wlan0-1 frequency: 2452 MHz Survey data from wlan0-1 frequency: 2457 MHz Survey data from wlan0-1 frequency: 2462 MHz [in use] noise: -92 dBm channel active time: 15350621 channel busy time: 1814642 channel receive time: 927034 channel transmit time: 671616

Igual que antes pero en E10, el transmisor.

root@E10:/# while true; do date; cat proc/uptime; cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/fa\:d1\ :11\:24\:53\:47/rc_stats; sleep 1; done Thu Nov 29 19:44:1 6 UTC 2012 15506.44 14433.03 type rate throughput ewma prob this prob this succ/attempt success attemptsHT20/LGI MCS0 6.2 99.9 100.0 0( 0) 802 815HT20/LGI MCS1 11.7 99.9 100.0 0( 0) 814 822HT20/LGI MCS2 16.3 98.9 100.0 0( 0) 820 828HT20/LGI MCS3 20.8 99.9 100.0 0( 0) 803 810HT20/LGI MCS4 26.8 95.5 100.0 0( 0) 1023 1042HT20/LGI t MCS5 33.6 99.7 100.0 0( 0) 11156 11589HT20/LGI MCS6 33.3 92.0 100.0 0( 0) 250756 271885HT20/LGI T PMCS7 39.0 99.9 100.0 5( 5) 1265882 1328089 Total packet count:: ideal 1525342 lookaround 6720 Average A-MPDU length: 1.0

Acá se ve la tabla que usa el algoritmo mencionado antes para seleccionar la modulación que se va a utilizar.

Entonces se usaron estos datos para analizar el comportamiento de los equipos con diferentes niveles de atenuación, transmitiendo con la máxima tasa posible con la aplicación iperf en modo UDP durante 15 segundos con un payload de 1470 bytes. Luego se realizó un promedio de los ciclos del while donde no se vieran efectos transitorios (es decir cuando por los valores se nota que la transmisión apenas comienza o termina) y se realizó una tabla resumen para cada comando.

En el caso de los station dump, se calcularon las tasas crudas y netas, la primera dividiendo directamente la cantidad de bytes por el tiempo del ciclo considerado, y la segunda teniendo en cuenta cuántos de esos bytes fueron de datos propiamente dichos, que surge de multiplicar los paquetes por el payload seleccionado al correr el iperf. En el caso de los survey dump los porcentajes se calculan promediando los ciclos de transmisión, recepción y ocupado a lo largo de la

13

transmisión, y luego calculando los porcentajes sobre el promedio de tiempo activo. En el caso de los rc_stats se consideran los paquetes enviados, exitosos y fallidos para cada modulación, y en base a esos valores se calculan los valores y porcentajes expresados.

2.3.1 Atenuación 75.4 dB, PTx 17 dBm

Con este nivel de atenuación, y con los equipos transmitiendo en 17 dBm, el nivel de recepción teórica es de -58.4 dBm.

sta dump E13 paq / s bytes / paq tasa cruda tasa neta tasa iperf

4258.6 1546.7 52.69 50.08 48.3

sta dump E10 paq. / s bytes / paq. paq. retr. / s paq. fall. / s tasa cruda tasa neta tasa iperf

4227.7 1554.1 8.6 0 52.56 49.72 48.3

survey dump E13 % t ocupado % t Rx % t Tx

93.2 88.8 3


93.4 4 88.1

rc_stats E10 paq. / s % paquetes M7 % ex. M7 paq. ex. M7 / s

4368.5 99.6 96.4 4198.038

Se puede ver que de acuerdo al survey dump de E10, éste estuvo un 88,1% del tiempo transmitiendo. A su vez, de acuerdo con rc_stats, en ese tiempo, el 99,6% (prácticamente todos) de los paquetes se enviaron usando la modulación MCS7, y por otro lado, según este mismo archivo el 96.4% de esos paquetes llegaron a E13 correctamente. Entonces de acuerdo con esos valores en 1 segundo E10 transmitió durante 0.881 s usando MCS7, lo que daría una tasa de 57.26 Mbps. A su vez, si tenemos en cuenta el porcentaje de éxito de los paquetes, tendríamos una tasa de 55.2Mbps, que no coincide pero se asemeja a las tasas crudas (sin diferenciar el overhead del payload) calculadas de acuerdo a los station dump de E10 y E13, de alrededor de 52 Mbps.

14


Con el mismo nivel de atenuación que antes, pero esta vez con los equipos transmitiendo en 5 dBm, o sea, con una señal teórica de -70.4 dBm, se repitió el procedimiento:

stat dump E13 paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

2289.25 1540.51 28.21 26.92 26.5

station dump E10 paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

2266.13 1553.26 57.94 0 28.16 26.65 26.5


88.4 83.55 3.17


89.28 5.24 82.28

rc_stats E10 paq. / s % paq. M4 % ex. M4 paq. ex. M4 / s % paq. M5 % ex. M5 paq. ex. M5 / s

2479.26 92.2 95.12 2174.33 6.22 48.55 74.92

En este caso se ve que E10 usa el canal para transmitir un 82.3% del tiempo. En ese tiempo, el 92.2% de los paquetes los envía usando MCS4, y el 6.22% usando MCS5. Teniendo en cuenta que los paquetes MCS4 son más lentos, y suponiendo que el tiempo que se usan otras modulaciones es despreciable, se puede estimar que un 95.2% del tiempo se usa la modulación MCS4, y un 4.8% se usa MCS5. Entonces si por cada segundo el canal se usa 0.8228 segundos, 0.7833 segundos se usarían en MCS4 y 0.0395 segundos en MCS5. De esta forma se habría transmitido a 39 Mbps por 0.7833 segundos, con un éxito del 95.12%, o sea, 29 M, más 52 Mbps durante 0.0395 segundos con un éxito del 48.55%, o sea 0.97 M más, dando un total de 29.97Mbps crudos. Si lo comparamos con los valores estimados de acuerdo a los station dump vuelven a dar ligeramente más altos.

15


Se repitió el procedimiento con una atenuación de 82.4 dB y una potencia de 5 dBm, es decir -77.4 dBm de señal:

sta dump E13 paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

1151.66 1527.76 14.08 13.54 13.2

sta dump E10 paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

1132.4 1552.71 70.62 0 14.07 13.32 13.2


83.84 78.85 3.29


88.97 4.47 82.63

rc_stats E10 paq. / s % paq. M2 % ex. M2 paq. ex. M2 / s % paq. M3 % ex. M3 paq. ex. M3 / s

1244.52 85.55 97.25 1035.38 10.77 43.46 58.23

Haciendo el mismo análisis que en el caso anterior se puede estimar que un 91% del tiempo se usa la modulación MCS2, y un 9% MCS3. Dado que en un segundo el canal se usa aproximadamente 0.826 s para transmitir, si el 91% de ese tiempo se usa MCS2 con un éxito del 97.25%, de la tasa de 19.5 Mbps propia de la modulación, llegamos a 14.25 Mbits transmitidos. Por otro lado con MCS3 (26 Mbps) teniendo en cuenta que se usa un 9% con un éxito del 43.46% tenemos 0.84 Mb más. Por lo tanto en total tendríamos 15.09 Mbits transmitidos. Como en los casos anteriores, da un poco más alto que el valor de tasa cruda deducido a través de los survey dump, de alrededor de 14 Mbps en este caso, pero es muy cercano.

2.4 Conclusiones

Empezando por la medición de sensibilidad, se puede observar que la diferencia entre los valores de señal calculados y los medidos en los routers fue como máximo de 1,6 dB, siendo en la mayoría de los casos incluso menor a 0.6 dB. Sin embargo cuando se realizaron las mediciones de modulaciones en el punto siguiente, se volvieron a registrar los niveles de señal, dando diferencias más grandes entre los dos equipos, de hasta 5 dB, estando E13 más alejado de los valores teóricos.

Con respecto a las modulaciones utilizadas con distintos niveles de señal, se ve que para un nivel de atenuación dado, E13 recibe de E10 a una tasa más alta que E10 de E13, correspondiéndose con

16

el hecho de que E10 usa siempre índices de modulación mayores o a lo sumo iguales a los que usa E13. Una posibilidad es que E13 tenga mejor sensibilidad que E10, por lo que E10 le puede mandar con modulaciones más altas. De todas formas, salvo en un caso, los dos equipos usan índices de modulación mayores o iguales a los especificados por la norma.

En el análisis detallado para diferentes condiciones de señal se puede explicar el desempeño de los equipos de acuerdo a los diferentes parámetros registrados. El caso en que E10 transmite con 17 dBm y la atenuación es de 75.4 dB, es una condición ideal, ya que a E13 le llegan -58.4 dBm, más que los -64 dBm necesarios que especifica la norma para usar MCS7. Además, como en todas estas pruebas de laboratorio, como los equipos están cableados se puede descartar cualquier interferencia. En estas condiciones ideales, la tasa obtenida fue de 48.3Mbps, un 25.7% menor a los 65 Mbps crudos que usa MCS7. Como se explicó, de los 65 Mbps se llega al valor real teniendo en cuenta el tiempo efectivo en que el router estuvo transmitiendo, el porcentaje de éxito de los paquetes, y el porcentaje de overhead introducido por las capas inferiores.

En el siguiente punto, con una señal de -70.4 dBm en E13, la primera diferencia que se observa con el caso ideal es que el porcentaje de tiempo de transmisión baja del 88% al 82.3%. Una posible explicación es que esta vez debido a que hay una cantidad pequeña de paquetes que no llegan correctamente a destino, se activa el proceso para evitar colisiones en el que el que envía espera un tiempo al azar antes de volver a intentar. En cuanto a la modulación, se puede ver que un 92% del tiempo se usa MCS4, la especificada por la norma para el valor de señal en este caso, con un porcentaje de éxito alto. El tiempo restante el algoritmo usa mayoritariamente la modulación MCS5, con un porcentaje de éxito bajo. En estas condiciones la tasa obtenida de 26.5 Mbps es un 32% más baja que la de la modulación cruda MCS4.

Finalmente en el último caso con el nivel de -77.4 dBm en E13, se observa también un tiempo de transmisión de un 82%. La modulación usada en un 85.5% es MCS2, la especificada por la norma para este nivel de señal. A su vez un 10.77% se usa MCS3 con un porcentaje de éxito mucho más bajo. La tasa obtenida mediante iperf de 13.2 Mbps es un 32.3% más baja que la de la modulación cruda MCS2.

17

3. Configuración de Nodos Dobles

3.1 Descripción

Uno de los principales problemas de las redes de tipo mesh en equipos con una sola radio es la degradación de las tasas de transferencia a medida que se van usando más saltos. Esto se da porque cada nodo tiene que recibir y transmitir usando una misma interfaz y una misma frecuencia, recibiendo señales de todos los equipos que tiene a su alcance y a su vez interfiriéndolos.

Para mejorar el problema anterior, batman-adv tiene la función de interface alternating mencionada anteriormente, que permite usar diferentes canales en caso de tener más de una interfaz, para no sufrir una degradación tan grande de las tasas de datos.

Para poder usar esta característica hay varias posibilidades:

• Usar directamente equipos multi-radio • Usar equipos con una sola radio agregando modulos wifi por USB. • Conectar dos equipos con una sola radio cada uno

En nuestro caso dado que contábamos con equipos con una única radio, consideramos las dos últimas opciones. Como los routers utilizados (TL-WR741ND) no vienen con conector USB (aunque internamente sí tienen un módulo), además de que el driver ath9k no funcionaban del todo bien en modo adhoc para dispositivos USB, nos inclinamos por la tercera opción.

La primera prueba que hicimos fue conectar directamente los routers de a dos a través de un cable, con batman-adv manejando las interfaces inalámbricas y cableadas:

Con un equipo en canal 1 y otro en 11 en cada nodo doble. El problema de esta configuración es que como se explicó antes los mecanismos de optimización de multi-enlaces se aplican luego de la selección del mejor camino hacia un destino. Por ejemplo, si B2 recibe un paquete de B1 con destino B3, nosotros quisiéramos que enviara ese paquete hacia B5, y de ahí a B6 y B3 para usar un canal distinto, pero el mecanismo es diferente. Cuando B2 recibe el paquete, primero elige cuál es el mejor salto posible para llegar a B3, siendo las opciones B5 y B3 directamente. La decisión entre esos dos dependerá de la calidad de cada camino hacia B3, siendo más probable que elija ir directo hacia B3 porque al ser directo la calidad probablemente sea más alta. Recién una vez que eligió el próximo salto (probablemente B3) el algoritmo analiza si hay más de un enlace para llegar a ese vecino, pero como no lo hay, manda el paquete por el único enlace posible. Para que esta configuración funcionara cambiando de canal, batman debería conocer las rutas completas para llegar al destino, y darse cuenta de que la ruta a través de B5 permite cambiar de canal, pero batman

18

sólo conoce el próximo salto para llegar a un destino dado.

Por lo tanto usamos esta otra configuración:

Donde ahora en cada par un equipo usa batman-adv (B1, B2 y B3) pero el otro funciona exclusivamente como repetidor (R4, R5 y R6). La idea en esta configuración, es que los repetidores sean transparentes, para que batman-adv vea a sus vecinos como si tuviera dos enlaces directos con ellos. Para eso los repetidores no usan batman-adv, y se configura un bridge entre eth y wlan para reenviar los paquetes en forma transparente. El problema con esta configuración, es que el modo adhoc no funciona correctamente en un bridge. Por ejemplo si B1 le quisiera enviar una trama a B2, ésta atravesaría el bridge, y saldría al aire con la dirección de destino de B2, por lo que ni llegaría a entrar a R5 porque el driver de la placa inalámbrica no reconocería que la trama es para él, y a su vez como R4 no recibiría ningún ack seguiría mandando la trama. Este problema es muy similar al de un equipo en modo estación en un bridge. En modo access point o estación una posible solución para este problema es usar WDS, que usa en total 4 direcciones MAC. Algunos drivers permiten el uso de 4 direcciones MAC también en modo adhoc, pero no es el caso del ath9k que usamos nosotros.

La solución que usamos entonces es cambiar la MAC de las interfaces Ethernet de los equipos que usan batman-adv, por la MAC de la interfaz inalámbrica del repetidor correspondiente:

19

De esta manera cuando B1 quiere llegar a B2, manda las tramas con la dirección de la MAC de la interfaz inalámbrica de R4 como destino. Así las tramas ingresan sin problemas a R4 y se envía el ack correspondiente. El detalle que queda es que una vez ingresada la trama, el bridge de R4 considera que ésta es para las capas superiores, porque tiene su propia dirección, y no reenvía el paquete hacia B2. Entonces para forzar el renvío de estas tramas, usamos la herramienta ebtables para cambiarles la MAC de destino por una dirección cualquiera una vez ingresadas a R4. De la misma forma, en B2 usamos ebtables para volver a cambiar la dirección de destino arbitraria que usamos antes por la correspondiente.

En nuevas versiones de la rama trunk de openwrt ya no se permite agregar una interfaz en modo adhoc a un bridge, por lo que no podríamos usar la configuración anterior. Las alternativas son usar un paquete llamado trelay con trunk, usar backfire en los repetidores, o bien modificar la porción de código que impide agregar la interfaz adhoc.

3.2 Interferencia en Nodos Dobles

Al utilizar nodos compuestos por dos Routers, por más que las frecuencias de trabajo sean diferentes es fundamental tener en cuenta los problemas de interferencia que surgen.

Los canales disponibles en la banda de 2.4 GHz son los siguientes:

Mientras que estas son las máscaras especificadas por la norma 802.11n, para los modos de 20 MHz (HT20) y 40 MHz (HT40):

20

Como se ve, para el modo con canales de 20 MHz, la norma exige que a 30 MHz de la frecuencia central del canal, la potencia transmitida caiga 45 dB respecto del máximo. Esta atenuación puede ser suficiente en muchos casos para trabajar por ejemplo con los canales 1 y 6, pero teniendo dos radios en un mismo equipo puede no serlo, por lo que es conveniente trabajar en los canales 1 y 11, que tienen una diferencia de 50 MHz.

De todos modos, incluso trabajando con esos canales en HT20, se comprobó una variación importante del comportamiento de los Nodos Dobles al variar la posición de las antenas. Dado que los monopolos, así como los dipolos, tienen el mínimo de radiación sobre su propio eje (como se puede ver en el diagrama de radiación en la siguiente sección), se colocaron de tal forma que sus ejes coincidieran para que la interferencia fuera mínima. En esa condición se realizaron mediciones de transmisiones desde un nodo a otro pasando por uno intermedio que recibiera en un canal y transmitiera en otro usando la característica de interface alternating de batman explicada anteriormente. Además de coincidir en sus ejes, se observó que aumentando la distancia entre las antenas a partir de alrededor de 50 cm la interferencia prácticamente desaparecía, por lo que al armar los Nodos Dobles se decidió usar una separación total de alrededor de 75 cm. De cualquier manera, también se comprobó que las distancias del Nodo a pisos o paredes conductoras, hacen variar mucho los niveles de interferencia, por lo que es conveniente tener en cuenta estos factores a la hora de la instalación. Finalmente también se comprobó que el uso de HT40 empeora la situación, ya que como se ve en la máscara correspondiente, a 50 MHz de la frecuencia central del canal, la atenuación es menor a 45 dB, lo cual hace muy difícil que no haya interferencias.

21

3.3 Archivos de configuración

A continuación se transcriben los archivos de configuración network, wireless, y el script de inicio utilizado, tomando un nodo llamado Villapompa como ejemplo.

3.3.1 Villapompa. Equipo con Batman

3.3.1.1 /etc/config/network

config interface loopback

option ifname lo

option proto static

option ipaddr 127.0.0.1

option netmask 255.0.0.0

config interface lan

option ifname bat0

option type bridge

option proto dhcp

option macaddr F8:D1:11:24:54:5C

option hostname villapompa

config interface ifaz_red_mesh

option proto none

option mtu 1530

config interface wan

option ifname eth1

option proto dhcp

config switch eth0

option enable_vlan 1

config switch_vlan

option device eth0

option vlan 1

option ports "0 1 2 3 4"

22

3.3.1.2

3.3.1.3 /etc/config/wireless

config wifi-device radio0

option type mac80211

option macaddr f8:d1:11:24:54:5c

option hwmode 11ng

option htmode HT20

list ht_capab SHORT-GI-40

list ht_capab TX-STBC

list ht_capab RX-STBC1

list ht_capab DSSS_CCK-40

option channel 11

config wifi-iface

option device radio0

option network lan

option mode ap

option ssid deltalibre.org.ar

option encryption none

config wifi-iface


option encryption psk2

option network lan

option mode ap

option ssid villapompa.wpa

option key clave1234

config wifi-iface


option network ifaz_red_mesh

option mode adhoc

option ssid batmesh.0

option bssid 02:5a:56:d6:f0:52


option mcast_rate 18000

23

3.3.1.4 /etc/init.d/inicio.sh

ifconfig eth0 down

ifconfig eth0 hw ether f8:d1:11:24:54:82

ifconfig eth0 up

batctl if add wlan0-2

brctl addbr br-eth0

brctl addif br-eth0 eth0

ifconfig br-eth0 up

batctl if add br-eth0

ebtables -t broute -A BROUTING -i eth0 -d 00:11:11:11:11:11 -j dnat --to-dst f8:d1:11:24:54:82 --dnat-target ACCEPT

3.3.2 Villapompa. Equipo Repetidor

3.3.2.1 /etc/config/network

config interface loopback

option ifname lo

option proto static



config interface lan

option ifname eth0

option type bridge

option proto static



config interface wan

option ifname eth1

option proto dhcp

config switch eth0

option enable_vlan 1

config switch_vlan

option device eth0

option vlan 1

option ports "0 1 2 3 4"

24

3.3.2.2 /etc/config/wireless

config wifi-device radio0

option type mac80211

option channel 1

option macaddr f8:d1:11:24:54:82

option hwmode 11ng

option htmode HT20

list ht_capab SHORT-GI-40

list ht_capab TX-STBC

list ht_capab RX-STBC1

list ht_capab DSSS_CCK-40

config wifi-iface


option network lan

option mode adhoc

option ssid mesh2

option bssid 02:06:05:04:03:02


option mcast_rate 18000

3.3.2.3 /etc/init.d/inicio.sh

ifconfig eth0 down

ifconfig eth0 hw ether f8:d1:11:24:54:85

ifconfig eth0 up

ebtables -t broute -A BROUTING -p arp -i wlan0 -j ACCEPT

ebtables -t broute -A BROUTING -p ipv4 -i wlan0 -j ACCEPT

ebtables -t broute -A BROUTING -p ipv6 -i wlan0 -j ACCEPT

ebtables -t broute -A BROUTING -i wlan0 -d f8:d1:11:24:54:82 -j dnat --to-dst 00:11:11:11:11:11 --dnat-target ACCEPT

3.3.3 Comentarios

En el script de inicio del equipo repetidor se pueden ver varias reglas de ebtables. Las primeras tres son para dejar que paquetes "normales", es decir, paquetes IP o ARP, entren al router y sean procesados por el mismo de manera normal. La última regla en cambio, se aplica a todos los paquetes que no sean ni IP ni ARP, y funciona para los paquetes de batman, cambiándoles su dirección MAC de destino por una arbitraria, haciendo que estos paquetes no sean procesados por el router, sino reenviados por la interfaz Ethernet.

A su vez en el script de inicio del equipo que usa batman primero se clona la dirección MAC 25

Ethernet para que sea igual a la dirección de la interfaz inalámbrica del equipo repetidor, para que cuando salgan paquetes batman originados en Ethernet, lleguen a través del repetidor a otros equipos en forma transparente, y cuando estos respondan a esa MAC, los paquetes sean aceptados por el repetidor como propios. Luego se crea un bridge al que se le incluye sólo eth0, para poder aplicar reglas de ebtables y al mismo tiempo usar batman en esa interfaz. Finalmente hay una regla de ebtables que toma todos los paquetes que entran por Ethernet, y si su dirección de destino es la elegida arbitrariamente, se vuelve a cambiar por la dirección correspondiente para ser procesada por el router.

Volviendo al equipo repetidor, en el script de inicio también se cambia la MAC Ethernet para que no coincida con la MAC wireless que a su vez es la misma que la MAC Ethernet del equipo con batman, ya que al intentar acceder en forma cableada cuando el repetidor y el equipo con batman están conectados, de otra forma podría pasar que hubiera un conflicto en los bridges y no se pudiera entrar.

26

4. Armado Físico de Nodos Dobles

4.1 Lista de materiales:

Material Medidas

Caja estanca IP-65 250X200X120 mm

2 placas de routers 15X10cm

Antena Externa 20 cm

Tornillos-accesorios 2.5 cm y 7,5 cm /diámetro 4mm

Roseta RJ45 ---

4.1.1 Caja Estanca IP-65:

Vista Delantera Vista Trasera

Vista Interna

27

4.1.2 Placa Router

Vista Superior Vista Inferior

Conectores Etiqueta Gabinete

Especificaciones Fabricante

28

4.1.3 Antena Externa:

29

4.1.4 Tornillos y Accesorios

Cantidad de tornillos y accesorios por placa:

• 4-tornillos 4 mm • 12-arandelas de metal de 1,2cm diámetro • 12-tuercas 4 mm • 4-arandelas glober de 0.6cm diámetro • 8-arandelas de goma de 1.2cm diámetro

Tubo hembra 20 X 1/2" F

• 1-tubo hembra 2 x 1/2" F • 1-abrazadera alambre 32 a 28 mm UN

30

4.1.5 Roseta RJ45

Vistas

Accesorios:

• 2 Leds de 3mm color verde o rojo (a elección) • 2 Resistencias de 1K 1/4w

Conexión de la roseta

PIN PIN

4 + 8 -

5 + 7 -

2 naranja 6 verde

pin 1 blanco naranja pin 3 blanco verde

Conexión Cable RJ45

1 blanco naranja

2 naranja

3 blanco verde

4 azul

5 blanco azul

6 verde

7 blanco marrón

8 marrón

31

4.2 Construcción

4.2.1 Como agujerear el gabinete:

Vista Superior

Vista Inferior

4.2.2 Armado del conector de la extensión de antena superior:

Vista Exterior Vista Interior

32

4.2.3 Armado de la extensión de antena superior:

1) Antena Externa2) Se saca el material de abajo, chapa e

imanes. La rosca es de 5mm cortada de un tapón de plástico de media pulgada

3) Se pega la rosca bien centrada 4) Se rellena la base con poxilina 10 Minutos

5) Se pinta la base6) Se rosca el caño de 50 cm a la antena, luego a través de un agujero hecho en la

punta se pasa el cable de la antena

33

4.2.4 Armado del conector de la antena inferior:

Vista Exterior Vista Interior

4.2.5 Cómo agujerear chapa interna para colocar las placas de los routers:

Vista y posición de los agujeros

34

4.2.6 Pasos para la colocación de los routers en la chapa interna:

Paso 1 Paso 2

Paso 3 Paso 4

Paso 5 Paso 6

Paso 7

35

4.2.7 Puesta del RJ45 en el gabinete:

Se coloca el conector y los leds y se pega por dentro por lo bordes usando ciano o un pegamento similar.

4.2.8 Pasos para el armado final del nodo:

1) Colocación de la chapa en el gabinete 2) Conexión de los cables

3) Colocación del conector de antena inferior 4) Colocación de extensión de antena

36

5) Acomodar cables 6) nodo terminado

37

5. Pruebas de campo en Delta Libre

En el marco de un acuerdo de cooperación con la organización AlterMundi, se colocaron tres Nodos Dobles en la red Delta Libre, en el delta del Tigre en la Provincia de Buenos Aires, para analizar el desempeño de los nodos.

5.1 Ubicación de los Nodos

En la siguiente imagen se pueden ver los 3 nodos INTI en amarillo, dentro de una red preexistente en el arroyo Angostura. De acuerdo a sus ubicaciones se nombraron Villapompa, Ponderosa y Moni.

En esta imagen se pueden ver los nodos en una escala más grande y con las distancias entre ellos:

38

5.2 Algunos resultados

5.2.1 Esquemas de desempeño de los nodos

En este esquema se muestran valores obtenidos el 29/10/12, con tasas de datos usando iperf en modo UDP, con tamaños de paquetes por defecto (1470 bytes de payload), y por lo tanto sujetos a fragmentación a nivel de ipv6, ya que ipv6 tiene un encabezado de 40 bytes, lo que hace que en total los paquetes sean de 1470 (Payload) + 8 (UDP) + 40 (IP) = 1518. Los valores de señal son los medidos en los routers usando el comando iw. Se ven también las distancias involucradas y la atenuación de espacio libre teórica en 2.4 GHz para esas distancias, aunque este último valor hay que tomarlo sólo como referencia, dado que al usar antenas omnidireccionales y estar en ambientes con múltiples reflexiones no se puede pensar en un canal con una atenuación bien determinada. Las líneas negras que unen directamente a equipos vecinos representan los enlaces directos entre ellos, a través de wlan y de br-eth. Las líneas negras que unen los extremos, es decir Villapompa con Moni, representan los enlaces que comunican esos equipos, usando como salto intermedio Ponderosa, pero sin cambiar de radio, ya que esas pruebas se realizaron con los enlaces alternativos deshabilitados. Finalmente en rojo y en azul se ven los enlaces entre los extremos, pero usando esta vez las dos radios. En el caso rojo entre Villapompa y Ponderosa se usa wlan y entre Ponderosa y Moni br-eth. En el caso azul se usa br-eth entre Villapompa y Ponderosa y wlan entre Ponderosa y Moni. Sobre las líneas se colocan los valores de transferencia para cada enlace, promediando los valores de ida y vuelta. Cabe aclarar que se usan los canales 1 y 11 en los diferentes radios de cada equipo.

En el siguiente esquema se muestran valores del día 14/11/12, con tasas de datos usando iperf en UDP, pero esta vez configurando el payload en 1422 para asegurar que no hay fragmentaciones ni a nivel ipv6 ni a nivel de batman-adv. Esto es así porque 1422+8+40=1470. Eso asegura que ipv6 no fragmenta. Por otro lado batman agrega 28 bytes más, llegando a 1498, lo que asegura que batman tampoco fragmenta las tramas, incluso aunque las transmita por la interfaz eth que tiene un MTU de 1500, y no de 1530 como las interfaces inalámbricas. Como en el gráfico anterior también se

39

muestran los valores de señal y las distancias. A diferencia del esquema anterior, esta vez se muestran las transferencias en ambos sentidos separados por una barra. El primer valor es de izquierda a derecha.

5.2.2 Análisis de las transferencias obtenidas y comparación con pruebas de laboratorio

En base a datos obtenidos el 17/12/12 se repitió el procedimiento realizado en el laboratorio (ver acá) para comparar los resultados. Cabe aclarar que los valores no coinciden exactamente con los de los esquemas anteriores por haber sido registrados en otra fecha.

5.2.2.1 Enlace Villapompa-Ponderosa wlan

Dado que las condiciones del enlace parecían variables se repitieron las pruebas 3 veces. A continuación se muestran los resultados para la primera medición, y luego para la segunda, que fueron las más extremas. En cuanto al nivel de señal, durante las pruebas los equipos se veían con -75 dBm de señal.

sta dump ponde 1 paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

912.08 1461.43 10.66 10.38 9.8

sta dump pompa 1 paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

883.89 1501.73 161.22 0 10.62 10.06 9.8

40

survey dump ponde 1 % t ocupado % t Rx % t Tx

65 56.5 5.1

survey dump pompa 1 % t ocupado % t Rx % t Tx

73 24.8 45

rc_stats pompa 1

paq. / s % paq. M4 % ex. M4 paq. ex. M4 / s % paq. M3 % ex. M3 paq. ex. M3 / s

1230.9 91.1 74.1 831.8 5.4 63 42

Se ve que Villapompa usa el canal para transmitir un 45% del tiempo. En ese tiempo, el 91.1 % de los paquetes los envía usando MCS4, y el 5.4% usando MCS3. Teniendo en cuenta que los paquetes en MCS3 duran 1.5 veces los de MCS4, y suponiendo que son las únicas modulaciones utilizadas, el 91.8% del tiempo se usó MCS4, y el 8.2% del tiempo MCS3. Entonces en promedio en un segundo Villapompa envió paquetes durante 0.45 segundos. Un 91.8% de ese tiempo, o sea, 0.413 segundos en MCS4, y un 8.2%, o 0.0369 segundos en MCS3. Entonces envió 0.413*39Mbps=16M en MCS4 y 0.0369*26Mbps=0.959Mb en MCS3. Finalmente considerando los porcentajes de éxito, a ponderosa le habrían llegado 16Mb*0.741=11.86Mb en MCS4 y 0.959Mb*0.63=0.604Mb en MCS3, dando un total de 12.46Mb.

Ese valor debería coincidir con las tasas crudas obtenidas a partir de los station dump en Ponderosa y Villapompa, pero es un 17% superior. En las mediciones hechas en el laboratorio las tasas calculadas en base a rc_stats también daban superiores a las obtenidas en base a los station dump. Una posibilidad es que del tiempo de transmisión de Villapompa, no todo se utilice para transmitir a ponderosa. Teniendo en cuenta los porcentajes de tiempo que Villapompa transmite antes y después de iniciar el iperf, que es de alrededor de un 3.15% (no figura en las tablas), y restando ese porcentaje de base al 45% de tiempo que transmite durante el iperf, podemos suponer que transmite alrededor de un 41.85% de tiempo a ponderosa. Con esta corrección el resultado final daría 11.67 Mbps, menos de un 10% superior a los valores promedio obtenidos de los station dump.

En la segunda medición los resultados fueron los siguientes:

sta dump ponde 2 paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

1224.2 1483.53 14.53 13.93 13.7

sta dump pompa 2 paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

1223.57 1507.63 135.47 0 14.76 13.92 13.7

41

survey dump ponde 2 % t ocupado % t Rx % t Tx

77.04 68.57 5.46

survey dump pompa 2 % t ocupado % t Rx % t Tx

89.99 20.46 67.08

rc_stats pompa 2


1638.47 90.41 65.53 970.74 5.94 64.18 62.44

Con el mismo razonamiento del punto anterior, tenemos que Villapompa transmitió en promedio el 67.08% del tiempo. Esta vez antes y después del iperf, el tiempo de transmisión en promedio fue de 4.77%, por lo que se puede suponer que transmitió a ponderosa un 62.31% del tiempo. A su vez, aproximadamente un 91% del tiempo usó MCS4 y un 9% del tiempo MCS3. Considerando también los porcentajes de éxito tenemos 14.49Mb en MCS4 más 0.94Mb en MCS3, dando un total de 15.43 Mbps, muy cercano a los valores de tasa cruda obtenidos en base a los station dump.

5.2.2.2 Enlace Villapompa-Ponderosa br-eth

Ahora se muestran las tablas para el enlace a través de br-eth. En este caso Ponderosa veía a Villapompa con un nivel de -80 dBm, y Villapompa a Ponderosa con -74 dBm.

sta dump ponde paq / s bytes / paq tasa cruda tasa neta tasa iperf

1577.4 1468.83 18.54 17.94 17.7

sta dump pompa paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

1565.95 1483.76 - 0 18.59 17.81 17.7

survey dump ponde % t ocupado % t Rx % t Tx

81.99 79.72 0.36

survey dump pompa % t ocupado % t Rx % t Tx

86.73 3.73 81.1

42

rc_stats pompa 1


1797.66 90 93.4 1508.31 7.65 32.76 46.93

En este caso tenemos que en promedio Villapompa transmitió un 81.1% del tiempo. Esta vez, antes y después del iperf, el tiempo de transmisión fue nulo, por lo que se puede suponer que ese 81.1% de tiempo fue todo de transmisión hacia Ponderosa. A su vez, de acuerdo con los porcentajes de paquetes en cada modulación, se puede estimar que un 94.6% del tiempo se usó MCS3 y un 5.36% MCS4. Entonces teniendo en cuenta además los porcentajes de éxito tenemos que en promedio se transmitieron 18.638 Mb en MCS3 y 0.13 Mb en MCS4, dando un total de 18.77 Mb en un segundo, muy cercano a los valores de tasa cruda obtenidas a través de los station dump.

En cuanto al dato de retransmisiones en Villapompa, se ignoraron los valores por ser extremadamente altos, no teniendo sentido. Este comportamiento se observó en todos los equipos retransmisores, por lo que suponemos que está relacionado con la configuración especial de esos equipos.

5.2.2.3 Enlace Moni-Ponderosa wlan

Se muestran las tablas para el enlace Moni-Ponderosa a través de wlan. En este caso los equipos se veían con un nivel de señal de -65 dBm.

stat dump ponde paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

2359.91 1507.99 28.47 26.85 24.9

station dump moni paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

2341.97 1521.02 76.17 0 28.5 26.64 24.9


88.49 74.55 4.48

survey dump moni % t ocupado % t Rx % t Tx

92.5 11.25 79.19

43

rc_stats moni paq. / s % paq. M7 % ex. M7 paq. ex. M7 / s % paq. M6 % ex. M6 paq. ex. M6 / s

3680.28 68.17 63.39 1608.55 22.24 62.37 504.4

% paq. M5 % ex. M5 paq. ex. M5 / s

5.43 49.18 124.96

En esta oportunidad Moni transmitió un 79.19% del tiempo mientras corría el iperf. Promediando el tiempo de transmisión anterior y posterior al iperf, que es de alrededor de 3.33%, se puede suponer que un 75.86% del tiempo transmitió hacia Ponderosa. Esta vez se tuvieron en cuenta 3 modulaciones, ya que con las dos más usadas se cubría sólo hasta el 90% de los paquetes enviados, mientras que considerando también la tercera modulación más usada se llega a casi un 96% de los paquetes. Pasando a tiempo y sin considerar las demás modulaciones, tenemos que un 68.4% del tiempo se transmitió en M7, un 24.8% en M6 y un 6.81% en M5. Considerando además los porcentajes de éxito en cada modulación da que se transmitieron 21.38 Mb en MCS7, 6.86 Mb en MCS6 y 1.32 Mb en MCS5, dando un total de 29.56 Mbps. Muy cercano a los valores obtenidos a partir de los station dump.

5.2.2.4 Enlace Moni-Ponderosa br-eth

Para el enlace a través de los equipos repetidores, los equipos se veían con -74 dBm. Los tablas correspondientes son las siguientes:

sta dump ponde paq. / s bytes / paq. tasa cruda tasa neta tasa iperf

2926.86 1478.25 34.61 33.3 32.9

sta dump moni paq. / s bytes / paq. paq. retr / s paq. fall / s tasa cruda tasa neta tasa iperf

2906.24 1483.88 - 0 34.5 33.06 32.9


71.9 67.55 1.38

survey dump moni % t ocupado % t Rx % t Tx

72.34 2.12 67.37

44

rc_stats moni paq. / s % paq. M6 % ex. M6 paq. ex. M6 / s % paq. M7 % ex. M7 paq. ex. M7 / s

3176.92 92 93.19 2715.59 7.77 68 185.95

En este caso antes y después del iperf el tiempo de transmisión en Moni es nulo, por lo que suponemos que el 67.37% del tiempo transmite a Ponderosa. En cuanto al tiempo que usa cada modulación, aproximadamente un 93% usa MCS6 y un 7% MCS7. Como en los casos anteriores, considerando también los porcentajes de éxito tenemos 33.72 Mb transmitidos en MCS6 y 0.238 Mb transmitidos en MCS7, dando un total de 33.958 Mbps, que prácticamente coincide con los valores de station dump. Por otro lado, como ya se mencionó antes, no se muestra el valor de retransmisiones porque en los equipos repetidores da un valor absurdo.

5.3 Conclusiones

En primer lugar, en relación a los esquemas de desempeño de los nodos, se observa que más allá de los valores particulares de cada enlace, cuando se alterna usando dos radios en Ponderosa, prácticamente se mantiene la transferencia del peor enlace utilizado, el que se comporta como un cuello de botella. Así por ejemplo en el primer esquema entre Villapompa y Ponderosa a través de wlan hay una tasa de 12.5 Mbps, y entre Ponderosa y Moni a través de br-eth hay 17.5 Mbps, mientras que entre Villapompa y Moni, usando primero wlan y luego alternando a br-eth tenemos 11 Mbps, muy cercano a los 12.5 Mbps entre Villapompa y Ponderosa. En cambio, si observamos los valores para los enlaces que pasan por Ponderosa, pero sin alternar, vemos que son menores a la mitad de los valores de los enlaces que hacen de cuello de botella. Esto demuestra la mejora introducida al utilizar dos radios y poder alternar entre frecuencias.

Con respecto a los enlaces directos entre vecinos, que no involucran saltos, se ve una mejora importante en el segundo esquema, cuando se usa un payload menor para asegurar que no hay ninguna fragmentación. Las pruebas se realizaron con UDP para tener un valor más cercano al máximo posible, ya que no hay control de flujo, ni otros mecanismos de TCP que no dan un valor tan cercano a la capacidad real del canal. Sin embargo, TCP es mucho más utilizado por los protocolos de capas superiores para transportar la información, y tiene la ventaja de que acomoda automáticamente el payload a través del parámetro MSS (Maximum Segment Size), por lo que en situaciones más reales al menos a nivel de ip no habría fragmentaciones. A nivel de batman seguiría habiendo fragmentaciones cuando los paquetes viajan a través de los equipos repetidores, ya que con los routers utilizados no se puede aumentar el MTU de las interfaces Ethernet involucradas.

Acerca del análisis más detallado de los enlaces directos entre vecinos, es interesante comparar los resultados con los obtenidos en el laboratorio con los equipos cableados, para tratar de entender las diferencias.

Empezando por el enlace Moni-Ponderosa br-eth, que es el que dio una tasa de datos más alta, se ve que de acuerdo a la norma, para el nivel de señal de -74 dBm leído en los equipos, debería poder usarse la modulación MCS3. Sin embargo se ve que Moni usa en un 92% de los paquetes enviados la modulación MCS6, con un éxito del 93.2%. En las pruebas de laboratorio, se ve que los equipos empezaban a usar MCS6 con alrededor de -68 dBm de señal. Por lo tanto, podría haber una diferencia entre la calidad de medición de los equipos utilizados en el laboratorio con los ubicados en Delta Libre, o también podría pasar que al estar en un ambiente inalámbrico real las mediciones de señal no sean tan confiables y en realidad en este caso la señal sea mejor a la leída. En cuanto al tiempo de utilización del canal, se ve que Moni transmite alrededor de un 67% del tiempo a

45

Ponderosa, mientras que en las mediciones en el laboratorio, los tiempos de transmisión variaban entre un 82% y un 88%, independientemente del nivel de señal recibido. Habría que analizar a qué se debe esta diferencia en el tiempo de utilización. El valor obtenido del iperf de 32.9 Mbps se explica entonces por las modulaciones usadas con sus porcentajes de éxito y el tiempo efectivo de transmisión.

En el caso del enlace Moni-Ponderosa a través de wlan, los equipos se ven con una señal aproximada de -65 dBm. Esta vez las modulaciones usadas, MCS7 y MCS6, se corresponden con las mediciones de laboratorio y con la norma para ese valor de señal. Se ve que un 68.17% de los paquetes se transmitió con MCS7 y un 22.24% con MCS6. En cuanto a los porcentajes de éxito, de 63.4% y 62.3% respectivamente, se puede suponer que no se deben tanto a la relación señal a ruido, como a posibles interferencias, dado que si bien no se muestran en la tabla resumen, en los datos completos obtenidos, se puede ver que con modulaciones aún más bajas como MCS5 el porcentaje de éxito no mejora sustancialmente. El tiempo de utilización del canal esta vez es un poco más alto, y se asemeja más a los medidos en laboratorio.

En cuanto al enlace Villapompa Ponderosa a través de br-eth, se ve que Ponderosa, que recibe el tráfico del iperf, ve a Villapompa con una señal de -80 dBm. De acuerdo a la norma y a las mediciones de laboratorio, debería usarse alguna modulación cercana a MCS1 para ese valor de señal. Sin embargo se ve que se usa MCS3 en un 90%, y MCS4 en un 7.65%, con éxitos del 93.4% y 32.76% respectivamente. El hecho de que pueda usarse MCS3 con un éxito tan grande podría indicar que en realidad la señal le llega a Ponderosa con un nivel de señal mejor a -80 dBm. En cuanto al tiempo de utilización del canal para transmisión, es mayor al 80% en Villapompa, parecido a los valores en laboratorio. En este caso, en que el éxito en MCS3 es tan alto, y tan bajo en MCS4 podría indicar que no se logran tasas más altas por no alcanzar la relación señal a ruido a la distancia en que están los equipos.

Finalmente, en el enlace Villapompa Ponderosa a través de wlan se analizan dos casos con tasas ligeramente diferentes. En el segundo caso, en que la tasa es de 13.7 Mbps, el nivel de señal registrado es de aproximadamente -75 dBm. Con ese valor, de acuerdo a la norma y las mediciones de laboratorio, debería poder usarse MCS3 o alguna modulación cercana. Vemos que en un 90.41% de los paquetes se usa MCS4, con un éxito del 65.5%, y en un 5.94% MCS3 con un éxito del 64.2%. Como en otros casos, el hecho de que los porcentajes de éxito no varíen para distintas modulaciones, puede significar que los paquetes se pierden por interferencia con otros equipos y no por un problema de relación señal a ruido. Otro indicio de que puede haber interferencia son los porcentajes de uso del canal. Se ve que Villapompa usa un 67% del tiempo para transmitir, y al mismo tiempo un 20.5% del tiempo para recibir, cuando en las mediciones de laboratorio con dos equipos, el que transmite una tasa alta apenas usa un 5% del tiempo para recibir. Además como ya se mencionó, del 67% del tiempo de transmisión, se estimó que casi un 5% de ese tiempo transmitió hacia otras estaciones. En el primer caso la tasa de datos es aún más baja, de 9.8 Mbps, con la curiosidad de que esta vez el porcentaje de éxito de los paquetes MCS4 es más alta, de un 74%, con casi la misma incidencia de esta modulación, un 90.41%. En MCS3 se transmite como en el otro caso un 5,4%, con un éxito del 63%. La diferencia es que esta vez, Villapompa transmitió apenas un 45% del tiempo, lo que lleva a pensar nuevamente en problemas de interferencia.

46

Redes Mesh con Routers Wi-Fi de bajo costo · Las redes de telecomunicaciones en malla, ... 1.1...

Documents

Transcript of Redes Mesh con Routers Wi-Fi de bajo costo · Las redes de telecomunicaciones en malla, ... 1.1...