Instalación

En este apartado se va a analizar cuáles son los primeros pasos que hay que seguir, para poder establecer el entorno de trabajo adecuado que servirá de base para el desarrollo del proyecto. En primer lugar, se indicará cómo se deben configurar el router CIT y el router GNU/Linux para que puedan ser utilizados de acuerdo a las necesidades que vayan surgiendo en cada momento. Por último, se explicará cómo crear la plataforma Software que va a albergar el router GNU/Linux y que, posteriormente, será empotrada dentro del mismo.

Entorno de trabajo

En la siguiente figura, que muestra cómo debe ser la disposición de los diversos equipos que se van a emplear, aparecen los puestos de trabajo asociados a los participantes del proyecto, conectados a la red interna del departamento DATSI a través de un switch.

Se observa que los router CIT y GNU/Linux están conectados a dos de esos puestos de trabajo de tal forma que cualquiera de los desarrolladores que desee configurar alguno de dichos router, puede hacerlo a través del puerto serie, en caso de que esté conectado directamente al mismo, o bien accediendo de forma remota al puesto de trabajo donde esté conectado.

Router

Antes de comentar qué cambios se van a tener que aplicar, es necesario explicar cómo se puede acceder a cada uno de los router existentes para poder llevar a cabo la configuración pertinente.

Acceso

El acceso a cualquiera de los dos router se debe hacer a través del puerto serie desde un equipo externo. Para ello, se podrán emplear dos programas: Putty (Windows/Linux) o Minicom (Linux).

En ambos casos se observa la misma información relativa al router, sin embargo la manera de establecer los parámetros de comunicación varían. Por consiguiente, se va a mostrar cómo se debe proceder en cada uno de los casos.

En el caso en el que se esté empleando el cliente Putty se deberá ejecutar y una vez que se abra la interfaz correspondiente habrá que hacer lo siguiente:

  • Se selecciona en Connection type la opción Serial
  • Se establece el valor Speed = 9600
  • Se asigna el valor Serial line = /dev/ttyS1/dev/ttyS0, según proceda)



Dentro de las pestañas que aparecen a la izquierda, se selecciona SERIAL y se establecen los siguientes parámetros:

  • Serial line to connect to = /dev/ttyS1/dev/ttyS0, según proceda)
  • Speed (baud) = 9600
  • Data bits = 8
  • Stop bits = 1
  • Parity = None
  • Flow Control = X ON/X OFF



Llegado a este punto ya se está en disposición de establecer la conexión. Por tanto, si se le da al botón de Open y se reinicia el router, aparecerá toda la información relativa al mismo.

En el caso de que se opte por la herramienta Minicom habrá que lanzar dicho programa y pulsar Ctrl+A y luego Z, para que aparezca el menú de configuración correspondiente:


Una vez dentro del menú de configuración se hace lo siguiente:

  • Pulsamos la tecla O que corresponde a la opción Configurar Minicom
  • Seleccionamos la opción Configuración del puerto serie




Dentro de este apartado modificamos los siguientes valores:

  • Pulsamos la tecla A para cambiar el dispositivo serie y ponemos /dev/ttyS0 (o /dev/ttyS1, según corresponda).
  • Modificamos la velocidad de transmisión y la paridad pulsando la tecla E y una vez dentro del submenú que aparece, pulsamos las teclas E y Q.






  • Pulsamos la tecla F para desactivar el Control de Flujo por Hardware.
  • Pulsamos la tecla G para desactivar el Control de Flujo por Software.




Habiendo establecido los parámetros de configuración correctos, tanto en una como en otra aplicación, aparece la siguiente información:

      .**************************************************
      .**************************************************
      .**************************************************
      
      BOOT CODE VERSION: 02.01-B  Apr 28 2008 13:17:09
        gzip  Apr 23 2008 17:04:30
      P.C.B.: 93  MASK:0C10  Microcode:00E1
      START FROM FLASH
      BIOS CODE DUMP......................
      BIOS DATA DUMP....
      End of BIOS dump
      
      
      BIOS CODE VERSION: 02.01-B
      CLK=262144 KHz   BUSCLK=65536 KHz   PCICLK=32768 KHz   L1
      Date: 05/06/08, Tuesday         Time: 13:21:47
      
      SDRAM size: 64 Megabytes
         BANK 0: 64 Megabytes (detected)
      I_Cache: ON
      D_Cache: ON    Write-Back
      FLASH: 16 Mb.
      NVRAM: 128 Kb.
      EEPROM: 2048 Bytes.
      DPRAM: 8192 Bytes.
      FAST ETHERNET 1
      FAST ETHERNET 2
      ISAC
      RDSI_B
      RDSI_B
      SECURITY ENGINE
      PCI device: Host bridge
        (Bus: 0, Device: 0, Function: 0)
        (Subs. Vendor: 0x0000, Subs. Device: 0x0000)
      Current production date: 08 16
      Current software license: 9 1
      Current serial number: 524/02056
      BIOS MAC Add: 00-a0-26-90-08-08
      >>
      ..

Una vez que aparecen los puntos anteriores, existen dos opciones:

  • Acceder al BootLoader, haciendo Ctrl+T.
  • No hacer nada y dejar que arranque el router con normalidad.

Si se opta por mostrar el menú del BootLoader, hay que tener en cuenta que en el router CIT aparecerán una serie de opciones de configuración que para el router GNU/Linux son insuficientes. Por tanto, será necesario realizar una puesta a punto que deje los router perfectamente preparados, para ser manipulados según convenga.

Puesta a punto

Antes de meternos de lleno con el “trasteo” de los routers, hay que decir que éstos no están preparados, de primeras, para poder desempeñar la labor que se les ha asignado. Hay que realizar las modificaciones oportunas que se detallan a continuación.

Router CIT

Para aquellos router CIT en los que no se va a empotrar un Sistema Operativo GNU/Linux, es necesario llevar a cabo una pequeña adaptación que consiste en habilitar la segunda interfaz de red y que va a resultar de vital importancia para poder llevar a cabo todo el estudio y desarrollo de los protocolos de comunicaciones.

Si se arranca el router CIT y se muestran por pantalla todas las interfaces disponibles, se observa que de las dos existentes sólo aparece una:

  p 4
  
  Config>list devices
  
  Interface            Connector     Type of interface
  ethernet0/0          FE0/LAN1      Fast Ethernet interface
  x25-node             ---           Router->Node          
  Config>

Para solucionar este problema se debe reiniciar el router, acceder al BootLoader y hacer lo siguiente (las licencias y claves que aparecen ocultas se pueden encontrar en el CD del proyecto, en el directorio /instalacion/):

  === INITIAL  MENU ===                                                    
                                                                            
  a) Change Time                                                              
  b) Change Date                                                              
  c) Change Code to Run                                                      
  d) Change Licence                                                          
  e) Load from console (pc_load)                                              
  f) Disk menu                                                                
  g) Set default name for file loaded from console                            
  h) Change BIOS licence                                                      
  l) Load from lan                                                            
  v) Change version control for loading                                      
  x) Load from console (xmodem)                                              
  r) Reset                                                                    
  w) Watchdog configuration.                                                  
  0) Exit                                                                    
  >>d
  
  Current software license: 9 1
  Current serial number: 524/02778
  New software license (family group), values from 0 to 65535: ****
     Push Enter when finished
  Code license:****
  New code license?****
  OK
  ...

Para finalizar, se vuelve a reiniciar el router y se comprueba que aparecen todas las interfaces de red habilitadas:

  Config>list devices
  
  Interface            Connector     Type of interface
  ethernet0/0          FE0/LAN1      Fast Ethernet interface
  ethernet0/1          FE1/LAN2      Fast Ethernet interface
  x25-node             ---           Router->Node          
  Config>

Router GNU/Linux

Para poder preparar un router que en un futuro tendrá empotrado un kernel de Linux, obviamente será necesario partir de un router CIT al que se le deberán practicar una serie de modificaciones. Más concretamente, habrá que cargar el fichero bootloader.BIN con la versión adaptada del BootLoader.

Comenzamos arrancando el router y mostrando el menú principal del BootLoader, que es el que aparece por defecto en cualquier router CIT.

  === INITIAL  MENU ===                                                    
                                                                            
  a) Change Time                                                              
  b) Change Date                                                              
  c) Change Code to Run                                                      
  d) Change Licence                                                          
  e) Load from console (pc_load)                                              
  f) Disk menu                                                                
  g) Set default name for file loaded from console                            
  h) Change BIOS licence                                                      
  l) Load from lan                                                            
  v) Change version control for loading                                      
  x) Load from console (xmodem)                                              
  r) Reset                                                                    
  w) Watchdog configuration.                                                  
  0) Exit                                                                    
  >>

En primer lugar, se selecciona la opción v) Change version control for loading y se desactiva el control de versiones para que el router permita cargar el nuevo fichero de BootLoader y se sobreescriba al anterior.

Una vez hecho ésto se procede a la actualización en sí, para ello habrá que instalar en el equipo desde el que se hace la carga el conjunto de protocolos de transferencia de ficheros (XMODEM, ZMODEM y demás):

  > sudo apt-get install lrzsz

Volvemos al menú principal del router y ejecutamos la opción x) Load from console (xmodem) lo que supondrá que el router se quede a la espera de recibir el fichero correspondiente. Es en ese instante cuando, suponiendo que desde la máquina origen se accede al router a través de un terminal de Minicom, presionamos Ctrl+A y luego Z y configuramos las opciones de envío con los siguientes parámetros:

  Parámetros de comunicación.......P
      I: 115200
  Enviar archivos..................S
      xmodem

Seleccionamos el fichero bootloader.BIN con la tecla Espacio y le damos al Enter.

Una vez que se ha completado la telecarga, volvemos a cambiar la velocidad de transmisión a 9600bps para poder visualizar la información del router correctamente:

  Parámetros de comunicación.......P
      E: 9600

Reiniciamos el router y nos aparece la nueva versión del BootLoader que nos va a permitir empotrar toda la arquitectura GNU/Linux necesaria:

  === INITIAL  MENU ===                                                    
  
  a) Change Time                                                              
  b) Change Date                                                              
  c) Change Code to Run                                                      
  d) Change Licence                                                          
  e) Load from console (pc_load)                                              
  f) Disk menu                                                                
  g) Set default name for file loaded from console                            
  h) Change BIOS licence                                                      
  l) Load from lan                                                            
  v) Change version control for loading                                      
  x) Load from console (xmodem)                                              
  z) Change command line (Linux)                                              
  r) Reset                                                                    
  lram) Load from lan and run without saving                                  
  lk) Load kernel from lan                                                    
  lf) Load file system from lan                                              
  0) Exit                                                                    
  >>

De todas las opciones que aparecen, a continuación se explican con más detalle aquellas que van a resultar relevantes.

(l) LOAD FROM LAN

Esta opción se selecciona pulsando la tecla L y sirve para actualizar el BootLoader.

(v) CHANGE VERSION CONTROL FOR LOADING

Como se ha visto con anterioridad, esta opción permite habilitar/deshabilitar la actualización de la versión actual del BootLoader.

(x) LOAD FROM CONSOLE (XMODEM)

Sirve para cargar desde un terminal remoto un fichero, como por ejemplo la imagen de un kernel o de un sistema de ficheros, empleando el protocolo XMODEM.

(z) CHANGE COMMAND LINE (LINUX)

Después de que aparezca el menú principal, si tecleamos la opción Z nos aparecen las acciones posibles para la línea de comandos (información relevante que emplea el router en el arranque y que está almacenada en la memoria i2C).

Para visualizar la línea de comandos almacenada actualmente, pulsamos la tecla A y nos aparece la siguiente configuración por defecto:

console=ttyCPM0,9600n8n    

Esa es la configuración inicial que trae el router, sin embargo la vamos a ir cambiando progresivamente para adaptarla a nuestro entorno. Para ello, pulsaremos la tecla B y estableceremos los siguientes parámetros:

  • console=ttyCMP0 (terminal específico e interno del router)
  • root=/dev/nfs
  • ip1=Dirección IP del router.
  • ip2=Dirección IP del servidor NFS.
  • ip3=Dirección IP del siguiente salto (en nuestro caso es Sigrid, cuya dirección es 138.100.8.125).
  • nfsroot=Directorio NFS donde está almacenado el sistema de ficheros.
  • rw (permisos de lectura/escritura sobre el sistema de ficheros).
console=ttyCPM0,9600n8n root=/dev/nfs ip=138.100.9.219:138.100.9.117:138.100.8.125:255.255.248.0:rteldat2:eth0:off nfsroot=/NFSroot rw

Esto es en el caso en el que se importe por NFS el sistema de ficheros del router, cosa que se hará de forma provisional ya que será necesario grabarlo en la memoria Flash en algún momento. Para ello se tendrá que emplear la opción lf) Load file system from lan.

(lk) LOAD KERNEL FROM LAN

Permite cargar por red la imagen correspondiente al compilado de un kernel. Cuando se ejecuta esta opción, el router se queda a la espera de que se le envíe dicha imagen, para lo cual se podrá emplear el programa de telecarga CargaLan_2_5_setup, creado por Teldat (véase Kernel).

(lf) LOAD FILE SYSTEM FROM LAN

De forma similar al caso anterior, con esta opción cargamos en el router el sistema de ficheros correspondiente (véase Sistema de Ficheros).

Plataforma Software

Una vez que se ha configurado todo el Hardware necesario, se pasa a definir el Software que va a ir empotrado. Por un lado, tenemos las herramientas que nos van a permitir construir el sistema de ficheros GNU/Linux del router; por otro, las aplicaciones que se van a compilar de forma independiente para posteriormente ser incrustadas; y, por último, los scripts a los que llamará el menú para ejecutar mandatos Quagga.

Desarrollo

Para configurar correctamente todo el Software que debe ir alojado dentro del router, es imprescindible seguir estos pasos:

  • Se crea un fichero de configuración de BusyBox, que será usado por Buildroot.
  • Se crea un fichero de configuración de Buildroot para realizar la compilación oportuna, basándose en el mismo, y así obtener el sistema de ficheros asociado.
  • Una vez que se tiene el sistema de ficheros, se insertan en elmismo aquellas aplicaciones que no vienen incluidas o que se desean compilar de forma separada.
  • Se implementan los diversos scripts que van a ser necesarios.

A continuación mostramos con más detalle cómo se realiza cada uno de dichos pasos.

BusyBox

En primer lugar, es necesario instalar una serie de paquetes sin los cuáles no se pueden ejecutar BusyBox y Buildroot. En función de la versión de Ubuntu que se esté empleando se instalará un conjunto de paquetes u otro.

Si se está trabajando con Ubuntu 7.10, entonces la lista de paquetes que hay que instalar es la siguiente:

minicom
libncurses5-dev
bison
flex
gettext
texinfo
patch
g++
fakeroot
lrzsz
jigit
nfs-kernel-server
liblzo2-dev

En cambio, si se trata de Ubuntu 8.04, la lista varía ligeramente:

minicom
manpages-dev
libncurses5-dev
bison
flex
gettext
texinfo
patch
g++
fakeroot
nfs-user-server
mtd-tools
jigit
lrzsz
git-core
mtd-utils
zlib1g-dev
liblzo2-dev
uuid-dev

Una vez que se han instalado todos los paquetes necesarios, se puede acceder a la última versión existente del BusyBox, de forma gratuita, yendo a la página http://busybox.net/downloads/.

Procedemos a descargar el fichero tar.bz2 y lo descomprimimos en el directorio correspondiente. Una vez hecho ésto, accedemos al directorio ./busybox-1.* que se ha creado y desde allí lanzamos el menú de configuración:

> wget http://busybox.net/downloads/busybox-1.*.tar.bz2
> tar jxf busybox-1.*.tar.bz2
> cd busybox-1.*
> make menuconfig



Si lo que queremos es ir modificando una a una todas las opciones de configuración existentes, debemos hacerlo a través del propio navegador. Ahora bien, si ya disponemos de un fichero con la configuración deseada lo que hacemos es cargarlo a través de la opción Load an Alternate Configuration File.

Por último, suponiendo que se han modificado parámetros de la configuración actual y que se desea salvar los cambios lo que hacemos es guardar todo en un fichero, a través del mandato Save Configuration to an Alternate File, sabiendo que el formato del mismo debe ser del tipo nombre.config. En nuestro caso almacenaremos todos los cambios realizados en el fichero de configuración por defecto .config, para mayor comodidad.

Buildroot

Al igual que en el caso de BusyBox, Buildroot se puede descargar de forma gratuita desde la web http://buildroot.uclibc.org/.

Una vez que tenemos el fichero tar.bz2, lo descomprimimos, accedemos al directorio ./buildroot-1.* que se ha creado y cargamos el menú de configuración de Buildroot:

> tar jxf buildroot-20080324.tar.bz2
> cd buildroot
> make menuconfig



Se observa que la manipulación de los parámetros de configuración se hace igual que en BusyBox, bien de forma manual, bien a través de un fichero. Además, se va a seguir aplicando el mismo criterio de almacenar todos los cambios en el fichero de configuración por defecto .config, ya que así va a resultar más sencillo de manejar.

Llegados a este punto, podemos realizar la compilación con la herramienta Buildroot. Para ello hay que tener en cuenta un aspecto muy importante y es que si se desea emplear un fichero de configuración de BusyBox (tanto si es predefinido como creado por nosotros) hay que dejarlo claramente indicado dentro de las opciones de Buildroot (en la siguiente imagen vemos que se toma el fichero busybox-1.9.0.config que está almacenado dentro del subdirectorio package/busybox/).

En el supuesto de que se estuviese empleando un fichero de configuración de Buildroot que no fuese el predeterminado, se recomienda copiar dicho fichero como .config, ya que de no hacerlo así habría que indicar de forma explícita el nombre del mismo a la hora de realizar la compilación. Y no es nada recomendable, porque resulta un tanto complicado de hacer.

> cp <nombre_fichero>.config .config
> make 

Después de 1 ó 2 horas el proceso de compilación termina y, si no se ha producido ningún fallo, tenemos a nuestra disposición varias herramientas de compilación cruzada, que nos van a servir para crear aplicaciones explícitamente compiladas para el arquitectura del router, y el sistema de ficheros que va a ir empotrado.

De las herramientas de compilación de cruzada se hablará en el apartado siguiente que es donde verdaderamente se va a hacer uso de ellas. Del sistema de ficheros sólo mencionaremos cómo extraerlo y, en un apartado posterior, veremos cómo se ha llegado a la versión más ad hoc del mismo.

El sistema de ficheros inicial que crea Buildroot está comprimido como un .tar en el directorio ./binaries/uclibc. Si queremos descomprimirlo en un directorio, tendremos que ejecutar el fakeroot para poder tener permisos de administrador durante esa sesión, lo cuál nos permite llevar a cabo acciones tales como crear un nuevo nodo de tipo consola:

  > fakeroot
  > mknod console c <mayor> <minor>

Sin embargo, como se ha dicho, estos privilegios sólo permanecen activos durante la sesión abierta. Por tanto, si hacemos un exit (o un Ctrl+D) o intentamos acceder al mismo directorio desde otra consola, todos los archivos pasan a tener como propietario el usuario de la máquina en lugar de root, lo que supone que archivos como los nodos pasen a ser meros ficheros de texto.

¿Cómo podemos conseguir que el sistema de ficheros mantenga todos los permisos que se le han dado? Una posible solución consiste en volver a comprimir el sistema de ficheros modificado, antes de finalizar la sesión fakeroot. De este modo, cuando volvamos a descomprimirlo en un futuro, los archivos conservarán el propietario original que los creó.

Otra alternativa más segura y cómoda, que es la que se va a utilizar, consiste en descomprimir el sistema de ficheros en un directorio creado dentro del raíz del equipo en el que estamos trabajando, ya que al ser propiedad de root si trasladamos allí el sistema de ficheros, los permisos del mismo permanecerán intactos.

  > cd /
  > sudo su
  > mkdir FS
  > cd FS
  > tar xvf <ruta>/buildroot/binaries/uclibc/rootfs.powerpc.tar .

Aplicaciones

Como se ha visto, con BusyBox y con Buildroot se pueden instalar muchos de los servicios y las aplicaciones que existen para GNU/Linux, y cada vez más con las nuevas versiones que aparecen de estas dos potentes herramientas. No obstante, es recomendable compilar de forma independiente algunas de esas aplicaciones ya que pueden no estar incluídas dentro de BusyBox o Buildroot o sí lo están, pero la versión que se instala no es recomendable (bien porque tiene algún bug, como de he hecho ha sucedido, o porque no se adecua a los requisitos del producto final).

Para el caso concreto que se está tratando, vamos a analizar cuáles son las aplicaciones que responden a ese perfil, haciendo previamente una breve explicación de cómo se realiza una compilación cruzada.

Compilación cruzada

La compilación cruzada tiene como objetivo crear código desde un equipo, para que pueda correr sobre la arquitectura y el sistema operativo de otro equipo igual o distinto. Para ello, se tendrá que hacer uso en la máquina de desarrollo de un compilador cruzado.

Nosotros ya disponemos de una serie de utilidades de compilación cruzada, como gcc, g++ y gdb, que Buildroot ha creado junto con el sistema de ficheros del router y que se encuentran almacenadas dentro de la carpeta buildroot, en el subdirectorio build_powerpc/staging_dir/usr/bin.

Para ver más en detalle cómo se puede hacer uso de dichas utilidades, el siguiente ejemplo muestra cómo se compila un fichero de código que hace un “Hello, world!”, para una arquitectura PowerPC y un sistema operativo GNU/Linux. Obsérvese que si no se incluye en la variable PATH el directorio donde está almacenado el compilador cruzado, no se puede ejecutar correctamente el último mandato.

> export PATH=$PATH:<ruta>/buildroot/build_powerpc/staging_dir/usr/bin
> powerpc-linux-gcc -g -Wall hello.c -o hello

Ya tenemos el ejecutable correspondiente creado y para cerciorarnos de que realmente se ha creado para un sistema PowerPC con GNU/Linux, podemos comprobar qué tipo de fichero es, haciendo lo siguiente:

> file hello

O bien, podemos trasladarlo al sistema de ficheros del router (en este caso montado por NFS) y comprobar que se ejecuta correctamente, accediendo de forma remota a un prompt (vía Putty o Minicom).

> hello
  Hola mundo!
Uso del make sin autoconf

Puede darse el caso de querer construir una aplicación con make y que no se pueda usar autoconf (configure no exista). El archivo Makefile ya estará creado con sus parámetros definidos en este caso. Normalmente no está configurado para reconocer las herramientas de compilación cruzada, así que tenemos que editar el archivo Makefile o pasarle las variables cuando hacemos el make. En este caso, hay varias variables importantes: * CC : identifica el gcc a usar * CFLAGS : opciones de compilación del gcc. Hay multitud de ellas y algunas son peligrosas, otras rompen el programa y otras incluyen una mejora bastante grande del rendimiento del programa compilado. Se usa en código escrito en C (archivos con extensión .c) * CXXFLAGS : opciones de compilación del gcc para código escrito en C++ (archivos con extensión .cpp) * LDFLAGS : opciones del linker

El CC en nuestro caso será el siguiente:

   > CC="powerpc-linux-gcc"

La componente más importante de las CFLAGS es -Os ya que optimiza para que ocupe el menor espacio posible, cosa altamente deseable para nuestro diseño de sistema. -mcpu nos dice el modelo de CPU (603e en este caso), -pipe hace que se usen pipes en tiempo de compilación para pasarse información de unas etapas a otras y -fsigned-char deja que el tipo char sea como el tipo signed char. He encontrado esto último bastante recomendable para la arquitectura powerpc en bastantes sitios en internet.

   > CFLAGS="-mcpu=603e -Os -pipe -fsigned-char"

Por último, estas variables deben pasarse al final del mandato make

   > make CC="powerpc-linux-gcc" CFLAGS="-mcpu=603e -Os -pipe -fsigned-char"
Analizador léxico: FLEX

Para poder compilar ipsec-tools nos hace falta flex, un analizador léxico. Por suerte en su versión stripped no ocupa demasiado y el make no hace librerías dinámicas, así que en el montaje de ipsec-tools hay que indicarle expresamente donde está la librería de flex contra la que montar estaticamente (extensión .a).Los pasos son los siguientes:

   > tar xvjpf flex-2.5.35.tar.bz2
   > cd flex-2.5.35.tar
   > ./configure --prefix=/TelDatsi/FS --host=powerpc-linux 

Después de esto tenemos que hacer algunos cambios para que funcione. En el fichero config.h tenemos que comentar los siguientes defines para que la compilación funcione.

   //#define malloc rpl_malloc 
   //#define realloc rpl_realloc

Esto hará que no nos de más el error al hacer el linkado de “symbol rpl_malloc” not found. Adicionalmente, para reducir el espacio ocupado modificamos las CFLAGS, CXXFLAGS y LDFLAGS.

   LDFLAGS=-s
   CFLAGS=-g -Os -fomit-frame-pointer
   CXXFLAGS=-g -Os -fomit-frame-pointer

Esto da un ejecutable y una librería stripped y optimizados para ocupar lo mínimo posible. Ahora hacemos el make

   > make

Ya tenemos construida la librería, con lo cual la dejamos así.

Internetworking: QUAGGA

La implementación de los protocolos de comunicaciones en un sistema GNU/Linux no se hacen partiendo de la nada, sino que se utiliza Quagga, que ofrece una potente base para su desarrollo. Quagga consta de un conjunto de demonios, cada uno de los cuáles se encarga de configurar y mantener la información relativa a los protocolos de red que están contemplados.

Siempre que se pueda, se realizará la labor de desarrollo haciendo uso de Quagga, ya que es la aplicación ad hoc propicia. Y en el caso en el que no se pueda, se recurrirá a los servicios que ofrece el propio sistema operativo GNU/Linux.

Vista la aplicación que tenemos entre manos, mostramos los pasos que hay que seguir para realizar la instalación de la misma. En primer lugar, vamos a acceder como superusuario para poder tener todos los permisos habilitados y que no haya problemas durante la instalación (muchos de los mandatos que se ejecutan necesitan acceder a directorios con permisos restringidos o que son propiedad de root).

> sudo su

Creamos una carpeta donde almacenar los paquetes de Quagga, descargamos dentro el fichero tar.gz correspondiente y lo descomprimimos.

> mkdir quagga
> cd quagga
> wget http://www.quagga.net/download/quagga-0.98.6.tar.gz
> tar xzvf quagga-0.98.6.tar.gz

Una vez descomprimido, accedemos a la carpeta que resulta y añadimos a la variable de entorno PATH el directorio donde se encuentran las utilidades de compilación cruzada de Buildroot.

> cd quagga-0.98.6
> export PATH=$PATH:<ruta>/buildroot/build_powerpc/staging_dir/usr/bin

Acto seguido, procedemos a crear el Makefile correspondiente para la arquitectura PowerPC del router y lo compilamos

> ./configure --host=powerpc-linux --prefix=<ruta_fs> --enable-user=root --enable-group=root --sysconfdir=/etc --localstatedir=/var/run
> make
> make install

Una vez finalizada la instalación, insertamos en el fichero <ruta_fs>/etc/services las nuevas entradas correspondientes a los servicios de Quagga

#
# QUAGGA specific services
#
zebrasrv	2600/tcp          # zebra service
zebra         2601/tcp          # zebra vty
ripd      	2602/tcp          # RIPd vty
ripngd        2603/tcp          # RIPngd vty
ospfd         2604/tcp          # OSPFd vty
bgpd          2605/tcp          # BGPd vty
ospf6d        2606/tcp          # OSPF6d vty
ospfapi       2607/tcp          # ospfapi
isisd        	2608/tcp          # ISISd vty

El siguiente paso es crear los ficheros de configuración necesarios para aquellos servicios que se van a arrancar, que en nuestro caso van a ser Zebra y Ripd. Para crear sendos ficheros basta con renombrar de la siguiente forma los ficheros de ejemplo correspondientes.

> cd <ruta_fs>/etc
> cp zebra.conf.sample zebra.conf
> cp ripd.conf.sample ripd.conf

Ya tenemos los ficheros de configuración creados y podemos arrancar los demonios correspondientes, bien de forma manual, bien de forma automática. Si se lanzan de forma manual desde la consola, se deben ejecutar los siguientes mandatos (téngase presente en todo momento que hay que seguir estrictamente el orden fijado):

> zebra -d
> ripd -d

Ahora bien, si es necesario que estos demonios se lancen cada vez que se arranca el router, entonces la mejor solución es programar dicha acción de forma automática, incluyendo las entradas pertinentes en el fichero <ruta_fs>/etc/inittab.

# Quagga
::sysinit:/sbin/zebra -d
::sysinit:/sbin/ripd -d

Para finalizar, ya sólo nos queda acceder al menú de configuración del servicio que deseemos, que en el caso de Zebra se hace de la siguiente forma:

> telnet localhost 2601

Cifrado/Descifrado:OpenSSL

OpenSSL es un conjunto de herramientas y librerías que implementa la capa SSLv2/v3 y TLSv1, además de ser una utilidad multipropósito de cifrado y descifrado. Esta aplicación es necesaria, ya que ipsec-tools se apoya en ella.

En el apartado de kernel se comenta la inclusión de ocf-linux para dar cierto soporte al hardware criptográfico. OpenSSL tiene soporte mediante el API del kernel cryptodev. Para ello hace falta un parche para la versión actual (0.9.8n). Este parche es una alteración del parche original de ocf-linux que incluye las modificaciones de código que hay que hacer en los archivos normales para que se pueda compilar contra uClib y añadir compatibilidad con ocf-linux. Asimismo, se incluye también el Makefile para que se pueda compilar. Puede descargarse aquí

El script Configure no tiene la opción de compilación cruzada, por tanto lo que haremos será definir nosotros las variables CC, CFLAGS, LDFLAGS y AR. CC representa el compilador usado (en nuestro caso powerpc-linux-gcc, CFLAGS, que representa los flags del compilador (en nuestro caso -Os para optimizar el espacio físico ocupado), LDFLAGS_SHARED que representa los argumentos del linker (en nuestro caso -s, que hace que el fichero final no tenga símbolos, es decir, en modo “stripped”) y AR, que representa la utilidad AR (en nuestro caso powerpc-linux-ar $ARFLAGS r). En cada subdirectorio de OpenSSL se incluye un fichero de configuración Makefile que incluye estas variables y muchas otras cosas. Podemos cambiar cada fichero a mano, o podemos pasarle estas variables al make y que el las sustituya en ejecución por las que vienen en los ficheros Makefile. Para ello ejecutaremos:

  >make CC=powerpc-linux-gcc LDFLAGS_SHARED=-s AR='powerpc-linux-ar $ARFLAGS r'
  

Por último instalaremos OpenSSL en el directorio raíz de nuestro sistema de ficheros definiendo la variable INSTALL_DIR como /TelDatsi/FS/ . Para ello ejecutamos :

  > make CC=powerpc-linux-gcc LDFLAGS_SHARED=-s AR='powerpc-linux-ar $ARFLAGS r' INSTALL_DIR=/TelDatsi/FS install

IPsec : ipsec-tools

El paquete ipsec-tools proporciona las utilidades para gobernar el protocolo IPsec. Se compone de dos utilidades: setkey y racoon. Setkey se utiliza para establecer los parámetros de configuración de las conexiones IPsec de forma estática y racoon se utiliza para negociar las claves de forma dinámica, usando el protocolo IKE.

Estas utilidades se apoyan en OpenSSL y flex, por tanto deben estar ya construidas previamente.

El paquete ipsec-tools a priori no es compatible con uClib ya que utiliza funciones de C que se han quedado obsoletas y uClib ya no las incluye. Es el caso de bcopy, que ha sido sustituido por memcpy Por suerte, estas funciones tienen otras equivalentes que uClib si incluye. Para corregir este defecto se usa el siguiente parche. Además, este parche incluye el archivo Makefile creado por el programa configure, para que no sea necesario correrlo otra vez. Estas son las instrucciones para hacer el build, incluyendo el configure. Si se usa el fichero Makefile creado, no hace falta correr el configure.

  >configure  --disable-security-context --with-kernel-headers=/TelDatsi/kernel/final/include/ --prefix=/TelDatsi/FS --with-openssl=/TelDatsi/FS --enable-shared --disable-static --disable-gssapi --enable-stats --enable-natt=kernel --with-flexlib=/TelDatsi/utilidades/flex-2.5.3/libfl.a --host=powerpc-linux

Con –disable-security-context desactivamos las directivas de seguridad del kernel (no las necesitamos), –with-kernel-headers=/TelDatsi/kernel/final/include/ define donde están los ficheros include del kernel, –prefix=/TelDatsi/FS define donde está el sistema base, -with-openssl=/TelDatsi/FS define donde está instalado openssl, –enable-shared –disable-static hace que las librerías se monten de forma dinámica y no de forma estática, –disable-gssapi desactiva la autenticación por gssAPI, –enable-stats activa el logging de estadísticas, –with-flexlib=/TelDatsi/utilidades/flex-2.5.3/libfl.a define donde está la librería flex (libfl.a) que se montará de forma estática y por último –host=powerpc-linux activará la compilación cruzada para powerpc-linux.

Por último construimos el sistema:

 >make
 >make install

Scripts

Desde un principio se pensó que la manera más óptima de realizar el desarrollo de código era hacerlo mediante scripting, ya que podría resultar más sencillo, intuitivo y eficiente. Por ello, el objetivo que se persiguió fue implementar el menú y los scripts de configuración empleando un lenguaje de scripting, que a ser posible pudiese ser el mismo en ambos casos.

Partiendo de estas premisas, se pensó que Python podría ser el candidato idóneo, sin embargo surgieron dos grandes complicaciones que impidieron el que se pudiera llevar a buen término. La primera que se encontró fue la gran cantidad de dependencias que Python posee y que resultan tremendamente complicadas de compilar de forma cruzada, y la segunda, como consecuencia de la anterior, el espacio que ocupa, que resulta completamente prohibitivo ya que supone aproximadamente un total de 60MB cuando la memoria Flash del router tiene un tamaño máximo de 16MB (12MB, si tenemos en cuenta que va alojado en la partición destinada al sistema de ficheros).

Por estos y otros motivos, se decidió que los scripts de configuración se iban a implementar en Bash, porque el intérprete es fácil de instalar (viene incluído en el propio Buildroot), ocupa poco espacio y la sintaxis es mucho más rica y extensa que la que emplean las otras versiones, como sh o ash (la que se instala por defecto en Ubuntu). En cuanto al menú, se optó por hacerlo en lenguaje C, ya que los requisitos del mismo y los criterios de diseño no son fáciles de codificar con un lenguaje de scripting; no obstante, del menú se encarga otro compañero del proyecto, así que sólo vamos a explicar en detalle todo lo concerniente a los scripts de configuración.

El cometido de los scripts de configuración es implementar en GNU/Linux la funcionalidad equivalente a los mandatos del menú del router CIT. Concretamente, consiste en traducir estos últimos en mandatos de configuración Quagga, de ahí que el nombre de los scripts se haya hecho corresponder con el mandato CIT equivalente, para que resulte más intuitivo, adaptable y fácil de localizar.

Dichos scripts, como se ha comentado, están implementados en Bash y poseen una estructura que es idéntica para todos, para que el menú los pueda invocar de la misma forma sin necesidad de saber qué se está ejecutando por debajo, si un mandato Quagga o una función/servicio de GNU/Linux.

Diseño

El diseño de los scripts gira en torno a la comunicación que hay que establecer con el servicio correspondiente de Quagga (Zebra o Ripd), para poder obtener la información deseada. Por tanto, va a ser necesario que haya un proceso que se encargue de enviar las órdenes a Quagga y lea los resultados correspondientes, otro proceso que sea el propio demonio de Quagga y un tercero que haga de intermediario para establecer la comunicación entre los dos primeros (véase el siguiente diagrama).

Atendiendo a lo que se representa en el diagrama, el proceso que ejecuta el script de configuración crea un proceso (que se ejecuta en modo background), a través del cuál se comunica indirectamente con el demonio de Quagga. Este proceso intermedio simplemente lanza un servicio de acceso remoto, como pueda ser telnet o netcat, y redirecciona las entradas y salidas a los otros dos procesos a través de pipes.

En un principio se optó por el uso de telnet como mecanismo de acceso remoto, sin embargo, se descubrió que netcat era el más indicado por dos motivos:

  • Transmite de forma transparente la informacion que se envia, evitando asi posibles interpretaciones de cadenas como mandatos propios, tal y como sucede en el caso de telnet.
  • Al emplear telnet estamos actuando como un Terminal Virtual Remoto, por lo tanto necesitamos mantener un diálogo constante. Esto provoca que al ejecutar ciertos mandatos remotos en Quagga (como show interface) no se muestre el resultado al completo por pantalla y se quede a la espera en un More, cosa que no sucede en el caso de netcat.

Por último, para garantizar que la ejecución de los scripts sea correcta, se han aplicado una serie de medidas previas al establecimiento de la comunicación que consisten en:

  • Eliminar todos los procesos anteriores que estuviesen ejecutando un netcat a un servicio de Quagga (así se asegura que cuando el proceso actual lance un netcat, éste no se va a ver bloqueado por otros en el acceso al router).
  • Eliminar todos los ficheros que tengan el mismo nombre que los pipes que se van a crear.

Control de versiones

En esta sección se va a explicar cuáles han sido todos y cada uno de los pasos que se han realizado para poder llegar a la versión final del sistema de ficheros, que irá empotrado en el router. Concretamente, se va analizar las distintas versiones que se han creado hasta llegar a dicho sistema de ficheros.

Versión 1.0

Para esta primera versión no se va a manipular nada, sino que se va a usar una configuración inicial ya creada, que es la que nos proporcionaron al inicio del proyecto. Es una configuración en la que se han tenido que adaptar algunos parámetros para garantizar una cierta estabilidad y un funcionamiento correcto del router.

Versión Configuración
BusyBox BusyBox 1.10.2 busybox-1.6.0.config
Buildroot Buildroot v0.10.0-svn buildroot.config


Lo que se ha hecho, por tanto, es partir de las configuraciones que traen por defecto BusyBox y Buildroot y realizar las modificaciones oportunas, partiendo de los siguientes criterios:

  • El microcontrolador del router es de la familia PowerPC (Target Architecture), versión 603e (Target Architecture Variant).
  • No se instala el compilador de C++ (Toolchain –> Build/install c++ compiler and libstdc++?).
  • Se instala un depurador GDB en el equipo local desde el que se está haciendo la compilación cruzada (Toolchain –> Build gdb for the Host).
  • No se va a trabajar con ficheros grandes (> 2GB) (Toolchain –> Enable large file (files > 2 GB) support?).
  • Se toma la configuración 1.6.0 de Busybox porque la versión 1.9.0 no existe (Package Selection for the target –> BusyBox Version).
  • Se instala la herramienta Fakeroot, que, como se vio, puede hacer falta a la hora de descomprimir el sistema de ficheros (Package Selection for the target –> fakeroot).
  • Se instala el Dropbear, que es un servidor de SSH y nos va a hacer falta para acceder de forma remota al router (Package Selection for the target –> Networking –> dropbear).
  • Se instala Iproute para facilitar la labor de routing y control del tráfico de red (Package Selection for the target –> Networking –> iproute2).
  • No se necesita soporte para aplicaciones gráficas (Package Selection for the target –> Graphic libraries and applications (graphic/text)).
  • No se necesita soporte para audio (Package Selection for the target –> Audio libraries and applications).
  • No se necesita soporte para manejo de HW/dispositivos de bloque/sistemas de ficheros (Package Selection for the target –> Hardware handling / blockdevices and filesystem maintenance).
  • Se instala el compresor Zlib (Package Selection for the target –> Compressors / decompressors –> zlib).
  • No se necesita soporte para lenguajes de scripting (Package Selection for the target –> Interpreter languages / Scripting).
  • No se necesita soporte para XML (Package Selection for the target –> XML handling).
  • No se necesita soporte para Java (Package Selection for the target –> Java).
  • No se necesita soporte para juegos (Package Selection for the target –> Games).
  • Se selecciona que Buildroot cree el sistema de ficheros en un .tar (Target filesystem options –> tar the root filesystem), pero sin comprimirlo (Target filesystem options –> Compression method (no compression)).
  • Se deshabilita la instalación de algún kernel específico (Kernel –> Kernel type (none)).
  • Sólo se van a emplear las cabeceras de la versión 2.6.21 (2.6.21.7) del kernel de Linux (Kernel –> Linux Kernel Version + Toolchain –> Kernel Headers).

Versión 2.0

Esta segunda versión surge a raíz de las necesidades que emergen de la implementación de los scripts de configuración. Así, partiendo de la versión anterior y la correspondiente configuración, lo único que hay que hacer es añadir bash y netcat al juego de herramientas existente.

En la siguiente tabla aparecen los ficheros de configuración finales que se han creado respondiendo a éstas necesidades y que son los que se van a usar para conformar el sistema de ficheros correspondiente.

Versión Configuración
BusyBox BusyBox 1.10.2 busybox2.config
Buildroot Buildroot v0.10.0-svn buildroot2.config


Bugs

Al compilar Buildroot con las anteriores configuraciones surgen una serie de errores, concretamente al intentar descargar paquetes de instalación de direcciones web que no existen. Ésto es debido a que en las url’s aparece replicado dos veces el directorio gnu, lo cuál induce a pensar que es fruto de un bug que se ha producido al construir dichas url’s.

http://ftp.gnu.org/pub/gnu/gnu/nombre_paquete

En efecto, muchos de los ficheros de configuración emplean un direccionamiento relativo a la variable BR2_GNU_MIRROR, que contiene la dirección:

http://ftp.gnu.org/pub/gnu 

y concatenan a la misma el directorio del paquete con el formato /gnu/nombre_paquete, lo que supone que la dirección final de descarga, como se ha dicho, resulte desconocida.

Ante esta situación se debe hacer una búsqueda de todos los ficheros existentes (dentro de la carpeta de Buildroot) que contienen la variable BR2_GNU_MIRROR, obteniéndose el siguiente resultado:

./ncurses.lst:./package/ncurses/ncurses.mk:NCURSES_SITE:=$(BR2_GNU_MIRROR)/gnu/ncurses
./package/gettext/gettext.mk:GETTEXT_SITE:=$(BR2_GNU_MIRROR)/gnu/gettext
./package/autoconf/autoconf.mk:AUTOCONF_SITE:=$(BR2_GNU_MIRROR)/gnu/autoconf
./package/findutils/findutils.mk:FINDUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/findutils/
./package/editors/ed/ed.mk:ED_SITE:=$(BR2_GNU_MIRROR)/ed/
./package/wget/wget.mk:WGET_SITE:=$(BR2_GNU_MIRROR)/gnu/wget
./package/make/make.mk:GNUMAKE_SITE:=$(BR2_GNU_MIRROR)/gnu/make
./package/readline/readline.mk:READLINE_SITE:=$(BR2_GNU_MIRROR)/readline
./package/bash/bash.mk:BASH_SITE:=$(BR2_GNU_MIRROR)/gnu/bash
./package/libtool/libtool.mk:LIBTOOL_SITE:=$(BR2_GNU_MIRROR)/gnu/libtool
./package/diffutils/diffutils.mk:DIFFUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/diffutils
./package/automake/automake.mk:AUTOMAKE_SITE:=$(BR2_GNU_MIRROR)/gnu/automake
./package/sed/sed.mk:SED_SITE:=$(BR2_GNU_MIRROR)/gnu/sed
./package/gzip/gzip.mk:GZIP_SITE:=$(BR2_GNU_MIRROR)/gnu/gzip
./package/gawk/gawk.mk:GAWK_SITE:=$(BR2_GNU_MIRROR)/gnu/gawk
./package/coreutils/coreutils.mk:COREUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/coreutils
./package/ncurses/ncurses.mk:NCURSES_SITE:=$(BR2_GNU_MIRROR)/gnu/ncurses
./package/bison/bison.mk:BISON_SITE:=$(BR2_GNU_MIRROR)/gnu/bison
./package/m4/m4.mk:M4_SITE:=$(BR2_GNU_MIRROR)/gnu/m4
./package/tar/tar.mk:GNUTAR_SITE:=$(BR2_GNU_MIRROR)/gnu/tar/
./package/config/buildroot-config/auto.conf:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./package/config/buildroot-config/autoconf.h:#define BR2_GNU_MIRROR "http://ftp.gnu.org/pub/gnu"
./.defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./.config:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./toolchain/gdb/gdb.mk:GDB_SITE:=$(BR2_GNU_MIRROR)/gdb
./toolchain/gcc/gcc-uclibc-3.x.mk:GCC_SITE:=$(BR2_GNU_MIRROR)/gcc/gcc-$(GCC_VERSION)
./toolchain/gcc/gcc-uclibc-4.x.mk:GCC_SITE:=$(BR2_GNU_MIRROR)/gcc/gcc-$(GCC_VERSION)
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./toolchain/binutils/binutils.mk:BINUTILS_SITE:=$(BR2_GNU_MIRROR)/binutils/
./project_build_powerpc/uclibc/buildroot-config/auto.conf:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./project_build_powerpc/uclibc/buildroot-config/autoconf.h:#define BR2_GNU_MIRROR "http://ftp.gnu.org/pub/gnu"
./target/device/valka/v100sc2_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/at91sam9260dfc/at91sam9260dfc_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/at91sam9261ek/at91sam9261ek_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/atngw100-expanded/atngw100_expanded_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/atngw100/atngw100_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/atngw100-base/atngw100-base_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/at91sam9263ek/at91sam9263ek_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/atstk1002/atstk1002-no-mplayer_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Atmel/atstk1002/atstk1002_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/x86/i386/i686_defconfig:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
./target/device/Config.in.mirrors:config BR2_GNU_MIRROR
./.config.old:BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"

De todos ellos, sólo se tienen que modificar realmente los siguientes:

./package/gettext/gettext.mk:GETTEXT_SITE:=$(BR2_GNU_MIRROR)/gnu/gettext
./package/autoconf/autoconf.mk:AUTOCONF_SITE:=$(BR2_GNU_MIRROR)/gnu/autoconf
./package/findutils/findutils.mk:FINDUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/findutils/
./package/wget/wget.mk:WGET_SITE:=$(BR2_GNU_MIRROR)/gnu/wget
./package/make/make.mk:GNUMAKE_SITE:=$(BR2_GNU_MIRROR)/gnu/make
./package/bash/bash.mk:BASH_SITE:=$(BR2_GNU_MIRROR)/gnu/bash
./package/libtool/libtool.mk:LIBTOOL_SITE:=$(BR2_GNU_MIRROR)/gnu/libtool
./package/diffutils/diffutils.mk:DIFFUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/diffutils
./package/automake/automake.mk:AUTOMAKE_SITE:=$(BR2_GNU_MIRROR)/gnu/automake
./package/sed/sed.mk:SED_SITE:=$(BR2_GNU_MIRROR)/gnu/sed
./package/gzip/gzip.mk:GZIP_SITE:=$(BR2_GNU_MIRROR)/gnu/gzip
./package/gawk/gawk.mk:GAWK_SITE:=$(BR2_GNU_MIRROR)/gnu/gawk
./package/coreutils/coreutils.mk:COREUTILS_SITE:=$(BR2_GNU_MIRROR)/gnu/coreutils
./package/ncurses/ncurses.mk:NCURSES_SITE:=$(BR2_GNU_MIRROR)/gnu/ncurses
./package/bison/bison.mk:BISON_SITE:=$(BR2_GNU_MIRROR)/gnu/bison
./package/m4/m4.mk:M4_SITE:=$(BR2_GNU_MIRROR)/gnu/m4
./package/tar/tar.mk:GNUTAR_SITE:=$(BR2_GNU_MIRROR)/gnu/tar/

Para ello lo que se hace es sustituir ($BR2_GNU_MIRROR)/gnu/nombre_paquete por $(BR2_GNU_MIRROR)/nombre_paquete.

En cualquier caso, para evitar en un futuro el tener que modificarlos cada vez que se quiera instalar Buildroot, se han guardado estos ficheros ya arreglados, para sobreescribirlos a los que utilice Buildroot por defecto; es decir, que se han guardado como parches.

Versión 3.0

Con vistas a crear un sistema de ficheros lo más ad hoc posible y con un número reducido de bugs, se decide emplear la última versión disponible y estable de Buildroot y BusyBox, con los siguientes ficheros de configuración:

Versión Configuración
BusyBox BusyBox 1.13.2 busybox3.config
Buildroot Buildroot v2009.02-rc4 buildroot3.config


Esta, sin duda, sería la versión más potente y estable de todas las creadas hasta ahora. Sin embargo, el sistema de ficheros que resulta tiene un tamaño de 25MB (20MB si reducimos notablemente el juego de aplicaciones), sin incluir el menú y Quagga, cuando la memoria Flash posee una capacidad máxima de almacenamiento de 16MB.

El hecho de que el tamaño de este nuevo sistema de ficheros sea mucho mayor que el inicial ha llevado a realizar una comparativa de versiones de Buildroot y BusyBox, comprobando que el mismo fichero de configuración en ambas versiones produce tamaños de sistemas de ficheros muy dispares (9MB, aproximadamente, en el inicial frente a los 20MB del final).

Esto nos lleva a pensar que en sucesivas versiones de Buildroot y Busybox, los servicios que se instalan ocupan más espacio, posiblemente porque incluyen más funcionalidades o porque las existentes han tenido que ser arregladas. Y en efecto, módulos como la uClibc han ido incluyendo más funcionalidad con cada versión de BusyBox que se ha publicado.

En conclusión, va a ser necesario crear una nueva versión del sistema de ficheros que logre fusionar lo mejor de todas las versiones que se han desarrollado hasta el momento.

Bugs
  • Hay que marcar Bash en el menú de configuración de Buildroot y desactivar la opción que oculta las aplicaciones incluídas en BusyBox.
  • Hay que modificar manualmente el fichero .config y establecer la versión 2.6.21 del kernel de Linux, que es la correcta:
# Kernel Header Options
#
# BR2_KERNEL_HEADERS_2_4_31 is not set
# BR2_KERNEL_HEADERS_2_6_20_4 is not set
# BR2_KERNEL_HEADERS_2_6_20 is not set
# BR2_KERNEL_HEADERS_2_6_21_5 is not set
BR2_KERNEL_HEADERS_2_6_21=y
# BR2_KERNEL_HEADERS_2_6_22_1 is not set
# BR2_KERNEL_HEADERS_2_6_22_10 is not set
# BR2_KERNEL_HEADERS_2_6_22 is not set
# BR2_KERNEL_HEADERS_2_6_23 is not set
# BR2_KERNEL_HEADERS_2_6_24 is not set
# BR2_KERNEL_HEADERS_2_6_25 is not set
# BR2_KERNEL_HEADERS_2_6_26 is not set
# BR2_KERNEL_HEADERS_2_6_27 is not set
# BR2_KERNEL_HEADERS_2_6_28 is not set
# BR2_KERNEL_HEADERS_SNAP is not set
# BR2_KERNEL_HEADERS_PATCH_DIR is not set
BR2_DEFAULT_KERNEL_HEADERS="2.6.21.7"
  • Hay que modificar el fichero buildroot2009.02-rc4/package/iproute2/iproute2.mk, ya que la dirección que construye para realizar la descarga de los fuentes no es correcta. Hay que reemplazarlo por lo siguiente:
$(DL_DIR)/$(IPROUTE2_SOURCE):
      $(call DOWNLOAD,$(IPROUTE2_SITE),$(IPROUTE2_SOURCE))
  • La dirección del repositorio de descarga de SOURCEFORGE ha estado inaccesible durante un largo periodo de tiempo. Para evitar que en lo sucesivo, si vuelve a ocurrir, el trabajo se vea paralizado por este motivo hay que modificar en todos los ficheros .mk, en los que aparezca la variable BR2_SOURCEFORGE_MIRROR, la dirección correspondiente por la siguiente:
http://dl.sourceforge.net/sourceforge/*

La lista de paquetes en los que hay que realizar dicho cambio se muestra a continuación:

package/ethtool/ethtool.mk
package/x11vnc/x11vnc.mk
package/tcl/tcl.mk
package/fuse/libfuse.mk
package/psmisc/psmisc.mk
package/libcgi/libcgi.mk
package/haserl/haserl.mk
package/bridge-utils/bridge.mk
package/libsysfs/libsysfs.mk
package/rdesktop/rdesktop.mk
package/nbd/nbd.mk
package/pcmcia/pcmcia.mk
package/tinyhttpd/tinyhttpd.mk
package/tn5250/tn5250.mk
package/hdparm/hdparm.mk
package/beecrypt/beecrypt.mk
package/e2fsprogs/e2fsprogs.mk
package/libupnp/libupnp.mk
package/iperf/iperf.mk
package/smartmontools/smartmontools.mk
package/libpng/libpng.mk
package/ipsec-tools/ipsec-tools.mk
package/games/lxdoom/lxdoom.mk
package/java/jamvm/jamvm.mk
package/netcat/netcat.mk
package/blackbox/blackbox.mk
package/nfs-utils/nfs-utils.mk
package/strace/strace.mk
package/netsnmp/netsnmp.mk
package/rxvt/rxvt.mk
package/libungif/libungif.mk
package/freetype/freetype.mk
package/libdnet/libdnet.mk
package/bootutils/bootutils.mk
package/ezxml/ezxml.mk
package/x11r7/mesa3d/mesa3d.mk
package/gtkperf/gtkperf.mk
package/icu/icu.mklibmad.mk
package/multimedia/madplay/madplay.mk
package/multimedia/mpg123/mpg123.mk
package/multimedia/libid3tag/libid3tag.mk
package/multimedia/libmad/libmad.mk
package/ltp-testsuite/ltp-testsuite.mk
package/vtun/vtun.mk
package/expat/expat.mkzl
package/usbutils/usbutils.mk
package/zlib/zlib.mk

Versión 4.0

Partiendo de las premisas anteriormente expuestas, se vuelve a retomar las versiones antiguas de Buildroot y BusyBox y sobre ellas se intenta hacer el sistema de ficheros lo más ad hoc posible, ya que no existen versiones intermedias disponibles de Buildroot entre la antigua y la que hay actualmente.

La versión antigua, a pesar de los bugs, de los cuáles muchos se han podido corregir, es la única que permite crear un sistema de ficheros con más servicios que la versión 3.0 y sin pasarse del límite de espacio disponible en Flash.

Por consiguiente, los ficheros de configuración que quedan en esta última versión son los siguientes:

Versión Configuración
BusyBox BusyBox 1.10.2 busybox4.config
Buildroot Buildroot v0.10.0-svn buildroot4.config


Bugs

Los bugs que aparecen en esta versión son los mismos que los de la versión 2.0, así que no es necesario volver a explicar como subsanarlos (para ello se crearon los parches correspondientes).

Ahora bien, hay un aspecto muy importante referente a Dropbear, que no se había contemplado hasta ahora (no tenía sentido hacerlo en versiones que no iban a ser definitivas), y es que nunca llega a arrancarse (aunque en el fichero /etc/inittab se invoca en modo respawn para que nunca se caiga, siempre se intenta arrancarlo sin éxito).

El problema radica en la ausencia de las claves RSA (/etc/dropbear/dropbear_rsa_host_key) y DSS (/etc/dropbear/dropbear_dss_host_key), sin las cuáles la aplicación no puede funcionar correctamente, por consiguiente habrá que crear dichas claves invocando las siguientes llamadas:

> dropbearkey -t rsa -f dropbear_rsa_host_key
> dropbearkey -t dss -f dropbear_dss_host_key

Componentes

Para implementar todas las funcionalidades pedidas es necesario instalar varias herramientas,cuidando siempre que el sistema de archivos no sobrepase los 12 Megas en la versión final (si montamos el sistema de archivos por NFS da igual). Hemos observado que el sistema de archivos construido por buildroot + quagga ocupaba 11,5 Megas, así que para reducir el tamaño hemos eliminado los simbolos de depuración, es decir hemos hecho un quagga “stripped”. Los símbolos de depuración son útiles cuando hacemos depuración simbólica de alguna utilidad para ver errores en tiempo de ejecución, pero para un producto final son inútiles. Por lo tanto, cuando terminamos de probar una utilidad hacemos una version “stripped” de ella añadiendo la variable LDFLAGS=”-s” al make

  >make LDFLAGS="-s"

Esta es la tabla comparativa de todas las utilidades que hemos usado para hacer el sistema de ficheros:

Versión Funcionalidades Tamaño normal Tamaño stripped Descripción
Buildroot 20080324 Sistema básico de ficheros,busybox,dropbear3,8 MB - Sistema de ficheros básico creado por buildroot
Quagga 0.9.8 IP,RIP,OSPF,BGP 7,4 MB 3,1 MB Suite de routing
Flex 2.5.35 libflex.a - 4,4 KB Analizador léxico
 
proyectos/teldatsi/instalacion.txt · Última modificación: 2012/10/08 17:58 (editor externo)
 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki