Portal

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE

ADMINISTRACIN EN UN

ENTORNO WI

Memoria del proyecto de

Informtica de Sistemas

Escuela Universitaria de Informtica Sabadell, junio de 2010

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE

ADMINISTRACIN EN UN

ENTORNO WI-FI ABIERTO

Memoria del proyecto de Ingeniera Tcnica en

Informtica de Sistemas Realizado por

Alberto Moral Gmez Y dirigido por

David Megas Jimnez

Escuela Universitaria de Informtica Sabadell, junio de 2010

1

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE

ADMINISTRACIN EN UN

FI ABIERTO

i

El firmante, David Megas Jimnez, Profesor de la Escuela de Ingeniera de la UAB,

CERTIFICA:

Que el trabajo al que corresponde la presente memoria ha sido realizado bajo su direccin por Alberto Moral Gmez

Y para que conste firma la presente. Sabadell, junio de 2010

------------------------------

Firmado: David Megas Jimnez

iii

Resumen

Aunque estemos en el siglo XXI todava hay zonas geogrficas donde conectarse a Internet es imposible, debido a que la lnea de ADSL de las compaas no llega a todas las partes de Catalua (en Catalua o cualquier otro territorio). Es por ese motivo por el que se ha creado una nueva topologa de red.

Ya hay ms de 9.000 nodos esparcidos por Catalua, sobretodo, ubicados en zonas cuyo acceso al ADSL es nulo: pueblos, casas aisladas en la montaa, etc. En este proyecto queremos que todos los usuarios que se conecten a nuestro nodo tengan la oportunidad de navegar por Internet.

Por eso se han ido interconectando estos nodos, de este modo todos estos usuarios afectados puedan crear una red con una infraestructura ms dinmica y navegar por Internet, algunos compartiendo su conexin a Internet y otros que no pueden tener una lnea de ADSL ir interconectndose con los nodos para llegar a un nodo con conexin.

Aparte de crear el sistema operativo para que esto sea posible, se ha creado un portal para informar al usuario y dar mayor ayuda a los usuarios que tienen un nodo y no saben cmo utilizarlo. Para ello se ha creado un manual.

Todos estos pasos se explican detalladamente a continuacin; mostrando desde el montaje de un nodo hasta su correcto funcionamiento.

v

Tabla de Contenidos

Resumen iii

Tabla de Contenidos v

Captulo 1: Introduccin 1 1.1 Presentacin 1 1.2 Estado del arte 2 1.3 Objetivos 3 1.4 Organizacin de la memoria 3

Captulo 2: Anlisis del sistema Actual 5 2.1 Introduccin a las redes mesh 5 2.1.1 Esquema clsico 5 2.1.2 Esquema mesh /ad-hoc 6 2.1.3 Servicio de conexin a Internet 7 2.2 Estudio de Viabilidad 8 2.2.1 Introduccin 8

2.2.2 Estudio de la situacin actual 10 2.2.3 Requisitos del proyecto 12 2.2.4 Alternativas y seleccin de la solucin 13 2.2.5 Planificacin 14 2.2.6 Evaluacin de riesgos 17 2.2.7 Presupuesto 18

2.3 Montaje del nodo 20

Captulo 3: Diseo del sistema 23 3.1 Anlisis de requerimientos 23 3.1.1 Requerimientos previos 23 3.1.2 Requerimientos funcionales 25 3.1.3 Requerimientos no funcionales 26 3.2 Descripcin de la plataforma 27 3.2.1 Introduccin 27 3.2.2 Sistema operativo 28 3.2.3 Directorios 29 3.2.4 Iptables 29 3.2.5 Wifidog 30 3.2.6 Estructura 33

Captulo 4: Implementacin 35 4.1 Introduccin 35

4.2 Estructura 35 4.2.1 Pgina principal 35 4.2.2 Administrador 36

Captulo 5: Mantenimiento y pruebas 45

Captulo 6: Conclusiones 47 6.1 Conclusiones globales 47

6.2 Ampliaciones 49

Bibliografa 49

Agradecimientos 51

Anexo A: Creacin del firmware 53

Introduccin

1

1. Introduccin

1.1. Presentacin

Este proyecto se basa en la creacin de un portal cautivo en un S.O. que funciona en dispositivos empotrados. Este S.O. se llama OpenWRT, que configurado correctamente proporciona una conectividad inalmbrica Wi-Fi bajo el estndar 802.11.

El firmware se implementa en OpenWRT, distribucin de GNU/Linux para dispositivos empotrados, que junto a unos protocolos de encaminamiento y otras utilidades se pueden conectar a una red mesh como las de guifi.net o graciasensefils.

La versin de OpenWRT que se utiliza es la Kamikaze 8.09.1. Aunque no es la ms reciente, goza de la ventaja de haber sido probada y mejorada por los usuarios. Por lo tanto, no es extrao que proporcione proporciona mayor fiabilidad.

Una vez creada la base del firmware con los paquetes necesarios para su correcto funcionamiento se ejecutar Wifidog, ste es un paquete de Kamikaze que se utiliza para bloquear el trfico a Internet hasta que un usuario se autentifique en un servidor.

Guifi.net da acceso a Internet de una forma libre, por lo tanto un objetivo bsico es que los usuarios no tengan que autenticarse. Debido a esto se ha buscado otra forma para no tener que registrarse. De esta manera a un usuario le aparece el portal cautivo y slo tiene que leer una normativa, y si est de acuerdo, slo debe pulsar un botn. Antes de esto, el usuario tiene la opcin para entrar a la pgina de guifi.net e informarse de todo su contenido con mayor detalle.

A medida que los usuarios se conectan al nodo, se va guardando informacin til para luego poder generar ficheros con datos posteriormente, con la finalidad de ayudar al administrador facilitndole informacin de lo que ocurre en su nodo.

Desarrollo de un portal cautivo y herramientas de administracin en un entorno Wi-Fi abierto

2

1.2. Estado del arte

Actualmente guifi.net posee un portal cautivo desarrollado con el paquete Squid, pero desde un principio siempre quisieron utilizar Wifidog. Sin embargo, no consiguieron ejecutarlo correctamente y decidieron buscar otra alternativa.

El portal actual slo posee un texto de bienvenida y un botn para aceptar su conexin y navegar por Internet.

Figura 1.1 portal cautivo de graciasensefils [http://graciasensefils/splash/]

Como se puede observar no hay posibilidad para cambiar el mensaje del nodo, ni subir fotos, ni tener un control del nodo de una manera eficaz, etc. Es esa la razn por la que en el proyecto se han desarrollado todas estas funciones para que el propietario del nodo, al ofrecer su conexin a Internet a otros usuarios pueda dar a conocer su negocio subiendo fotos y comentarios para hacer publicidad de su negocio. Tambin los usuarios que no poseen conocimientos sobre GNU/Linux o redes en la seccin del administrador se les han asignado comandos para ir monitorizando lo que ocurre en su nodo, todo con una explicacin y un manual en formato pdf.

1.3. Objetivos

El objetivo principal es que los usuarios que se conecten al nodo se les aparezcan un portal cautivo, bloqueando todo tipo de conexin hasta que no se acepte una normativa.

Una vez aceptado el usuario podr navegar libremente, con todos los puertos necesarios abiertos y sin ningn tipo de restriccin. Pasado cierto

Introduccin

3

tiempo el portal volver a recordar a los usuarios que estn utilizando esa conexin gracias a guifi.net.

Como todos los usuarios que se conectan al nodo son annimos, no necesitan dejar ningn tipo de identificacin, por eso cada vez que un usuario se conecte al nodo se generar un registro donde se guardaran la direccin IP y hora de cada usuario, para llevar un control y generar informes para el administrador.

El administrador tendr su propio espacio en el portal cautivo, dnde podr autenticarse como tal y ver el funcionamiento del nodo, subir archivos al servidor, modificar una pequea parte del portal o ejecutar algn comando para monitorizar el nodo.

Otra parte consiste en el montaje de un nodo, con todos los componentes necesarios para proporcionar una conexin Wi-Fi.

1.4. Organizacin de la memoria

La memoria se ha estructurado en seis captulos:

Inicialmente, se ha elaborado un resumen donde se explica de qu consta el proyecto y seguido de la tabla de contenidos.

A continuacin est el primer captulo, una introduccin sobre la base del proyecto, y los objetivos a cumplir.

El segundo captulo contiene una pequea introduccin sobre el funcionamiento del tipo de red utilizada, un estudio de viabilidad, y para acabar fotos de los componentes del nodo y su correcto montaje para luego instalarlo en un tejado.

En el tercer captulo, se explican los requerimientos del proyecto y conocimientos bsicos: el sistema operativo utilizado, teora para comprender mejor el funcionamiento del portal y, por ltimo, cmo se han estructurado las pginas Web en el servidor.

En el cuarto captulo se explica cmo se han desarrollado las pginas Web para que el usuario pueda utilizar comandos y obtener informacin de lo que ocurre en su nodo y tambin cdigos en PHP con la finalidad de modificar el portal.

El quinto captulo describe las pruebas y el mantenimiento del nodo, se utiliza un programa que intercepta paquetes para verificar que el portal cautivo funciona correctamente.


4

El ltimo captulo resume las conclusiones extradas a lo largo de todo el proyecto.

Finalmente, se detalla la bibliografa donde se describirn todas las fuentes utilizadas y para acabar, la ltima seccin, la de agradecimientos.

Anlisis del sistema actual

5

2. Anlisis del sistema actual

2.1 Introduccin a las redes mesh

2.1.1 Esquema clsico

El mtodo clsico de red es una topologa estrellada con infraestructura [5]. Es el caso de la figura 2.1, dnde todos los nodos estn conectados directamente a un punto central y todas las comunicaciones se han de realizar a travs de este supernodo, el cual puede comunicarse con otro abarcando grandes distancias.

Figura 2.1 Esquema clsico

Los nodos de esta red, no interactan directamente entre s, sino que deben conectar primero con el nodo en modo mster, que es el que distribuir las solicitudes a los otros nodos.

Inconvenientes: Si falla el nodo en modo mster, se desconectara esa rama de la red, dejando los nodos totalmente incomunicados, figura 2.2.

Figura 2.2 Fallo en el esquema clsico


6

2.1.2 Esquema mesh / ad-hoc

Esta topologa combinada con unos protocolos de encaminamiento, nos proporciona ms estabilidad porque un nodo se conecta con todos los que tenga a su alrededor, siempre que est a su alcance, figura 2.3.

Figura 2.3 Red mesh

Si tuviramos un fallo entre los nodos, los protocolos de encaminamiento se encargaran de buscar un nuevo camino hacia el destino. Figura 2.4.

Figura 2.4 Fallo en red mesh

La red en modo ad-hoc no tiene un nodo central, por lo tanto todos los nodos estn en igualdad de condiciones. Con la posibilidad de buscar varios caminos alternativos en caso de error.

__________________________________________________________________________Anlisis del sistema actual

7

2.1.3 Servicio de conexin a Internet

Los nodos configurados como proveedores de Internet, al tener una conexin directa, por defecto utilizan esta conexin para acceder a Internet [4], como muestra la figura 2.5.

Los nodos que no tienen proveedor de Internet lo que hacen es buscar un camino hasta los nodos proveedores, puede haber caminos alternativos, pero siempre se escoger el mejor (los protocolos de encaminamiento se encargan de ello), figura 2.6.

Figura 2.5 Proveedor de Internet Figura 2.6 Ruta alternativa

Estos nodos que estn configurados como proveedores de Internet comprueban constantemente la conexin directa a Internet, para saber si hay fallos o no. En caso de perder la conexin directa a Internet el nodo que estaba configurado como proveedor de Internet deja de serlo y busca a otro candidato, hasta que no recupera su conexin directa otra vez. Todo este procedimiento es transparente para el usuario. Como ya he mencionado anteriormente, los protocolos de encaminamiento se encargan de buscar el mejor camino hacia Internet.

Se ha utilizado una aplicacin para este tipo de red, que en cuanto un usuario se conecta aparezca un portal cautivo que avisa de una normativa que puede ser aceptada para que los usuarios puedan navegar libremente, utilizando todas las ventajas de la red mesh.


8

2.2 Estudio de viabilidad

2.2.1 Introduccin

2.2. 1.1 Tipologa:

Desarrollo de un portal cautivo y herramientas de administracin en un entorno Wi-Fi abierto.

2.2. 1.2 Descripcin:

El proyecto a realizar ir destinado exclusivamente a aquellos nodos que utilizan distribuciones de OpenWRT basado en GNU/Linux. stos se utilizan por guifi.net para dar acceso a una red mesh.

La funcin principal del proyectista es crear un portal cautivo incluyendo el correcto montaje de un nodo para que los usuarios puedan conectarse a l y compartir una conexin a Internet. OpenWRT ya posee varios paquetes que podran hacer de portal cautivo, pero se alejan de los objetivos finales, como la utilizacin de bases de datos para almacenar usuarios con contrasea. Sin embargo esto cargara demasiado al nodo y no cumplira los objetivos del proyecto.

2.2. 1.3 Objetivos del proyecto:

Los objetivos que son expuestos van de mayor prioridad a menor:

Ofrecer una interfaz para el portal cautivo. Autenticar al propietario del nodo. Visualizar una parte esttica que se muestre en todos los nodos. Monitorizar actividades que se ejecutan en el nodo. Monitorizar a los usuarios conectados en el nodo. Parte dinmica que pueda ir cambiando el propietario del nodo. Subir imgenes con comentarios. Permitir acceso a la pgina de guifi.net para dar ms informacin. Dividir el portal en un mensaje, parte modificable, y un men. Montaje del nodo.


9

2.2. 1.4 Definiciones, acrnimos y abreviaciones

Host: Ordenador que funciona como el punto de inicio o final de las transferencias de datos.

Ad-Hoc: Red inalmbrica descentralizada.

Nodo: Es un router que se conecta con otros formando una red mesh.

S.O.: Sistema operativo.

Shell Script: Lenguaje de programacin que en este proyecto se utiliza para interactuar con el servidor y obtener datos de l.

2.2. 1.5 Partes interesadas

Perfiles de usuario

Perfil Responsabilidad Administrador del

nodo Podr acceder al portal cautivo mediante autenticacin y podr modificar su interfaz Web, y tambin monitorizar

desde los usuarios conectados al nodo hasta los procesos ejecutados en l.

Usuario El usuario slo podr ver el mensaje de bienvenida del portal cautivo y el mensaje del propietario del nodo.

Equipo de proyecto

Descripcin Responsabilidad

Analista Colabora con el Director de proyectos en el estudio de viabilidad i la planificacin del proyecto.

Programador Disea y desarrolla la aplicacin de acuerdo con el anlisis y planificacin prevista.

Tcnico de pruebas Realiza las pruebas del software y participa en el control de calidad.

Tcnico de hardware

Montaje un nodo.

Director del proyecto Supervisa el trabajo del proyectista


10

2.2.2 Estudio de la situacin actual

2.2. 2.1 Contexto

La red mesh es una red ad-hoc descentralizada, por lo tanto, cada nodo puede reenviar los datos a los dems y la decisin de que nodos envan a los dems se crea de forma dinmica gracias a los protocolos de encaminamiento. Difiere de las redes inalmbricas convencionales.

En la figura 2.7 se observa que todos los nodos de color rojo, estn conectados entre s. Si un nodo dejara de funcionar, se calculara otra ruta para contactar con el destino al que se quiera llegar. El nodo de color negro est tan separado de los dems que no puede comunicarse con ellos, por lo tanto ese nodo no puede acceder a ninguno.

Figura 2.7 Ejemplo nodos conectados

Son conexiones inalmbricas por lo tanto los nodos deben situarse en puntos elevados, lo ms altos posibles como tejados, chimeneas, etc. Una buena colocacin proporcionar una mejor recepcin de la seal, hecho que conlleva a una mayor calidad en la conexin.

2.2. 2.2 Desarrollo del proyectista

Guifi.net ya dispone de un portal cautivo, pero slo muestra un mensaje de bienvenida, una simple pgina en HTML. Sin embargo, lo que se pretende es que el usuario tenga cuatro partes bien diferenciadas cuando visualice el portal cautivo:

La primera parte ser esttica. Todo host cuando se conecte al nodo ver un mensaje, por ejemplo Bienvenido a la red guifi.net. Este mensaje ser comn para todos los nodos.


11

La segunda parte ser dinmica. El propietario del nodo podr modificar el portal cautivo, poniendo texto y fotos con comentarios. As cuando los usuarios se conecten a ese nodo podrn ver la publicidad o el texto redactado del administrador.

La tercera parte es un men bastante simple pero que proporciona informacin tanto a los usuarios como al administrador.

La cuarta parte ser un espacio reservado para el administrador con herramientas de administracin y monitorizacin del nodo.

2.2. 2.3 Usuario y/o personal del sistema

Perfil

Responsabilidad

Administrador del nodo

Podr acceder al portal cautivo mediante autenticacin y podr modificar su interfaz web, y tambin monitorizar desde

los usuarios conectados al nodo hasta los procesos ejecutados en l.

Usuario El usuario slo podr ver el mensaje de bienvenida del portal cautivo y el mensaje del propietario del nodo.

2.2. 2.4 Diagnstico del sistema

o Deficiencias

El portal cautivo es muy simple visualmente. No se puede modificar ni subir fotos. No distingue entre administrador y usuario. No se obtiene informacin del nodo. No hay ningn control sobre los usuarios conectados al

nodo.


12

o Mejoras

Aspecto ms atractivo Posibilidad de ser modificado. Enlace con pgina de guifi.net Espacio para el administrador Monitorizacin del nodo Informacin sobre los usuarios conectados al nodo. Herramientas de administracin

2.2.3 Requisitos del proyecto

2.2. 3.1 Requisitos funcionales (RF):

1 Visualizacin portal cautivo 2 Autenticacin por parte del usuario del nodo 3 Visualizacin de un mensaje de bienvenida 4 Monitorizacin de actividades/usuarios en el nodo 5 Modificacin del portal con capacidad para soportar imgenes 6 Conexin externa con guifi.net para obtener mayor informacin 7 Estructuracin del portal 8 Montaje del nodo

2.2. 3.2 Requisitos no funcionales (RNF):

1 Rendimiento del sistema 2 Disponibilidad de servidor 3 Calidad de imagen 4 Eficiencia 5 Soporte 6 Necesidad de recursos 7 Velocidad de carga del portal


13

2.2. 3.3 Restricciones

1 La aplicacin se ha implementado utilizando software libre. 2 El proyecto ha de estar finalizado antes del 30 de Junio. 3 El portal cautivo puede que no funcione en todos los nodos. Puede

necesitar que se instalen algunos paquetes que no posee.

2.2. 3.4 Catalogacin y priorizacin de los requisitos funcionales (RF)

1 2 3 4 5 6 7 8 Esencial X X X

Condicional X X X Opcional X X

2.2. 3.5 Catalogacin y priorizacin de los requisitos no funcionales (RNF)

1 2 3 4 5 6 7 Esencial X X X

Condicional X X X Opcional X

2.2.4 Alternativas y seleccin de la solucin

El desarrollo del proyectista se har basndose en un paquete: Wifidog que es compatible con Kamikaze 8.09.1, en caso de no tener xito se buscaran soluciones como:

Alternativa 1: Si el paquete de Wifidog no es compatible con Kamikaze, se implementara en otra versin llamada WhiteRussian, sta es una versin ms antigua y ms testeada por los usuarios.

Alternativa 2: Crear un servidor con el paquete Lighttpd, servidor muy completo que destaca por su rapidez, y con algn lenguaje de programacin bloquear todo tipo de conexiones.


14

Alternativa 3: Se utilizara otro paquete que incorpora GNU/Linux, llamado Squid, el cual posee un Proxy cach para dar mayor velocidad a la hora de re direccionar pginas.

2.2.5 Planificacin del proyecto

Antes de todo, es necesario explicar que este proyecto tiene un desarrollo evolutivo, es decir, el proyectista tiene una ligera idea de los requerimientos, pero no todos son conocidos al inicio del proyecto. Esto implica que requiere un especial cuidado en la manipulacin de documentos, cdigos de ejecucin, etc. Cada cambio en el proyecto debe ser registrado para que los documentos sean fcilmente recuperables, todo esto dependiendo de la fase.

2.2. 5.1 Planificacin

Calendario del proyecto: el proyecto se desarrollar de octubre del 2009 hasta el 29 de Junio del 2010 Fecha de comienzo: 1 de Octubre del 2009 Fecha de finalizacin: 20 de Junio del 2010 Herramientas de planificacin: Microsoft Project 2007 (Diagramas de Gantt)

2.2. 5.2 Recursos del proyecto

Recursos humanos Valoracin

Jefe de proyecto 40/h

Programador Analista Tcnico de pruebas

Tcnico de hardware

20/h

Reuniones con la comunidad 0/h


15

2.2. 5.3 Planificacin del proyecto con MSProject

# Tarea Duracin

1 Estudio y documentacin guifi.net 25

2 Documentacin Portales cautivos 32

3 Estudio y documentacin Ubuntu 30

4 Reuniones con la comunidad 12

5 Estudio de viabilidad 15

6 Aprobacin del estudio de viabilidad 2

7 Anlisis de requisitos 20

8 Montaje del nodo 5 9 Creacin del portal cautivo

10 - Base del firmware instalada 15

11 - Descargar paquete Wifidog 3

12 - Configuracin Wifidog 40

13 - Creacin pgina Splash 75

14 - Creacin del nuevo firmware 3

15 Realizacin pruebas 15

16 Finalizacin memoria 5

Duracin Total de la planificacin 297


16

2.2. 5.4 Planificacin Diagrama de Gantt

Figura 2.8 Diagramas de Gantt

Figura 2.9 Diagramas de Gantt


17

2.2.6 Evaluacin de riesgos

2.2. 6.1 Riesgos

R1. Planificacin temporal optimista: no se acaba en la fecha prevista, los recursos aumentan y por lo tanto el coste sera mayor.

R2. Falta alguna tarea: volver a reconstruir la planificacin, retraso en el proyecto.

R3. Cambio de requisitos: retraso en el proyecto.

R4. Posibilidad de que los nodos se averen: volver a comprar otros, aumento de presupuesto.

R5. Diferentes versiones de los nodos: puede que el software desarrollado slo funcione en unos nodos con un firmware especfico.

R6. Abandonar el proyecto antes de su finalizacin: no se cumplen los objetivos, frustracin por parte del proyectista.

2.2. 6.2 Medidas

R1. Afrontar que no se acabar en ese perodo y asumir que habr prdidas.

R2. Modificar el estudio de viabilidad en el apartado de planificacin y asumir que podra variar el presupuesto.

R3. Modificar el estudio de viabilidad en el apartado de planificacin y asumir que podra variar el presupuesto.

R4. Comprar otros nuevos, aumento del presupuesto del proyecto.

R5. Documentarse de los tipos de nodos que hay y mirar de instalar los paquetes necesarios para que el software desarrollado funcione.

R6. No tiene solucin.


18

2.2.7 Presupuesto

2.2. 7.1 Estimacin coste de personal

Personal Horas Coste Proyectista* 297 5.940

* El proyectista a lo largo del proyecto realizar funciones de analista, programador, realizador de pruebas y tcnico de hardware.

2.2. 7.2 Estimacin coste de recursos

Coste amortizacin

Coste Periodo amortizacin

Periodo utilizacin

PC 375 1500 36 m 9 m

VMware 20 80 36 m 9 m

Ubuntu * * * *

OpenOffice.org * * * *

MSProject 90 360 36 m 9 m

* Es gratuito

TOTAL = 547,5

El proyectista incluye cada componente que tiene un nodo con su respectivo precio [11]:

MATERIAL Cantidad Precio

PC- engines ALIX 2D2 LX800 2 LAN 2 MPCI256 MB USB

1 83,80

Fuente de alimentacin 18 v. 0,8 A (15 W) 1 5,93 Compex WLM54SAG23 802.11 AGB 200mW 108 Mb/s

2 24,40

Pigtail 5 GHz UFL-N Jack Bulkhead 30 cm 2 5,19


19

MATERIAL Cantidad Precio

Antena Dipolo DUAL 5/2,4 Ghz 7 dBi Connector N Macho

2 22,28

Caja Universal IP65 ABS con conector RJ45 incluido

1 24,40

CompactFlash Transcend TS2GCF133 (4GB) 1 15,5 Total* 233,37

I.V.A ( 16% ) 37,34 Total Presupuesto Nodo 270,71

TOTAL= 270,71

2.2.7.3 Resumen del presupuesto

Coste del desarrollo del proyecto5.940

Coste de amortizacin del material.....817,6

TOTAL 6.757,6


20

2.3 Montaje del nodo

En esta seccin se detalla de qu componentes est formado el nodo y como montar uno en pasos muy reducidos para ms tarde instalarlo en el hogar.

Componentes: 1xCaja estanca 1xPlaca Alix c2c 2xMini-PCI 1xTarjeta CompactFlash 2xPigtails 2xAntenas

Caja estanca

En la caja donde irn todos los componentes electrnicos del nodo, se tiene que hacer tres agujeros, dos para la colocacin de las antenas, y otro para la salida de la corriente y cable Ethernet (Algunos nodos no necesitan cable de corriente ya que se alimentan directamente por el de Ethernet utilizando PoE).

Alix c2c con las Mini-PCI

Figura 2.10 Placa Alix


21

Conectamos en la placa las 2 Mini-PCI. De cada Mini-PCI se le conectar un pigtail que ir conectado a la base de una antena. Es decir un Mini-PCI para la antena de 2,4 Ghz y otra mini-PCI para la antena de 5 Ghz conectados mediante los pigtails.

Una vez hecho esto se mete la placa en la caja y se atornilla en los extremos para inmovilizarla.

Insertamos la CompactFlash con nuestro sistema operativo en la nica ranura posible, en la figura 2.10 se observa que est en la parte superior derecha.

Se conecta el cable RJ-45 y el de corriente (si fuera necesario) y se extraen por el tercer agujero hecho en la caja, una vez sacados se cierra presionando bien los tornillos para que encaje perfectamente.

Recordamos que la caja estar al aire libre sufriendo todo tipo de condiciones atmosfricas.

Finalmente se subira el nodo al tejado con un cable RJ-45 lo suficientemente largo para que llegue al interior del hogar, figura 2.11.

Se colocar el nodo en una zona lo ms elevada posible para tener una mejor conexin con los nodos vecinos, figura 2.12.

Figura 2.11 Montaje del nodo

Figura 2.12 Colocacin del nodo


22

Diseo del sistema

23

3. Diseo del sistema

3.1 Anlisis de requerimientos

En esta seccin se tratarn y analizarn los requerimientos, tanto desde la creacin del firmware como del correcto funcionamiento del paquete Wifidog.

Estos requerimientos pueden variar, debido a los rpidos cambios de las versiones de Kamikaze. Es posible que el paquete de ste no funcione en segn qu versiones, o que el paquete descargado no sea el idneo para la arquitectura del nodo.

3.1. 1 Requerimientos previos

El proyectista empezar a explicar estos requerimientos, ya que si no se cumplieran no funcionara Wifidog, por lo tanto se han de seguir ciertos pasos para compilar el firmware.

RP1: Compilador

Es necesario tener una mquina que sea capaz de compilar el firmware. Se utilizar una mquina virtual en un ordenador, con el S.O. Ubuntu, que posee todo lo necesario para compilar con xito el firmware. Para que funcione el compilador tiene que haber una serie de paquetes instalados en el sistema, de no ser as se tienen que descargar e instalar.

RP2: Acceso a Internet

Al generar el firmware con los paquetes que hayamos seleccionado en el make menuconfig, tendr que acceder a Internet para podrselos descargar e incluir en el firmware.

RP3: Grabador CompactFlash

Una vez finalizado el proceso del firmware, el proyectista tendr que copiar la imagen generada durante la compilacin en la CompactFlash.


24

RP4: Paquetes

Uno de los paquetes esenciales es Wifidog. ste es un paquete que podemos encontrar en el repositorio de Kamikaze concretamente el de la versin 8.09.1.

Para poder utilizar Wifidog, primero deberemos instalar una serie de paquetes:

IPTABLES 1.4.0-1 IPTABLES MOD CONNTRACK 1.4.0-1 IPTABLES MOD EXTRA -1.4.0-1 IPTABLES MOD IPOPT -1.4.0-1 IPTABLES MOD NAT 1.4.0-1 IPTABLES MOD NAT EXTRA 1.4.0-1

KMOD IPIP 2.6.25.17 x86-1 KMOD IPT CONNTRACK 2.6.25.17-x86-1 KMOD IPT CORE 2.6.25.17-x86-1 KMOD IPT EXTRA 2.6.25.17-X86-1 KMOD IPT IPOPT 2.6.25.17-X86-1 KMOD IPT NAT EXTRA 2.6.25.17-X86-1 KMOD IPT NATHELPER - 2.6.25.17-X86-1

OPKG 4564 3 (Paquete que permitir instalar y actualizar paquetes en el sistema)

PHP4 4.4.7 1 (Utilidad para poder ejecutar cdigo PHP en las pginas del servidor, fichero que ha de ser configurado)

WIFIDOG 1.1.5 2 (Paquete para anular todo tipo de trfico a los usuarios que se conecten al nodo)

VI (Editor de textos)

__________________________________________________________________________________Diseo del sistema

25

3.1. 2 Requerimientos funcionales

RF1: Visualizacin portal cautivo

Este requerimiento es prioritario a todos los dems, es la base para que el proyecto tenga xito y se puedan cumplir los dems objetivos. En esta pgina aparecer un botn donde el usuario, despus de leer la normativa, podr aceptar para navegar libremente por Internet.

RF2: Autenticacin por parte del propietario del nodo

El propietario del nodo tendr un usuario y contrasea dnde podr acceder a la informacin del nodo, usuarios conectados, grficas, estadsticas, monitorizacin del correcto funcionamiento de los protocolos y ms herramientas.

RF3: Monitorizacin de actividades/usuarios en el nodo

Una seccin importante del portal, es que el propietario del nodo podr extraer informacin de los usuarios conectados a l. Tambin podr monitorizar los procesos que se estn ejecutando en el nodo y ejecutar comandos para informarse sobre las interfaces activas, calidad de la seal Wi-Fi, etc.

RF4: Modificacin del portal

Una vez identificado el propietario del nodo, podr subir fotos y distribuir su pgina a convenir, por ejemplo si el propietario del nodo tiene un bar, podr poner el men del da, la carta con sus precios, horarios de apertura, etc.


26

RF5: Conexin externa con guifi.net para obtener mayor informacin

En el portal cautivo se hallar cierta informacin sobre la red de guifi.net, pero en una versin muy reducida, por eso se da la posibilidad de que los usuarios puedan acceder a todo el contenido de la pgina de guifi.net.

RF6: Estructuracin del portal

El portal cautivo estar dividido por tres partes. Cada seccin tendr una finalidad distinta, un men, una normativa que ser igual en cada nodo y el mensaje del propietario del nodo.

3.1. 3 Requerimientos no funcionales

RNF1: Rendimiento del sistema

Se calcula que el nmero de personas que se conecten al nodo sea de aproximadamente veinte personas. Un nmero superior podra influir en el rendimiento del sistema y ralentizar el nodo.

RNF2: Disponibilidad del servidor

Si el servidor de guifi.net no est disponible por mantenimiento, cambio de web, etc., el usuario no podr acceder para informarse.

RNF3: Calidad imagen

El nodo tiene espacio limitado, en el caso del proyectista una CompactFlash de 4 Gb, para asegurarnos de tener espacio en un futuro se recomienda subir imgenes lo ms pequeas posibles ya que as tardarn menos en cargarse y ocuparn menos espacio.


27

RNF4: Eficiencia

Dado el poco conocimiento previo, se intentar hacer que funcionen los objetivos prioritarios aunque tengan consecuencias en el rendimiento, como por ejemplo mucha carga en CPU o uso de memoria excesivo.

RNF5: Soporte

En caso de algn tipo de duda o problema, el usuario deber ponerse en contacto va E-mail con algn tcnico de guifi.net o en el foro de guifi.net. La respuesta puede demorarse.

RNF6: Necesidad de recursos

Los nodos tienen poca capacidad de almacenamiento, memoria, etc. Por lo tanto se tendrn que optimizar, reduciendo imgenes para que ocupen menos espacio, permitir que el propietario del nodo tenga informes del consumo de cada usuario, por si alguno tiene un uso demasiado elevado, etc.

RNF7: Velocidad de carga del portal

Si el usuario no respeta unas pautas, como tener un tamao reducido en la calidad de las imgenes puede que el tiempo de carga del portal sea excesivo.

3.2 Descripcin de la plataforma

3.2.1 Introduccin

Se ha estructurado este apartado en varias partes para que se pueda ir asimilando poco a poco todo el proyecto.

Hay desde una pequea explicacin del sistema operativo donde se ha implementado el proyecto hasta un fragmento donde se especifica cmo estn distribuidas las pginas del portal cautivo.


28

3.2.2 Sistema Operativo

Se ha desarrollado su proyecto en un sistema operativo distribuido por GNU/Linux y que se utiliza en dispositivos empotrados [7]. En este caso, un router. OpenWRT no tiene interfaz grfica, es decir, slo se puede utilizar la lnea de comandos, lo que conlleva a tener un dominio bsico del sistema operativo.

OpenWRT posee 2 versiones: WhiteRussian y Kamikaze, sta ltima ha sido la elegida ya que es la ms reciente, pero tiene un inconveniente, ya que cada cierto tiempo se va actualizando puede que no funcionen los paquetes de otras versiones. Tiene licencia GPL, por ello se pueden encontrar diferentes versiones ya que los usuarios pueden modificar archivos del propio S.O. e instalar los paquetes que crean necesarios.

Al ser distribuido por GNU/Linux tiene comandos muy similares, pero no iguales, ya que al ser ms ligero el S.O. los comandos no tienen todas las funciones.

Por ejemplo, el comando grep si lo ejecutamos en el nodo, nos aparece las opciones de la figura 3.1, pero si lo ponemos en una versin de GNU/Linux para dispositivos que no son empotrados nos salen tres veces ms de opciones para poder utilizar.

Figura 3.1 Captura opciones del comando grep en Kamikaze

Siempre se ha tenido en cuenta todos los comandos del nodo, ya que pueden funcionar en una versin de GNU/Linux, y luego al pasar el cdigo al nodo, no funcionar.


29

3.2.3 Directorios

Los directorios que tiene son similares que en Linux [1], pero destacaremos dos. En stos se hallan los archivos ms importantes para el correcto funcionamiento del proyecto.

/etc

Aqu se hallarn dos archivos esenciales wifidog.conf y php.ini y los archivos de configuracin del sistema. El primero da unas caractersticas especficas de la configuracin de Wifidog y el segundo se ha de modificar y permitir funcionalidades para poder ejecutar cdigo PHP en las pginas web del servidor.

/www

En este directorio se hallar toda la configuracin del portal cautivo. Desde las pginas Web en Shell Script, HTML, PHP hasta las imgenes utilizadas en estas pginas.

Tambin podemos encontrar los archivos de texto que formarn el portal cautivo: el ttulo, el texto y los comentarios de las fotos que ponga el administrador.

3.2.4 Iptables

En ocasiones el trmino Iptables [8] se confunde con Netfilter. ste ltimo es un Framework situado en el ncleo de Linux que permite interceptar y manipular paquetes de red en diferentes estados del procesamiento.

Iptables es el componente ms popular de Netfilter, se utiliza para que un administrador cree sus propias polticas o normas de envo o recepcin de paquetes. Para aclararlo, sera similar a un portero de discoteca, donde la cola de gente seran los paquetes que llegan de Internet y que ms tarde el portero analizar. ste posee una lista con una serie de normas en la vestimenta, tipo de peinado, etc. Si una persona no la cumple, no puede dejarla pasar.

ste es un ejemplo muy simple, pero deja bastante claro el concepto de las Iptables. Al ejecutar Wifidog, crea una serie de Iptables, normas que han de cumplir los paquetes que son interceptados por el nodo, al principio bloquean todo tipo de trfico y redirigen al portal cautivo a todos los usuarios.

Wifidog est diseado para que los usuarios se autentiquen en el servidor, y cuando lo hagan se les da el privilegio de navegar por la red mesh.


30

Pero en nuestro caso no queremos que los usuarios se autentifiquen, queremos una red libre sin restricciones. Por eso, mientras que el programa mientras espera una autenticacin lo que hacemos es crear las dos Iptables bsicas para que el usuario si acepte la normativa pueda navegar.

Wifidog sigue ste pseudocdigo:

Si El usuario tiene una Iptable que deja de redirigirlo al portal cautivo

Si El usuario tiene una Iptable que le da acceso a Internet

Usuario con conexin a Internet

Si no

Por mucho que deje de redirigirse al portal cautivo, si no tiene una va de salida, jams podr ir a Internet

Si no

Siempre se redirigir al portal cautivo

3.2.5 Wifidog

Para instalar Wifidog [6] deberemos seleccionarlo antes de compilar nuestro propio firmware. Con el comando make menuconfig, en la seccin Network en Portales cautivos. Este proceso se explica ms detalladamente en el Anexo A.

Una vez instalado, Wifidog crea un archivo de configuracin en el directorio /etc llamado wifidog.conf, ste archivo se modifica con los parmetros deseados:

- Interfaz de entrada - Interfaz de salida a Internet - Direcciones IP que sern bloqueadas - Direcciones IP que permitiremos conectarse a los usuarios - Puerto que utilizar Wifidog


31

Anteriormente se explica que Wifidog anula todo tipo de trfico a los usuarios, pero habilita una direccin IP en concreto, la del servidor de guifi.net. As cuando a los usuarios les salga el portal cautivo, si quieren ms informacin podrn ir a un enlace que les lleva directamente a la pgina de guifi.net. Slo est habilitada esta pgina. Si el usuario intenta ir a otro sitio web que no sea ste siempre ser redirigido al portal cautivo.

Wifidog est diseado para servidores de autenticacin, pero en nuestro caso slo queremos que se bloquee el acceso a Internet a los usuarios que no acepten una normativa. Si el usuario acepta la normativa podr navegar libremente por Internet, en caso contrario el usuario no tendr ningn tipo de privilegio y ser redirigido siempre al portal cautivo.

Si creamos nuestro firmware con Wifidog, al ejecutarlo en el nodo tendramos que seguir unos ciertos pasos para configurarlo y cada vez que creramos el firmware se repetira este proceso. Para hacerlo de una manera ms eficaz se ha creado un archivo de configuracin genrico que sustituye al fichero de configuracin predeterminado de Wifidog, como se menciona al inicio de esta seccin, se explica en el anexo A.

Wifidog.conf

Se explican los conceptos bsicos de este fichero de configuracin sin entrar en detalle, donde se configura el funcionamiento que queremos de Wifidog.

- Interfaz de Salida

Figura 3.2 Asignar interfaz de salida

Aqu se pondr cul es la interfaz de salida a Internet para que Wifidog sepa dnde tiene que bloquear el trfico.

- Interfaz de entrada

Figura 3.3 Asignar interfaz de entrada

Esta ser la interfaz donde los usuarios se conectaran al nodo, la Wi-Fi de 2,4 Ghz.


32

- Puerto utilizado

Figura 3.4 Asignar puerto

Por defecto el puerto utilizado por Wifidog es el 2060, pero puede ser modificado. En este puerto estar escuchando constantemente, para analizar las peticiones de los usuarios.

- Servidor de Autenticacin

Figura 3.5 Asignar direccin IP del nodo

Estas lneas sirven para saber cul es el servidor de autenticacin, poniendo la direccin IP del nodo y la ruta hacia la pgina del portal cautivo. Un fallo en la ruta significara que no se mostrara ninguna pgina como portal, dara el tpico error: Request not found.

- Usuarios desconocidos

Figura 3.6 Asignar normas

Para los usuarios que no hayan aceptado la normativa, slo se les permitir acceso a lo mostrado en la ltima captura. Se acepta las direcciones IP de servidores (puerto 53), DHCP (puerto 67) y conexin con el servidor de guifi.net (puerto 80 habilitado).


33

- Bloquear usuarios

Figura 3.7 Asignar direcciones IP a bloquear

En caso de tener problemas con ciertos usuarios, el administrador podr poner su direccin IP en esta norma del fichero impidindole la conexin con el nodo.

Wifidog crea varias Iptables, pero nosotros nos centraremos en las dos ms importantes llamadas WiFiDog_WIFI2Internet y WiFiDog_Unknown ms tarde explicar el porqu.

3.2.6 Estructura

La estructura de las pginas del portal cautivo es muy simple. Hay una pgina principal que sera el portal cautivo, otra pgina donde se autenticara el administrador del nodo y por ltimo las encargadas de modificar el portal implementadas en PHP.

3.2.6.1 Pgina principal

La pgina principal est formada por un men, un mensaje e informacin sobre el propietario del nodo, tanto con fotos con su respectivo comentario como con otro mensaje personalizado.

En el men encontramos, la seccin del administrador, un enlace a la pgina de guifi.net, por si el usuario quiere informarse ms detalladamente sobre la conexin que va a utilizar. Ms abajo, se informa del puerto utilizado y la direccin IP del nodo al cual est conectado el usuario y la pgina a la cual iba a visitar.

La pgina que iba a visitar el usuario, se refiere a que cuando un usuario se conecta al nodo por primera vez, va al explorador y pone una direccin URL del servicio www . El usuario solicita una peticin por el puerto 80, pero no est autorizado a utilizar la red de guifi.net ya que no ha aceptado previamente una normativa. El nodo comprueba que no hay ninguna Iptable para esa direccin


34

IP y contesta su peticin por el puerto 2060, donde le muestra el portal cautivo. La pgina que el usuario haba solicitado inicialmente se guarda, si el usuario acepta la normativa abajo aparece un enlace con esa pgina web, para que pueda ir a ese sitio web, sin tener que ir al explorador y volverlo a escribir.

El mensaje de informacin es igual en todos los nodos, y abajo hay un botn por si el usuario acepta. Como Wifidog no est diseado para nuestro propsito, lo que se hace cuando el usuario acepta la normativa es crear dos Iptables. Estas dos Iptables son bsicas para dar paso al usuario hacia Internet.

Debajo del mensaje, el propietario del nodo podr poner un ttulo, un texto, y subir varias fotos al nodo. Con cada foto el propietario podr poner un comentario para explicar mejor su contenido. Cuando los usuarios se conecten al nodo vern lo que el administrador haya escrito y subido. En los siguientes apartados se explica con ms detalle como se ha implementado.

3.2.6.2 Administrador

El administrador tiene su espacio reservado. Slo tiene que autenticarse para poder acceder a su seccin. La pgina est distribuida en comandos asociados a botones para que los propietarios del nodo que no tengan conocimientos sobre redes ni GNU/Linux, puedan obtener informacin. Hay comandos ms complejos que otros, por ejemplo asignar una direccin IP cmo salida a Internet, ver el estado de todas las interfaces, etc. Por eso al pulsarlo sale una pequea explicacin de la finalidad de esa instruccin.

Gracias a la informacin que adquiera el administrador, podr tomar decisiones. Por ejemplo puede ver si un usuario consume demasiado ancho de banda. De ser as puede restringirle la conexin al nodo durante un cierto perodo de tiempo.

En sta misma pgina hay una seccin para la modificacin del portal, ste lleva a unas pginas en PHP encargadas de ello.


35

3.2.6.3 Modificar portal

La pgina est dividida en dos partes, una para poner un ttulo, y redactar un texto, y la otra para poner una foto con su comentario. Una vez subida la foto con su comentario podr ser eliminada.

La pgina donde modifica el portal tiene el mismo aspecto que el portal cautivo, a medida que se va modificando se van observando los cambios.

Diseo del sistema

36

Implementacin

37

4. Implementacin

4.1 Introduccin

En esta seccin se explica ms detalladamente y a un nivel ms tcnico el funcionamiento de las pginas web [9].

4.2 Estructura

Este apartado est organizado como el anterior, primero se comentar la pgina principal que es el portal cautivo y en los apartados posteriores se detalla la parte del administrador y la modificacin del portal. Resaltando los cdigos ms importantes.

4.2.1 Pgina principal

Como se comenta en el apartado anterior al pulsar el botn de la normativa las Iptables que se crean son:

Iptables t nat I WiFiDog_Unknown 1 s $REMOTE_ADDR j ACCEPT

Iptables t nat I WiFiDog_WIFI2Internet s $REMOTE_ADDR j ACCEPT

Estas dos Iptables [3] son vitales para el correcto funcionamiento del portal cautivo. A continuacin estn explicadas con detalle.

Iptables t nat I WiFiDog_Unknown 1 s $REMOTE_ADDR j ACCEPT

Deja de re direccionar al portal cautivo. Es decir, si no pusiramos este comando, aunque tuviramos acceso a Internet, no podramos visitar otras pginas ya que el nodo nos redirigira siempre al portal cautivo.

Iptables t nat I WiFiDog_WIFI2Internet s $REMOTE_ADDR j ACCEPT

Da paso a Internet. Este comando har que el nodo deje de bloquear trfico al usuario y permita navegar libremente por la red.


38

* $REMOTE_ADDR, es una variable de Shell Script, cuando el usuario pulsa el botn aceptando la normativa, se crean las dos Iptables con la direccin IP del usuario que ha pulsado en el botn.

Aparte de mostrar el mensaje inicial esttico por guifi.net, el propietario del nodo puede crear una parte dinmica, para mostrar el ttulo y el texto, se llama a la funcin:

Cat ttulo.txt Cat cuerpo.txt

Titulo.txt contiene como bien dice el nombre, el ttulo que haya puesto el administrador, y en cuerpo.txt se halla el texto que haya redactado.

Para las fotos y sus comentarios, se crea un bucle foreach que por cada foto que est en la carpeta se muestra la imagen, junto con su comentario. Para mostrar el comentario de las fotos se vuelve a utilizar el comando cat del archivo, sabemos a qu comentario pertenece cada foto porque se llaman igual pero uno acabado en .jpg y el otro en .txt. Por lo tanto se coge el nombre de la foto y se concatena con la extensin .txt.

Se ha creado una funcin en Shell Script que recoge los parmetros pasados por el mtodo GET, para que coja el que contenga la variable URL. En esta variable se guarda el contenido de la primera pgina que solicit el usuario. As cuando acepte la normativa le saldr un enlace justo debajo para que pueda seguir navegando a esa pgina. Lo mostramos con un echo $url, y el usuario slo tiene que pulsarlo y se redirigirse al sitio web. Exactamente de misma forma se hace para las variables del puerto utilizado y direccin IP del router que se muestran en el men. Aunque se utilice una funcin ms simple.

4.2.2 Administrador

La parte reservada al administrador posee comandos para la correcta monitorizacin del nodo y de los usuarios conectados a l, a continuacin comentar cada uno de las instrucciones ejecutadas agrupadas por sus funciones.

Grficas, pgina donde se muestran las grficas de los paquetes recibidos y transmitidos de cada interfaz.

Reiniciar, con este comando reiniciamos el nodo, reboot.

Implementacin

39

Modificar contrasea, posibilidad de cambiar la contrasea para acceder al nodo, primero se ha de verificar la actual, y luego en dos campos poner la nueva. Hay dos campos para controlar que el administrador coloque la misma, sin margen de error. Al utilizar por primera vez el S.O. no hay contrasea, por eso en el manual que va adjunto en la seccin del administrador se recomienda poner una de inmediato.

Protocolos de encaminamiento, El nodo funciona con tres protocolos de encaminamiento, BMX, OSLR y BATMAN, junto a cada protocolo hay un botn correspondiente a su activacin o desactivacin. Si se activa o desactiva se muestra un mensaje, cmo BMX iniciat o BMX parat.

Configuracin de la Mesh, ste es un fichero dnde podemos configurar opciones del nodo, como la longitud o latitud de donde est situado, las direcciones de IP de servidores y configuracin de la LAN. Cabe la posibilidad de habilitar el nodo para que sea el servidor DHCP y los usuarios soliciten direcciones IP libres, activar o desactivar NAT. Este proceso consiste en pasar de una direccin IP privada a una pblica cuando queremos acceder a Internet.

Informacin del Nodo

- PROCESOS, Obtener la informacin de los procesos ejecutados en el nodo. Se ejecuta el comando ps y se muestra una lista con todos los procesos ejecutados en el nodo.

- HISTORIAL DE USUARIOS CONECTADOS AL NODO, Cuando el usuario acepta la normativa se guarda su direccin IP, su hora exacta de conexin y su primera pgina de inicio. Al solicitar esta informacin se ejecuta el comando ya utilizado anteriormente cat registro.txt donde est toda esta informacin almacenada. Se crea un fichero conjunto con toda la informacin de todos los usuarios.


40

- INFORMACIN SOBRE LA CPU, es informacin muy detallada sobre la CPU, como la familia, tamao de la cach, velocidad., etc. El comando utilizado es cat /proc/cpuinfo.

- INFORMACIN SOBRE LA MEMORIA UTILIZADA, comando muy similar al anterior, pero en este caso sobre la memoria, cunto espacio tiene ocupado, cunto le queda disponible, cach, buffers, etc. Esta informacin vara constantemente mientras el sistema est en funcionamiento. El comando utilizado es cat /proc/meminfo.

- ESPACIO DISPONIBLE EN LA COMPACTFLASH, comando que nos permite saber el espacio de la CompactFlash utilizado, el espacio disponible, el porcentaje de uso total y por ltimo el punto de montaje del sistema. El comando utilizado es el df -h. Se puede observar que tambin nos indica las unidades montadas en el sistema.

Informacin de red

- INFORMACIN INTERFACES ACTIVAS, Mostramos todas la interfaces activas con dos comandos, cat /proc/net/dev y ifconfig, los dos obtienen informacin muy til.

cat /proc/net/dev

Lista todas las interfaces activas, y extrae datos tanto los bytes como los paquetes recibidos/transmitidos, errores, paquetes comprimidos, etc.

ifconfig

Lista todas las interfaces configuradas en el nodo, con su direccin IP y mscara, direccin MAC, mtrica, paquetes transmitidos (TX), paquetes recibidos (RX), etc.

Implementacin

41

- USUARIOS CONECTADOS AL NODO, Se ejecuta el comando cat /proc/net arp el protocolo ARP nos dice todos los dispositivos que estn conectados al nodo, tanto por Wi-Fi como por cable. Nos hace una lista de todos los vecinos del nodo.

- INFORMACIN ESPECFICA DEL USUARIO, Podemos sacar mayor informacin de cada usuario si ponemos una direccin IP concreta, como por ejemplo su direccin MAC, los paquetes y la cantidad de informacin transmitida, y la misma informacin que en registro.txt. Este Fichero que contiene la hora exacta de conexin al nodo y la primera pgina web visitada.

Para hacer todo esto se saca la informacin del comando Iptables -L-v y se pasa por pipes con las instrucciones cut y awk para sacar toda la informacin que queremos mostrar.

Se ejecuta tambin el comando ping y traceroute. El primero para saber si la conexin que tenemos con ese usuario es buena, y el segundo para saber cuntos saltos hay hasta llegar a l. Los saltos son los routers o nodos que hay en todo el camino hasta llegar al usuario.

- ESTADO DE LA WIRELESS, Este comando nos dice la calidad de la Wi-Fi de las dos antenas, tambin el ruido y los paquetes descartados.

- TABLA DE ENCAMINAMIENTO, Con el comando route -n, nos muestra todas las rutas que posee nuestro nodo, y a que interfaces estn asociadas. (eth0, eth1, ath0, ath1, etc.).

- ESTABLECER UNA RUTA POR EFECTO, cuando un usuario conecta su nodo por primera vez o lo reinicia, hay rutas que desaparecen, por ejemplo un usuario tiene el nodo conectado a un router por un cable RJ-45, l se conecta al nodo y el nodo tiene como salida a Internet el router del


42

proveedor de Internet. Gracias a este comando podemos especificar por donde queremos tener salida a Internet. En el caso del usuario sera por ejemplo la 192.168.1.1 porque es la direccin IP que tiene su router.

La direccin IP se inserta en un textarea y se guarda en una variable y se ejecuta el siguiente comando:

Ip route add default gw $VARIABLE

- NETSTAT, este comando se usa para mostrar el estado de la red. Tiene varios parmetros que pueden mostrar toda la informacin que se necesite, en este caso el comando utilizado es el netstat -a.

Wifidog

- ACTIVAR WIFIDOG, Para activarlo se ejecuta el paquete Wifidog, comando wifidog f d 7. Las opciones -f y -d significa que se ejecuta en segundo plano y en modo debugging.

- DESACTIVAR WIFIDOG, Se ejecuta el comando killall de Wifidog, slo si est en los procesos activos.

- IPTABLES, Podemos visualizar las Iptables creadas por Wifidog, e ir viendo todos los usuarios que van accediendo a nuestro nodo, por cada usuario que acepta la normativa se generan Iptables para dar paso a Internet.

Para ver los usuarios que van aceptando la normativa, slo hace falta ir a la Iptables WiFiDog_WIFI2Internet e ir viendo cmo se van aadiendo las direcciones IP.

Implementacin

43

Modificar portal

Nos dirige a unas pginas en PHP con la finalidad de modificar una parte del portal cautivo [12]. Una vez all podemos ver que hay dos textareas. En ella se visualiza el contenido actual del ttulo y el texto escrito por el propietario del nodo.

Como no se pueden aadir negritas, cursivas ni subrayado, se han creado una serie de normas. Por ejemplo si se quiere crear un texto con negrita al inicio del textarea se pone anegrita y al final cnegrita. stas cadenas sern intercambiadas por respectivamente, as cuando el usuario abra la pgina web se interpretar en cdigo HTML y saldr en negrita.

ABRIR CERRAR EQUIVALE anegrita cnegrita Texto Texto acursiva ccursiva Texto Texto

asubrayado csubrayado Texto Texto

Estas cadenas se explican en un fichero aparte para que el usuario adquiera estos conocimientos para hacer su pgina ms atractiva, con la posibilidad de poner cursiva, negrita, subrayado y cambiar el tamao del texto.

A medida que vamos subiendo fotos al nodo, stas van apareciendo con su comentario y un checkbox al lado. Adems las fotos pueden verse en versin reducida en la parte inferior de la pgina, para ir controlando el nmero de fotos que vamos subiendo. Se utiliza un bucle similar al de la pgina principal para que vayan apareciendo las imgenes con sus respectivos comentarios, en el recuadro que aparece al lado podemos seleccionarlo para borrar la foto deseada.

Las pginas titulo.php, cuerpo.php, subearchivo.php, delete.php, tienen un cdigo en PHP que se redirigen directamente a la pgina de modificar. Es decir, cuando se sube una foto o se cambia un ttulo, depende de lo que se haga va a una pgina PHP o a otra. Para no tener que volver atrs una vez se ha puesto un ttulo, hay un cdigo en todas las pginas que hace que se re direccione, de manera que veamos automticamente los cambios efectuados.


44

Cdigo para re direccionar:

>

Creamos una variable para almacenar el tiempo en segundos. En este caso es 0 segundos ya que no se quiere que d tiempo a visualizar la pgina.

Adems, se crea otra variable para el contenido de la pgina, que en todos los casos ser la misma, Login.php.

Figura 4.1

Como se muestra en la figura 4.1, Login llama a las pginas para borrar y subir fotos, editar texto y editar el ttulo y automticamente vuelven a Login.

A continuacin explicar el funcionamiento bsico de estas pginas:

Titulo.php y Cuerpo.php

El cdigo de estas dos pginas es exactamente igual. El valor del ttulo o del texto de la pgina se almacena en una variable, y se guarda en un fichero nuevo llamado titulo.txt o cuerpo.txt. As cuando estamos en la pgina principal lo podemos ver ejecutando el comando cat titulo.txt y cat cuerpo.txt.

Implementacin

45

Subearchivo.php

Su funcionamiento es cargar un archivo del ordenador y subirlo al servidor junto con su comentario.

Tiene unas condiciones que de no cumplirse no se completar la subida del archivo. La foto debe estar en un formato .jpg o .gif y no debe ocupar ms de 10 Megabytes. En caso de error se notificara con un mensaje.

Delete.php

Este fichero sirve para borrar las fotos del servidor y su respectivo comentario. Para ello se selecciona un checkbox que va al lado de cada foto de manera que se pasa el nombre del archivo. Como el comentario tiene el mismo nombre pero con una extensin diferente se concatena el nombre de la foto con .txt para la correcta eliminacin.

Se utiliza la funcin unlink($foto), donde el contenido de la variable foto, es el nombre de la fotografa a borrar.


46

Pruebas y mantenimiento

47

5. Pruebas y mantenimiento

Las pruebas para comprender mejor el comportamiento del portal cautivo se han realizado con un programa llamado Wireshark [13], que permite obtener en tiempo real informacin detallada de cada paquete de datos que entra o sale de nuestra red.

Figura 5.1 Captura Wireshark


En la fila del No. 16 se observa como Wifidog permite acceso al puerto 53, que son las direcciones de IP de servidores por eso deja pasar los paquetes cuando solicitamos por primera vez la pgina de Apple. Se ve claramente que el origen es el usuario que solicita la pgina y el destino es el nodo, que luego se encargar de buscar esa informacin, para posteriormente, realizar el recorrido inverso, como se ve en el No. 17.

En el No. 18 el usuario ya tiene la direccin IP de la pgina solicitada y comienza con la peticin para conectarse al servidor que contiene la pgina de Apple. Seq=0.

En el No. 19, el servidor con la pgina de Apple le contesta, diciendo que ha recibido su peticin y que espera establecer una conexin con el usuario. Seq=0 Ack=1.


48

En el No. 20, el usuario le devuelve una respuesta dicindole que ha recibido correctamente la aceptacin de conexin con el servidor. Seq=1 Ack=1.



En el No. 33, el usuario le dice al nodo que quiere conectarse a la direccin IP del servidor de Apple.

En los Nos. 34 y 35 empieza otra vez la negociacin para establecer una conexin como en los pasos 18, 19 y 20.

En el No. 36, una vez se ha conectado, el servidor contesta con la pgina de inicio del portal cautivo.

Conclusiones

49

6. Conclusiones

6.1 Conclusiones globales

A lo largo del proyecto se han podido observar diferentes campos, como la construccin de un nodo, manejo de un sistema operativo desconocido y utilizacin de lenguajes de programacin.

Para todo ello se ha tenido que adquirir una gran experiencia ya que al inicio del proyecto no se dominaba la mayora de estos campos. Para solucionar dichos problemas, el proyectista se document todo lo posible y se inscribi en foros y listas.

En los foros se habla ms sobre el sistema operativo para comprender mejor su funcionamiento y de los ficheros de los cuales est formado, se buscaba y dejaba informacin aunque muchas veces no se obtena respuesta. Tambin se recurri a las listas sobre Wifidog, dnde se tena que escribir en francs o ingls para que los usuarios comprendieran las dudas y las resolvieran.

En varias ocasiones se ha quedado con los creadores de guifi.net desde reuniones en el Rabal hasta en Sant Joan Desp, en todas ellas se aprendan lecciones avanzadas sobre redes, por eso ir a todas era de gran ayuda.

Ha habido momentos de dificultad ya que al principio del proyecto no se poda ni cumplir el objetivo nmero uno, que era que apareciese el portal cautivo.

Los resultados que ha obtenido el proyectista han sido positivos, sobretodo porque al principio no se esperaba terminar el proyecto con tantos objetivos cumplidos y haber realizado una base del firmware ya compilada con toda su configuracin.

Finalmente, cabe destacar que los conocimientos adquiridos sobre telecomunicaciones son beneficiosos ya que el proyectista se dedicar a ello en un futuro.


50

6.2 Ampliaciones

El proyecto slo consista en generar un portal cautivo en el nodo, pero para que todos los usuarios que quieran disfrutar de l no sigan todos los pasos realizados previamente, se ha creado un archivo con unas instrucciones. Estas ltimas permiten que, al ejecutarlo, se cree el sistema operativo con todos los archivos de configuracin incluidos.

En un futuro se podran ampliar las caractersticas del portal cautivo, con la posibilidad de subir videos y un nmero mayor de fotos con una calidad superior y comandos ms elaborados.

Bibliografa

51

Bibliografa

Publicaciones impresas

[1] Andrew y Paul Hudson. La biblia de Ubuntu, Ed. Anaya Multimedia, 2008. Madrid.

[2] Mut, Jose Carlos. Desarrollo e implementacin de un entorno Wi-Fi abierto. Proyecto de la universidad UAB Sabadell, 2009.

[3] Odom, Wendell. Cisco CCNA ICND1 y ICND2, Ed. Pearson, 2008. Madrid

Recursos electrnicos

[4] Guifi.net [www.guifi.net] o ltimo acceso: 28 de junio de 2010

[5] GraciasenseFils [www.graciasensefils.net] o ltimo acceso: 28 de junio de 2010

[6] Wifidog [dev.wifidog.org] o ltimo acceso: 28 de junio de 2010

[7] OpenWRT [www.openwrt.org] o ltimo acceso: 28 de junio de 2010

[8] Foros del web [www.forosdelweb.com] o ltimo acceso: 28 de junio de 2010

[9] Ubuntu [www.ubuntu-es.org] o ltimo acceso: 28 de junio de 2010

[10] Linux [www.linux-os.com] o ltimo acceso: 28 de junio de 2010

[11] Landashop [www.landashop.com] o ltimo acceso: 28 de junio de 2010

[12] 3schools [www.3schools.com] o ltimo acceso: 28 de junio de 2010

[13] Wireshark [www.wireshark.org] o ltimo acceso: 28 de junio de 2010


52

[14] UOC [www.uoc.edu] o ltimo acceso: 28 de junio de 2010

[15] Lugro-mesh [www.lugro-mesh.org.ar] o ltimo acceso: 28 de junio de 2010

[16] Youtube [www.youtube.com] o ltimo acceso: 28 de junio de 2010

Agradecimientos

53

Agradecimientos

Antes de todo el proyectista agradece todos los consejos y tiempo dedicado que le ha ofrecido el director del proyecto, David Megas.

A la universidad por invertir en la compra de los recursos, que sin ellos no hubiera sido posible realizar el proyecto.

Destacar tambin Jose Carlos Mut por todos sus consejos.

Y Finalmente, a mi familia y sobre todo a mi padre por la ayuda ofrecida en la construccin del nodo y a mi novia por toda la paciencia que ha tenido.

Gracias a todos.

Alberto Moral Gmez, Sabadell, junio 2010.

Portal

Documents

Transcript of Portal