Portal

DESARROLLO DE UN
PORTAL CAUTIVO Y
HERRAMIENTAS DE
ADMINISTRACIN EN UN
ENTORNO WI-FI
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
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
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.
iii
Tabla de Contenidos
Resumen
iii
Tabla de Contenidos
Captulo 1: Introduccin
1.1
1.2
1.3
1.4
Presentacin
Estado del arte
Objetivos
Organizacin de la memoria
Captulo 2: Anlisis del sistema Actual

2.1 Introduccin a las redes mesh
2.1.1 Esquema clsico
2.1.2 Esquema mesh /ad-hoc
2.1.3 Servicio de conexin a Internet
2.2 Estudio de Viabilidad
2.2.1 Introduccin
2.2.2 Estudio de la situacin actual
2.2.3 Requisitos del proyecto
2.2.4 Alternativas y seleccin de la solucin
2.2.5 Planificacin
2.2.6 Evaluacin de riesgos
2.2.7 Presupuesto
2.3 Montaje del nodo
Captulo 3: Diseo del sistema

3.1 Anlisis de requerimientos
3.1.1 Requerimientos previos
3.1.2 Requerimientos funcionales
3.1.3 Requerimientos no funcionales
3.2 Descripcin de la plataforma
3.2.1 Introduccin
3.2.2 Sistema operativo
3.2.3 Directorios
3.2.4 Iptables
3.2.5 Wifidog
3.2.6 Estructura
1
2
3
3
5
5
5
6
7
8
8
10
12
13
14
17
18
20
23
23
23
25
26
27
27
28
29
29
30
33
Captulo 4: Implementacin
35
4.1 Introduccin
4.2 Estructura
4.2.1 Pgina principal
4.2.2 Administrador
35
35
35
36
Captulo 5: Mantenimiento y pruebas
45
Captulo 6: Conclusiones
47
6.1 Conclusiones globales

6.2 Ampliaciones
47
49
Bibliografa
49
Agradecimientos
51
Anexo A: Creacin del firmware
53
Introduccin
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
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
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.
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
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

5
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
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.
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.
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
Administrador del
nodo
Usuario
Responsabilidad
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.
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
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.
10
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.
El usuario slo podr ver el mensaje de bienvenida del portal
cautivo y el mensaje del propietario del nodo.
Usuario
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.
11

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
2
3
4
5
6
7
8
Visualizacin portal cautivo

Autenticacin por parte del usuario del nodo
Visualizacin de un mensaje de bienvenida
Monitorizacin de actividades/usuarios en el nodo
Modificacin del portal con capacidad para soportar imgenes
Conexin externa con guifi.net para obtener mayor informacin
Estructuracin del portal
Montaje del nodo
2.2. 3.2 Requisitos no funcionales (RNF):

1
2
3
4
5
6
7
12
Rendimiento del sistema

Disponibilidad de servidor
Calidad de imagen
Eficiencia
Soporte
Necesidad de recursos
Velocidad de carga del portal
2.2. 3.3 Restricciones

1
2
3
La aplicacin se ha implementado utilizando software libre.

El proyecto ha de estar finalizado antes del 30 de Junio.
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)
Esencial
Condicional
Opcional
1
X
2
X
X
X
2.2. 3.5 Catalogacin y priorizacin de los requisitos no funcionales

(RNF)
Esencial
Condicional
Opcional
1
X
2
X
3
X
X
X
X
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.
13
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
Programador
Recursos humanos
Valoracin
Jefe de proyecto
40/h
Analista Tcnico de
Tcnico de
pruebas
hardware
Reuniones con la comunidad
14
20/h
0/h
2.2. 5.3 Planificacin del proyecto con MSProject

#
Tarea
Duracin
Estudio y documentacin guifi.net
25
Documentacin Portales cautivos
32
Estudio y documentacin Ubuntu
30
Reuniones con la comunidad
12
Estudio de viabilidad
15
Aprobacin del estudio de viabilidad
Anlisis de requisitos
20
Montaje del nodo
Creacin del portal cautivo
10
Base del firmware instalada
15
11
Descargar paquete Wifidog
12
Configuracin Wifidog
40
13
Creacin pgina Splash
75
14
Creacin del nuevo firmware
15 Realizacin pruebas
15
16 Finalizacin memoria
Duracin Total de la planificacin
297
15
2.2. 5.4 Planificacin Diagrama de Gantt
Figura 2.8 Diagramas de Gantt
Figura 2.9 Diagramas de Gantt
16
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.

17
2.2.7 Presupuesto
2.2. 7.1 Estimacin coste de personal

Personal
Proyectista*
Horas
297
Coste
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
9m
VMware
20
80
36 m
9m
Ubuntu
OpenOffice.org
MSProject
90
360
36 m
9m
* 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
Fuente de alimentacin 18 v. 0,8 A (15 W)
83,80
5,93
24,40
5,19
Compex WLM54SAG23 802.11 AGB 200mW 108

Mb/s
Pigtail 5 GHz UFL-N Jack Bulkhead 30 cm
18

MATERIAL
Cantidad
Precio
Antena Dipolo DUAL 5/2,4 Ghz 7 dBi Connector N

Macho
Caja Universal IP65 ABS con conector RJ45
incluido
CompactFlash Transcend TS2GCF133 (4GB)
22,28
24,40
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
6.757,6
TOTAL
19
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
20
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

21
22
Diseo del sistema
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.
23
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)
24
__________________________________________________________________________________Diseo del sistema
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.
25
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.
26
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.
27
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.
28
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.
29
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
30
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.
31
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).
32
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
33
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.
34
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.
35
Diseo del sistema
36
Implementacin
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.
37
* $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.
38
Implementacin
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.
39
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.
40
Implementacin
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
41
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.
42
Implementacin
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
anegrita
acursiva
asubrayado
CERRAR
cnegrita
ccursiva
csubrayado
EQUIVALE
Texto 
Texto
Texto
 Texto 
 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.
43
Cdigo para re direccionar:

<?php $tiempo = 0;
$pagina = login.php
>
<meta
http-equiv=refresh
url=$pagina?>>
content=<?=$tiempo;
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.
44
Implementacin
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.
45
46
Pruebas y mantenimiento
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.
47
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.
48
Conclusiones
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.
49
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.
50
Bibliografa
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]
[6] Wifidog [dev.wifidog.org]
[7] OpenWRT [www.openwrt.org]
[8] Foros del web [www.forosdelweb.com]
[9] Ubuntu [www.ubuntu-es.org]
[10] Linux [www.linux-os.com]
[11] Landashop [www.landashop.com]
[12] 3schools [www.3schools.com]
[13] Wireshark [www.wireshark.org]
51
[14] UOC [www.uoc.edu]

[15] Lugro-mesh [www.lugro-mesh.org.ar]
[16] Youtube [www.youtube.com]
52
Agradecimientos
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.
53
54

Portal

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Portal

Uploaded by

Copyright:

Available Formats

DESARROLLO DE UN

Escuela Universitaria de Informtica

El firmante, David Megas Jimnez,

Que el trabajo al que corresponde la presente memoria

-----------------------------Firmado: David Megas Jimnez

Captulo 2: Anlisis del sistema Actual

Captulo 3: Diseo del sistema

Captulo 5: Mantenimiento y pruebas

6.1 Conclusiones globales

Anexo A: Creacin del firmware

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

1.2. Estado del arte

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

Como se puede observar no hay posibilidad para cambiar el mensaje del

1.4. Organizacin de la memoria

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

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

Anlisis del sistema actual

2. Anlisis del sistema actual

Figura 2.1 Esquema clsico

Figura 2.2 Fallo en el esquema clsico

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

2.1.2 Esquema mesh / ad-hoc

Figura 2.3 Red mesh

Figura 2.4 Fallo en red mesh

__________________________________________________________________________Anlisis del sistema actual

2.1.3 Servicio de conexin a Internet

Figura 2.5 Proveedor de Internet

Figura 2.6 Ruta alternativa

Estos nodos que estn configurados como proveedores de Internet

Se ha utilizado una aplicacin para este tipo de red, que en cuanto un

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

2.2 Estudio de viabilidad

2.2. 1.1 Tipologa:

2.2. 1.3 Objetivos del proyecto:

__________________________________________________________________________Anlisis del sistema actual

2.2. 1.4 Definiciones, acrnimos y abreviaciones

2.2. 1.5 Partes interesadas

Colabora con el Director de proyectos en el estudio de

Disea y desarrolla la aplicacin de acuerdo con el anlisis y

Realiza las pruebas del software y participa en el control de

Director del proyecto

Supervisa el trabajo del proyectista

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

2.2.2 Estudio de la situacin actual

Figura 2.7 Ejemplo nodos conectados

Son conexiones inalmbricas por lo tanto los nodos deben situarse en

2.2. 2.2 Desarrollo del proyectista

__________________________________________________________________________Anlisis del sistema actual

La segunda parte ser dinmica. El propietario del nodo podr

2.2. 2.3 Usuario y/o personal del sistema

Podr acceder al portal cautivo mediante autenticacin y

2.2. 2.4 Diagnstico del sistema

El portal cautivo es muy simple visualmente.

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

2.2.3 Requisitos del proyecto

2.2. 3.1 Requisitos funcionales (RF):

Visualizacin portal cautivo

2.2. 3.2 Requisitos no funcionales (RNF):

Rendimiento del sistema

__________________________________________________________________________Anlisis del sistema actual

2.2. 3.3 Restricciones

La aplicacin se ha implementado utilizando software libre.

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