Comprobando La Fonera he encontrado que fon está actualizando los firms para corregir cosas como por ejemplo, el bug de los mil servidores ntp en el inicio. También actualiza el interprete cgi-web (haserl) y algunas de las páginas web.

Además han añadido un script nuevo llamado validate.awk (/usr/lib/webif) que contiene (entre muchas cosas) lo siguiente:

if ( $0 ~ /\|@$|['`"$%&()]/ ) {
valid = 0
verr = “@TR<<>>”
}

Estre trozo de código fija válido a cero si encuentra cualquiera de los símbolos que están definidos en la condición, lo que seguramente sea una forma de corregir los numerosos bugs de la interfaz web que existían hasta ahora.

Ademas en el mismo script también hay una verificación específica por cada campo que se haye en las páginas actualizadas.

Resumidamente, esta actualizacion de tipo parche parece ser tan solo para corregir bugs anteriores no añadiendo ninguna funcionalidad nueva a nuestra fonera.

Al parecer el programa ipkg de La Fonera está de alguna forma corrupto (o quizas intencionadamente manipulado, who knows).

Según he podido experimentar, el programa ipkg es capaz de instalar correctamentelos paquetes que le demos en nuestra fonera, pero si usamos remove para eliminar algún paquete instalado, no se sabe como ipkg acaba eliminando el directorio /usr/bin de un plumazo y sin parpadear.

Realmente no es un problema excesivamente grave ya que si reiniciamos la fonera a fábrica (bien eliminando /jffs bien pulsando durante 15sec el botón reset) el directorio /usr/bin volverá a su sitio sin mas problemas que reconfigurar la fonera a como la teníamos.

Como consejo, siempre que se pueda evitar usar ipkg remove.

Como al final acabamos confundidos con la memoria flash y como va distribuida, voy a exponer un análisis para explicar la constitución y particion de la misma.

Cualquiera que tenga una fonera abierta puede ver lo siguiente escribiendo dmesg:

MTD driver for SPI flash.
spiflash: Probing for Serial flash …
spiflash: Found SPI serial Flash.
8388608: size
Creating 8 MTD partitions on “spiflash”:
0×00000000-0×00030000 : “RedBoot”
0×00030000-0×00720000 : “rootfs”
0×001c0000-0×00720000 : “rootfs1″
0×00720000-0×00730000 : “config”
0×00730000-0×007e0000 : “vmlinux.bin.l7″
0×007e0000-0×007ef000 : “FIS directory”
0×007ef000-0×007f0000 : “RedBoot config”
0×007f0000-0×00800000 : “board_config”

Según la cuarta linea de este paste la fonera dispone de 8388608 bytes de espacio (exactamente 8Mb) y leyendo la quinta linea vemos que está particionada en 8 dispositivos mtdX donde:

• mtd0: Tiene 196608 bytes (192Kb) que ocupa desde la posición 0×00000000 hasta la posición 0×00030000 y está etiquetada como “RedBoot” que es el bootloader de la fonera.
• mtd1: Tiene 7274496 bytes (6.93Mb) que va desde la posición 0×00030000 hasta la 0×00720000 y está etiquetada como “rootfs”. Aqui se guarda el sistema de archivos inicial (raiz).
• mtd2: Tiene 5636096 bytes (5.37Mb) que va desde la posición 0×001c0000 hasta la 0×00720000 y está etiquetada como “rootfs1″. Contiene los cambios que realizamos en la fonera y se monta en /jffs.
• mtd3: Tiene 65536 bytes (64Kb) que va desde la posición 0×00720000 hasta la 0×00730000 y está etiquetada como “config”. Este espacio realmente está en blanco, solamente contiene ‘1337′ en los dos primeros bytes (7 ascii).
• mtd4: Tiene 720896 bytes (704Kb) que va desde la posición 0×0073000 hasta la 0×007e0000 y está etiquetada como “vmlinux.bin.l7″. Contiene el nucleo linux.
• mtd5: Tiene 61440 bytes (60Kb) que va desde la posición 0×007e0000 hasta la 0×007ef000 y está etiquetada como “FIS directory”. Parece contener información sobre el particionado de la flash.
• mtd6: Tiene 4096 bytes (4Kb) que va desde la posición 0×007ef000 hasta la 0×007f0000 y está etiquetada como “RedBoot config”. Contiene la configuración del bootloader ReedBot.
• mtd7: Tiene 65536 bytes (64Kb) que va desde la posición 0×007f0000 hasta la 0×00800000 y está etiquetada como “boad_config”. Aqui podemos encontrar la configuración general de la placa y cosas como el número de serie, las direcciones mac, etc.

Como se aprecia, rootfs y rootfs1 comparten espacio desde la posicion 0×001c0000 hasta la 0×00720000 (/jffs). Esto nos deja solamente 0×001c0000 – 0×00030000 de espacio para el sistema de archivos rootfs (1638400 bytes o 1.56Mb). Si es superado ese espacio con una imagen de sistema de archivos (como ha sido mi caso, la superé por unos cientos de Kb por el modulo cifs.o) pasa esto:

root@fonera:~# du -sh /jffs/
12.5k /jffs
root@fonera:~# df -h
Filesystem Size Used Available Use% Mounted on
none 7.0M 52.0k 6.9M 1% /tmp
/dev/mtdblock/2 5.4M 332.0k 5.1M 6% /jffs

Es decir, a pesar de que /jffs no ocupa mucho, df nos dice que si porque parte de la memoria está siendo usada por la imagen excesivamente grande que puse, lo que me lleva a pensar que hay de capacidad hasta 6.9 megas para poner nuestra imagen, pero que agotaríamos así la capacidad de /jffs impidiendo poder realizar cambios, así que preferiblente es mejor no execeder esos 1.56 megas para el sistema de archivos inicial.

Pues bien, como estaba cansado de que cada vez que volvia la fonera a su estado inicial de fábrica tenía que usar los metodos anteriormente descritos para abrir el acceso a la misma, he decidido flashearla con mi propio sistema de archivos en el que ya lleva varias cosas tocadas:

• Abre los puertos 22 y 80 tanto en la wifi como en la lan.
• Ejecuta dropbear al inicio.
• El thinclient funciona, pero está ‘capado’ para que no ejecute los shellscripts que se baje. Clasifica los mismos según hora y dia y no guarda dos shellscripts identicos para evitar que llene la memoria de basura.
• Corrige el bug de la versión 0.7.1.1 consistente en que el script N45ntpclient se añade de forma constante en el crontab.

La imagen en cuestion se puede descargar de aqui ya preparada para ser flasheada de la siguiente forma desde la fonera:

# mtd write karman.fon.rootfs.squashfs rootfs

Esperar a que acabe y muy importante, no cortar el programa bajo ningun concepto. Cuando haya acabado, reiniciar el router y esperar que arranque.

Nota: A mi esta imagen me ha funcionado perfectamente y es la que uso en todas mis foneras. En cualquiera de los casos no me hago responsable si por cualquier razón no funcionase.

Para aquellos valientes que quieran añadir/modificar/quitar cosas del sistema de archivos raiz, he creado un método con el que construir una imagen squashfs propia y customizada para la fonera descargable desde aqui.

El espacio en memoria para rootfs segun /proc/mtd es de 7274496 bytes (lo que vienen a ser 7.1Mb) así que no recomiendo flashear ninguna imagen de sistema de archivos mayor a dicho tamaño.

Debido a que la fonera no tiene casi espacio para hacer experimentos, me he visto obligado a montar un disco duro en red que me proporcione mas espacio.
En realidad se trata de un recurso compartido de windows en un servidor linux con samba.

Para conectar la fonera a dicho recurso es tan fácil como copiar el módulo cifs.o en la carpeta /lib/modules/2.4.32 y luego ejecutar:

root@OpenWrt:~# mount -t cifs //laipdelserver/recurso /mnt/netdisk -o unc=\\\\laipdelserver\\recurso,ip=laipdelserver,user=usuario,pass=contraseña,dom=grupotrabajo

Sustituyendo laipdelserver por la ip del servidor en donde se encuentre el recurso compartido, recurso por el nombre del recurso compartido, usuario por el nombre del usuario que tenga permisos para dicho recurso, contraseña por la contraseña de dicho usuario y grupotrabajo por el grupo de trabajo en el que está configurado el servidor, y asegurarse de que el punto de montaje (ej. /mnt/netdisk) exista.

Si diese algún error, probar insmod cifs.