Meshias 0.1 Resurrection

Como lo prometido es deuda y porque más vale tarde que nunca, ya está disponible Meshias 0.1 “Resurrection”. Es la primera versión “estable” que sacamos. No pretendemos decir que no tenga bugs, pero lo hemos testeado y la funcionalidad básica está presente: ahora es el momento de que otros lo prueben y nos informen de los problemas que les surgen en sus configuraciones. Happy testing!

Comunicación por socket UNIX funcionando

Pues el desarrollo del programa sigue su curso. Ya hemos completado la comunicación a través del socket unix. Ahora podemos ejecutar el demonio meshias en un terminal, y en otro distinto ejecutamos meshias-tools comunicamos con él interactivamente. Por ahora la comunicación es pobre pero es fácilmente ampliable. Por ahora nos muestra las estadísticas que se han producido, las limpia y mata al demonio, y dentro de poco también la tabla de rutas.

Se pueden crear varios clientes con distintas características y el demonio sea programado pensando en esa futuras características y poder pasar todo tipo de información. Dos clientes que nos gustaría implementar, además del básico de meshias-tools, sería un servidor web y un cliente con QT.

El servidor web podría estar hecho en python y podríamos verificar el estado del demonio desde cualquier ordenador con cualquier sistema operativo, incluso modificar parámetros propios del demonio meshias u otros, como el ESSID, ajenos a éste. De esta manera podríamos configurar sistemas sin teclado y ratón a través de la propia red, un ejemplo de ellos, son los mini-sistemas que tenemos para empezar a hacer pruebas que nos han subvencionado gracias a Pablo Neira. Placas bases pequeñas con procesador de bajo consumo (AMD Geode), memorias flash y tarjetas inalámbricas. Sería útil cargar en las memorias además del meshias, su interfaz web para poder configurarlo a través de un portátil con firefox.

El cliente QT sería una aplicación orientada al ordenador personal. En él, además de poder configurar parámetros, se podría visualizar la arquitectura de la red, que ordenadores existen en él, posibilidad de seguir explorando la red, eliminar enlaces permanentemente, ver el flujo de la red, etc. todo integrado para el escritorio KDE. Por supuesto se podría hacer para Gnome, pero tenemos más “amistad” con el de KDE.

Bueno esto ha sido todo por hoy, seguiremos avanzando para sacar meshias “resurrection”.

Nuevo logo, virtualbox

Hoy he enviado por fin la revisión 100 de meshias, y como ha contado Alejandro en el post anterior, ahora prácticamente todos los bugs conocidos han sido arreglados. He estado toda esta mañana trabajando en ello. La versión 0.1 cada vez está más cerca. Danigm no sólo nos ha cedido un espacio web y nos ha montado un wiki en él sino también se ha currado un nuevo logo, cuyas semejanzas con el todopoderoso FSM no hay que menospreciar. Personalmente me parece que está genial:

El logo ya aparece en el wiki de meshias. En el wiki no sólo pondremos tutoriales e información para desarrolladores sino también muy pronto lo reorganizaremos para que enlace al blog, que enlace al sitio de launchpad, etc, en definitiva será un portal completo y fácil de usar que será la plataforma de entrada del proyecto en Internet.

Otra cosa de la que aun no he hablado en el blog es del nuevo método para testear Meshias que he implementado: usando máquinas virtuales que hagan de nodos de la red.

El sábado pasado estuve todo el dia configurando una máquina virtual con VirtualBox para que sirva de nodo en una red mesh virtual de sólo dos nodos (mi máquina física y la virtual), de manera que puedo usar tan solo un netbook de poca potencia como mi Acer Aspire One y usarlo para desarrollar meshias durante las vacaciones, desde el tren, desde la casa de la playa, cuando me vaya mañana a Madrid, etc.

En trunk/ hay un fichero con información para desarrolladores donde se cuenta cómo configurar el virtualbox, y he subido la imagen de la máquina virtual a los servidores de SUGUS para que quien quiera pueda probar este cómodo método para testear meshias.

Ahora el siguiente paso es usar más máquinas virtuales (por ahora sólo uso uno) y conseguir que ciertos nodos se vean entre ellos pero que no se vean todos entre todos, de manera que algunos nodos tengan que hacer de enrutadores forzosamente. Para eso Alejandro me ha sugerido usar Channel bonding / unión de interfaces, y mañana testearé eso. Si lo consigo, añadiré al tutorial cómo hacerlo. De todas formas lo ideal sería que VirtualBox permitiese decir qué máquinas ven a cuales otras, así que me he bajado el código de VirtualBox y voy a bichearlo a ver si consigo hacer un parche para conseguir eso. Sí, estoy loco por intentarlo, pero ese es el espíritu .

Todos los bugs corregidos

Después de varios días solo corrigiendo bugs, por fin hemos conseguido hacer ping. Vale, esto que significa, pues que conectamos dos ordenadores a nivel de enlace, ya sea por cable o a través de wifi, y arrancamos meshias en ambos. Bien, ahora desde el ordenador A hacemos ping a la ip del ordenador B. Sabemos que esta justo al otro lado del cable o wifi pero esto no lo sabe el demonio así que capturas los ping y los va guardando en cola, mientras envía el paquete aodv RREQ (el de búsqueda de ruta). El ordenador B se da cuenta de que le ha llegado un petición de ruta para su IP y crea su respuesta correspondiente, o sea manda su RREP. Esto le llega al ordenador A, crea su entrada correspondiente en la tabla de rutas. Después de eso busca todos los paquetes que hemos ido guardando y lo enviamos sin que se pierda ni un solo paquete, es decir, responde a todas las peticiones de ping.

Además hemos comprado los dominios www.meshias.net que es el principal y meshias.com que redirige al anterior. Ahora mismo hay colgado un wiki que iremos llenando de contenido. Desde aquí dar las gracias danigm (su blog es: http://www.danigm.net/) también participante del concurso, que nos ha cedido su servidor personal para nosotros. El wiki obviamente no va a reemplazar este blog. Cada uno tiene su función, aquí publicaremos nuestras noticias del avance que va alcanzando el proyecto. El wiki contendrá manuales, más o menos actualizados, de como usar el proyecto, posibilidades de configuración, y todo lo que tenga más forma de HOWTO que de noticia.

Pues un saludo y seguro que vendremos con noticias muy pronto.

Jornadas de Conocimiento Libre en Sevilla

Las Jornadas de Conocimiento Libre se celebraron en la Universidad de Sevilla el pasado jueves y viernes. Vinieron ponentes muy interesantes, como Jorge cortell, inventor del concepto de suidad, y Harald, ex-arquitecto jefe de OpenMoko y mantenedor de iptables. El viernes se presentaron los proyectos que participan en el concurso de software libre en el premio local de Sevilla, entre ellos Meshias, y luego se dieron los premios. Mi enhorabuena a Danigm, Carmona y Virako por sus premios: a nosotros por meshias nos dieron un accésit y estamos muy agradecidos por ello.

El desarrollo de meshias sin embargo no termina aquí de ninguna manera. El domingo de resurrección, sacaremos la versión 0.1 final titulada “Resurrection” tal y como hemos prometido. Estuvimos unos meses sin hacer apenas nada de meshias y por eso es lógico que en el concurso local no sacásemos más que un accésit, pero el desarrollo de meshias como comprobaréis es frenético desde que lo retomamos hace como un mes y continuará así en el futuro. Para el premio nacional vamos a por todas.

Comunicación y socket unix

El proyecto ha dado un nuevo paso. Meshias además de generar respuestas de rutas ahora, además, es capaz de procesar e interpretar este tipo de paquete. Todavía no esta probado y pasaremos la tarde intentando que esto funcione. Si lo conseguimos os ofreceremos un ejemplo de uso próximamente. También lo haríamos cuando presentemos el proyecto dentro de las Jornadas sobre el Conocimiento Libre 2009 organizada desde nuestra escuela. Desde aquí dar las gracias a los organizadores por la maravillosa oportunidad que nos ofrecen.

Además de este nuevo paso queríamos mostraros la idea, que aun no implementada, pero que el código está preparado para ello y que esperemos incorporar lo más pronto posible, es la comunicación con el demonio a través de un socket unix. La idea básica es tener un programa, a parte del propio demonio, que se pueda ejecute dentro de la misma maquina y que se comunique con meshias para:

1. Mirar estadísticas, en vez de tener un archivo log dificil de tratar hemos pensado que sería mejor que el programa nos mostrará una serie de estadísticas que de un vistazo pudieramos ver que falla dentro del programa.
2. Ver las rutas actuales, así como añadir o eliminar algunas de ellas.
3. Reiniciar, matar o parar el demonio.
4. Ver las colas de espera de los paquetes.
5. Modificar en tiempo de ejecución la configuración del demonio.

En un desborde de orignalidad a esta herramienta la hemos llamado meshias-tools. Aunque a primera vista es algo más dificil de implementar, a la hora de debugear el programa esperamos recuperar ese tiempo; ya que un programa de este calibre con tratamiento distribuido de información es mucho más costoso reparar fallos que uno normal. Cabe añadir otras ventajas como poder crear distintos clientes con menor o mayor funcionalidad, liberamos al demonio de tareas innecesarias ya que recaeran sobre el cliente con lo que no dejamos de atender paquetes, interactividad entre usuario y demonio, y un largo etc.

Podemos imaginarnos por ejemplo un cliente integrado en tu escritorio favorito (KDE / Gnome / Xfce) donde gráficamente te muestre algunas estadísticas, diagramas del esquema actual de la red, añadir rutas manualmente o busquedas proactivas de rutas específicas; todo ello gracias a dotar al demonio de una interactvidad fácilmente ampliable.

Avanzando a pasos agigantados.

Y es que no paramos de trabajar… Si bien todavía nos queda mucho para tener algo estable y usable, esta misma semana podremos llegar a tener incluso algo funcional.

AODV que funciona a través del puerto UDP 654 genera y puede recibir tres tipos de paquetes:

1. Route Requests (RREQ): Cuando queremos queremos comunicarnos con un ordenador C, desde nuestro ordenador A, entonces generamos un paquete de este tipo. Lo mandamos en Broadcast, es decir, mandamos un paquete esperando que lo lean la más gente posible para que nos generen una respuesta. Este paquete contiene información sobre quien lo ha generado (A) y hacia donde quiere ir (C), además de otra información de control necesaria para el protocolo: números de saltos o tiempo de vida del paquete. El paquete ira saltando por todos los nodos intermedios B1, B2, B3, etc. buscando su destino.
2. Route Replies (RREP): Cuando un ordenador recibe un paquete RREQ cuyo destino es el mismo, o sea, el paquete anterior llega a C, entonces se genera RREP. El paquete se envia por el mismo camino que ha llegado pero, obviamente en sentido inverso. Todos los nodos intermedios aprobecharan además para actualizar su tabla de rutas porque ya saben donde estan el resto de ellos. En nuestro ejemplo, a medida que vaya pasando por los distintos nodos C, B3, B2, B1 y A añadiran en su tabla de rutas los nodos correspondientes.
3. Route Errors (RERR): Son mensajes de error cuando alguien se ha caido de la red. Se genera este tipo de paquetes para comunicar que el nodo o nodos son inaccesibles.

Pues bien, nosotros hemos conseguido realizar peticiones de rutas e incluso respuestas de ellas. Aunque todavía está un poco verde creo que podremos mostraros un ejemplo de funcionamiento esta misma semana del funcionamiento de Meshias; desde como compilarlo, pasando por las reglas de iptables necesarias, para luego hacer un ping y conseguir generar una petición de ruta y su respuesta, consiguiendo conectar con el objetivo.

Capturando paquetes y mirando su ruta

¿Cómo capturamos los paquetes?

Como viene explicado en el anterior post meshias se pone en funcionamiento cada vez que tenemos que mandar un paquete. En ese momento debemos capturar el paquete para averiguar hacia donde va dirigido. Una vez averiguado hacia donde va dirigido comprobamos en la tablas de rutas del kernel si sabría enrutarlo. Este proceso es bastante sencillo de entender, no ha sido igualmente facil para programarlo.

Hemos necesitado dos librerías auxiliares para hacer este trabajo. Para capturar los paquetes hemos utilizado libnetfilter-queue, a partir de ahora nfqueue. Nfqueue es una herramienta del equipo de netfilter que nos permite hacer cosas muy curiosas. Su funcionamiento la podemos dividir en dos partes. La primera es que necesitamos reglas de iptables. Iptables es el firewall de núcleo Linux, también desarrollado por el equipo de netfilter y que nos permite, entre otras muchas cosas, crear una regla para los paquetes que cumplan las condiciones necesarias, pasarlas a cola de nfqueue. Esto significa que podemos crear reglas de iptables que irán encolando los paquetes que nosotros queramos para tratarlos manualmente.

Una vez en la cola de nfqueue podemos aceptarlos, robarlos o tirarlos para que no sigan su camino. Robarlos significa que podemos mantenerlos en espera hasta que queramos aceptarlos o tirarlos posteriormente. Nosotros lo único que hacemos es mirar a qué IP están dirigidos los paquetes, para comprobar si existe una ruta para el paquete; si existe lo aceptamos  sin más, y entonces el paquete es enrutado y  enviado por la interfaz de red correspondiente.  Si sin embargo no tenemos la ruta para la IP de destino de ese paquete y esa IP está dentro del rango de direcciones de la red mesh que está usando meshias (por ejemplo la red 192.168.1.X) lo robamos hasta averiguar la ruta. Si no la encontramos tiramos el paquete o si lo encontramos agregamos la ruta al kernel y lo aceptamos.

Manejando rutas

Hemos dicho que usamos principalmente dos librerías. Pues si la primera era nfqueue, la segunda es libnl. Esta ruta es una interfaz que nos permite comunicarnos con el kernel mediante sockets netlink, pero que nos oculta su funcionamiento interno y nos ofrece una interfaz más cómoda de usar. Como bien explican en la wikipedia, los sockets netlink son usados por muchas aplicaciones de red para comunicarse con el kernel, por ejemplo iproute los usa.

Nosotros para agregar o quitar rutas si se cae un enlace lo hacemos a través del libnl. Una vez conocida la ruta para una dirección ip, la añadimos a la tabla de rutas con libnl. Pero ahí no acaba nuestro trabajo: tenemos que mantener la ruta actualizada. Las redes mesh tienen un carácter más o menos dinámico, y los nodos pueden conectarse, desconectarse,y moverse de lugar con el tiempo. Por ello si no recibimos actividad por cierta ruta tras cierto intervalo de tiempo, asumimos que algún nodo de la ruta ya no está ahí, y tenemos que borrar la ruta de la tabla de rutas. El borrar de la tabla de ruta también lo hacemos con libnl.

Hay otro tipo de ocasiones en las que también necesitamos borrar rutas. Como ya contamos en la entrada anterior del blog, una ruta puede tener varios nodos intermedios por los que va saltando el paquete hasta llegar a su destino. En el párrafo anterior hemos contemplado que si una ruta deja de estar activa cierto tiempo debemos asumir que algún enlace de la cadena se ha roto y por tanto tenemos que invalidr la ruta. Bien, pues gracias a que libnl nos permite conocer el estado de los nodos que están cerca nuestra mediante la tabla de vecinos,podemos saber si un vecino ya no está ahí. Si un vecino deja de serlo, libnl nos avisará, y nosotros entonces comprobaremos si teníamos alguna que pasaba por ese vecino. En caso de que sea así, tendremos que borrar la ruta. Esto actualmente no lo tenemos implementado y en AODV es opcional (está contemplado como detalle de implementación), pero planeamos hacerlo.

Documentando el proyecto

Feliz año! La última entrada decía que el trabajo se demuestra andando, pero lo cierto es que si bien nosotros hemos andado mucho en meshias, ha sido en la sombra porque no hemos publicado nada en el blog. Sólo un post! Está claro que a estas alturas ya lo único que podemos hacer es.. documentar mediante el weblog. Y eso intentaré hacer.

¿Qué es Meshias?

Meshias por ahora pretende ser una implementación del RFC experimental 3561, que se refiere al protocolo AODV. AODV es un protocolo de red que permite implementar una red mesh, que es básicamente una red wifi descentralizada que no necesita de puntos de acceso, y cuyo radio de cobertura de la red no es el del punto de acceso/los puntos de acceso de la red como en una red wifi normal (porque como he dicho, no existen puntos de acceso), sino que el radio de cobertura de la red es la unión del radio de todos los nodos de la red.

¿Cómo funciona AODV?

Hablaré muchas veces de AODV y de Meshias indistintamente, pero que quede claro que AODV es el protocolo, Meshias una implementación de éste. Bien. AODV trabaja sobre una red wifi en modo Ad-Hoc. AODV es un protocolo de enrutado, y entra en acción cuando se va a enviar un paquete a una dirección IP hacia la cual no tenemos una ruta conocida. Si tenemos 3 equipos A-B-C y cada equipo solo tiene enlace con los que tiene a su lado, en una red Ad-Hoc normal A nunca podría enviar paquetes a C porque no tiene enlace con él. Con AODV, todos los nodos de la red pasan a ser enrutadores en caso necesario. Así, si A quiere enviar un paquete a C, B haría de paso intermedio, recibiría los paquetes de A y los enviaría a C.

El problema radica en encontrar el camino de A a C, porque puede haber cualquier número de nodos intermedios entre los dos equipos: A-B1-B2-B3…BN-C. AODV se encarga de calcular la ruta de A a C cuando se detecta un paquete dirigido a un equipo (C) cuya ruta es desconocida. Una vez Meshias encuentra la ruta, añade a la tabla de rutas del kernel (puedes consultarla con el comando route -n) y ya está, todo funciona sólo sin necesidad de Meshias, Linux lo hace todo sólito. Meshias deja que se envíe el paquete que había capturado dirigido a C, y el kernel lo enruta y todo funciona de forma transparente.

Meshias volverá a capturar sucesivos paquetes dirigidos a C (y en general captura paquetes dirigidos a cualquier equipo de la red mesh), pero comprobará que ya existe una ruta a C en la tabla de rutas del kernel, y “aceptará” etos paquetes, los dejará pasar de largo para que el kernel de Linux se encargue de enrutarlos.

Encontrando la ruta

Bien, y ahora viene la gran pregunta ¿cómo demonios encuentro la ruta del arroz? Ahí está el quit de la cuestión. La idea es enviar una petición de ruta por broadcast para que todos los equipos que estén dentro de mi rango de cobertura la reciban y la procesen. De esa manera, si desde A queremos encontrar la ruta a C, B recibiría una petición broadcast de A preguntando “¿donde está C?”. B en un principio no sabría donde está C, así que haría exactamente lo mismo. Pero antes se apunta que tiene enlace directo con la ip de A en su tabla de rutas, aprovechando que le ha llegado tráfico de A.

Despues de eso, B  renviaría la petición broadcast que le llega de A. C recibiría una petición de ruta por broadcast enviada por B en nombre de A diciendo “¿donde está C?”, y como Ć lo sabe (es él!), se apunta que tiene una ruta hacia A, que es exactamente la ruta inversa que ha seguido la petición broadcast. Luego de eso, C envia una respuesta a la petición de ruta: una respuesta de ruta.  Se la envía directamente con destino A. Al enviar ese paquete, como ya tenemos la ruta hacia A, el paquete se envía. B lo procesa, y se guarda la ruta hacia C igual que hacemos cada vez que recibimos un paquete AODV. Finalmente esa misma respuesta de ruta llega a A, y se apunta la ruta hacia C en la tabla de rutas. Por fin, despues de eso, Meshias acepta el paquete inicial que iba dirigido a C, y el kernel lo enruta adecuadamente. B recibe ese mismo paquete, y como también conoce una ruta hacia C, hace de router reenviando el paquete, que finalmente llega a C.

Este es, a muy groso modo por supuesto el funcionamiento de AODV.

State of the art

Actualmente tenemos creada  la infraestructura y enviamos y procesamos peticiones de rutas, falta poder procesar respuesta de rutas para que AODV funcione mínimamente. El desarrollo de meshias estuvo parado unos meses por navidades y Enero pero luego, pese a no haber estado publicando en el blog, hemos estado programando, que es lo que realmente nos gusta. El código no lo hemos subido aun sin embargo a la forja de RedIRIS, porque hemos tenido problemas con ella (mi usuario no funciona!). Mientras tanto hemos estado usando Launchpad con bazaar que funcionan muy bien. Podéis descargaros el código de meshias con el siguiente comando:

bzr branch lp:meshias

Para compilarlo, las instrucciones están (en inglés, como todo el código de Meshias) en el fichero COMPILE. Comprobaréis que compila. Se puede ejecutar, pero lo cierto es que actualmente no hemos creado ningún fichero con instrucciones de cómo usar meshias porque aun no es usable. Pronto (esta semana o la siguiente!) lo será, y subiremos instrucciones para poder probarlo en casa. Be tunned!

El trabajo se demuestra mandando andando

Introducción

Es un poco tarde para escribir la primera entrada del blog, pero eso no significa que no hayamos estado trabajando sino todo lo contrario. Pero comencemos por el principio: Dicho así de pronto, Meshias es un proyecto cuyo objetivo es investigar una implementación eficiente de redes mesh para Linux. En este proyecto colaboraremos Alejandro Castaño del Castillo y yo, Eduardo Robles Elvira, estudiantes de la Universidad de Sevilla y miembros de la Asociación SUGUS, además tenemos como mentor del proyecto a Pablo Neira, desarrollador de Netfilter. Eso sin olvidar que este también es mi proyecto de fin carrera .

Akademy

La primera fase del proyecto será hacer una buena implementación del protocolo Ad hoc On Demand Distance Vector (AODV), y eso es precisamente lo que estamos realizando ahora mismo. En el repositorio de subversion se puede ver que estamos trabajando ya en ello. Actualmente todos los commits los ha realizado Alejandro porque estoy teniendo problemas con mi cuenta de subversion que espero que se solucionen en breve.

Durante el Akademy estuvimos trabajando a comenzar sobre la base que había realizado Alejandro, que había estado usando algunos ejemplos de Netlink. AODV se encarga de buscar la ruta correcta para los paquetes que se envían dentro de la red mesh. Por tanto desde el punto de vista del cliente AODV necesita capturar los paquetes que se van a enviar, mirar su dirección IP destino y ver si ya tenemos su ruta en caché. Si no está en caché, buscamos la ruta, y la añadimos a la lista de rutas del kernel en caso de encontrarla, y la cacheamos. Finalmente, se le dice al kernel que envíe el paquete capturado, y él mismo ya sabrá como enrutarlo. Para capturar paquetes y mirar o añadir rutas al kernel estuvimos trabajando las librerías netlink y netfilter_queue, que se comunica con el kernel de manera que al final no necesitaremos más que escribir el código en espacio de usuario correspondiente.

Alejandro había estado usando Makefiles para compilar, y debido a que yo como programador KDE había utilizado CMake y siendo que estabamos con gente que conocía CMake a fondo en el Akademy, fue este el lugar y el momento ideal para pasar a usar CMake como sistema de compilación. Y la verdad es que vale la pena, con unas pocas líneas muy fáciles de entender y mucho menos farragosas / a bajo nivel que los Makefiles, CMake hace lo mismo y mejor.

Ayer por la mañana llegamos Alex y yo de A Coruña (donde se celebró el Akademy-es 2008 que fue genial) y fuimos directamente a parar al despacho de Pablo y estuvimos 2 horas allí hablando, aclarando dudas, nos explicó como funcionan netfilter y netlink entre otras cosas, la verdad es que fue bastante productivo. Como conclusión, vamos a usar libnl en vez de netlink porque es un wrapper sobre netlink que lo abstrae y nos facilita el trabajo.

Ya han comenzado los examenes de diciembre y los primeros parciales y la verdad es que resulta algo complicado sacar tiempo para el proyecto, pero cuando uno tiene interés en algo siempre encuentra un momento para dedicárselo así que seguro que espero que pronto tengáis más noticias nuestras.