+----------------------------------+
| HOWTO
OPENWRT-EH |
+----------------------------------+
La intención de éste howto es facilitar la transición
desde los firm del tipo "plug & play" (como yo los llamo) tipo
Satori. Creo necesario destacar que no soy ningún experto en linux (más bien
todo lo contrario), ni en firmwares, ni en el wrt45g. Por ello, puedes
encontrarte con algún error de concepto, erratas, o algún término digamos que
no demasiado técnico. Para cualquiera de los casos, no dudes en hacérmelo saber
;-). La información aquí recogida está basada en mi propia experiencia, así
como la consulta a varias listas de correo y foros. Espero que algo de esto te
sirva de ayuda. Comenzamos:
INTRODUCCION (versión utilizada OpenWRT-EH-beta3)
------------
OpenWRT (http://openwrt.org) es una distribución de linux
para el linksys WRT54g. A diferencia de otras, la filosofía de OpenWRT no ronda
en incorporar un montón de funciones 'preinstaladas', sino que provee un
firmware 'mínimo' a partir del cual las posibilidades son elevadísimas. En resumen,
OpenWRT dista mucho de ser un firm del tipo "plug & play", sino
más del tipo "Hágaselo usted mismo". Prueba de ello es que el OpenWRT
original no trae configuración por web, ni por ejemplo, servidor ssh.
OpenWRT-EH es un firm desarrollado por la gente de
Valenciawireless, tomando como base el OpenWRT original, y siendo compatible al
99% con él, de manera que casi cualquier cosa que valga para el OpenWRT, es válida
también para el OpenWRT-EH.
El OpenWRT-EH trae algunas diferencias, pero digamos que
son personalizaciones, como por ejemplo, que incorpora una rudimentaria página
web donde se pueden configurar algunos parámetros (en desarrollo), aunque yo
personalmente no la utilizo. También incorporan 'de serie' un servidor ssh
(dropbear).
Podemos decir que la intención de OpenWRT es proveer de
la base para que por ejemplo, luego los cracks de valenciawireless (o quien
sea) construyan un firm a medida, personalizado.
Básicamente, OpenWRT Contiene dos sistemas de ficheros:
- Una pequeña
partición de modo "sólo lectura" con el sistema de ficheros squashfs
(http://squashfs.sourceforge.net). Ésta partición contiene el corazón del
aparato: un entorno linux mínimo, preparado para arrancar el router, y proveer
lo básico.
- Una partición
"lectura+escritura" con el sistema de ficheros jffs2
(http://sources.redhat.com/jffs2), que es un sistema de ficheros con journaling
especialmente diseñado para sacarle el máximo partido a memorias tipo flash.
Todo lo que no provee la partición squashfs, es puede ser incorporado en ésta
partición.
* Hardware
--------
Como muchos ya
sabéis, hay 3 versiones del linksys, 1, 1.1 y 2. Las diferencias hardware entre
ellas son fácilmente localizables en muchas páginas web. Básicamente, el driver
de red cambia entre las v1 y la v2, y la v2 lleva un micro más rápido.
De todas las
diferencias, la que personalmente veo con mayor trascendencia en el uso diario
e inmediato del aparato es la del driver de red, que causa que haya diferencias
en los interfaces de red de cada aparato. Respecto a éste tema, no abunda la
información comparativa entre las dos versiones.
En resumen, esto
es lo que nos encontramos en cada versión en cuanto a interfaces de red (en
OpenWRT):
**** Versión 1
y 1.1 ****
eth0 = 4
puertos del switch.
vlan2 = vlan
que engloba los 4 puertos (eth0)
eth1 =
wan-internet. Fake interface (cosa del driver de las v1). No funciona sólo.
Debe estar asociado a una vlan (vlan1).
vlan1 = vlan
que referencia la salida internet-wan
eth2 =
wireless
br0 = (cuando
está, por defecto , ya que para modo cliente lo quitamos) bridge eth2+vlan2 (switch+wireless)
*****************************************************
**** Version 2 ****
eth0 = 4 puertos (switch)
eth1 = wireless
vlan0 = vlan para eth0 (switch)
vlan1 = vlan
para el puerto wan-internet (aquí el driver no crea el fake-interface eth1)
br0 = (si
existe, ya que para modo cliente lo quitamos) vlan0+eth1 (switch+wireless)
Con esto os podréis centrar un poco, y saber sobre qué estáis
trabajando.
--------------------------------------
Bueno, pues vistas ya cuatro generalidades, si os parece
pasamos a ir entrando en harina ;-):
PASO 1) ACTIVAR EL BOOT_WAIT.
----------------------------
y os preguntareis... y qué es esto del boot_wait? Bueno,
pues luego os lo explico ;-)
Para activar el boot_wait, si usáis Satori o Samadhi, es fácil:
en la sección de administración tenéis un radio donde lo podéis seleccionar.
Desde la consola, pues teclearíais:
#nvram
set boot_wait=on
#nvram commit
PASO 2) SUSTITUCION DEL VIEJO FIRMWARE POR VUESTRO
FLAMANTE OPENWRT-EH
---------------------------------------------------------------------
La última versión la podéis encontrar en la web de valenciawireless.
Actualmente, está en:
http://valenciawireless.net/wrt54g/firm/openwrt-eh_beta3.bin
Para reemplazar vuestro viejo firm, tenéis dos
posibilidades:
- Si actualmente estáis usando un firm tipo Satori, con posibilidad
de flashear via web, pues ésta es la opción más sencilla: lo hacéis como
siempre, utilizando el binario que os acabáis de descargar.
- Si no, pues podéis usar el método del tftp`. Éste
método es universal, pero para que funcione debemos tener activado el
boot_wait, QUE NO SE OS OLVIDE HACERLO ANTES DE NADA!!!
La forma de subir
el nuevo firm con éste sistema la tenéis descrita en:
http://wiki.valenciawireless.net/index.php/Mini%20Howto%20de%20la%20Instalaci%F3n%20del%20Firmware%20OpenWRT-EH%20mediante%20tftp?PHPSESSID=1b4a5f9036b6f85a75c08526ebcbcb5c
Básicamente, necesitáis
un cliente tftp (con debian: apt-get install tftp ;-)), con el que transferir
en modo binario el fichero .bin que contiene el nuevo firm. Esto debe hacerse
'apuntando' siempre a la 192,168.1.1, y en los 3-5 segundos después de conectar
el aparato. A veces se resiste un poco, pero acaba saliendo. Cuando probéis
unas cuantas veces le iréis cogiendo el hilo al momento exacto en que debéis
darle al 'enter' ;-).
*********** ¿Cómo
funciona esto? ***********
(Lee esto sólo si eres una mente inquieta, te pica la
curiosidad, o simplemente tienes tiempo libre. Si no, puedes saltar al
siguiente paso).
Ésta parte tiene
mucho que ver con el famoso boot_wait. Para entender cómo funciona, hay que
entender un poco el proceso de arranque del linksys:
1.- Se
enciende el AP (si no, lo llevamos claro ;-))
2.- Se carga
la PMON (v1.x) o CFE (v2), que es como una especie de BIOS, de la primera
partición (mtd0) de la flash (ésta partición es distinta de las que os he
hablado antes).
3.- PMON
comienza a validar los datos de la nvram, que están situados en la parte final
de la flash. Si son correctos, busca la variable boot_wait. Si existe, y esta a
'on', entonces se entra en lo que podemos llamar el estado 'boot_wait'.
4.- El linksys
permanecerá en éste estado durante 3 segundos. Tras ellos, intentará cargar el
kernel. Para ello, hace un checkeo CRC al fichero .trx (contiene el kernel y el
sistema de ficheros raíz) guardado en la flash. Si supera el checkeo, el gestor
de arranque (PMON o CFE) carga el kernel y lo ejecuta. Si no, permanece en éste
estado a la espera de que le llegue un nuevo firm por tftp.
Durante esos 3 segundos, o si el CRC falla,
el gestor de arranque incorpora un mini soporte ethernet, que incluye respuesta
a broadcast arp que pregunten por su ip (192.168.1.1), y a los que responde adecuadamente,
y soporte para paquetes tftp entrantes.
Si se recibe un firmware por tftp, y supera
el CRC, el gestor lo arrancará.
Importante: el tftp en este punto es un
tftp SIN CONTRASEÑA.
5.- Si no hay
kernel panic, el kernel monta el sistema de ficheros, activa los servicios,
cede el control al busybox, y arreando ;-)
**********************************************
---> Si no os arranca:
Es que algo ha
ido mal ;-p. Error en la transferencia, kernel panic... vete tú a saber... yo ahí
me pierdo :-(
El síntoma más
característico es que el led de 'power' se queda parpadeando de una manera que podríamos
describir como 'sin sentido' o 'a lo loco', vamos, sin ningún orden.
Hay bastante
documentación por la web, de cómo recuperarse de éstas situaciones. En resumen:
- Si
activaste el boot_wait, pues vuelve a repetir el proceso.
- Si no... cachiiisss... mira que te lo
advertí!!! La cosa se complica. La única solución es intervenir quirúrgicamente de la manera que se explica en
muchos sitios como por ejemplo en
http://voidmain.is-a-geek.net:81/redhat/wrt54g_revival.html . En resumen (pero léete
el link eh!!) hay que puentear las patillas 15-16 de la flash en el momento en
que se enciende el aparato. Esto provoca la entrada del chisme en modo
failsafe, y que quede esperando a que le llegue un nuevo firm por tftp. Haz esto
en última instancia. Personalmente, yo lo tuve que utilizar y funcionó bien...
pero no mola si hay otras opciones.
PASO 3) ARRANCANDO POR PRIMERA VEZ
----------------------------------
Enhorabuena. Has pasado la parte más complicada. Ahora es
cuando vas a empezar a disfrutar, ya lo veras ;-)
Entramos por ssh, logueándonos como root, con password
"valenciawireless".
Una vez dentro, lo primero que tenemos que teclear es
"firstboot", que es un script que crea la partición rw que tan bien
nos va a venir. También crea toda la ristra de enlaces simbólicos que luego
veremos. Tras esto, debemos reiniciar el aparato tecleando "reboot".
Bueno, tras reiniciar, lo primero que se os ocurrirá a la
mayoría es que queréis cambiar la contraseña. Bieeeeennnn :-). Entramos en
harina ;-). Si lo intentáis así "a pelo" os va a dar error ya que el
fichero /etc/passwd es de sólo lectura. Por qué?? Bueno, pues resulta que para
ahorrar espacio y obtener esos maravillosos 2 megas, lo que se hace es que todo
lo que haya en /etc sean enlaces simbólicos a lo que hay en /rom/etc. En /rom
está montada la partición squashfs (lo podéis ver tecleando 'mount'), que como
recordaréis es 'sólo lectura'. Lo que hay en /rom/etc es la configuración que
trae por defecto el firmware. Qué hacemos para cambiarla? Pues fácil: borramos
el enlace simbólico del fichero que queramos cambiar, copiamos el fichero de
/rom/etc (ro) a /etc (rw), y ya podemos editarlo. Pues eso mismo hacemos con
/etc/passwd y /rom/etc/passwd. Tras ello, podremos cambiar la contraseña sin
problemas. Éste es el método que deberemos seguir con cualquier configuración
que queramos cambiar. En adelante, cuando me refiera a editar un fichero,
deberá entenderse que primero deberemos hacerlo editable repitiendo el proceso
que acabo de describir para ese fichero.
Si le echáis un vistazo a /etc, y tenéis un mínimo de
experiencia con linux, ya podréis imaginaos cómo funciona el proceso de
arranque. Todos los servicios se cargan en su correcto orden gracias al
contenido de /etc/init.d. Los script allí contenidos son de fácil lectura, y por
tanto, el proceso de arranque de fácil entendimiento ;-)
El fichero S100rc.tweek viene ya preparado para que
añadamos comandos personalizados que se ejecuten al final del arranque, aunque
también podemos añadir script S__xxxx al gusto de cada uno, así como modificar
los existentes, of course.
Nota: en /etc/conf.d/servicios tenéis la lista de
servicios que arrancará el script S50services. Podéis quitar los que no vayáis
a usar. Yo personalmente no uso el httpd. Si lo quitáis y no vais a utilizar el
servidor dhcp, os podéis saltar el primer bug que describo a continuación,
aunque al ser tan simple su solución no os lo recomiendo.
PASO 4) SOLUCIONANDO BUGS
-------------------------
- Bug del httpd:
Si así de
primeras probáis a añadir cosas a S100rc.tweak, comprobaréis que no funciona.
Es más, si os fijáis en el script S99done, veréis que se encarga de apagar el
lez DMZ. Ahora mirad dicho led: está encendido!!. El S99done viene muy bien
para saber cuándo finaliza el proceso de arranque, pero vemos que no se
ejecuta. Por qué? Bien, pues es debido a un pequeño bug en el script httpd.
Éste script se encarga de levantar el servidor web. Tras hacerlo, deja colgada
esa consola, impidiendo que se ejecuten los script posteriores al S50. Se
soluciona fácilmente añadiendo un ampersand ('&') en la línea que comienza
con start). Quedaría así "start) ${bin} ${opt} &;;". Después de esto,
al arrancar ya deberíais ver que el lez DMZ se apaga.
- Bugs del udhcpd:
Si no solucionáis
el bug anterior, al quedarse bloqueado no arrancan los servicios posteriores al
httpd, entre los que se incluye el udhcpd. Si vais a usar el ap como cliente de
otro, no os hace falta udhcpd, y podéis saltaros esto si queréis. Incluso podéis
borrar la línea "udhcpd" del fichero /etc/conf.d/servicios. Si no, sigue
leyendo ;-). En relación con el arranque del udhcpd hay dos pequeños bug.
Primero, que no comprueba la existencia de udhcpd.leases, y no arranca, y
segundo, que el script original contenido en la rom, y que hay que traerse para
modificarlo no es ejecutable. Para solucionarlo, debéis modificar el script 'de
serie' (/etc/init.d/udhcpd) por, por ejemplo, este otro, creado por Daniel
Cabezas, y sacado de la lista de openwrt-eh
(http://listas.valenciawireless.net/pipermail/openwrt-eh/2004-July/000128.html):
#!/bin/ash
srv=udhcpd
conf=/etc/udhcpd.conf
bin=/usr/sbin/${srv}
case $1
in
start)
touch /tmp/udhcpd.leases && ${bin} ${conf};;
stop)
killall $srv;;
*)
exit;;
esac
Tras ello, le hacemos ejecutable: chmod 755 /etc/init.d/udhcpd.
Con esto, y adecuando la configuración de /etc/udhcpd.conf a nuestras
necesidades, hacemos funcionar correctamente el servidor dhcp.
Nota: Éstos y otros bug a los que no me he referido los
podéis encontrar en http://wiki.valenciawireless.net/index.php/Bugs%20-%20fallos%20de%20OpenWrt-EH?PHPSESSID=b00739a70e862f52c86130082c5932d4
- Bug del bridge+modo cliente:
Parece ser que
es un fallo en el código del driver de red, que se manifiesta cuando usamos el
bridge por defecto (br0) y el modo cliente. Por tanto, esto sólo os afecta si
vais a usar el ap como cliente de otro. Los síntomas son que pese a que vuestro
linksys se asocia perfectamente al ap-master en cuestión, pero no pasa ni un
ping, o lo hace con muchísimo retardo. La solución está en romper el bridge
br0. Para mí, la solución más fácil es dejar que lo hagan todo los script de
arranque, los cuales configuran la red en función de los valores contenidos en
la nvram. Por ello, vamos a ver las modificaciones que serian necesarias:
Nota: lan_* hace
referencia bien al bridge(br0=4switch+wifi) o bien a los 4 puertos del switch
solamente-
(V2)
lan_ifname=vlan0 (Con esto ya le decimos que no forme un
bridge, por defecto viene a br0)
lan_proto=static
lan_ipaddr=192.168.2.1
lan_netmask=255.255.255.0
lan_gateway
(ip del default gateway. No es necesario. Sólo debe ir relleno en una
interfaz)
wifi_proto=static
wifi_ifname=eth1
(en V2, eth2 en V1.1)
wifi_ipaddr=192.168.4.2
wifi_netmask=255.255.255.0
wifi_gateway=192.168.4.1 (ejemplo con default gateway
asociado a la interfaz wifi)
(V1.1)
lan_ifname=vlan2 (Con esto ya le decimos que no forme un
bridge, por defecto viene a br0)
lan_proto=static
lan_ipaddr=192.168.1.1
lan_netmask=255.255.255.0
lan_gateway
(ip del default gateway. No es necesario. Sólo debe ir relleno en una
interfaz)
wifi_proto=static
wifi_ifname=eth2
(eth1 en V2, eth2 en V1.1)
wifi_ipaddr=192.168.4.1
wifi_netmask=255.255.255.0
wifi_gateway=192.168.4.1 (ejemplo con default gateway
asociado a la interfaz wifi)
Con esto, y tras reiniciar el aparato, habremos perdido
el interfaz br0, pasando a disponer de dos nuevos (y 100% funcionales)
interfaces: vlan0(v1) o vlan2(v2), que hace referencia a las 4 bocas del switch
y eth2(v1) o eth1(v2) para la interfaz wifi.
Nota: - para
mostrar una variable de la nvram usamos #nvram show variable. Ej:#nvram show
lan_proto (devuelve static)
- para anotar
una variable e la nvram usamos #nvram set variable. Ej:#nvram set
lan_proto=statc (no olvidéis el '=')
- para mostrar
todas las variables de la nvram usamos #nvram show
- para guardar
de forma permanente los cambios realizados usamos #nvram commit
Nota: La nvram
del openWRT es mucho más reducida que la usada en otros firm del tipo
"plug & play". Esto es debido a la existencia de la partición
jffs2 que permite cambiar las configuraciones con los script de inicio. Sin
embargo, es posible configurar ip's, essid, rutas, etc, a través de la nvram y
los script de inicio (quienes a su vez leen la nvram). En
http://www.openwrt.org/OpenWrtNVRAM tenéis la descripción de las variables
nvram de las que hace uso openWRT, y por tanto openWRT-EH. Yo personalmente
creo que en general es mas sencillo añadir configuraciones personalizadas en
los script de inicio, sin tocar la nvram, pero para gustos colores ;-)
PASO 5) CONFIGURACIONES SENCILLAS
---------------------------------
Nota: en openWRT-EH van incluidas las wireless-tools. Por
tanto, ya no es necesario usar el comando wl para la mayoría de los cambios
relativos al wifi. Por ejemplo:
#wl ap 1
#wl ssid redlibre
#wl rts 256
Puede ser sustituido por:
#iwconfig eth2 mode master essid redlibre rts 256 (usad
eth1 si es una v2)
*** COMO MASTER:
Sencillísimo (podríamos añadir estas líneas a un script
de inicio):
iwconfig eth2
mode master essid tu_essid (eth1 en los v2)
ifconfig br0
ip.del.interfaz.wifilan netmask la.mascara.de.subred
ifconfig eth1
ip.del.interfaz.wan netmask yyy.yyy.yyy.yyy (vlan1 en v2)
Y si queremos que asigne ip's, pues modificaríamos el
/etc/udhcp.conf a conveniencia. Por
ejemplo:
max_leases 200
start 192.168.1.20
end 192.168.1.250
interface br0
lease_file /tmp/udhcpd.leases
domain lan
pidfile
/tmp/udhcpd.pid
option dns
192.168.1.1
option subnet
255.255.255.0
option router
192.168.1.1
lease 7200
... esto comenzaría a asignar ip's dinámicas a partir de
la 192.168.1.20 y hasta la 192.168.1.250, con la máscara 255.255.255.0, default
gateway apuntando a 192.168.1.1, al igual que el servidor dns. Fácil no? ;-)
*** COMO CLIENTE:
Añadiríamos a un script de inicio, por ejemplo:
iwconfig eth2 mode managed essid essid_al_que_asociarse (ya no hace falta usar 'wl join essid')
ifconfig eth2 aaa.aaa.aaa.aaa netmask bbb.bbb.bbb.bbb
(interfaz wifi, usa eth1 en v2)
ifconfig eth1 ccc.ccc.ccc.ccc netmask ddd.ddd.ddd.ddd
(interfaz wan, usa vlan1 en v2)
ifconfig vlan2 eee.eee.eee.eee netmask fff.fff.fff.fff
(interfaz lan=switch, usa vlan0 en v2)
PASO 6) IPKG
------------
Es posiblemente lo que más me llamó la atención. Para los
que usáis Debian, esto os sonará mucho;-). ipkg es una herramienta para la
gestión de paquetes para el linksys, al estilo de apt. Hay ya muchos paquetes
preparados para su uso, y otros que vendrán. Los paquetes disponibles en el
repositorio de valenciawireless los podéis ver en
http://www.valenciawireless.net/ipkg. Su uso es sencillísimo:
- Para actualizar la lista de paquetes disponibles teclea
#ipkg update (debes tener conexión a internet, el repositorio utilizado por
defecto es el de valenciawireless, pero puede cambiarse en /etc/ipkg.conf)
- Para listar los paquetes disponibles: #ipkg list
- Para instalar un paquete: #ipkg install
nombre_del_paquete . Ej: #ipkg install kismet
- Para ver todas las opciones, simplemente teclea #ipkg
;-)
--------------------------------------------------------------------------------DISCLAIMER:
La información
aquí recogida está basada en mi propia experiencia, y en datos recopilados por
distintos foros y listas de correo accesibles a través de internet. Aunque todo
lo aquí expuesto ha sido probado personalmente por mí, no garantizo que
funcione bajo cualquier circunstancia ni cualquier aparato. Es más, no me
responsabilizo de los daños que puedas ocasionarle a tu aparato.
Para cualquier duda o sugerencia, puedes contactar conmigo en ivan @ forcada.info
Iván Forcada, 15/11/2004
--------------------------------------------------------------------------------***TODO:
- Añadir info sobre wds (cuando
tenga tiempo para probar :-(). Si alguien se anima, toda info será bien
recibida ;-)