Capítulo 1 - Universidad de Sevillabibing.us.es/proyectos/abreproy/12016/fichero/PFC+-+JMLC.pdf ·...
Transcript of Capítulo 1 - Universidad de Sevillabibing.us.es/proyectos/abreproy/12016/fichero/PFC+-+JMLC.pdf ·...
1
Capítulo 1
Objetivo y Justificación del Proyecto
2
3
ÍNDICE
1.1. Introducción .......................................................................................................... 4
1.2. FADA-CATEC ..................................................................................................... 4
1.2.1. Áreas de desarrollo ....................................................................................... 5
1.2.2. Localización .................................................................................................. 6
1.3. Justificación del Proyecto ..................................................................................... 7
1.4. Objetivo del Proyecto ........................................................................................... 7
Proyecto Final de Carrera - José M León Coca
4
1.1. Introducción
A lo largo de este documento se expone el Proyecto Final de Carrera realizado por
José María León Coca. Este trabajo supone la culminación de la titulación de Ingeniería
de Telecomunicaciones en la Universidad de Sevilla.
El proyecto se ha realizado en su totalidad en el seno de la empresa FADA-CATEC,
más concretamente en el área de aviónica y sistemas no tripulados, como consecuencia
del disfrute de una beca de inserción laboral en las fechas de Julio a Diciembre de 2010.
Sin ninguna duda, este autor puede afirmar que sin los medios materiales y humanos
propios de la empresa este proyecto no podría haberse realizado. Por ello agradecer una
vez más a FADA-CATEC y a mis tutores y responsables dentro de la empresa: Antidio
Viguria, Miguel Cordero y Antonio Bellido; la oportunidad que me brindaron, ya que
sin ninguna duda ha reorientado mi carrera profesional hacia el mundo de la
investigación.
1.2. FADA-CATEC
El Centro Avanzado de Tecnologías Aeroespaciales (CATEC) es un centro
implantado y gestionado por la Fundación Andaluza para el Desarrollo Aeroespacial
(FADA).
Su puesta en marcha comienza a finales del primer trimestre de 2008, con las
contrataciones de personal especializado cuyo cometido será el desarrollo y puesta en
marcha los distintos departamentos que estructurarán el Centro. Durante este periodo, el
Centro se establece en unas oficinas provisionales del centro de empresas EUROCEEI,
y desde allí comenzará diseñar las instalaciones e infraestructuras definitivas, a gestar y
desarrollar los primeros proyectos de I+D+i y logrará su calificación como Centro
Tecnológico Avanzado en el Registro Andaluz de Agentes del Conocimiento.
En junio de 2010, se produce el traslado a las instalaciones de CATEC en el Parque
Tecnológico y Aeronáutico de Andalucía AEROPOLIS. A partir de este momento, se
intensificarán las labores de puesta en marcha de las infraestructuras científico –
tecnológicas que culminarán con la inauguración oficial de CATEC en Enero de 2011.
Durante este periodo, el centro realizará un importante esfuerzo en la definición de sus
Capítulo 1: Objetivo y Justificación del proyecto
5
líneas de investigación, la puesta en marcha de proyectos de I+D+i relacionados con
dichas líneas, su homologación como centro de investigación a nivel nacional y europeo
y la estructuración de la propia organización junto con la implantación de un sistema
integrado de la Calidad.
Figura 1: Logotipos de FADA-CATEC
En la actualidad, CATEC continúa trabajando intensamente en la generación de
conocimiento mediante la puesta en marcha de proyectos de investigación y desarrollo
tanto de carácter interno como en colaboración con empresas y organismos en el ámbito
regional, nacional y europeo.
1.2.1. Áreas de desarrollo
Las áreas de desarrollo de CATEC son el motor del centro. Se encargan de
desarrollar las líneas de investigación en los campos de la ingeniería de Materiales y
Procesos, Aviónica y Sistemas no Tripulados, Simulación y Desarrollo Software o la
Automatización y Robótica. Todo ello enfocado desde la perspectiva del sector
industrial aeroespacial al que prestan sus servicios.
Figura 2: Áreas de desarrollo FADA-CATEC
Proyecto Final de Carrera - José M León Coca
6
Estas áreas están especializadas en la prestación de servicios de alto valor añadido en
campos como los ensayos mecánicos a gran escala de componentes estructurales, el uso
de plataformas UAV como plataformas de experimentación o la gestión del
conocimiento realizada a través de la vigilancia tecnológica del sector o la transferencia
de tecnología hacia el mismo.
El área en la que se desarrolló este proyecto fue, tal y como se ha comentado
anteriormente, el área de Aviónica y Sistemas No Tripulados, de la cual es responsable
Antidio Viguria. El principal objetivo del área es el desarrollo de tecnologías en
funcionalidades tales como: sistemas de control y navegación, tecnologías aplicadas a
“sense and avoid” (detectar y evitar), sistemas de percepción avanzados, coordinación
multivehículo y nuevos desarrollos en comunicaciones inalámbricas.
1.2.2. Localización
FADA-CATEC se encuentra en El Parque Tecnológico Aeroespacial de Andalucía,
Aerópolis, el cual es un recinto de excelencia dedicado en exclusiva a la industria
aeronáutica y aeroespacial. Aerópolis nace con el objetivo de impulsar el sector
aeronáutico y aeroespacial andaluz al reunir a su industria colaboradora auxiliar en un
único espacio, dotado con las últimas tecnologías y con capacidad para prestar servicios
avanzados.
La creación de Aerópolis es una iniciativa promovida por la Junta de Andalucía y se
enmarca en los objetivos del Gobierno andaluz de consolidar la industria auxiliar
aeronáutica en la comunidad autónoma, incentivando con este fin la promoción de suelo
industrial adecuado para la instalación de este tipo de empresas. Aerópolis supone un
importante instrumento de apoyo a las pymes andaluzas del sector aeronáutico en su
esfuerzo financiero y tecnológico para mejorar su competitividad, y poder hacer frente a
los grandes proyectos que se llevarán a cabo en la comunidad autónoma durante los
próximos años, especialmente los relativos al nuevo avión de transporte militar A400M
y a la fabricación de componentes de alta tecnología para el Airbus 380.
Capítulo 1: Objetivo y Justificación del proyecto
7
1.3. Justificación del Proyecto
Este proyecto nació ante la necesidad de comprobar la integridad de los datos
enviados y recibidos a través de una interfaz inalámbrica a un dispositivo embarcado no
tripulado, el cual está basado en un sistema Linux empotrado. El motivo de la
comprobación de la integridad de los datos enviados entre una entidad remota,
supongamos un UAV, y una estación base fija, puede justificarse en aquellos protocolos
no orientados a conexión, típicos en aplicaciones que requieren transmisión en tiempo
real (transmisión de video, conversaciones de voz…). En los cuales el paquete recibido
sólo tiene interés en ese instante y una retransmisión del mismo carece de sentido. Es
por ello que se hace presente la comprobación en todo momento la integridad de esos
datos recibidos y llevar un control de errores en los mismos para detectar las posibles
irregularidades del canal de datos inalámbrico.
Esta idea fue la motivación inicial del proyecto, el cual tras un largo proceso de
investigación, fue modificándose hasta tener como resultado el desarrollo en un
dispositivo empotrado de una aplicación para el control del enlace inalámbrico.
1.4. Objetivo del Proyecto
El objetivo inicial del proyecto fue el estudio de los sistemas empotrados disponibles,
utilizados como posibles ordenadores de abordo en vehículos no tripulados, en pos de
crear un entorno de desarrollo de aplicaciones no propietario. El siguiente objetivo fue
el desarrollo en dicho entorno de una aplicación que pudiera detectar y controlar los
errores en el enlace inalámbrico de forma remota.
Estos objetivos han sido cumplidos y la forma en la que se han realizado, se explica a
lo largo de este documento, el cual se ha estructurado en siete capítulos, siendo éste el
primero de ellos, los restantes se presentan a continuación con un breve resumen de lo
que exponen:
Capítulo 2: Se comentan y resaltan las características más importantes de los
recursos hardware y software disponibles.
Capítulo 3: Explicación del proceso de instalación y configuración en los
dispositivos empotrados del sistema operativo OpenWrt.
Proyecto Final de Carrera - José M León Coca
8
Capítulo 4: Explicación de las herramientas de compilación cruzada y la
generación de las mismas para los dispositivos empotrados.
Capítulo 5: Introducción del entorno de desarrollo Eclipse y su integración con
las herramientas de compilación cruzada para la generación de aplicaciones.
Capítulo 6: Se explican las características principales de la aplicación creada en
este proyecto WiLCA (Wireless Link Control Application - Aplicación para el
control del enlace inalámbrico).
Capítulo 7: Se propone un escenario real en el cual utilizar la aplicación WiLCA,
desarrollando la aplicación para cada entidad propuesta.
9
Capítulo 2
Recursos Disponibles, Hardware y Software
10
11
ÍNDICE
2.1. Introducción ........................................................................................................ 12
2.2. Recursos Hardware ............................................................................................. 13
2.2.1. RouterBoard 433 UAH ............................................................................... 13
2.2.2. RouterStation Pro ........................................................................................ 16
2.2.3. Radios mini-PCI ......................................................................................... 17
2.3. Recursos Software .............................................................................................. 24
2.3.1. Sistemas Operativos .................................................................................... 24
2.3.2. Programas y Aplicaciones .......................................................................... 27
Proyecto Final de Carrera - José M León Coca
12
2.1. Introducción
En este capítulo se describirán los recursos que fueron necesarios para la realización
de este proyecto. Al principio del proyecto se disponían de todos los recursos materiales
y fue necesario el estudio de sus características para poder aprovecharlos mejor.
La descripción de los recursos a lo largo de este capítulo se realizará de la siguiente
manera:
Recursos Hardware
RouterBoard 433UAH
RouterStation Pro
Radios miniPCI
XtremeRange 2
XtremeRange 5
XtremeRange 9
Recursos Software
Sistemas Operativos
Windows 7
Ubuntu 10.04
OpenWRT 10.03
Aplicaciones
Eclipse
VirtualBox
PuTTy
Tabla 1: Recursos Disponibles
Se establece una clasificación de recursos hardware y software.
Capítulo 2: Recursos Disponibles, Hardware y Software
13
2.2. Recursos Hardware
Los recursos hardware utilizados en este proyecto, son los productos que se
disponían previamente en la empresa. Fue necesario un estudio previo para conocer
mejor cada elemento y sus características, y así poder plantear el objetivo final de este
proyecto.
En primer lugar se explicaran los dos tipos de placas router de las que se disponían,
la RouterBoard 433UAH de Mikrotik y la RouterStation Pro de Ubiquiti, siendo la
primera, la que se utilizó principalmente para la realización de este proyecto. Tras estas,
se comentan las características de las tarjetas radio miniPCI que se disponían y
dependiendo de la banda de frecuencias en la que se fuese a trabajar la utilización de
una u otra.
2.2.1. RouterBoard 433 UAH
El dispositivo RouterBoard 433 UAH, pertenece a la línea de productos RouterBoard
de la empresa letona Mikrotik, fabricante de productos inalámbricos y desarrolladora
del sistema operativo para dispositivos embedded: RouterOS.
Desde Mikrotik definen esta placa como el punto de acceso inalámbrico universal.
Dotada con tres puertos miniPCI, tres interfaces Ethernet, una de ellas POE (Power
Over Ethernet), y, diferenciándose de otros modelos de su familia, dos puertos USB 2.0.
Además de utilizar los puertos USB para conectar dispositivos de almacenamiento
masivo y aumentar así su memoria no volátil, también posee un puerto de tarjetas
microSD que nos posibilita esta tarea.
Su procesador Atheros (AR7161) trabaja a 680MHz basado en una arquitectura
MIPS. Posee una memoria RAM de 128MB y una sorprendente memoria NAND de
512 MB, mucho mayor que los dispositivos de su especie.
Estas características destacan a la RB433UAH en una de las placas router más
potentes y flexibles del mercado.
De serie, incluye el sistema operativo RouterOS v3 con nivel 5 de licencia. En este
proyecto sólo se utilizará este sistema operativo para la realización de una copia de
seguridad del mismo, simplemente.
Proyecto Final de Carrera - José M León Coca
14
En la siguiente tabla, Tabla 2 , se resumen las características más importantes del
dispositivo facilitadas por el fabricante en su datasheet.
CPU Atheros AR7161 680MHz network processor
Memory 128MB DDR SDRAM onboard memory
Boot Loader RouterBOOT
Data Storage 512MB onboard NAND memory chip and microSD
Ethernet Three 10/100 Mbit/s Ethernet ports with Auto-MDI/X
Expansion 2x USB 2.0 ports, max 480Mbit throughput. Max current 2A.
miniPCI Three MiniPCI Type IIIA/IIIB slots
Figura 3: RouterBoard 433UAH
Capítulo 2: Recursos Disponibles, Hardware y Software
15
Extras Reset switch, Beeper,Voltage monitor
Serial Port One DB9 RS232C asynchronous serial port
LEDs Power, NAND activity, 5 user LEDs
Power Options Power over Ethernet: 10..28V DC (except power over datalines). Power jack:
10..28V DC. Voltage monitor.
Dimensions 10.5 cm x 15 cm, 137 grams
Power
Consumption
3W without extension cards, up to 10W when using USB. Maximum – 32W,
16W output to cards
Operating
System MikroTik RouterOS v3, Level5 license
Tabla 2: Características RB433UAH
En esta placa es donde se ha desarrollado la mayor parte del proyecto, como se ha
comentado anteriormente. En la placa que se explicará a continuación, es posible
adaptar lo realizado en la RB433UAH, claro está instalándole una distribución Linux
compatible y las dependencias necesarias.
Proyecto Final de Carrera - José M León Coca
16
2.2.2. RouterStation Pro
El dispositivo RouterStation Pro es el buque insignia en placas routers de la empresa
Ubiquiti Networks. Comparable en potencia con la RB433UAH, posee una CPU muy
similar, Atheros AR7161 MIPS 24K a 680MHz.
Figura 4: RouterStation Pro
El resto de características no son tan comparables con las de la anterior. Posee 128
MB de memoria RAM, la mitad que la anterior, y 16 MB de memoria FLASH, contra
512 MB que ofrece la RB433UAH. Por estas razones terminó por elegirse para el
desarrollo del proyecto la RB433UAH.
En la siguiente tabla, Tabla 3, se recogen las características más importantes
facilitadas por el fabricante en su datasheet.
CPU Atheros AR7161 680MHz 24K
Memory 128MB DDR
Boot Loader RedBoot
Data Storage Flash SPI 16 MB and SDIO
Capítulo 2: Recursos Disponibles, Hardware y Software
17
Ethernet 4-Port Gigabit Ethernet Switch – One port WAN & POE ( 802.3af )
Expansion 1x USB 2.0 ports, SDIO.
miniPCI Three MINI-PCI Slots supports Type IIIA
Extras RTC (Real Time Clock), Reset Button, UART J3, JTAG J4, USER GPIO
J33
Serial Port Built in RS232/dB9 Connector
LEDs Power, RF, WAN, LAN1, LAN2, LAN3
Power Options Power over Ethernet: Up to 25 W. Power jack: 40…56 VDC. Voltage
monitor.
Dimensions 15.2 cm x 13.2 cm, 150 grams
Power
Consumption
3W without extension cards, 5W idle One Radio present, 7W while passing
1000Mbps traffic.
Operating
System OpenWRT Kamikaze
Tabla 3: Características RS Pro
Destacar que de serie posee el Sistema Operativo OpenWRT con el que se trabajará
en este proyecto, pero en una versión más actual.
2.2.3. Radios mini-PCI
Las tarjetas inalámbricas disponibles e idóneas para estos dispositivos son del tipo
mini-PCI.
Los dispositivos mini-PCI, se añadieron a la versión 2.2 PCI para el empleo en
ordenadores portátiles y usa un bus de 32 bits, de 33 MHz con conexiones impulsadas a
3.3 V generalmente. El tamaño estándar para tarjetas mini-PCI es aproximadamente 1/4
de las tarjetas similares PCI.
En el entorno comercial se pueden encontrar muchos de estos dispositivos: tarjetas
WiFi, Fast-Ethernet, Bluetooth, módems, tarjetas de sonido… Hay tres factores de
forma de tarjeta: Tipo I, Tipo II, y Tipo III. Las tarjetas que se van a utilizar en este
proyecto son Tipo III con un pinout de 124 pines.
Proyecto Final de Carrera - José M León Coca
18
Se disponen de parejas de tarjetas de los modelos: XR2, XR5 y XR9 de la marca
Ubiquiti. Estos módulos en general se destacan por su gran compatibilidad y rango de
señal.
2.2.3.1. XTREMERANGE 2
La XtremeRange2 es la primera tarjeta de la clase 802.11 b/g basada en un módulo
de radio a 2.4 GHz especialmente diseñado para redes mesh, puentes de red y
aplicaciones de infraestructura que requieran un altísimo nivel de funcionamiento y
responsabilidad. Esta tarjeta es capaz de ofrecer 600 mW aproximadamente de potencia
de transmisión, muchísimo comparado el límite comercial de uso doméstico en España,
de 100 mW.
Figura 5: XtremeRange2
Processor Specs Atheros, 6th Generation, AR5414
Radio Operation IEEE 802.11b/g, 2.4GHz
Interface 32-bit mini-PCI Type IIIA
Operation Voltage 3.3VDC
Antenna Ports Single MMCX
Temperature Range -45 to +90C (extended temp version up to +95C)
Security WPA, WPA2, AES-CCM & TKIP Encryption,
802.1x,64/128/152bit WEP
Capítulo 2: Recursos Disponibles, Hardware y Software
19
Data Rates 6Mbps, 9Mbps, 12Mbps, 24Mbps, 36Mbps, 48Mbps. 54Mbps
TX Channel Width Support 5MHz / 10MHz / 20MHz / 40MHz
RoHS Compliance YES
Avg. TX Power 28dBm, +/-1dB
Max Current Consumption 1.30A, +/-100mA
Indoor Range (Antenna
Dependent) up to 200meters
Outdoor Range (Antenna
Dependent) over 50km
Operating System Support Linux MADWIFI, WindowsXP, Windows2000
Advanced Mobility / Quick
Handoff
WindowsXP/2000 Utility with Enhanced Mobility Driver
from Ubiquiti
Cisco Support CCX 4.0 Supported Driver/Utility also available from
Ubiquiti
Tabla 4: Características XR2
Proyecto Final de Carrera - José M León Coca
20
2.2.3.2. XTREMERANGE 5
La tarjeta XtremeRange5 al igual que su “hermana” XR2 está especialmente
diseñada para redes mesh, puentes de red y aplicaciones para infraestructuras con alto
nivel de seguridad y compromiso. Esta tarjeta está basada en el estándar 802.11a
trabajando en la banda de los 5 GHz, banda para uso industrial en el que es capaz de
ofrecernos 600 mW de potencia de transmisión, llegando incluso a generar tasas de pico
de 1000 mW.
Figura 6: XtremeRange 5
Processor Specs Atheros, 6th Generation, AR5414 with SuperA/Turbo
Support
Radio Operation IEEE 802.11a, 5GHz
Interface 32-bit mini-PCI Type IIIA
Operation Voltage 3.3VDC
Antenna Ports Single MMCX
Temperature Range -45 to +85C (extended temp version up to +95C)
Security 802.11i, AES-CCM & TKIP Encryption, 802.1x,
64/128/152bit WEP
Data Rates 6Mbps, 9Mbps, 12Mbps, 24Mbps, 36Mbps, 48Mbps,
54Mbps
Capítulo 2: Recursos Disponibles, Hardware y Software
21
TX Channel Width Support 5MHz / 10MHz / 20MHz / 40MHz
RoHS Compliance YES
Avg. TX Power 28dBm, +/-1.5dB
Max Current Consumption 1.80A, +/-100mA
Indoor Range (Antenna
Dependent) over 150m
Outdoor Range (Antenna
Dependent) over 50km
Operating System Support Linux MADWIFI, WindowsXP, Windows2000
Advanced Mobility / Quick
Handoff
WindowsXP/2000 Utility with Enhanced Mobility Driver
from Ubiquiti
Cisco Support CCX 4.0 Supported Driver/Utility also available from
Ubiquiti
Tabla 5: Características XR5
Proyecto Final de Carrera - José M León Coca
22
2.2.3.3. XTREMERANGE 9
La XtremeRange9 es presentada por Ubiquiti como una ponderosa portadora de radio
para la banda sin licenciar de 900MHz. Esta tarjeta utiliza un avanzado sistema de
inmunidad al ruido en la interfaz radio desarrollado por los ingenieros de
radiofrecuencia de Ubiquiti, a través de la interacción entre sus clientes y pruebas de
campo a lo largo de más de dos años. Esto confecciona la segunda generación de
Ubiquiti de las la “tecnología de las frecuencias de la libertad”.
Figura 7: XtremeRange 9
Processor Specs Atheros, 6th Generation, AR5414
Radio Operation Proprietary 900MHz
Interface 32-bit mini-PCI Type IIIA
Operation Voltage 3.3VDC
Antenna Ports Dual MMCX
Temperature Range -45C to +90C (extended temp version up to +95C)
Security 802.11i, AES-CCM & TKIP Encryption, 802.1x,
64/128/152bit WEP
Capítulo 2: Recursos Disponibles, Hardware y Software
23
Data Rates 6Mbps, 9Mbps, 12Mbps, 24Mbps, 36Mbps, 48Mbps,
54Mbps
TX Channel Width Support 5MHz / 10MHz / 20MHz / 40MHz
RoHS Compliance YES
Avg. TX Power 28dBm, +/-1dB
Max Current Consumption 1.10A, +/-100mA
Indoor Range (Antenna
Dependent) over 400m
Outdoor Range (Antenna
Dependent) over 50km
Operating System Support Linux MADWIFI, WindowsXP, Windows2000
Advanced Mobility / Quick
Handoff
WindowsXP/2000 Utility with Enhanced Mobility Driver
from Ubiquiti
Cisco Support CCX 4.0 Supported Driver/Utility also available from
Ubiquiti
Tabla 6: Características XR9
Proyecto Final de Carrera - José M León Coca
24
2.3. Recursos Software
Los recursos software a utilizar para el desarrollo del proyecto se pueden clasificar
en Sistemas Operativos, en dónde se dará una breve pincelada de los SO utilizados, y
aplicaciones genéricas, muchas de ellas multiplataforma.
2.3.1. Sistemas Operativos
Para la introducción de esta sección, se utilizará la definición formal de la Real
Academia de la Lengua, la cual dicta:
“Un sistema operativo (SO) es el programa o conjunto de programas que efectúan
la gestión de los procesos básicos de un sistema informático, y permite la normal
ejecución del resto de las operaciones.”
Podemos entender un SO como la capa de adaptación entre la aplicación y la
máquina sobre la que corre.
Figura 8: Interacción SO
A lo largo de la historia estos sistemas han ido evolucionando de forma conjunta con
el desarrollo de las máquinas que los hacen funcionar.
En la actualidad, el SO más utilizado es Windows, prácticamente la mayoría de los
equipos contienen una versión instalada de serie. Existen otros sistemas operativos
restringidos a la máquina en la que van instalados, como MAC’OS instalado
únicamente ordenadores Apple y SO libres, como las numerosas distribuciones de
Linux (Ubuntu, Fedora, Kubuntu, Debian…).
Capítulo 2: Recursos Disponibles, Hardware y Software
25
Los SO utilizados en este proyecto han sido Windows 7, Ubuntu 10.04 (Linux) y
OpenWRT Backfire 10.03 para dispositivos embebidos.
2.3.1.1. Windows 7
Windows 7 es la versión más reciente de Microsoft Windows, línea de sistemas
operativos producida por Microsoft. Esta versión está diseñada para uso en PC,
incluyendo equipos de escritorio en hogares y oficinas, equipos portátiles, tablet PC y
netbooks. El desarrollo de Windows 7 se completó el 22 de julio de 2009, siendo
entonces confirmada su fecha de venta oficial para el 22 de octubre de 2009.
La utilización de este SO para la realización del proyecto, se debe a su gran
compatibilidad con la mayoría de los programas del mercado y al estar pre-instalado en
las HP WorkStation disponibles en FADA-CATEC. Debido a la potencia hardware de
los ordenadores que se disponían y en post de obtener el máximo rendimiento del
mismo, se decidió utilizar este sistema operativo como base por unos drivers más
conseguidos y virtualizar el resto de sistemas utilizando VirtualBox.
2.3.1.2. Ubuntu 10.04
Ubuntu es una distribución Linux basada en Debian que proporciona un fuerte
enfoque en la facilidad de uso e instalación del sistema, apostando por un sistema
operativo actualizado y estable para el usuario medio. Como la mayoría de
distribuciones Linux dispone de múltiples paquetes de software distribuidos bajo una
licencia libre o de código abierto.
Está patrocinado por Canonical. Cada seis meses se publica una nueva versión de
Ubuntu la cual recibe soporte por parte de Canonical, durante dieciocho meses, por
medio de actualizaciones de seguridad, parches para bugs críticos y actualizaciones
menores de programas. Las versiones LTS (Long Term Support), que se liberan cada
dos años, reciben soporte durante tres años en los sistemas de escritorio y cinco para la
edición orientada a servidores.
La versión utilizada 10.04 (Lucid Lynx) es la actual LTS es por ello que se ha
decidido utilizar, además de tener experiencia de trabajo acumulada en este SO. Sobre
este SO se ha decidido programar la herramienta y gestionar el acceso a las placas, por
su facilidad gracias al uso de herramientas SSH y creación de servidores de ficheros de
Proyecto Final de Carrera - José M León Coca
26
forma rápida. Evitando de esta manera los continuos bloqueos “por seguridad” en
Windows.
2.3.1.3. OpenWRT 10.03
OpenWRT es una distribución de Linux basada en el cambio de firmware en
dispositivos empotrados tales como routers personales. En un comienzo, el soporte fue
limitado originalmente al modelo Linksys WRT54G, pero desde su rápida expansión se
ha incluido soporte para otros fabricantes y dispositivos, incluidos el Netgear, D-Link,
ASUS...
OpenWRT utiliza principalmente una interfaz de línea de comando. El soporte
técnico es provisto como en la mayoría de los proyectos OpenSource, a través de foros
y su canal IRC. Al igual que la mayoría de proyectos de software libre bajo licencias
GPL, que impulsa a todos aquellos fabricantes que modificaban y mejoraban el código,
a liberar éste y contribuir, de esta forma, al proyecto general.
El sistema ha ido creciendo y, actualmente, se encuentran características
implementadas muchos otros fabricantes de dispositivos comerciales no disponen, tales
como QoS, VPN y otras características que dotan a aquellos dispositivos con OpenWRT
de potencia y versatilidad.
La última versión estable, a la fecha, es la 10.03 Backfire. La elección de esta
distribución o SO para sistemas empotrados fue que era libre y era posible conseguir
unas herramientas de desarrollo para las placas que se disponían. Además de incluir
muchísimas aplicaciones y soporte en su página web (openwrt.org).
Capítulo 2: Recursos Disponibles, Hardware y Software
27
2.3.2. Programas y Aplicaciones
Los programas y aplicaciones más utilizados en el proyecto y que sin ellos no
hubiera sido posible la implementación realizada del mismo se introducen a
continuación.
2.3.2.1. ECLIPSE
Eclipse es un entorno de desarrollo integrado (IDE) de código abierto
multiplataforma. La forma de trabajar en eclipse es mediante la creación de nuevos
proyectos o proyectos predefinidos, permitiendo configurar una infinidad de opciones
en compilación y linkado. En Eclipse también es posible, dependiendo del tipo de
proyecto, una vista u otra, por ejemplo, el IDE de Java llamado Java Development
Toolkit (JDT) y el compilador (ECJ). La precarga o instalación de una vista para el IDE,
más específica para el proyecto a realizar, se realiza mediante “plug-in”. En ese
proyecto se ha utilizado el complemento CDT para eclipse el cual provee un entorno de
desarrollo y unas herramientas muy completas para la programación en C/C++.
El uso de esta herramienta ha colaborado a la creación de este proyecto facilitando
muchas de las tareas: compilación cruzada, gestión de librerías y dependencias, edición
fácil y rápida de los documentos del proyecto…
La versión que se ha utilizado en este proyecto es Helios, publicada el 23 de junio de
2010.
2.3.2.2. VIRTUALBOX
Oracle VM VirtualBox es un software de virtualización para arquitecturas x86,
creado originalmente por la empresa alemana innotek. Actualmente es desarrollado por
Oracle Corporation como parte de su familia de productos de virtualización. Por medio
de esta aplicación es posible instalar sistemas operativos adicionales, conocidos como
«sistemas invitados», dentro de otro sistema operativo «anfitrión», cada uno con su
propio ambiente virtual.
La aplicación es Open Source bajo licencia de uso GPL versión 2. Ofrece algunas
funcionalidades interesantes, como la ejecución de maquinas virtuales de forma remota,
por medio del Remote Desktop Protocol (RDP), soporte iSCSI.
Proyecto Final de Carrera - José M León Coca
28
Su forma de trabajar la emulación de hardware, se basa en la creación de los sistemas
invitados en los sistemas anfitriones como archivos individuales en un contenedor
llamado Virtual Disk Image. Otra de las funciones que presenta es la de montar
imágenes ISO como unidades virtuales ópticas de CD o DVD.
VirtualBox es incompatible con otro software de virtualización, por ejemplo, VM
Ware.
2.3.2.3. PUTTY
PuTTY es un cliente SSH, Telnet, rlogin, y TCP raw con licencia libre. Disponible
para Windows, varias plataformas Unix y se está desarrollando la versión para Mac OS.
El nombre PuTTY proviene de las siglas Pu: Port unique TTY: terminal type (Puerto
único para tipos de terminal). Sus características más relevantes son: El almacenamiento
de hosts y preferencias para uso posterior, control sobre la clave de cifrado SSH y la
versión de protocolo, clientes de línea de comandos SCP y SFTP, llamados "pscp" y
"psftp" respectivamente, control sobre el redireccionamiento de puertos con SSH,
incluyendo manejo empotrado de reenvío X11, completos emuladores de terminal
xterm, VT102, y ECMA-48, soporte IPv6, 3DES, AES, RC4, Blowfish, DES,
autenticación de clave pública y, para lo que más se ha utilizado en este proyecto,
soporte para conexiones de puerto serie local (ausencia de un programa específico en
Win7).
29
Capítulo 3
Instalación y Configuración de OpenWrt en RouterBoard
433UAH
30
31
ÍNDICE
3.1. Introducción ........................................................................................................ 32
3.2. Pasos previos ....................................................................................................... 33
3.2.1. Conexión de los Equipos ............................................................................ 33
3.2.2. Copia de seguridad Mikrotik RouterOS ..................................................... 34
3.3. OpenWrt .............................................................................................................. 36
3.3.1. Versión OpenWrt ........................................................................................ 36
3.3.2. Dependencias y Descarga OpenWrt ........................................................... 36
3.3.3. Adaptar OpenWrt ........................................................................................ 37
3.3.4. Compilación de OpenWrt ........................................................................... 38
3.4. RouterBOOT ....................................................................................................... 42
3.4.1. Formatear el sistema ................................................................................... 42
3.4.2. Seleccionar el modo de arranque ................................................................ 43
3.5. Instalación del sistema ........................................................................................ 44
3.5.1. Carga de la imagen por conexión de red local ............................................ 45
3.5.2. Arranque Netboot ....................................................................................... 48
3.5.3. OpenWrt en la Memoria NAND ................................................................. 49
3.6. Configuración de las Interfaces de Red .............................................................. 53
Proyecto Final de Carrera - José M León Coca
32
3.1. Introducción
En este capítulo se van a indicar los pasos realizados para la instalación del firmware
OpenWrt en la memoria no volátil de las placas RouterBoard 433UAH.
Para poder instalar con éxito el firmware es necesario modificar la distribución
original para que sea compatible con las tarjetas router. Además de estos pasos previos,
se explicará la disposición inicial de los equipos: la alimentación, la comunicación y el
acceso a los mismos.
Una visión general de los pasos que se seguirán en la instalación de OpenWrt sería:
Precarga en las placas de dicho sistema de forma NetBoot (arranque por red).
Instalación de forma definitiva en la memoria no volátil de las placas.
Podría dar la sensación que se instala dos veces el mismo sistema operativo, pero la
precarga del firmware en la placa para su posterior instalación es necesaria, ya que el
sistema operativo RouterOS con el que viene de serie los dispositivos, no permite su
modificación.
Al final del capítulo se expondrán las dificultades encontradas, fallos operativos y la
solución a los mismos.
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
33
3.2. Pasos previos
Como ya se comentó anteriormente, el trabajo se ha realizado en un PC con la
distribución de Linux Ubuntu 10.04. Es necesaria la utilización de alguna distribución
Linux para compilar la imagen de carga propia para la placa y sistema de ficheros
OpenWrt. No es posible utilizar los archivos precompilados en la página oficial de la
distribución ya que no funcionarían, al no estar adecuados al hardware con el que se
trabaja.
En el uso de programas comerciales y aplicaciones específicas que requieran del
sistema operativo Windows, se dispone en otra partición del equipo Windows 7.
3.2.1. Conexión de los Equipos
El esquema de la conexión de los equipos es el siguiente:
Figura 9: Conexión de los equipos configuración RB433UAH
La alimentación de la placa se realiza con una fuente de tensión continua, que
atendiendo a las especificaciones del fabricante de la placa, nos proporcione 10 V de
tensión.
La comunicación inicial con la RB433UAH se realizará mediante el puerto serie con
un cable RS232 en configuración null-modem (puertos de transmisión y recepción
cruzados), los datos específicos de configuración del terminal puerto serie son los
siguientes:
Proyecto Final de Carrera - José M León Coca
34
Velocidad 115200 bps
Datos de 8 bits
Sin paridad
1 bit de stop
Sin control de flujo
Tabla 7: Configuración Terminal Serie RB433UAH
Este tipo de acceso a los sistemas empotrados es más que recomendable para
acciones de configuración inicial y acciones críticas de control, evitando quebraderos de
cabeza innecesarios por problemas de conectividad. Claro está, siempre que sea posible
el acceso al dispositivo.
Una vez configurados los parámetros básicos en el dispositivo, es necesario habilitar
la interfaz Ethernet para dotarla de conectividad. La mejor forma de acceder a todos los
dispositivos es conectarlos en red mediante un Router/Switch, tal y como se puede ver
en el montaje propuesto en la ¡Error! No se encuentra el origen de la referencia..
3.2.2. Copia de seguridad Mikrotik RouterOS
Antes modificar el firmware es conveniente realizar una copia de seguridad del
mismo, con el interés de restaurarlo en un futuro.
Por defecto, los credenciales de acceso a la placa mediante un terminal son:
Usuario: admin
Contraseña: [ENTER]
Tabla 8: Credenciales de acceso RouterOS
Entre las opciones que se pueden encontrar al acceder al sistema RouterOS, se
encuentra la de realizar un backup al propio sistema, pero la forma más sencilla de
realizar la copia de seguridad es mediante una aplicación facilitada por el fabricante:
WinBox.
Como su propio nombre indica WinBox, es una aplicación creada para el sistema
operativo Windows. Se recomienda el uso de esta aplicación, ya que, por defecto, la
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
35
placa no tiene habilitada la interfaz Ethernet y con esta herramienta reconoce
automáticamente la MAC de la interfaz de red de la placa y se conecta a ella sin tener
una IP definida previamente, con lo que ello conlleva.
La aplicación permite configurar varias opciones de la placa con los distintos
submenús: estadísticas, interfaces habilitadas, firewall, rutas por defecto...
En la pestaña “Tools” podemos encontrar la herramienta que permite guardar una
copia de seguridad del sistema RouterOS, ésta se guardará en un archivo con extensión
“*.backup”.
Tras esta acción, podemos comenzar a sustituir el firmware de la placa.
Figura 10: WinBox
Proyecto Final de Carrera - José M León Coca
36
3.3. OpenWrt
Como se comentó en el Capítulo 2, OpenWrt es una distribución firmware basada en
Linux especialmente diseñada para dispositivos empotrados. Con una gestión de
paquetes muy ligera: opkg, un sistema para dispositivos con limitaciones serias de
almacenamiento. La instalación de paquetes con opkg se puede asociar al uso de apt-
get, por ejemplo, para distribuciones basadas en Debian.
3.3.1. Versión OpenWrt
La versión estable y más actual a la fecha de este PFC, es la versión 10.03 con el
nombre en clave Backfire.
Figura 11: Logotipo de Arranque OpenWrt
Como nota curiosa, cada distribución de OpenWrt tiene el nombre en clave de un
combinado el cual explican su realización bajo el logotipo.
3.3.2. Dependencias y Descarga OpenWrt
Tal y como se puede seguir en la wiki de la comunidad OpenWrt, se promueven unos
pasos previos antes de trabajar con el sistema. Por ejemplo, conseguir las dependencias
necesarias para que funcione. Para ello se escribe en un terminal de Linux la siguiente
instrucción:
sudo aptitude install build-essential binutils flex bison autoconf gettext texinfo
sharutils subversion libncurses5-dev ncurses-term zlib1g-dev gcc-3.4
El siguiente paso es la descarga de los paquetes de OpenWrt, para ello es necesario
situarse en el directorio donde se quiera disponer de los mismos. Para la descarga se
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
37
hará uso de una herramienta para el control de versiones, la cual en este proyecto sólo se
ha utilizado para la descarga de los paquetes:
svn co svn://svn.openwrt.org/openwrt/branches/backfire
Estos paquetes conformaran la imagen de arranque y el sistema de ficheros,
permitiéndonos configurar el firmware a instalar, como se desee.
NOTA: ANTES DE LANZAR EL COMANDO SVN SITUARSE EN EL DIRECTORIO
DONDE SE QUIERAN DESCARGAR LOS PAQUETES. EN ESTE PROYECTO LOS DATOS SE
HAN DESCARGADO EN LA CARPETA OPENWRT.
3.3.3. Adaptar OpenWrt
La modificación que se realiza, a grandes rasgos, incrementa el espacio destinado por
defecto a la partición del Kernel del sistema, ya que de otra manera no se dispone de
espacio suficiente para el generado. Es por tanto necesario, para esta placa, esta
modificación. El problema se debe a que, por defecto, la memoria reservada de forma
“teórica” al Kernel de OpenWrt es demasiado pequeña para poder albergar todo el
Kernel generado. Es por ello que se deben modificar los parámetros de partición de la
memoria NAND y extenderla para que acoja al susodicho Kernel.
El archivo a modificar y su ruta son:
/openwrt/target/linux/ar71xx/files/drivers/mtd/nand/rb4xx_nand.c
En este fichero se debe localizar el siguiente fragmento de código (línea 92-98),
prestando atención a la línea señalada:
{
.name = "kernel",
.offset = (256 * 1024),
.size = (4 * 1024 * 1024) - (256 * 1024),
}
{
.name = "rootfs",
Se modifica la línea 95, la señalada en el anterior fragmento de código, de forma que
quede de la siguiente manera:
Proyecto Final de Carrera - José M León Coca
38
.size = (8 * 1024 * 1024) - (256 * 1024),
La simple modificación de un 4 por un 8 permite incrementar el tamaño destinado a
la partición del Kernel de 4 Mb a 8 Mb, disponiendo de esta manera de espacio
suficiente para la instalación.
3.3.4. Compilación de OpenWrt
El realizar de esta acción debe ser estando logeado en el sistema como un usuario
“normal” no como super-usuario, ya que el sistema no permitirá la compilación de esta
manera. Aún así y si se produce la compilación como super-usuario en el punto 3.6 se
presenta la solución a este problema.
La compilación del sistema se realizará dos veces, una indicando que la salida del
mismo sea un RAMDISK y la siguiente vez el sistema de ficheros que instalaremos en
la NAND.
3.3.4.1 RAMDISK
En primer lugar, se generará un tipo de archivo que permita cargarse en la RAM del
dispositivo, el problema de este tipo de “instalación” es que se perderá en el mismo
momento en el sistema se reinicie, debido a la volatilidad de la memoria RAM.
Para ejecutar la aplicación que nos permita generar este archivo, teclear en la carpeta
dónde se han descargado los archivos:
make menuconfig
Se accede a una interfaz gráfica en la que se muestran las instrucciones para navegar
por los menús. Ahora, seleccionar el Procesador de la placa (AR7161), para ello seguir
la siguiente ruta:
Target System Atheros AR71xx/AR7240/AR913x.
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
39
Lo siguiente a configurar es el tipo de imagen que se desea generar, marcando las
siguientes opciones en la ruta:
Target Images * ramdisk * tar.gz.
Para comenzar la compilación se cierra la aplicación guardando los cambios
realizados y se invoca el comando:
make
Figura 12: Menú Inicial de Configuración OpenWrt
Figura 13: Menú de Target Images para el ramdisk
Proyecto Final de Carrera - José M León Coca
40
El proceso es bastante pesado, estimándose en torno a 45 minutos dependiendo de la
máquina.
Una vez terminado se puede comprobar que los ficheros generados se encuentran en
la siguiente ruta:
/openwrt/bin/ar71xx
Entre otros archivos, los que se necesitan son:
openwrt-ar71xx-rootfs.tar.gz
openwrt-ar71xx-vmlinux-initramfs.elf
3.3.4.1 SISTEMA DE FICHEROS
La forma de proceder será idéntica que en la generación de archivos anterior, se
teclea:
make menuconfig
En esta ocasión se deben marcar las siguientes opciones de la ruta que se indica:
Target Images * tar.gz
* jffs2 (NEW)
* squashfs (NEW)
Figura 14: Menú Target Images Sistema de Ficheros
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
41
Las opciones que se marcan, jffs2 y squashfs, son extensiones de sistemas de
archivos comprimidos, la primera de lectura y de escritura y sólo de lectura la segunda.
Siendo jffs2 un sistema de soporte especializado en transacciones en memorias flash.
Tras el paso anterior se cierra guardando la aplicación y volvemos a teclear:
make
Los archivos de salida generados se encuentran en la misma ruta que los anteriores:
/openwrt/bin/ar71xx
Ahora, se disponen de todos los archivos necesarios para poder instalar el firmware
OpenWrt en las placas.
Proyecto Final de Carrera - José M León Coca
42
3.4. RouterBOOT
El routerBOOT el es la primera rutina en cargar al iniciar la RB433UAH. Los
mensajes que arroja, son redirigidos por defecto a la consola serie del dispositivo. Se
puede asemejar a la “bios” de un ordenador personal, ya que permite configurar las
opciones de arranque y otras herramientas más avanzadas por medio de un menú. Este
menú de configuración aparece al pulsar cualquier tecla durante el tiempo de arranque
de la placa, el tiempo es configurable, pero por defecto, muy pequeño (2 segundos).
Figura 15: Menú RouterBOOT
Las opciones de este menú que se comentan a continuación serán las de “format
NAND” y “boot protocol”.
3.4.1. Formatear el sistema
Lo primero que se sugiere antes de realizar este paso es hacer una copia de seguridad
del sistema explicado en el apartado 3.2.2, ya que la acción a realizar conlleva el
borrado de la memoria NAND, proceso irreversible.
Para realizar el formateo del sistema, será necesario entrar en el menú de
configuración de arranque de la placa, routerBOOT. Para ello, como se explicó en el
apartado anterior, es necesario pulsar una tecla cualquiera en la consola serie en los 2
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
43
segundos tras alimentar la placa. Una vez dentro del menú routerBOOT, tendremos que
seleccionar la siguiente opción para iniciar el borrado de la memoria NAND:
format NAND
Se espera a que finalice totalmente el proceso. Se recuerda que, en este tipo de
acciones tan críticas, un corte de alimentación por accidente podría llegar a bloquear la
tarjeta llegando a dejarla inservible. En otras ocasiones, si se interrumpiera el proceso
por algún tipo de evento, se recomienda realizar de nuevo la misma acción para que
quede totalmente borrada la memoria.
3.4.2. Seleccionar el modo de arranque
Para la instalación de OpenWRT es necesario cargar una imagen con el firmware
mediante la interfaz de red, a esto se le conoce como netboot.
La configuración y carga del netboot necesita tener habilitada la interfaz de red con
una IP dentro del rango de la red. Para la consecución de esta IP es necesario activar el
protocolo DHCP. Para ello se seleccionan las siguientes opciones en el menú
routerBOOT:
boot protocol -> dhcp protocol
Cabe decir que el dispositivo que contenga la imagen de carga ha de implementar un
servidor DHCP que nutra a las placas, tal y como se explica en el apartado 3.5.1.1.
Tras este paso solo queda indicar desde donde se quiere arrancar, para ello se
seleccionarán las siguientes opciones en el menú routerBOOT:
boot device -> boot over Ethernet
Ya están preparadas las placas para el arranque e instalación del sistema, ahora será
necesaria la configuración del dispositivo de red que contenga la imagen a instalar.
Proyecto Final de Carrera - José M León Coca
44
3.5. Instalación del sistema
Para poder instalar el sistema es necesario copiar en la memoria NAND el nuevo
sistema de ficheros de OpenWRT, para ello la opción que se ha ido comentando a lo
largo de este capítulo se recuerda que se basaba en dos ideas claves:
Carga de una imagen RAMdisk.
Una vez cargada la imagen, escribir en la memoria no volátil OpenWRT.
El esquema de conexionado de los equipos se realizará prácticamente igual que como
se recomendó al inicio del proyecto (3.2.1), pero suprimiendo el router/switch y
conectando directamente el PC a la RB433UAH. Tal y como se indica en la siguiente
ilustración:
Figura 16: Conexión de los Equipos NetBoot
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
45
3.5.1. Carga de la imagen por conexión de red local
La carga de la imagen por conexión de red, consiste en la ejecución de un entorno de
prearranque en la entidad cliente, que se encarga de buscar lo necesario para comenzar
una transferencia básica de ficheros con la entidad servidora, que proporciona lo
requerido al cliente. Ese proceso se puede ver más claramente en la siguiente figura:
Figura 17: Diagrama PXE
En este proyecto el servidor DHCP y el servidor TFTP se encuentran en la misma
máquina, es por ello que se debe instalar y configurar ambos servidores.
Proyecto Final de Carrera - José M León Coca
46
3.5.1.1. Servidor DHCP
DHCP (Dynamic Host Configuration Protocol - Protocolo de configuración dinámica
de host) es un protocolo de red que permite a los clientes de una red IP obtener sus
parámetros de configuración automáticamente. Protocolo de tipo cliente/servidor en el
que un servidor posee una lista de direcciones IP dinámicas y las va asignando a los
clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado
en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.
Una vez conocido, es necesario instalar el servidor DHCP ya que no es una
herramienta muy común en distribuciones Linux destinadas para escritorio. Su
instalación es sencilla, sólo se ha de invocar el siguiente comando:
sudo apt-get install dhcp3-server
Antes de configurar este servidor ha de decirse que los parámetros del servidor
DHCP y TFTP han de corresponderse entre ellos, no son independientes entre sí.
Los archivos de configuración del servidor DHCP se encuentran en la siguiente ruta:
/etc/dhcp3/dhcp.conf
/etc/default/dhcp3-server
A modo de ejemplo, o como plantilla pueden utilizarse los mismos archivos de
configuración usados en este proyecto (dirección IP del PC 192.168.1.10):
######################################################
### Configuración del archivo /etc/dhcp3/dhcp.conf ###
### José M. León Coca ###
######################################################
ddns-update-style none;
# El dominio de la red que se utilice, OBLIGATORIO
option domain-name "catec.com";
# Por defecto
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
# Definición de los parámetros de la red
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.20 192.168.1.49;
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
47
option domain-name-servers 192.168.1.1;
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
}
# Configuración específica de los equipos que arranquen desde nuestro servidor.
# Es importante, la dirección del servidor tftp en este caso la misma máquina con
dhcpd
# en next-server. La dirección IP de nuestro PC es 192.168.1.10
host RB_433U {
hardware ethernet 00:0C:42:43:B2:81;
fixed-address 192.168.1.100;
next-server 192.168.1.10;
filename "/srv/tftp/vmlinux.elf";
}
host RB_433U_2 {
hardware ethernet 00:0C:42:44:E9:55;
fixed-address 192.168.1.101;
next-server 192.168.1.10;
filename "/srv/tftp/vmlinux.elf";
}
######################################################
### Configuración /etc/default/dhcp3-server ###
### José M. León Coca ###
######################################################
# En este archivo indicar la interfaz sobre la que estableceremos el
# servidor
INTERFACES="eth0"
3.5.1.2. Servidor TFTP
TFTP (Trivial file transfer Protocol - Protocolo de transferencia de archivos trivial)
es un protocolo de transferencia muy simple semejante a una versión básica de FTP. Se
utiliza principalmente para lo mismo que en este proyecto, el arranque en red de los
equipos. Utiliza para la transferencia de paquetes el protocolo UDP sobre el puerto 69,
carece de mecanismos de autenticación o cifrado.
Ahora es turno de instalarlo, al igual que con el servidor DHCP, se instala invocando
la orden:
sudo apt-get install atftp
Proyecto Final de Carrera - José M León Coca
48
Encontrándose su fichero de configuración en la ruta:
/etc/default/atftp
Al igual que en el servidor anterior, este fichero de configuración puede ser utilizado
como plantilla:
#############################################
### Configuración /etc/default/atftpd ###
### José M. León Coca ###
#############################################
# Las opciones que se indican son para que funcione en transmisiones
# bootp, resaltar “/srv/tftp” ruta donde estarán los archivos a
# utilizar
USE_INETD=false
OPTIONS="--daemon --port 69 --retry-timeout 5 --mcast-port 1758 --mcast-ttl 1 --
maxthread 100 --verbose=5 /srv/tftp"
La ruta en la que hemos configurado que se encontrarían los archivos de la imagen
de carga es la siguiente:
/srv/tftp
Es por tanto donde se debe copiar el archivo generado en el punto 3.3.4: “openwrt-
ar71xx-vmlinux-initramfs.elf”. Por comodidad y tratar de evitar errores, en este
proyecto se renombra este archivo a “vmlinux.elf”.
3.5.2. Arranque Netboot
Al haberse realizado los pasos anteriores, el sistema se ha predispuesto para realizar
la carga de la imagen mediante netboot. Este tipo de arranque se realiza conectando los
equipos en red y encendiendo, o reiniciando en el sistema, de los servidores
anteriormente instalados y configurados en el PC: el servidor TFTP y el servidor
DHCP.
sudo /etc/init.d/atftpd restart
sudo /etc/init.d/dhcp3-server restart
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
49
Ahora es el momento de alimentar la placa y monitorizar por el puerto serie la carga
del SO OpenWrt. Se observa como solicita una dirección IP por DHCP e inicia, tras
esto, la descarga de la imagen del sistema procedente del ordenador.
Tras su carga, la placa está lista para trabajar con ella y configurarla, pero estos
cambios son siempre volátiles, ya que al apagar el sistema se perderán; es una carga del
sistema en la memoria RAM (RAMdisk) y al cargar nuevamente el sistema operativo
por red, como se ha realizado, estará como al principio.
3.5.3. OpenWrt en la Memoria NAND
Para poder instalar OpenWrt de forma definitiva en la placa, es necesario instalarlo
en su memoria no volátil. La memoria no volátil del dispositivo, la NAND, es de 512
MB, mucho mayor de lo que suele ser habitual en este tipo de dispositivos.
Para esta tarea se utiliza la herramienta facilitada por OpenWrt en sus sistemas:
wget2nand, que permite la descarga e instalación de la imagen en la memoria NAND
sin muchos inconvenientes. Para la utilización de la herramienta es necesario tener un
servidor FTP activo en el computador, su instalación y configuración se detallan a
continuación.
3.5.3.1. Servidor FTP
En la comunidad Linux hay multitud de programas que realizan la creación y
configuración de servidores FTP, el utilizado en este proyecto ha sido el “vsftpd”
disponible en los repositorios de Ubuntu.
Instalación:
sudo apt-get install vsftpd
Configuración se realiza editando el archivo de la ruta:
/etc/vsftpd.conf
Proyecto Final de Carrera - José M León Coca
50
El utilizado para este proyecto, como en las configuraciones anteriores se muestra a
continuación como ejemplo:
#############################################
### Configuración /etc/vsftpd.conf ###
### José M. León Coca ###
#############################################
# Correr desde el principio el programa.
listen=YES
# Permite conexiones anónimas: nuestro caso.
anonymous_enable=YES
# Permite a usuarios locales la conexión.
local_enable=YES
# Opciones varias
dirmessage_enable=YES
use_localtime=YES
# Activar las descargas/subidas
xferlog_enable=YES
# Aceptar conexiones entrantes desde el puerto 20.
connect_from_port_20=YES
# Banner que aparecerá al aceptar la conexión
ftpd_banner=BIENVENIDO AL SERVIDOR DE CATEC
# Por seguridad se permite el acceso a un directorio que debe estar vacio
secure_chroot_dir=/var/run/vsftpd/empty
# Nombre del servicio PAM del programa
pam_service_name=vsftpd
# Especifica la localización del certificado RSA para conexiones SSL encriptadas.
rsa_cert_file=/etc/ssl/private/vsftpd.pem
A continuación será necesario copiar en una misma carpeta, openwrt, por ejemplo;
los archivos generados en el punto 3.3.4:
openwrt-ar71xx-vmlinux.elf
openwrt-ar71xx-rootfs.tar.gz
En la ruta creada por defecto por el servidor FTP, ubicamos la carpeta:
/srv/ftp/openwrt
Reactivación del demonio que controla el servidor:
sudo /etc/init.d/vsftpd restart
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
51
3.5.3.2. WGET2NAND
El primer paso a realizar es la carga del sistema mediante la red, como se indica en el
punto 3.5.2. Una vez se tenga el control del sistema OpenWrt por la interfaz abierta en
el puerto serie, será necesario editar la herramienta wget2nand, ya que no se encuentra
adaptada a la extensión de nuestros archivos generados. Aclarar que esta herramienta se
trata de un script, es por ello que se puede editar.
El script wget2nand se encuentra en la ruta:
/sbin/wget2nand
Su edición se realizará con el editor de textos por defecto en el sistema: vi/vim. Es
necesario cambiar las líneas que se refieran a cualquier archivo con extensión “*.tgz” y
modificar dicha extensión por “*.tar.gz”, la cual se corresponde con los archivos
generados del sistema.
Ya preparado el sistema, se lanza la aplicación indicando la dirección del servidor
FTP creado en el PC (dirección 192.168.1.10):
wget2nand ftp://192.168.1.10/openwrt
Esta es la salida resultante de tan delicado proceso:
Connecting to 192.168.1.10 (192.168.1.10:21)
kernel 100%
|*****************************************************************| 2627k 00:00:00 ETA
Connecting to 192.168.1.10 (192.168.1.10:21)
rootfs.tar.gz 100%
|*****************************************************************| 2291k --:--:-- ETA
Erasing filesystem...
Mounting /dev/mtdblock2 as new root and /dev/mtdblock1 as kernel partition
Copying kernel...
Preparing filesystem...
./
./overlay/
./var
./bin/
[…]
./dev/
./proc/
./www/
Cleaning up...
Image written, you can now reboot. Remember to change the boot source to Boot from
Nand
Proyecto Final de Carrera - José M León Coca
52
Si todo ha ido como debe, tal y como se puede apreciar en el mensaje final emitido
por la aplicación, es necesario reiniciar el sistema y cambiar el modo de arranque. Se
escribe en el terminal la orden de reinicio del sistema:
reboot
La herramienta wget2nand realiza multitud de operaciones complejas como montar y
desmontar bloques de la memoria NAND, copia de cada parte dónde le corresponde…
Es por ello que se recomienda su uso, ya que es posible una instalación manual, pero
como opinión personal creo que evita quebraderos de cabeza.
3.5.3.3. Arranque Desde la Memoria NAND
Tal y como se ha realizado anteriormente, es necesario que mientras arranca la placa
se pulse rápidamente una tecla para conseguir entrar en el menú del RouterBOOT. Y
modificar lo siguiente:
boot device boot from NAND only
Salir del sistema y dejar que cargue sin realizar acción alguna y finalmente se obtiene
el resultado:
loading kernel from nand... OK
setting up elf image... OK
jumping to kernel code
[...]
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
BusyBox v1.15.3 (2010-07-21 09:59:27 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
Backfire (10.03, r22269) --------------------------
* 1/3 shot Kahlua In a shot glass, layer Kahlua
* 1/3 shot Bailey's on the bottom, then Bailey's,
* 1/3 shot Vodka then Vodka.
---------------------------------------------------
root@OpenWrt:/#
Capítulo 3: Instalación y Configuración de OpenWrt en RouterBoard 433UAH
53
3.6. Configuración de las Interfaces de Red
OpenWrt se configura según el sistema UCI (Unified Configuration Interface –
Interfaz de Configuración Unificada) el cual trata de centralizar toda la configuración.
Ésta se realiza modificando los archivos de texto plano que se encuentran en la ruta:
/etc/config/
La configuración de las interfaces de red se realiza teniendo en cuenta el modelo de
red a implementar. Ya que será necesaria una configuración más o menos compleja de
los siguientes archivos:
network: En este archivo se centraliza la configuración de las interfaces de
red. En el pueden definirse switch VLANs, relizar la configuración IP de
cada interfaz, asociándola a una zona y añadir rutas de red.
wireless: Es el encargado de la configuración inalámbrica, en él se
distinguen dos zonas de configuración; la correspondiente a la definición del
dispositivo físico y sus parámetros (driver, canal, banda de funcionamiento,
región…) y otra correspondiente a la definición de una o varias interfaces
virtuales asociadas al dispositivo físico definido anteriormente y sus
atributos (modo de funcionamiento, SSID, encriptación...).
dhcp: Establece la configuración que atañe a los servidores de DNS y de
DHCP. Permite configurar y activar un servidor DHCP en la zona que se
desee, estableciendo el rango de IPs que se quieran repartir.
firewall: La configuración de este archivo se basa en la definición de
distintas zonas en las que se establecen reglas de tráfico entre ellas para
permitir o denegar el flujo de datos dependiendo del protocolo utilizado.
Permite enmascarar el tráfico y reenviar los paquetes que se consideren.
Como se puede observar, mediante la configuración de estos archivos puede
generarse una red y configurarla tanto como se desee. Teniendo en cuenta la
procedencia del movimiento OpenWrt, a partir de creación de un firmware para el
Router Linksys WRT54G, un router doméstico, es loable las opciones de configuración
que permite en relación al resto de routers domésticos no profesionales.
Proyecto Final de Carrera - José M León Coca
54
La red que se ha configurado para este proyecto se muestra en la siguiente figura:
Punto de Acceso ClienteRouter
CATEC_AP
Figura 18: Esquema de Red
La red consta de un punto de acceso conectado a un router que permite la salida a
internet y un cliente que se conecta al punto de acceso. Las RB433UAH se han
configurado de forma conveniente para que realicen: una el papel de punto de acceso y
otra como cliente.
55
Capítulo 4
Entorno de Compilación Cruzada OpenWrt
56
57
ÍNDICE
4.1. Introducción ........................................................................................................ 58
4.1.1. Toolchain .................................................................................................... 58
4.1.2. Compilación Cruzada ................................................................................. 59
4.1.3. Buildroot ..................................................................................................... 59
4.1.4. Entorno de Compilación Cruzada ............................................................... 60
4.2. Buildroot OpenWRT ........................................................................................... 61
4.2.1. Obtener Buildroot OpenWrt ....................................................................... 61
4.2.2. Configuración del Buildroot OpenWrt ....................................................... 62
4.2.3. Funcionamiento Buildroot OpenWrt .......................................................... 64
4.3. Entorno de Compilación Cruzada ....................................................................... 67
4.3.1. Herramientas de Compilación Cruzada OpenWrt ...................................... 68
4.3.2. Modificación de las Variables de Entorno .................................................. 68
Proyecto Final de Carrera - José M León Coca
58
4.1. Introducción
A lo largo de este capítulo se explican los conocimientos adquiridos en la generación
y utilización del entorno de compilación cruzado de OpenWRT. El inicio se dedica a la
explicación de varios conceptos informáticos, abordados por primera vez en la
realización del proyecto, conceptos necesarios para la comprensión del Buildroot
OpenWRT.
4.1.1. Toolchain
El primer término a definir es la palabra inglesa toolchain, cuya traducción literal
quiere decir cadena de herramientas. Se conoce en términos informáticos como el
conjunto de programas o herramientas que se usan para crear un determinado producto,
que normalmente es otro programa o un sistema informático. Su nombre se debe a que
distintos programas se suelen usar en cadena, de modo que la salida de cada herramienta
sea la entrada de la siguiente. En la actualidad este término se ha generalizado y se
utiliza para referirse a cualquier tipo de herramientas de desarrollo, aún sin estar
enlazadas.
Un ejemplo de una simple cadena de herramientas de desarrollo de software es: el
uso de un editor de texto, para generar código fuente; un compilador y un enlazador,
para transformar el código fuente en un programa ejecutable; librerías para proveer de
una interfaz al sistema operativo y un depurador.
El uso de unas toolchain específicas permite generar programas para ejecutarlos en
otras máquinas de arquitecturas distintas o más especificas (distintas librerías, sistema
operativo…) que en el sistema donde se ha diseñado el programa. Comúnmente, se
conoce como compilación cruzada, justamente lo que se ha realizado en este proyecto.
Para ello es necesario utilizar las herramientas específicas del sistema donde se quieren
ejecutar los trabajos.
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
59
4.1.2. Compilación Cruzada
El termino compilación cruzada se puede definir como la compilación de código
fuente que, realizada bajo una determinada arquitectura genera código ejecutable para
una arquitectura diferente. Se definen dos tipos de entidades: el sistema huésped y el
sistema objetivo, siendo posible encontrar mayores referencias con sus respectivos
términos en inglés host/target respectivamente.
Entorno de Desarrollo
Cruzado
Kernel
Sistema de Archivos
Librerías
Equipo Huésped Equipo Objetivo
Figura 19: Esquema de Compilación Cruzada
Para la realización de esta tarea es necesario generar un “ambiente” propicio para
ella, compuesto por conjunto determinado de programas y librerías que generen el
entorno de compilación cruzada.
4.1.3. Buildroot
Un buildroot es un conjunto de herramientas que permite generar tanto las
herramientas de compilación cruzada como el sistema de ficheros raíz, en general para
un dispositivo empotrado. Cada vez son más las plataformas en las que se pueden
trabajar y desarrollar nuevos proyectos y aplicaciones software gracias a la generación
de estas herramientas.
Figura 20: Logotipo de la Comunidad BuildRoot
Proyecto Final de Carrera - José M León Coca
60
4.1.4. Entorno de Compilación Cruzada
Un entorno de compilación cruzada está formado por un conjunto de librerías, de
archivos utilitarios y de archivos binarios, que permiten realizar la compilación cruzada.
Prestando especial atención a los sistemas GNU/Linux empotrados, entorno de
compilación que se trata en este proyecto, este conjunto de archivos se les denomina
toolchain components. Formados por:
Compilador de C: Un compilador de C básico el cual sea capaz de generar
código objeto, tanto del Kernel como de las aplicaciones.
Librerías de C: Librerías que implementan las llamadas al sistema mediante APIs
(Application Programming Interface – Interfaz de Programación de Interfaces).
Binutils: Conjunto de programas necesarios para la compilación, enlazado,
ensamblado y depuración de código.
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
61
4.2. Buildroot OpenWRT
El Buildroot de OpenWRT es una herramienta que se distribuye de forma gratuita
por la propia comunidad OpenWRT. Permite realizar una imagen genérica de la
distribución para varios tipos de arquitectura y también permite su personalización y
configuración a la hora de generarla. Además de proveer las herramientas en cadena de
compilación cruzada (cross-compile toolchain). El Buildroot de OpenWrt se compone
de Makefiles y archivos modificadores (parches) escritos en diff, distintos para cada tipo
de arquitectura y modelo.
Aunque en otros capítulos se comentan algunos de los aspectos que aparecen en este
capítulo, como por ejemplo la descarga de los paquetes de OpenWrt, se ha decidido,
para no perder generalidad, volver a comentarlos.
4.2.1. Obtener Buildroot OpenWrt
El Buildroot OpenWrt está disponible en un servidor de versiones, es por ello que se
necesita de la aplicación subversion para poder descargar los paquetes, invocando el
siguiente comando pueden descargarse los paquetes de la versión en desarrollo de la
distribución:
svn co https://svn.OpenWrt.org/OpenWrt/trunk/
Aunque en el sitio de OpenWrt se nos recomienda encarecidamente que si se desea
generar una imagen personalizada de su sistema, lo más idóneo sería descargar la última
versión estable de OpenWrt, a la fecha de realización de este proyecto: “Backfire”:
svn co https://svn.OpenWrt.org/OpenWrt/branches/backfire/
NOTA: AL REALIZAR LA INVOCACIÓN DEL COMANDO SVN REALIZARLO EN EL
DIRECTORIO EN EL CUAL QUERAMOS UBICAR LOS PAQUETES DESCARGADOS.
Proyecto Final de Carrera - José M León Coca
62
4.2.2. Configuración del Buildroot OpenWrt
Para comenzar a usar el Buildroot OpenWrt se configura gracias a una herramienta
que presenta una interfaz gráfica, similar a la que se puede encontrar en la configuración
de los Kernel de Linux o en Busibox.
NOTA: HAY QUE TENER EN CUENTA QUE LA HERRAMIENTA SIEMPRE HAY QUE
UTILIZARLA COMO UN USUARIO CON CREDENCIALES NORMALES, NO DE
SUPERUSUARIO.
Para lanzar el menú de configuración, invocar:
make menuconfig
En el menú de configuración se podrá observar que por cada entrada una pequeña
descripción del elemento a configurar, además de instrucciones para moverse por el
mismo.
Figura 21: Menú Inicial Configuración OpenWrt
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
63
Es necesario configurarlo con los parámetros necesarios, por ejemplo: la
arquitectura, en este caso, se han marcado las siguientes opciones:
Target System Atheros AR71xx/AR7240/AR913x.
[*] Build the OpenWrt SDK
[*] Build the OpenWrt based Toolchain
Una vez configurados todos los parámetros, la herramienta genera un archivo de
configuración:
.config
El archivo es configurable sin necesidad de pasar por la herramienta gráfica, el cual
será la entrada al realizar la invocación de:
make
Con este comando se descargarán, configuraran y compilarán las herramientas
seleccionadas, y finalmente se generará la imagen firmware objetivo y los paquetes
adicionales seleccionados. Los ficheros resultantes, se encuentran en el subdirectorio
/openwrt/bin/
Respecto a las imágenes del firmware, se han generado dos tipos de sistemas de
archivos: jffs2 y squashfs.
jffs2: Contiene un sistema de ficheros que permite la escritura, el cual se expande
por toda la memoria NAND disponible, hay que tener en cuenta que dependiendo
de cada dispositivo esta memoria es variable y por tanto hay que seleccionar de
forma correcta los parámetros de configuración para que se ajuste a esta.
squashfs: Se trata de un sistema de ficheros solo de lectura con compresión
LZMA. A la hora del arranque, se puede crear un segundo sistema de ficheros
que posibilite la escritura, el cual contenga las modificaciones realizadas sobre el
mismo, incluyendo los paquetes de la instalación.
Proyecto Final de Carrera - José M León Coca
64
4.2.3. Funcionamiento Buildroot OpenWrt
Como se comentó anteriormente, el Buildroot de OpenWrt es básicamente un
conjunto de Makefiles que descargan, configuran y compilan software con las opciones
correctas. También incluye varios parches y archivos procedentes de fuentes distintas,
principalmente aquel software que tiene que ver con la compilación cruzada y sus
herramientas (gcc, binutils y µClibc).
4.2.3.1. CARPETAS OPENWRT
En cada programa o elemento software, distribuidos por carpetas en los paquetes
descargados, hay prácticamente un Makefile. Se encuentran distribuidos de la siguiente
manera en cada ruta indicada:
/openwrt/package/
Contiene los Makefiles y archivos asociados para el espacio de usuario y sus
herramientas. Éstos pueden compilarse y añadirse al sistema de archivos raíz objetivo.
Hay uno por cada subdirectorio correspondiente a cada herramienta.
/openwrt/toolchain/
Se localizan los Makefiles y ficheros asociados al software relacionado con las
herramientas de compilación cruzada: binutils, ccache, gcc, gdb, cabeceras del Kernel y
µClibc.
/openwrt/target/
En su interior alberga los Makefiles y archivos asociados al software relacionado con
el sistema de ficheros de la imagen objetivo y el Kernel para los diferentes sistemas,
según el chip de su arquitectura. Los sistemas de ficheros soportados son los
comentados anteriormente: jffs2 y squashfs.
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
65
Cada directorio contiene al menos dos ficheros:
Makefile: es el encargado de descargar, configurar y compilar el sistema de
ficheros.
config.in: es parte de la herramienta del archivo de configuración. Describe las
opciones seleccionadas para el software actual.
4.2.3.2. MAKEFILE PRINCIPAL
El Makefile principal, tras ser configurado, trabaja de la siguiente manera:
1) Crea el directorio de descarga:
./dl/
En el cual los directorios y ficheros fuente se descargarán junto con sus permisos
(tarballs), es interesante saber que estos ficheros fuente se encuentran aquí, ya
que evitan futuras descargas.
2) Crea el directorio de trabajo:
./build/
En el que todas las herramientas del espacio de usuario serán compiladas.
3) Crea el directorio de trabajo de las toolchain
./toolchain_build/
Aquí serán compiladas las herramientas de compilación cruzada.
4) Configura la estructura de los directorios:
./staging_dir/
En este directorio se instalarán las herramientas de compilación cruzada.
5) Crea el directorio del dispositivo objetivo y el esqueleto del sistema de ficheros
./build/root/
Si se realizara alguna configuración indebida en éste, es posible restaurarlo
copiando el esqueleto disponible por defecto en:
Proyecto Final de Carrera - José M León Coca
66
./target/default/target_skeleton/
6) Realiza las llamadas para preparar la configuración, compilación e instalación
para los subdirectorios:
./toolchain
./package
./target
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
67
4.3. Entorno de Compilación Cruzada
Para conseguir realizar la compilación cruzada de código con herramientas de
autotools es necesario modificar las variables de entorno de nuestro sistema para
realizar la compilación desde nuestra máquina.
NOTA: ESTE MÉTODO NO ES PERMANENTE, YA QUE AL MODIFICAR LAS
VARIABLES DE ENTORNO EN UNA TERMINAL, AL CERRARLA Y VOLVERLA A ABRIR,
SE CARGARÁ CON LAS CONSTANTES DEL SISTEMA, POR DEFECTO.
En primer lugar se presenta el esquema de la operación a realizar:
Figura 22: Compilación Cruzada x86/MIPS32
Tal y como se observa en la Figura 22, se realiza el desarrollo en un PC cuya
arquitectura es x86 y gracias a las herramientas de compilación cruzada es posible
generar programas ejecutables en la placa RB433UAH cuya arquitectura es MIPS.
Proyecto Final de Carrera - José M León Coca
68
4.3.1. Herramientas de Compilación Cruzada OpenWrt
Las herramientas de compilación cruzada o cross-compile toolchain OpenWrt se
componen de:
El compilador: gcc.
Las herramientas binarias como el ensamblador y el enlazador (assembler &
linker): binutils.
Las librerías estándar de C: µClibc.
Estas herramientas han sido generadas siguiendo los pasos del apartado anterior y tal
como se comentan se encuentran en el directorio “stagin_dir”, más concretamente sus
binarios se encuentran ubicados en:
/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin
Es a esta ruta donde se tendrán que redirigir las variables del entorno de compilación.
4.3.2. Modificación de las Variables de Entorno
Para la modificación de las variables de entorno se ha creado un script que las
modifica utilizando el comando “export” y además, el propio script, realiza la
invocación del archivo de configuración con las opciones pertinentes de host/target y
lanza también la compilación:
#!/bin/bash
######################################################
### Archivo cross-compile.sh ###
### José M. León Coca ###
######################################################
echo Empezando $0 ...
echo ------------------------------------------
echo - Modificando las variables de entorno -
echo ------------------------------------------
export PATH="$PATH:/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-
4.3.3+cs_uClibc-0.9.30.1/usr/bin"
echo Cambiado el PATH ... $PATH
export AR=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-ar
echo Cambiado AR ... $AR
Capítulo 4: Entorno de Compilación Cruzada OpenWrt
69
export AS=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-as
echo Cambiado AS ... $AS
export LD=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-ld
echo Cambiado LD ... $LD
export NM=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-nm
echo Cambiado NM ... $NM
export CC=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-gcc
echo Cambiado CC ... $CC
export CPP=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-cpp
echo Cambiado CPP ... $CPP
export GCC=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-gcc
echo Cambiado GCC ... $GCC
export CXX=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++
echo Cambiado CXX ... $CXX
export RANLIB=/home/pepe/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-ranlib
echo Cambiado RAMLIB ... $RAMLIB
export LDFLAGS="-static"
export CFLAGS="-Os -s"
echo ----------------------------------------------
echo - Fin modificación variables de entorno -
echo ----------------------------------------------
echo Ejecutando configure...
./configure --target=mips-openwrt-linux --host=mips-openwrt-linux
echo Ejecutando make...
make
echo FIN DE LA COMPILACIÓN CRUZADA
Reflejar que este es un script genérico y que para utilizarlo en este proyecto se han
comentado algunas de las variables que aparecen y que no son necesaria su
modificación.
70
71
Capítulo 5
Eclipse, Entorno de Desarrollo
72
73
ÍNDICE
5.1. Introducción ........................................................................................................ 74
5.1.1. Historia ........................................................................................................ 74
5.1.2. Características ............................................................................................. 75
5.2. Descarga e Instalación de Eclipse ....................................................................... 77
5.2.1. Obtención de Eclipse .................................................................................. 77
5.2.2. Interfaz de Eclipse ...................................................................................... 78
5.2.3. Instalación de Nuevo Software ................................................................... 79
5.3. Configuración de Eclipse .................................................................................... 81
5.3.1. Opciones del Compilador Cruzado ............................................................. 82
5.3.2. Opciones del Enlazador y Librerías ............................................................ 84
Proyecto Final de Carrera – José M León Coca
74
5.1. Introducción
Eclipse es una potente herramienta muy útil para cualquier desarrollo software. Se
trata de un entorno de desarrollo de código abierto multiplataforma. La propia
definición que da el proyecto Eclipse sobre su software es: "una especie de herramienta
universal - un IDE abierto y extensible para todo y nada en particular".
Esta plataforma, ha sido utilizada para desarrollar IDE (Integrated Development
Environment - entornos de desarrollo integrados) de varios proyectos software, como
ejemplos:
IDE de Java: Java Development Toolkit (JDT) y el compilador (ECJ) que se
entrega como parte de Eclipse (y que son usados también para desarrollar el
mismo Eclipse).
IDE de Android: Android Development Kit (ADK).
Eclipse posee una comunidad de usuarios muy activa, que ayudan a mejorar la
experiencia del producto extendiendo constantemente las áreas de aplicación cubiertas y
dando soporte por medio de sus foros, manuales y wiki.
5.1.1. Historia
Eclipse fue desarrollado originalmente por la OTI (Object Technology International)
dentro de IBM Canadá, como el sucesor de su familia de herramientas para VisualAge.
En noviembre de 2001, se formó la Fundación Eclipse, un consorcio independiente sin
ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de
productos complementarios, capacidades y servicios.
En cada una de las versiones de Eclipse, su comunidad se reunía para liberar y aunar
bajo un mismo nombre o versión sus distintos proyectos de software abierto. Un hito
destacable fue en 2003 cuando seleccionó las especificaciones de la plataforma OSGi
como la arquitectura de tiempo de ejecución.
En la siguiente tabla se pueden ver las distintas versiones de Eclipse que han visto la
luz hasta la fecha de redacción de este proyecto.
Capítulo 5: Eclipse, Entorno de Desarrollo
75
Versión Lanzamiento Versión Proyecto
Indigo 22 de junio de 2011 3.7 Indigo projects
Helios 23 junio de 2010 3.6 Helios projects
Galileo 24 de junio de 2009 3.5 Galileo projects
Ganymede 25 junio de 2008 3.4 Ganymede projects
Europa 29 de junio de 2007 3.3 Europa projects
Callisto 30 de junio de 2006 3.2 Callisto projects
Eclipse 3.1 28 de junio 2005 3.1
Eclipse 3.0 28 de junio de 2004 3.0
Tabla 9: Versiones de Eclipse
Este proyecto se realizó con la versión Eclipse Helios, la más actual disponible a la
fecha de ejecución.
5.1.2. Características
La base para Eclipse es su plataforma RCP (Rich Client Platform - Plataforma de
cliente enriquecido). Los componentes que constituyen dicha plataforma son:
Plataforma principal: inicio de Eclipse, ejecución de plugins.
OSGi: una plataforma para bundling estándar.
Standard Widget Toolkit (SWT): Conjunto de herramientas y aplicaciones
ligeras, portables y estándar.
JFace: manejo de archivos, manejo de texto, editores de texto.
El lugar de desarrollo de Eclipse: vistas, editores, perspectivas, asistentes.
El SWT usa widgets implementados como widgets de Java. A diferencia de la
mayoría de las aplicaciones Java que usan las opciones estándar Abstract Window
Toolkit (AWT). La interfaz de usuario de Eclipse también posee una capa GUI
intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basadas
para el SWT.
El IDE de Eclipse emplea plugin (módulos), para mostrar sus funcionalidades al
frente de la plataforma de cliente enriquecido. Difiere de otros entornos monolíticos en
Proyecto Final de Carrera – José M León Coca
76
los cuales las funcionalidades se encuentran incluidas en la misma interfaz, siendo
requeridas o no por el usuario. Este mecanismo de módulos permite generar una
plataforma ligera de componentes software, permitiendo a los desarrolladores formar
nuevas interfaces de trabajo de forma rápida y simple. Eclipse permite la extensión a
otros lenguajes de programación como son C/C++ y Python, haciéndolo trabajar incluso
con lenguajes de procesado de texto como LaTeX, aplicaciones en red como Telnet y
sistemas de gestión de base de datos.
En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks
muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de
modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing
Framework - Framework para la edición gráfica) es un plugin de Eclipse para el
desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta
editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. Dado que los
editores realizados con GEF "viven" dentro de Eclipse, además de poder ser usados
conjuntamente con otros plugins, hacen uso de su interfaz gráfica personalizable y
profesional.
El SDK de Eclipse incluye las herramientas de desarrollo Java, ofreciendo un IDE
con un compilador de Java interno y un modelo completo de los archivos fuente de
Java. Esto permite técnicas avanzadas de refactorización y análisis de código que
muestran en cada momento fallos de sintaxis en el código. Mediante plugins estas
herramientas han sido extendidas a otros lenguajes permitiendo que estén también
disponibles para C/C++, en la medida de lo posible, para lenguajes basados en script
como PHP o JavaScript…
Capítulo 5: Eclipse, Entorno de Desarrollo
77
5.2. Descarga e Instalación de Eclipse
En este apartado se comentará la forma de obtener eclipse y la instalación del
software adicional necesario para conseguir realizar la compilación cruzada, además de
una breve presentación de la interfaz presentada al usuario.
5.2.1. Obtención de Eclipse
La manera más fácil y segura de obtenerlo es descargándolo directamente de su sitio
web de forma totalmente gratuita:
http://www.eclipse.org
Tal y como se ha comentado anteriormente, existen varias versiones dependiendo del
tipo de proyecto a realizar, es por ello necesario elegir alguna de las particularizaciones
de desarrollo. Para este proyecto, ya que el leguaje de programación ha sido C, se ha
utilizado la versión CDT.
Figura 23: Logo Proyecto Eclipse CDT
Una vez descargado, no es necesaria su instalación en el sistema simplemente hay
que lanzarlo desde su icono de aplicación. Al funcionar bajo Java, es muy posible que
no funcione y lance un mensaje de error si no disponemos de la Máquina Virtual Java
(JVM), por ello que siguiente paso a realizar sea instalarla. Como dicta en su sitio web,
dependiendo de cada versión se nos exigirá una determinada JVM.
NOTA: DEPENDIENDO DE CÓMO SE HAYA REALIZADO LA INSTALACIÓN DE LA
JVM SERÁ NECESARIO O NO INCLUIR EL DIRECTORIO DE LOS BINARIOS DE JAVA
EN LA VARIABLE PATH DEL ENTORNO DEL SISTEMA.
Proyecto Final de Carrera – José M León Coca
78
5.2.2. Interfaz de Eclipse
El aspecto que muestra Eclipse para el desarrollo del proyecto, se distinguen las
siguientes áreas:
1
2 3
4
Figura 24: Área de Trabajo de Eclipse
1) Explorador de Proyectos: Cada trabajo que se realiza en Eclipse se organiza por
proyectos, en esta área se muestran los distintos archivos y librerías que
componen cada proyecto.
2) Editor de texto enriquecido: En esta área se pueden editar los archivos que
compongan el proyecto, añadiendo la funcionalidad de corregir posibles errores
de sintaxis que aparezcan en el mismo y autocompletando aquellas estructuras
predefinidas, muy útil en el uso de punteros y estructuras anidadas.
3) Variables del proyecto: Aquí se muestran en forma de variables las librerías y
estructuras utilizadas en el proyecto.
4) Consola: Aquí se muestran los resultados de compilación, warning y errores que
pudiera arrojar el proyecto. Además de los mensajes propios de Eclipse a la hora
de funcionar.
Capítulo 5: Eclipse, Entorno de Desarrollo
79
5.2.3. Instalación de Nuevo Software
El motivo de instalar software extra a la herramienta Eclipse, es para dotarlo de la
posibilidad de configurar herramientas de compilación cruzada. La forma de instalar
software para Eclipse puede realizarse de dos maneras:
Mediante la inclusión de plugins: copiando directamente los contenidos en la
carpeta de plugins de Eclipse.
Instalándolo desde los repositorios de software de Eclipse.
Las herramientas de compilación cruzada que se van a utilizar las provee Eclipse, es
por ello que la forma más fácil y directa de instalarlas es desde sus propios repositorios.
Para ello, situados en la interfaz de usuario de Eclipse, dirigirse por sus menús a:
Help Install New Software…
Ahora, se debe añadir el repositorio del CDT de la versión Helios, para ello pulsar
en:
[Add...]
Y rellenar los datos del repositorio:
Name: CDT
Location: http://download.eclipse.org/tools/cdt/releases/helios
Aceptar y esperar hasta que carguen todas las entradas del repositorio añadido,
buscar entre las herramientas disponibles:
C/C++ GCC Cross Compiler Support
Proyecto Final de Carrera – José M León Coca
80
Figura 25: Instalación de Nuevo Software en Eclipse
Continuar con la instalación pulsando siguiente y aceptando los mensajes que vayan
apareciendo, como aceptación de licencias... Tras instalar el software, Eclipse, suele
reiniciarse para cargar los cambios realizados en el mismo. Tras reiniciar la aplicación
es necesario configurarla de forma pertinente y enlazarla con las herramientas de
compilación cruzada que se requieran.
Capítulo 5: Eclipse, Entorno de Desarrollo
81
5.3. Configuración de Eclipse
Para iniciar la configuración de un proyecto de compilación cruzada y editar sus
opciones, el primer paso a realizar es la creación de un nuevo proyecto, en este caso un
proyecto de programación en C. Para ello pulsar:
File New… C Project
Aparecerá un menú emergente en el cual seleccionar que se creará un proyecto de
compilación cruzada:
Cross-Compile Project
Figura 26: Creación de un Proyecto de Compilación Cruzada
Pulsar la opción de finalizar, una vez introducido el nombre del nuevo proyecto, ya
que el resto de opciones de configuración que pide la creación del nuevo proyecto, no
Proyecto Final de Carrera – José M León Coca
82
permite configurar completamente todas las opciones de configuración. Para acceder al
menú de configuración del proyecto simplemente situar el cursor sobre él, pulsar el
botón derecho del ratón y seleccionar:
[Properties]
Aparecerá el menú de configuración del proyecto en el que modificar las distintas
opciones, comentadas a continuación en los apartados que siguen, todas ellas se
realizarán en la pestaña desplegable:
C/C++ Build
5.3.1. Opciones del Compilador Cruzado
La configuración se realizará según el orden que ocupen las distintas de las pestañas
de configuración. La primera a modificar será la pestaña:
Environment
Figura 27: Cambio de la Variable de Entorno
Capítulo 5: Eclipse, Entorno de Desarrollo
83
Como puede apreciarse en la Figura 27, es necesario modificar la variable de entorno
PATH, con este cambio lo que indicaremos al sistema es en qué directorio debe buscar
los archivos que necesite. Las distintas rutas de búsqueda se encuentran separadas entre
sí por medio de dos puntos “:”, para añadir la ruta del directorio de las herramientas de
compilación cruzada, pulsar sobre:
[Edit]
Y añadir la ruta completa del directorio donde se encuentran las herramientas de
compilación cruzada:
/home/USUARIO/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr
NOTA: SUSTITUIR USUARIO POR EL USUARIO DEL EQUIPO EN EL QUE SE
COMPILE.
La siguiente pestaña a situarse para configurar el resto de opciones será la de:
Settings
Aquí es donde se pueden configurar los parámetros del compilador y las opciones de
las librerías. El menú que se muestra, permite rellenar dos campos, hacerlo con:
Prefix: mips-openwrt-linux-uclibc-
Path: /home/USUARIO/openwrt/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-
0.9.30.1/usr/bin/
Lo que se ha configurado, es el prefijo necesario para la llamada al compilador
cruzado y la localización de los archivos binarios del compilador, enlazador…
Proyecto Final de Carrera – José M León Coca
84
Figura 28: Configuración de las Opciones de Compilación - Prefijo
5.3.2. Opciones del Enlazador y Librerías
Sin abandonar la pestaña del apartado anterior:
Settings
Situarse sobre:
Cross GCC Linker General
Y marcar la opción:
No shared libraries (-static)
Capítulo 5: Eclipse, Entorno de Desarrollo
85
Figura 29: Opciones de Configuración del Enlazador - Estático
Al marcar esta opción se deshabilita el enlazado de librerías de forma dinámico
establecido por defecto, esto repercutirá en que el ejecutable generado será más pesado
pero “contendrá” todas las librerías necesarias para su funcionamiento.
La última modificación a realizar será añadir, a la hora de enlazar, las librerías de
programación de varios hilos de ejecución, necesario por la herramienta realizada en
este proyecto. Para añadir estas librerías acceder al menú:
Cross GCC Linker Libraries
Y pulsa en:
Libraries (-l) Add..
Para escribir:
pthread
Proyecto Final de Carrera – José M León Coca
86
Figura 30: Opciones de Configuración del Enlazador – Librerías
Una vez realizados estos cambios ya es posible escribir un nuevo proyecto y
compilarlo para obtener ejecutables para la arquitectura MIPS32. Si se desea comprobar
la arquitectura de un ejecutable: puede verse gráficamente en Eclipse o puede ejecutarse
en una terminal el comando:
file nombre_ejecutable
El cual mostrará la información del mismo.
87
Capítulo 6
Herramienta de Monitorización del Enlace Inalámbrico en
Tiempo Real (WiLCA)
88
89
ÍNDICE
6.1. Introducción ........................................................................................................ 90
6.2. Herramientas Auxiliares ..................................................................................... 92
6.2.1. Wireless Tools for Linux ............................................................................ 92
6.2.2. Tcpdump ..................................................................................................... 93
6.2.3. Tcptrace ...................................................................................................... 94
6.3. WiLCA (Wireless Link Control Application) .................................................... 95
6.3.1. Esquema General ........................................................................................ 95
6.3.2. Estadísticas del Driver ................................................................................ 96
6.3.3. Estadísticas TCP ......................................................................................... 98
6.3.4. Estadísticas UDP ....................................................................................... 101
6.3.5. Funcionalidades ........................................................................................ 102
6.4. Programación de la Aplicación. ........................................................................ 103
6.3.1. Hilo principal ............................................................................................ 103
6.3.2. Hilo de Envío ............................................................................................ 104
6.3.3. Hilo Driver ................................................................................................ 104
6.3.4. Hilos TCP ................................................................................................. 105
6.3.5. Hilos UDP ................................................................................................. 106
6.5. Configuración Inicial de la Aplicación ............................................................. 107
6.5.1. XML .......................................................................................................... 107
6.5.2. Formato del Archivo de Configuración .................................................... 108
Proyecto Final de Carrera – José M León Coca
90
6.1. Introducción
La herramienta de monitorización del enlace inalámbrico en tiempo real es la
aplicación resultante de este proyecto final de carrera. El nombre propuesto para ella es
“WiLCA”, que proviene de las siglas de las palabras inglesas: Wireless Link Control
Application, Aplicación para el control del enlace inalámbrico.
Esta herramienta posee dos fuentes de datos bien diferenciadas, se basa en la
detección del tráfico inalámbrico y en la constante monitorización de los parámetros del
driver de la tarjeta inalámbrica. La primera fuente, la detección del tráfico, se centra en
la captura de paquetes UDP y TCP, de los cuales analiza sus campos y confeccionamos
estadísticas que nos indican la calidad del enlace inalámbrico.
Figura 31: Esquema de las Estadísticas de Captura de Tráfico
La segunda fuente, son los datos que nos facilita el propio driver de la tarjeta
inalámbrica. El conocimiento de estos datos procedentes de una entidad remota, por
ejemplo, los datos de potencia en recepción de la tarjeta permiten hacerse una idea de
cómo se encuentra el enlace inalámbrico.
Captura Paquetes UDP y TCP Análisis Herramientas
de Análisis Estadísticas Envío de Estadísticas
Lectura Consulta
Estadísticas Driver
Encapsulado Copia y
Encapsulado de los Datos
Estadísticas Envío de Estadísticas
Figura 32: Esquema de las Estadísticas de Datos del Driver
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
91
Antes de comenzar, se comentan algunos aspectos de la aplicación a tener en cuenta
para su futuro trabajo:
La herramienta asume que existe una conexión inalámbrica previamente
establecida.
La existencia entre las máquinas de una configuración temporal ajustada
mediante un servidor de tiempos NTP o, de lo contrario, habrá que tener en
cuenta las distintas escalas temporales de las entidades.
La configuración inicial mediante un archivo XML, solamente ha sido
esbozada, no realizada, siendo necesario realizar el "parseo" de variables
previo.
La herramienta ha sido diseñada para funcionar de forma autónoma, ya que si
no hay un tráfico existente entre las entidades, hay un módulo que puede
generarlo de forma automática.
A lo largo de este capítulo se explicará la forma de trabajo de la aplicación y cómo
ha sido realiza. Se comenzará explicando aquellas herramientas auxiliares utilizadas por
la herramienta para hacer su cometido. Tras esto, cómo ha sido realizada, primero se
esquematizará su funcionamiento por módulos y luego la forma en la que ha sido
programada. Finalmente, se explicará la forma esbozada de configuración inicial en
XML, indicando los parámetros más importantes con los cuales se dota de mayor
versatilidad a la aplicación.
Proyecto Final de Carrera – José M León Coca
92
6.2. Herramientas Auxiliares
El trabajo de investigación previo realizado para conseguir los objetivos del
proyecto, culmina en la decisión del uso de estas herramientas en las que se apoya
WiLCA para lograr su propósito. Estas herramientas son:
Wireless Tools for Linux: Son un conjunto de herramientas para manejar las
tarjetas inalámbricas en Linux.
Tcpdump: Herramienta para la captura de tráfico basada en las librerías libpcap.
Tcptrace: Herramienta para el análisis de capturas de paquetes TCP.
6.2.1. Wireless Tools for Linux
El desarrollo de la parte inalámbrica en Linux y las herramientas inalámbricas para
ello, son un proyecto Open Source patrocinado por Hewlett Packard desde 1996. El
proyecto ha sido construido también por muchos usuarios de Linux de todo el mundo.
La “Wireless Extension” (WE) es una API genérica que permite a un driver mostrar,
en el espacio de usuario, la configuración y las estadísticas específicas comunes de una
red de área local inalámbrica (WLAN, en adelante). Las bondades de esta API residen
en que un solo conjunto de herramientas pueden soportar todas las variaciones de una
WLANs, sin tener en cuenta sus tipos. Otra ventaja es que los parámetros de
configuración de la red pueden cambiar sin tener que reiniciar el propio driver de la
tarjeta inalámbrica.
Las “Wireless Tools” (WT) son un conjunto de herramientas que permiten manipular
las extensiones inalámbricas. Estas usan una interfaz textual con la cual ayuda a
soportal el total de las WE. Algunas de estas WT son:
iwconfig: manipula los parámetros inalámbricos básicos.
iwlist: permite escanear y listar las distintas redes, frecuencias…
iwspy: permite obtener la calidad del enlace por nodo.
iwspriv: permite manipular WE específicas para un driver.
ifrename: permite nombrar las interfaces que cumplan algunos criterios de
estado.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
93
La mayoría de distribuciones de Linux traen integradas el soporte de las WE en sus
script de inicialización de red, para una configuración de arranque más fácil de las
interfaces inalámbricas. También incluyen las WT como paquetes estándar.
6.2.2. Tcpdump
Tcpdump permite analizar el tráfico que existe en una red. Es una herramienta cuya
interfaz es mediante línea de comandos. El usuario es capaz de capturar y visualizar en
tiempo real los paquetes transmitidos y recibidos en la red dónde el dispositivo esté
conectado. La herramienta funciona en la mayoría de los sistemas operativos UNIX:
Solaris, Linux, BSD, Mac OS X… para su funcionamiento, hace uso de la biblioteca
libpcap.
Tcpdump fue creado por Van Jacobson, Craig Leres y Steven McCanne en el Grupo
de Investigación de Red del Laboratorio Lawrence Berkeley, y mejorada por Andrew
Tridgell.
Debido a su modo de funcionamiento, Tcpdump debe poner la interfaz de red en
modo “promiscuo”, es decir, escucha todos los paquetes aunque no sean para la propia
máquina. Esta funcionalidad no está permitida por todos los dispositivos de red
existentes, ya que el driver que controla la tarjeta no lo permite. Un claro ejemplo de
esta situación sucede en los entornos con el sistema operativo Windows, ya que por su
política DRM (Digital Rights Management - Gestión de los Derechos Digitales) este
tipo de acciones no están permitidas.
Figura 33: Logotipo Tcpdump
Proyecto Final de Carrera – José M León Coca
94
6.2.3. Tcptrace
Tcptrace es una herramienta escrita por Shawn Ostermann en la Universidad de
Ohio. Es una aplicación que sirve para analizar los datos generados por paquetes TCP.
Tcptrace puede acoger como entrada los archivos producidos por los más conocidos
programas de captura de paquetes ( Tcpdump, Snoop, Etherpeek, HP Net Metrix).
Tcptrace puede producir muy diferentes formas de salida, las cuales contienen
información de cada conexión existente, como el tiempo transcurrido, bytes y
segmentos enviados y recibidos, retransmisiones, RTT (Round Trip Time - Tiempo de
Ida y Vuelta), datos de las ventanas de congestión, throughput (retardo) y más.
Figura 34: Logotipo Tcptrace
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
95
6.3. WiLCA (Wireless Link Control Application)
Como se comentó anteriormente, WiLCA, está formado de las siglas de las palabras
anglosajonas Wireless Link Control Application (Aplicación de Control del Enlace
Inalámbrico), que tratan de describir la funcionalidad de la herramienta.
La herramienta comenzó a desarrollarse al buscar una forma de monitorización de
los paquetes que llegan a una entidad remota, a la cual no se tiene acceso físico y es
imposible situarle una entidad externa situada junto a la misma que esnife el tráfico
generado. Una captura remota de paquetes de la cual se pudiera extraer información
para conocer la integridad del enlace. Bajo esa idea se confeccionó WiLCA.
A lo largo de la descripción de este capítulo y el siguiente cuando se haga referencia
a “estadísticas”, querrá decirse datos del enlace o resultados de los análisis realizados.
6.3.1. Esquema General
La herramienta se puede analizar desde el punto de vista del cliente y el servidor, los
cuales intercambian sus papeles dependiendo de la fase de la ejecución del programa.
SERVIDORCLIENTE
Estadísticas
TCP
Envía EstadísticasRecibe Estadísticas
Tráfico
Generado
Existente
Estadísticas
Driver
Estadísticas
UDP
Figura 35: Esquema General WiLCA
El cliente requiere conocer las estadísticas del enlace inalámbrico desde el punto de
vista de la entidad remota, la cual actúa de servidor, ya que es la que proporciona los
datos que el cliente necesita. Ambas entidades conocen la forma de comunicarse entre
ellas ya que la conexión ha sido previamente configurada, al igual que algunos aspectos
Proyecto Final de Carrera – José M León Coca
96
propios a nivel de la propia aplicación. Estos datos y la forma en que se configuran se
presentan más adelante en el apartado 0.
Tal y como se muestra en la ¡Error! No se encuentra el origen de la referencia. en
l servidor se generan tres flujos de información: las estadísticas del trafico TCP, las
estadísticas del tráfico UDP y las estadísticas del driver.
6.3.2. Estadísticas del Driver
En el proyecto se han denominado estadísticas del driver a los datos que nos
proporciona nuestra propia máquina sobre la información del enlace inalámbrico. Estos
datos se consiguen gracias a las Wireless-Tools for Linux que de forma automática y
periódica generan un log de parámetros al que podemos acceder. Este log se encuentra
en la ruta:
/proc/net/wireless
La forma de generar por tanto estas estadísticas es sencilla, simplemente se lee el log
y se escriben de una forma ordenada siguiendo un formato CSV, se realiza una
conexión UDP con la entidad par y se transmiten dichas estadísticas. En la siguiente
figura se ilustra este proceso.
SERVIDORCLIENTE
Lee Datos del Driver
Envía EstadísticasRecibe Estadísticas
SOCKET UDP RX
Esta
dís
tica
s
SOCKET UDP TX
Figura 36: Estadísticas del Driver
Los datos que se obtienen del log se presentan en el archivo de la siguiente manera:
Inter-|sta| Quality | Discarded packets
face |tus|link level noise| nwid crypt misc
ath0: f0 15. 24. 4. 181 0 0
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
97
Si existiera otra interfaz inalámbrica se generaría una nueva línea tras esta y así de
forma sucesiva con tantas interfaces como se dispongan.
Los datos obtenidos para cada interfaz nos proporcionan la siguiente información:
Status: es el estado actual en el que se encuentra la interfaz inalámbrica.
Quality - link: Calidad general en recepción.
Quality - level: Potencia de la señal en recepción.
Quality - noise: Potencia cuando hay ausencia de paquetes, Ruido.
Discarded - nwid: Número de paquetes descartados por tener una identificación
de red no válida.
Discarded - crypt: Número de paquetes descartados por no ser capaz de
desencriptarlos.
Discarded - misc: Parámetro sin uso actualmente.
Gracias a estos datos se puede conocer cómo se encuentra el enlace y permite que el
usuario se haga una idea de qué problema existe. Los datos más importantes a
considerar son los datos de calidad (Quality): de calidad de enlace (link) y potencia
(level).
La salida del proceso generará la siguiente línea que será transmitida:
#D1,D2,D3,D4,D5,D6,D7,D8
A continuación, se indica el significado de cada uno de los valores transmitidos:
#: Bandera que indica que la línea recibida son estadísticas del driver.
D1: Marca de tiempo del instante en que se envió el paquete.
Los siguientes son datos propios del driver:
D2: Status.
D3: Quality – link.
D4: Quality – level.
D5: Quality – noise.
D6: Discarded – nwid.
D7: Discarded – crypt.
D8: Discarded – misc.
Proyecto Final de Carrera – José M León Coca
98
6.3.3. Estadísticas TCP
Las estadísticas TCP se obtienen al analizar un conjunto de paquetes TCP capturados
en el dispositivo. Para conseguir capturar paquetes TCP es necesario que exista un flujo
de tráfico de dichos paquetes, de lo contrario será habrá que generarlo. Tal y como se
muestra en el siguiente esquema, el tráfico puede ser existente o generado; se captura,
analiza y se envían las estadísticas resultantes.
SERVIDORCLIENTE
Captura Paquetes TCP
Envía EstadísticasRecibe EstadísticasSOCKET UDP TXSOCKET UDP RX
Trafico TCP
Generado
Existente
SOCKET TCP TX SOCKET TCP RX
Análisis Paquetes TCP
Estadísticas
Figura 37: Estadísticas TCP
La captura de paquetes se hace gracias a la aplicación Tcpdump, en la cual pueden
configurarse multitud de opciones para afinar la captura y observar el tráfico que sea
interesante o existente. Una de las variables a configurar, será el número de paquetes a
capturar, permitiendo mejor reacción cuando menor sea el número de paquetes y más
información cuando sea mayor. La salida de Tcpdump es un archivo específico con
extensión *.pcap, el cual contiene toda la información de la captura y será la entrada a la
siguiente herramienta: Tcptrace.
Tcptrace analizará el archivo pcap y será capaz de extraer las estadísticas. El
resultado de las estadísticas se guardará en un archivo de texto, del cual se extraerán
aquellas estadísticas que se han considerado relevantes para esta versión del programa,
pudiéndose elegir de entre todas las que ofrece Tcptrace. A continuación se muestra
como ejemplo una salida tipo de Tcptrace, la cual sólo ha de tenerse en cuenta el tipo de
datos que ofrece, no los valores, ya que éstos no son reales.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
99
1 arg remaining, starting with 'captura.pcap'
Ostermann's tcptrace -- version 6.4.6 -- Tue Jul 1, 2003
20 packets seen, 20 TCP packets traced
elapsed wallclock time: 0:00:00.037948, 50 pkts/sec analyzed
trace file elapsed time: 0:00:00.404427
TCP connection info:
1 TCP connection traced:
TCP connection 1:
host a: 192.168.7.2:2326
host b: 192.168.3.202:2327
complete conn: yes
first packet: Thu Oct 28 13:10:05.914101 2010
last packet: Thu Oct 28 13:11:09.318528 2010
elapsed time: 0:00:00.404427
total packets: 20
filename: captura.pcap
a->b: b->a:
total packets: 20 total packets: 20
ack pkts sent: 15 ack pkts sent: 16
pure acks sent: 13 pure acks sent: 2
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 450 unique bytes sent: 18182
actual data pkts: 1 actual data pkts: 13
actual data bytes: 450 actual data bytes: 18182
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 1 pushed data pkts: 1
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1
req 1323 ws/ts: Y/Y req 1323 ws/ts: Y/Y
adv wind scale: 0 adv wind scale: 0
req sack: Y req sack: N
sacks sent: 0 sacks sent: 0
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 1460 bytes mss requested: 1460 bytes
max segm size: 450 bytes max segm size: 1448 bytes
min segm size: 450 bytes min segm size: 806 bytes
avg segm size: 449 bytes avg segm size: 1398 bytes
max win adv: 40544 bytes max win adv: 33304 bytes
min win adv: 5840 bytes min win adv: 33304 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 23174 bytes avg win adv: 33304 bytes
initial window: 450 bytes initial window: 1448 bytes
Proyecto Final de Carrera – José M León Coca
100
initial window: 1 pkts initial window: 1 pkts
ttl stream length: 450 bytes ttl stream length: 18182 bytes
missed data: 0 bytes missed data: 0 bytes
truncated data: 420 bytes truncated data: 17792 bytes
truncated packets: 1 pkts truncated packets: 13 pkts
data xmit time: 0.000 secs data xmit time: 0.149 secs
idletime max: 103.7 ms idletime max: 99.9 ms
throughput: 1113 Bps throughput: 44957 Bps
Las estadísticas extraídas, generan una línea al igual que en el caso anterior:
?D1,D2,D3,D4,D5,D6,D7,D8
Los datos de la línea, según su posición significan:
?: Bandera identificativa que muestra que la línea recibida es una estadística
TCP.
D1: Marca de tiempo.
D2: Numero de secuencia.
D3: Máximo de la ventana de congestión.
D4: Mínimo de la ventana de congestión.
D5: Media de la ventana de congestión.
D6: Máximo retardo de ida y vuelta (RTTmax).
D7: Mínimo retardo de ida y vuelta (RTTmin).
D8: Media del retardo de ida y vuelta (RTTav).
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
101
6.3.4. Estadísticas UDP
Las estadísticas UDP se colectan de forma semejantes a las TCP, pero de éstas solo
es posible obtener el retardo de transmisión de los paquetes. La forma de conseguir las
estadísticas se muestra en el siguiente esquema:
SERVIDORCLIENTE
Recepción Paquetes UDP
Envía EstadísticasRecibe EstadísticasSOCKET UDP TXSOCKET UDP RX
Trafico UDP
Generado
Existente
SOCKET UDP TX SOCKET UDP RX
Análisis Paquetes UDP
Estadísticas
Figura 38: Estadísticas UDP
El envío de paquetes UDP desde la parte del cliente incluye una marca de tiempo al
ser enviado, la cual, al recibirse en el servidor se analiza y compara con el tiempo en el
que el paquete fue recibido; obteniéndose el retardo de transmisión.
La línea generada que se envía como resultado del proceso, es la siguiente:
@D1,D2
El significado de los símbolos a transmitir es:
@: Bandera identificativa que muestra que la línea recibida es una estadística
UDP.
D1: Marca de tiempo del momento del envío de las estadísticas.
D2: Retardo (throughput).
NOTA: GRACIAS A LAS MARCAS DE TIEMPO ENVIADAS EN CADA PAQUETE ES
POSIBLE AÑADIR ESTE DATO COMO UN CAMPO MÁS EN LAS ESTADÍSTICAS DEL
DRIVER.
Proyecto Final de Carrera – José M León Coca
102
6.3.5. Funcionalidades
En el proceso de desarrollo de la aplicación, se han tenido en cuenta algunas
características o funcionalidades que pueden darle un valor añadido a la aplicación.
IP dinámica de la entidad: Esto nos permite que la aplicación sea versátil y no
sea necesario ligarla “por compilación” a una máquina o dirección de red.
Puertos configurables: Permite configurar los puertos UDP/TCP de transmisión
y recepción.
Generación de tráfico: En el caso en que se deseen obtener las estadísticas
UDP/TCP y se carezca del tráfico que las genere, se puede generar de forma
autónoma el tráfico UDP/TCP necesario.
Número de paquetes TCP capturados: El número de paquetes que se capturan en
cada análisis es configurable para la obtención de las estadísticas TCP. El valor
se puede variar, dando mayor rapidez, en general, a la aplicación si se disminuye
el valor, perdiendo, en contraposición, unas estadísticas más precisas.
Generación de log: Crea en la propia entidad un documento en el que se escriben
las líneas que se irían enviando a la otra entidad. Útil para generar unos
resultados a estudiar en situaciones de mala cobertura; tiene como
contraprestación que un largo tiempo de monitorización necesitará mucho
espacio en disco, es por ello que se recomienda escribir los logs en una unidad
de almacenamiento masivo USB.
Estas opciones se configuran modificando los valores de ciertas variables en un
documento XML creado para ello, el cual se explica más adelante en este capítulo.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
103
6.4. Programación de la Aplicación.
La programación de la herramienta, se basa en el manejo de sockets y el uso de las
aplicaciones comentadas en el apartado 0. Todo esto realizado con diferentes hilos de
programación, que permiten, por ejemplo, el envío de unos datos por un socket mientras
se escucha si hay datos por otro. A continuación se presenta una figura en la que puede
verse el esquema general de los hilos.
Hilo Principal
Hilo Envío Hilo Driver Hilos TCP Hilos UDP
Hilo TCP
Transmisión
Hilo TCP Captura
y Análisis
Hilo UDP
Transmisión
Hilo UDP
Recepción y
Análisis
Figura 39: Esquema General Hilos WiLCA
El número de hilos generados por la aplicación serán, en total y como máximo, siete
hilos, cuando sean habilitadas todas las opciones de la herramienta.
En los apartados siguientes se dará una breve reseña de cuál es la tarea de cada hilo y
unas pinceladas de su implementación.
6.4.1. Hilo principal
Este hilo es el principal del proyecto, su función central es ser el encargado de
generar los otros hilos y temporizar algunos de ellos, además de la gestión de errores.
Este hilo comienza configurando la aplicación según los valores introducidos en el
archivo de inicio, abriendo los sockets necesarios para que funcione la aplicación. Tras
esto, dependiendo de lo indicado en archivo XML de inicio, se crearán, o no, todos los
Proyecto Final de Carrera – José M León Coca
104
hilos anteriormente citados. Su siguiente función, es la de controlar los semáforos de los
distintos hilos para así configurar su temporización.
Mientras realiza todas las tareas citadas, efectúa un control de errores en el caso de
que una acción imprevista haga que la aplicación falle.
6.4.2. Hilo de Envío
Es un hilo independiente, no atiende a ninguna señal de temporización, sólo en caso
de error interrumpe su tarea. Este hilo, gestiona una cola FIFO implementada con una
lista enlazada. Su tarea será la de enviar por un socket UDP, las estadísticas que se
encuentren en la cola que gestiona. La lectura o escritura en esta cola se realiza por
exclusión mutua (mutex), ya que todos los hilos que generen estadísticas pueden enlazar
un nuevo elemento cuando lo tengan disponible y siempre que existan datos, el hilo de
envío, los enviará a la entidad con la que se encuentre apareado.
Otra funcionalidad a destacar, es la escritura en un fichero de texto de las líneas de
las estadísticas a enviar, se generan unos “logs”, si la variable que controla esta
funcionalidad está activa.
6.4.3. Hilo Driver
Este hilo es el encargado de generar las estadísticas del driver. Es un hilo que
realizará su tarea cada vez que el hilo principal se lo permita, dominado por la
temporización que él disponga por semáforos. Su tarea se basa principalmente en leer el
archivo:
/proc/net/wireless
Y extraer las estadísticas para enlazarlas en la cola FIFO del hilo de envío.
NOTA: LA TEMPORIZACIÓN IMPUESTA POR EL HILO PRINCIPAL AL HILO DRIVER
HA DE SER SIEMPRE MAYOR QUE LA DURACIÓN DE LA TAREA DEL HILO DRIVER, ES
POR ELLO UN PARÁMETRO AJUSTABLE DEPENDIENDO DE LA PLATAFORMA. EN
ESTE PROYECTO HA SIDO AJUSTADA PARA QUE ASÍ SEA EN LAS RB433UAH.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
105
6.4.4. Hilos TCP
En este apartado se tienen en cuenta los hilos que tienen que ver con las estadísticas
TCP: Un hilo que envía paquetes TCP y un hilo que los “recibe”.
Hilo TCP Transmisión:
Este hilo es el encargado de enviar paquetes TCP a la unidad con la que se encuentre
emparejado. Es un hilo opcional, ya que se crea si se activa la variable de generación de
tráfico TCP. Al igual que el hilo driver, se encuentra temporizado por el hilo principal
mediante semáforos.
NOTA: EL NÚMERO DE PAQUETES TCP A ENVIAR DEBE SER MAYOR O IGUAL AL
NÚMERO DE PAQUETES INDICADO EN LA CAPTURA DEL TRÁFICO TCP. RESPECTO A
LA TEMPORIZACIÓN, AL IGUAL QUE EN EL HILO DRIVER, HAY QUE TENER EN
CUENTA QUE NO SOLAPE LA HABILITACIÓN DEL SEMÁFORO CON LA TAREA
REALIZADA POR EL HILO.
Hilo TCP Captura y Análisis:
Las tareas de este hilo son: lanzar las aplicaciones tcpdump y tcptrace, analizar el
resultado y generar las estadísticas, para luego, enlazarlas en el hilo de envío. La
temporización no depende del hilo principal, el tiempo de cada ciclo del hilo depende
del número de paquetes que tenga que capturar. Existe un tiempo máximo de captura, el
cual es configurable; si en un tiempo dado no se han capturado todos los paquetes
indicados, cesa la captura y se pasa a su análisis.
Proyecto Final de Carrera – José M León Coca
106
6.4.5. Hilos UDP
Al igual que los hilos TCP, los dos hilos a comentar a continuación son los
encargados de las estadísticas UDP. Hay que comentar algunas peculiaridades a la hora
de la transmisión de paquetes UDP, ya que al enviarse las estadísticas de la unidad a
monitorizar, con una marca de tiempo como dato, esta marca se usa para calcular el
retardo de transmisión, es decir, no es necesario el envío de paquetes UDP “extra” para
conseguir el valor del retardo. Pero en el sentido contrario, sí que será necesario el envío
de los paquetes UDP.
Hilo UDP Transmisión:
Este hilo enviará paquetes UDP los cuales contienen una marca de tiempo escrita en
su interior en el momento de ser enviados. Su temporización viene determinada por el
hilo principal.
Hilo UDP Recepción y Análisis:
Es un hilo que se encarga de la recepción de los paquetes UDP en general y
dependiendo de en qué entidad se implemente, tendrá unas tareas u otras, las cuales se
explicarán con mayor profundidad en el siguiente capítulo. Por ejemplo, en aquella
entidad a monitorizar, su tarea será recibir los paquetes UDP y comparar la marca de
tiempo del paquete recibido, con el instante de tiempo de su llegada y enlazar los
resultados en la cola del hilo de envío. No tiene dependencia temporal, sólo en el caso
de error.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
107
6.5. Configuración Inicial de la Aplicación
La configuración de inicio de la aplicación es lo primero que carga la herramienta
para comenzar a trabajar. Está escrita en lenguaje XML, tal como se ha comentado
anteriormente, para facilitar su portabilidad y configuración. En este apartado se darán
unas breves reseñas del lenguaje XML y tras este se explicará el archivo de
configuración inicial de la aplicación.
6.5.1. XML
El lenguaje XML es un lenguaje de marcas que se ha elaborado para la definición de
estructuras de documentos y el almacenamiento de datos. Sus siglas en ingles provienen
de eXtensible Markup Language (Lenguaje de marcado extensible) es considerado un
estándar abierto y fue desarrollado por el grupo W3C (World Wide Web Consortium).
Se considera que XML puede describir los documentos de forma simple con el uso
de etiquetas, pero además también se puede utilizar para crear nuestro propio lenguaje
de marcado, es por ello que se le denomina como lenguaje de meta-marcado.
A continuación se muestran, las reglas básicas para la creación de un fichero XML.
El elemento raíz debe de ser único.
Todos los elementos con contenido deben de tener etiquetas de cierre y con el
mismo nombre que la etiqueta inicial.
Las etiquetas de distintos elementos no se pueden solapar o superponer.
Cerrar en orden correcto las etiquetas de elementos anidados.
Los atributos de los elementos deben ir entre comillas.
Un elemento no tiene dos atributos con el mismo nombre.
No se pueden utilizar los caracteres <, >, & en el contenido de un elemento.
Los comentarios y las IP no aparecen en ninguna etiqueta.
Todos los caracteres que aparecen en el documente deben de ceñirse a la
codificación especificada en el atributo “encoding” del encabezado.
Proyecto Final de Carrera – José M León Coca
108
6.5.2. Formato del Archivo de Configuración
El archivo de configuración inicial, se analiza cada vez que se lanza la aplicación y
determina algunas variables cruciales para el funcionamiento de la aplicación. Es un
archivo escrito en XML con nombre iniVal.xml el cual debe encontrarse en el mismo
directorio donde se ejecute la aplicación.
A continuación se muestra un ejemplo de este documento:
##################################################################################
### Ejemplo de Documento ./iniVal.xml ###
### José M. León Coca ###
##################################################################################
<?xml version="1.0" encoding="UTF-8"?>
<sections>
<comment> Configuración General Unidad Remota </comment>
<section name="configIni">
<item key="ip_dest" value="192.168.3.202" />
<item key="ip_orig" value="192.168.7.2" />
<item key="logs" value="0" />
<item key="puertoPP" value="2323" />
<item key="generaUDP" value="1" />
<item key="generaTCP" value="1" />
</section>
<section name="genUDP">
<comment> Configuración de los parámetros de la generación UDP </comment>
<item key="puertoUDP_Rx" value="2325" />
<item key="puertoUDP_Tx" value="2324" />
</section>
<section name="genTCP">
<comment> Configuración de los parámetros de la generación TCP </comment>
<item key="puertoTCP_Rx" value="2326" />
<item key="puertoTCP_Tx" value="2327" />
<item key="paqTCP" value="20" />
</section>
</sections>
Este archivo proviene de la configuración de la aplicación para una estación base que
monitoriza a una entidad remota y posee una estación de control desde la cual se
observan los resultados de la monitorización. En el siguiente capítulo se explicará mejor
esta arquitectura.
Capítulo 6: Herramienta de Monitorización del Enlace Inalámbrico en Tiempo Real (WiLCA)
109
Los valores introducidos en el archivo de configuración inicial se dividen en tres
secciones:
Sección 1: Configuración inicial.
ip_dest: Dirección IP del destino de las estadísticas del enlace.
ip_orig: Dirección IP de la propia entidad.
logs: Variable binaria de habilitación de logs. Variable activa a nivel alto.
puerto_PP: Puerto UDP principal por el que se enviarán las estadísticas.
genera_UDP: Variable binaria que habilita la generación de tráfico UDP.
Variable activa a nivel alto.
genera_TCP: Variable binaria que habilita la generación de tráfico TCP. Variable
activa a nivel alto.
Sección 2: Configuración de la generación de paquetes UDP.
puertoUDP_Rx: Puerto UDP para la recepción de los paquetes.
puertoUDP_Tx: Puerto UDP para la transmisión de los paquetes.
Sección 3: Configuración de la generación de paquetes TCP.
puertoTCP_Rx: Puerto TCP para la recepción de los paquetes.
puertoTCP_Tx: Puerto TCP para la transmisión de los paquetes.
paqTCP: Número de paquetes TCP a capturar en cada análisis de las estadísticas
TCP.
110
111
Capítulo 7
Aplicación en un Sistema Real: Estación de Control, Estación
Base y Unidad a Monitorizar
112
113
ÍNDICE
7.1. Introducción ...................................................................................................... 114
7.1.1. UAV .......................................................................................................... 114
7.1.2. Estación Base ............................................................................................ 115
7.1.3. Estación de Control ................................................................................... 115
7.2. Sistema de Monitorización ............................................................................... 117
7.2.1. Análisis y Control del Enlace Inalámbrico ............................................... 118
Proyecto Final de Carrera – José M León Coca
114
7.1. Introducción
En este capítulo se describe la utilización de la aplicación desarrollada en un sistema
real propuesto. Este sistema consta de una estación de control, una estación base y una
unidad a monitorizar.
ESTACIÓN DE CONTROL ESTACIÓN BASE UNIDAD A MONITORIZAR
Figura 40: Flujo de Datos de Monitorización
Este sistema comenzó a generarse cuando se realizaron las primeras pruebas de la
aplicación. En un primer paso se realizaron pruebas simples que constaban de dos
entidades que se transmitían información. Acto seguido se propuso incluir una tercera
entidad desde la cual fura posible analizar todos los datos generados en la
monitorización del enlace. Es así como terminó definiéndose el sistema real que se
analiza en este capítulo.
La unidad a monitorizar objetivo del proyecto fue un UAV, base del desarrollo en
varios proyectos de FADA-CATEC.
7.1.1. UAV
El termino UAV responde a las siglas en inglés de Unmanned Aerial Vehicle,
vehículo aéreo no tripulado. El concepto de “no tripulado” puede dar lugar a confusión
e incluirse a otros dispositivos sin tripulación, ya que es cierto que en el interior del
vehículo no va ningún tripulante, pero existe contacto entre el UAV y la unidad en tierra
que lo controla. Estando ligado a una estación terrenal, ya sean pilotos, controladores o
cualquier otro tipo de operario relacionado con la monitorización de la aeronave.
Gracias a esta matización no todo lo que está en el aire se considera un UAV ya que los
globos aerostáticos o los misiles no son considerados como tales.
El inicio de la utilización de este tipo de vehículos tuvo fines militares, pues con
ellos se puede tanto vigilar o atacar una zona en conflicto, sin poner en peligro vidas
humanas. En los últimos años se ha avanzado en este campo, y hay gran variedad de
Capítulo 7: Aplicación en un Sistema Real: Estación de Control, Estación Base y Unidad a Monitorizar
115
tamaños de estos vehículos, desde varios metros de envergadura hasta unos pocos
centímetros.
Figura 41: Representación del telecontrol del UAV
7.1.2. Estación Base
En comunicaciones basadas en radiofrecuencias, una estación base es una instalación
fija de radiofrecuencias para la comunicación bidireccional. Se usa para comunicar con
una o más estaciones, fijas o portátiles. Las estaciones base normalmente se usan para
conectar radios bidireccionales de baja potencia, como por ejemplo la de un teléfono
móvil, un teléfono inalámbrico o un ordenador portátil con una tarjeta de conexión
inalámbrica. La estación base sirve como punto de acceso a una red de comunicación
fija (como la Internet o la red telefónica) o para que dos terminales se comuniquen entre
sí fluyendo la comunicación por la estación base.
En este proyecto la mejor acepción que define al proyecto es la definición dada para
las redes locales inalámbricas (WiFi o WiMAX), en la que una estación base es un
transmisor/receptor de radio que sirve como nexo de la red de área local inalámbrica.
También puede servir como pasarela entre las redes inalámbrica y fija.
7.1.3. Estación de Control
Bajo el nombre genérico de “estación de control” se quiere hacer referencia a una
central SCADA (Supervisory Control And Data Acquisiton – Control, Supervisión y
Adquisición de Datos): Es un sistema computacional que permite supervisar y controlar
variables de proceso a distancia, proporcionando comunicación con los dispositivos de
campo (controladores autónomos) y controlando el proceso de forma automática por
medio de un software especializado. Es capaz de mostrar la información de los
dispositivos que controla y difundir esta información con sus asociados.
Proyecto Final de Carrera – José M León Coca
116
En el proyecto, la aplicación generada para la estación de control será capaz de
recopilar los datos de las unidades remotas y mostrarlos para su posterior tratamiento.
BS1
BS2
BS3
SCADA
Nodos Remotos
Figura 42: Esquema de Central de Adquisición de Datos
Capítulo 7: Aplicación en un Sistema Real: Estación de Control, Estación Base y Unidad a Monitorizar
117
7.2. Sistema de Monitorización
La arquitectura del sistema de monitorización propuesto está formada por los
siguientes dispositivos:
ESTACIÓN CONTROL ESTACION BASE UNIDAD A MONITORIZAR
Figura 43: Esquema General del Sistema de Monitorización
Estación de Control: Ordenador portátil de campo.
Estación Base: Mikrotik RouterBoard 433 UAH.
Unidad a Monitorizar: Mikrotik RouterBoard 433 UAH embarcada en un UAV.
Este sería el esquema de la arquitectura propuesta para la utilización de la
herramienta. La creación de distintas aplicaciones muy parecidas entre sí, en lo que a
módulos de código se refiere, es necesaria según en qué entidad han de ejecutarse. Ya
que las tareas a realizarse en cada entidad son distintas. En la ¡Error! No se encuentra
l origen de la referencia. se muestra una visión general esquematizada de las distintas
tareas que se realizan en cada entidad y del flujo de los datos recibidos y enviados por
cada una.
En los siguientes apartados y teniendo como referencia la figura anteriormente
mencionada, se explicarán las tareas a realizarse en cada una de las entidades y cómo
han sido diseñadas cada una de ellas.
Proyecto Final de Carrera – José M León Coca
118
7.2.1. Análisis y Control del Enlace Inalámbrico
El enlace inalámbrico el cual se desea estudiar y monitorizar es el formado por la
estación base y la unidad remota. La unidad remota, es la entidad a monitorizar ya que
la estación base se considera fija. En la arquitectura propuesta, se encuentra
denominado como UAV, por ser en éste en el que va embarcado, de aquí en adelante y
por no perder generalidad se le denominará unidad a monitorizar o unidad remota.
Para realizar el análisis del enlace inalámbrico el estudio se realiza del enlace
ascendente y descendente, para ello se hace uso de la aplicación realizada, la cual
implementa los servicios necesarios para el correcto análisis.
Envío de Paquetes
Recepción y
Generación de
Estadísticas
UAVEstación Base
Enlace Ascendente
Envío de Paquetes
Recepción y
Generación de
Estadísticas
Enlace Descendente
Figura 44: Análisis de los Enlaces Descendente y Ascendente
Los servicios que se implementan, son los siguientes:
Envío de Paquetes: El tráfico, tanto TCP como UDP, es necesario para que se
realice el análisis de paquetes por la aplicación. Este servicio se pondrá en
ejecución cuando no exista tráfico en la red y sea necesario generarlo.
Recepción y Generación de Estadísticas: Establece los medios necesarios para la
recepción de los paquetes TCP y UDP, su captura, el posterior análisis y la
generación de las estadísticas.
Capítulo 7: Aplicación en un Sistema Real: Estación de Control, Estación Base y Unidad a Monitorizar
119
En la Figura 44 puede verse esquematizado el flujo de las estadísticas que se
obtienen en la captura del tráfico de la red. Una vez generadas estas estadísticas, serán
enviadas de la unidad que se monitoriza a la estación base para su posterior análisis o
reenvío.
Las aplicaciones realizadas para cada una de las entidades pueden verse en la
siguiente figura:
UNIDAD A MONITORIZAR
CLIENTE
ESTACIÓN BASE
SERVIDOR
Estadísticas
TCP
Envía Estadísticas
Estadísticas
Driver
Estadísticas
UDP
Tráfico
Generado
Existente
SERVIDOR CLIENTE
Estadísticas
TCP
Estadísticas del Enlace Recibe Estadísticas
Tráfico
Generado
Existente
Estadísticas
Driver
Estadísticas
UDP
Figura 45: Esquema Estación Base y Unidad a Monitorizar (Enlace Inalámbrico)
En ambas aplicaciones el modelo cliente/servidor se hace visible. Como se comentó
en el capítulo anterior, este modelo hace referencia a la “solicitud” o “entrega” de los
datos que se requieren de cada entidad. En la estación base, cabe comentar que los datos
que se generan en la parte servidor, serán enviados a la entidad de control. Al estar
reflejado en la figura anterior, cabe mencionar este detalle, que podrá verse en la figura
que representa la funcionalidad de las aplicaciones en el enlace de control.
En esta versión de la aplicación, el enlace de control es simplemente un mero
sumidero de datos. Los datos simplemente se reciben y se muestran al usuario.
Proyecto Final de Carrera – José M León Coca
120
ESTACIÓN BASEESTACIÓN DE CONTROL
CLIENTE
Recibe Estadísticas
SERVIDOR
Envía Estadísticas
Analiza los Datos
Presentación al Usuario
Figura 46: Esquema Estación de Control y Estación Base, Enlace de Control
A continuación se comentará más en profundidad los detalles de cada una de las
aplicaciones generadas.
7.2.1.1. Unidad a Monitorizar
La aplicación generada para esta entidad implementa los servicios para recibir y
transmitir paquetes TCP y UDP, por ello se crean los sockets y se reservan dos puertos
para TCP y tres para UDP. Estos sockets se utilizan en su mayoría para la generación de
tráfico, por cada tipo de paquetes, dos sockets, para poder recibir y transmitir paquetes.
Cuando el tráfico es generado, lo que se recibe y se envía son paquetes prácticamente
vacíos, sólo contienen una marca de tiempo. El quinto socket UDP, se utiliza para el
envío de las todas estadísticas generadas hacia la estación base.
El núcleo de la aplicación realiza las funciones explicadas en el capítulo 6, se crean
los distintos hilos que implementan los métodos de creación de estadísticas y se
preparan para su envío a la entidad par. Cabe destacar que las estadísticas generadas por
esta entidad, pertenecerán al enlace ascendente ya que el flujo de paquetes analizado
pertenece a ese tramo de la comunicación inalámbrica.
Capítulo 7: Aplicación en un Sistema Real: Estación de Control, Estación Base y Unidad a Monitorizar
121
7.2.1.2. Estación Base
La aplicación desarrollada para esta entidad es la más compleja, ya que realiza
prácticamente las mismas operaciones que la aplicación de la unidad a monitorizar y
además establece una conexión con la estación de control para el envío de las
estadísticas. Es por ello que en la misma se necesitan reservar 3 puertos destinados a la
generación de tráfico, dos para el envío y recepción de paquetes TCP y uno UDP sólo
para enviar. Un puerto destinado a la recepción de paquetes UDP de la unidad a
monitorizar que contendrá las estadísticas y finalmente un puerto para el envío en UDP
a la estación de control de todas las estadísticas generadas tanto en la unidad remota
como en la propia estación base.
Las estadísticas generadas por esta entidad pertenecen al enlace descendente ya que
el análisis de los paquetes que se realiza pertenece a ese tramo del enlace.
7.2.1.3. Estación de Control
Como se ha comentado, la implementación de esta entidad ha sido sencilla y no
dispone de mucha complejidad en esta versión. Como características, especificar que
sólo necesita la reserva de un puerto para la creación de un socket UDP que permita la
recepción de todas las estadísticas. Se comenzó el diseño de una interfaz gráfica en Qt
que mostrase las estadísticas en el monitor del ordenador, pero por falta de tiempo,
simplemente se reciben y se imprimen por pantalla en línea de comandos.
I
ÍNDICE GENERAL
Capitulo 1: Objetivo y Justificación del Proyecto.
1.1. Introducción .......................................................................................................... 4
1.2. FADA-CATEC ..................................................................................................... 4
1.2.1. Áreas de desarrollo ....................................................................................... 5
1.2.2. Localización .................................................................................................. 6
1.3. Justificación del Proyecto ..................................................................................... 7
1.4. Objetivo del Proyecto ........................................................................................... 7
Capitulo 2: Recursos Disponibles, Hardware y Software.
2.1. Introducción ........................................................................................................ 12
2.2. Recursos Hardware ............................................................................................. 13
2.2.1. RouterBoard 433 UAH ............................................................................... 13
2.2.2. RouterStation Pro ........................................................................................ 16
2.2.3. Radios mini-PCI ......................................................................................... 17
2.3. Recursos Software .............................................................................................. 24
2.3.1. Sistemas Operativos .................................................................................... 24
2.3.2. Programas y Aplicaciones .......................................................................... 27
Capitulo 3: Instalación y Configuración de OpenWrt en RouterBoard
433UAH.
3.1. Introducción ........................................................................................................ 32
3.2. Pasos previos ....................................................................................................... 33
3.2.1. Conexión de los Equipos ............................................................................ 33
3.2.2. Copia de seguridad Mikrotik RouterOS ..................................................... 34
3.3. OpenWrt .............................................................................................................. 36
3.3.1. Versión OpenWrt ........................................................................................ 36
3.3.2. Dependencias y Descarga OpenWrt ........................................................... 36
II
3.3.3. Adaptar OpenWrt ........................................................................................ 37
3.3.4. Compilación de OpenWrt ............................................................................ 38
3.4. RouterBOOT ....................................................................................................... 42
3.4.1. Formatear el sistema .................................................................................... 42
3.4.2. Seleccionar el modo de arranque ................................................................ 43
3.5. Instalación del sistema ........................................................................................ 44
3.5.1. Carga de la imagen por conexión de red local ............................................ 45
3.5.2. Arranque Netboot ........................................................................................ 48
3.5.3. OpenWrt en la Memoria NAND ................................................................. 49
3.6. Configuración de las Interfaces de Red ............................................................... 53
Capitulo 4: Entorno de Compilación Cruzada OpenWrt.
4.1. Introducción ........................................................................................................ 58
4.1.1. Toolchain ..................................................................................................... 58
4.1.2. Compilación Cruzada .................................................................................. 59
4.1.3. Buildroot ...................................................................................................... 59
4.1.4. Entorno de Compilación Cruzada ............................................................... 60
4.2. Buildroot OpenWRT ........................................................................................... 61
4.2.1. Obtener Buildroot OpenWrt ........................................................................ 61
4.2.2. Configuración del Buildroot OpenWrt ........................................................ 62
4.2.3. Funcionamiento Buildroot OpenWrt ........................................................... 64
4.3. Entorno de Compilación Cruzada ....................................................................... 67
4.3.1. Herramientas de Compilación Cruzada OpenWrt ....................................... 68
4.3.2. Modificación de las Variables de Entorno .................................................. 68
Capitulo 5: Eclipse, Entorno de Desarrollo.
5.1. Introducción ........................................................................................................ 74
5.1.1. Historia ........................................................................................................ 74
5.1.2. Características ............................................................................................. 75
5.2. Descarga e Instalación de Eclipse ....................................................................... 77
5.2.1. Obtención de Eclipse ................................................................................... 77
III
5.2.2. Interfaz de Eclipse ...................................................................................... 78
5.2.3. Instalación de Nuevo Software ................................................................... 79
5.3. Configuración de Eclipse .................................................................................... 81
5.3.1. Opciones del Compilador Cruzado ............................................................. 82
5.3.2. Opciones del Enlazador y Librerías ............................................................ 84
Capitulo 6: Herramienta de Monitorización del Enlace Inalámbrico en
Tiempo Real (WiLCA).
6.1. Introducción ........................................................................................................ 90
6.2. Herramientas Auxiliares ..................................................................................... 92
6.2.1. Wireless Tools for Linux ............................................................................ 92
6.2.2. Tcpdump ..................................................................................................... 93
6.2.3. Tcptrace ...................................................................................................... 94
6.3. WiLCA (Wireless Link Control Application) .................................................... 95
6.3.1. Esquema General ........................................................................................ 95
6.3.2. Estadísticas del Driver ................................................................................ 96
6.3.3. Estadísticas TCP ......................................................................................... 98
6.3.4. Estadísticas UDP ....................................................................................... 101
6.3.5. Funcionalidades ........................................................................................ 102
6.4. Programación de la Aplicación. ........................................................................ 103
6.4.1. Hilo principal ............................................................................................ 103
6.4.2. Hilo de Envío ............................................................................................ 104
6.4.3. Hilo Driver ................................................................................................ 104
6.4.4. Hilos TCP ................................................................................................. 105
6.4.5. Hilos UDP ................................................................................................. 106
6.5. Configuración Inicial de la Aplicación ............................................................. 107
6.5.1. XML .......................................................................................................... 107
6.5.2. Formato del Archivo de Configuración .................................................... 108
IV
Capitulo 7: Aplicación en un Sistema Real: Estación de Control, Estación
Base y Unidad a Monitorizar.
7.1. Introducción ...................................................................................................... 114
7.1.1. UAV .......................................................................................................... 114
7.1.2. Estación Base ............................................................................................ 115
7.1.3. Estación de Control ................................................................................... 115
7.2. Sistema de Monitorización ................................................................................ 117
7.2.1. Análisis y Control del Enlace Inalámbrico ............................................... 118
V
LISTADO DE FIGURAS
Figura 1: Logotipos de FADA-CATEC............................................................................ 5
Figura 2: Áreas de desarrollo FADA-CATEC ................................................................. 5
Figura 3: RouterBoard 433UAH ..................................................................................... 14
Figura 4: RouterStation Pro ............................................................................................ 16
Figura 5: XtremeRange2 ................................................................................................. 18
Figura 6: XtremeRange 5 ................................................................................................ 20
Figura 7: XtremeRange 9 ................................................................................................ 22
Figura 8: Interacción SO ................................................................................................. 24
Figura 9: Conexión de los equipos configuración RB433UAH ..................................... 33
Figura 10: WinBox ......................................................................................................... 35
Figura 11: Logotipo de Arranque OpenWrt ................................................................... 36
Figura 12: Menú Inicial de Configuración OpenWrt ...................................................... 39
Figura 13: Menú de Target Images para el ramdisk ....................................................... 39
Figura 14: Menú Target Images Sistema de Ficheros .................................................... 40
Figura 15: Menú RouterBOOT ....................................................................................... 42
Figura 16: Conexión de los Equipos NetBoot ................................................................ 44
Figura 17: Diagrama PXE ............................................................................................... 45
Figura 18: Esquema de Red ............................................................................................ 54
Figura 19: Esquema de Compilación Cruzada ............................................................... 59
Figura 20: Logotipo de la Comunidad BuildRoot .......................................................... 59
Figura 21: Menú Inicial Configuración OpenWrt .......................................................... 62
Figura 22: Compilación Cruzada x86/MIPS32 .............................................................. 67
Figura 23: Logo Proyecto Eclipse CDT ......................................................................... 77
Figura 24: Área de Trabajo de Eclipse ........................................................................... 78
Figura 25: Instalación de Nuevo Software en Eclipse .................................................... 80
Figura 26: Creación de un Proyecto de Compilación Cruzada ....................................... 81
Figura 27: Cambio de la Variable de Entorno ................................................................ 82
Figura 28: Configuración de las Opciones de Compilación - Prefijo ............................. 84
VI
Figura 29: Opciones de Configuración del Enlazador - Estático .................................... 85
Figura 30: Opciones de Configuración del Enlazador – Librerías .................................. 86
Figura 31: Esquema de las Estadísticas de Captura de Tráfico ....................................... 90
Figura 32: Esquema de las Estadísticas de Datos del Driver .......................................... 90
Figura 33: Logotipo Tcpdump ........................................................................................ 93
Figura 34: Logotipo Tcptrace .......................................................................................... 94
Figura 35: Esquema General WiLCA ............................................................................. 95
Figura 36: Estadísticas del Driver ................................................................................... 96
Figura 37: Estadísticas TCP ............................................................................................ 98
Figura 38: Estadísticas UDP ......................................................................................... 101
Figura 39: Esquema General Hilos WiLCA ................................................................. 103
Figura 40: Flujo de Datos de Monitorización ............................................................... 114
Figura 41: Representación del telecontrol del UAV ..................................................... 115
Figura 42: Esquema de Central de Adquisición de Datos ............................................. 116
Figura 43: Esquema General del Sistema de Monitorización ....................................... 117
Figura 44: Análisis de los Enlaces Descendente y Ascendente .................................... 118
Figura 45: Esquema Estación Base y Unidad a Monitorizar (Enlace Inalámbrico) ...... 119
Figura 46: Esquema Estación de Control y Estación Base, Enlace de Control ............ 120
VII
LISTADO DE TABLAS
Tabla 1: Recursos Disponibles ....................................................................................... 12
Tabla 2: Características RB433UAH .............................................................................. 15
Tabla 3: Características RS Pro ...................................................................................... 17
Tabla 4: Características XR2 .......................................................................................... 19
Tabla 5: Características XR5 .......................................................................................... 21
Tabla 6: Características XR9 .......................................................................................... 23
Tabla 7: Configuración Terminal Serie RB433UAH ..................................................... 34
Tabla 8: Credenciales de acceso RouterOS .................................................................... 34
Tabla 9: Versiones de Eclipse ......................................................................................... 75
A mi padre, Ella estaría orgullosa…
AGRADECIMIENTOS
En primer lugar quisiera agradecer a la empresa FADA – CATEC la oportunidad que
me ha brindado para realizar este proyecto y a mis tutores dentro de la misma Antidio y
Miguel por guiarme e iniciarme en el mundo de la investigación. Agradecer también a
Federico y sus constantes tirones de orejas para que este proyecto no quedara en el
olvido.
A mis padres, gracias a ellos soy lo que soy. A mi hermana, que todos estos años me
ha cuidado y facilitado mi vida fuera de casa. Y por supuesto al resto de mi familia, mis
tíos, mis primos, mis suegros, mis cuñadas y en especial a mi tía Mili, una segunda
madre para mí. Y también a mis familiares, que por desgracia, ya no están.
A todos mis compañeros y amigos de la ESI, en especial a Ángel, sin su amistad y
sus apuntes no hubiera sido lo mismo.
A todos mis amigos de siempre: Pedro, Juanma, Javichu, Juanjo… y a todos los
demás que siempre estáis ahí. A Juanlu y a Carmen, aún recuerdo ese viaje exprés para
levantarme el ánimo.
Y finalmente a mi Ángelita, mi todo.
Muchísimas gracias a todos
“QUÉ MAL REPARTIDO ESTÁ EL MUNDO
DESDE EL PRIMER MES DE ENERO.
PORQUE ESTE JUEGO DURA UN SEGUNDO.
Y GANA QUIEN MARCA PRIMERO…”
Estopa, Vacaciones