Capítulo 1 - Universidad de Sevillabibing.us.es/proyectos/abreproy/12016/fichero/PFC+-+JMLC.pdf · Proyecto Final de Carrera - José M León Coca 4 1.1. Introducción A lo largo

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


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.


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


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.


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


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.


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


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.


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


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


20


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



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


21


RoHS Compliance YES

Avg. TX Power 28dBm, +/-1.5dB



Dependent) over 150m





Handoff


from Ubiquiti


Ubiquiti



22


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



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


23

Data Rates 6Mbps, 9Mbps, 12Mbps, 24Mbps, 36Mbps, 48Mbps,

54Mbps


RoHS Compliance YES

Avg. TX Power 28dBm, +/-1dB



Dependent) over 400m





Handoff


from Ubiquiti


Ubiquiti



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…).


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


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).


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.


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


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:


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


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


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


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:


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.


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


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


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.


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


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.


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


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.


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;


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 ###


######################################################

# 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


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 ###


#############################################

# 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


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


50

El utilizado para este proyecto, como en las configuraciones anteriores se muestra a

continuación como ejemplo:

#############################################

### Configuración /etc/vsftpd.conf ###


#############################################

# 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


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


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:/#


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.


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


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


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.


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.


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


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.


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.


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:


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


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.


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 ###


######################################################

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


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


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…


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.

http://www.eclipse.org/


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.


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


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.


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


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


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…


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)


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


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


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.


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.


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


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


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


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


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.


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.


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


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).


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.


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.


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


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.


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.


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.


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.


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 ###


##################################################################################

<?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.


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


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.


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


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.


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.


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.


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.


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 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

Documents

Capítulo 1 - Universidad de Sevillabibing.us.es/proyectos/abreproy/12016/fichero/PFC+-+JMLC.pdf · Proyecto Final de Carrera - José M León Coca 4 1.1. Introducción A lo largo