Fonera Reseteada

Finalmente el firmware kamikaze 7.07 que le instalé a la fonera no soluciono mi problema. Al pasar un día dejó de responder igual que con el 7.09, por lo que me mosqueó que pudiera tener algún fallo de hardware, ya que no encontré a nadie que se quejara de algo así por Internet. Mirando en la página de fon me dí cuenta de que esa fonera era la que había dado de alta, así que decidí reinstalar el firmware original de fon version 0.7.1.1, para tener un linux operativo y a la vez colaborar con fon, pues es lo minimo que puedo hacer despues de que me hayan regalado los routers. Hasta ahora lleva un record de 4 dias de uptime sin cuelgues (a los 4 días la tuve que cambiar de enchufe), y tiene pinta de ser estable.

Una vez con la fonera controlada me dio por coger la que estaba bloqueada. Había activado el ssh muchos meses atrás para trastear con ella. Por supuesto, desactivé la autoactualización para que fon no trasteara con ella. Y como suele pasar, tras un par de meses sin entrar se me olvidó la contraseña. El método normal para cambiar la password era a través de la página de fon (aotuactualización), por lo que no iba a funcionar. La otra opción era darle al botoncito de reset de debajo, pero no parecía funcionar. El funcionamiento del reset es muy curioso ya que lo que hace es tocar es sistema de ficheros.
La fonera de serie (y luego con Kamikaze también) trae dos "particiones" de la flash. La primera es de solo lectura y está comprimida (squashfs) y es lo que hay de inicio en el firmware. Más tarde, toda la flash que no ha sido utilizada para la imagen raíz se queda como disponible, con el sistema de archivos jffs2. Cuando la fonera arranca, monta la parte squashfs en /rom y la jffs2 en /jffs.

root@mercury_friendship:~# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /dev type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mtdblock3 on /jffs type jffs2 (rw)
mini_fo:/jffs on / type mini_fo (rw)

Por último para el sistema raíz / usa mini_fo, una combinación sobre la marcha de ambos sistemas de ficheros: si algo está en jffs lo lee de ahí, y si no lo busca en rom, de manera que se puede "modificar" los ficheros de la rom creando un fichero con la misma ruta en jffs, ya que este archivo se leerá antes.
Sabido esto, lo que pasa al darle al boton reset, es que la fonera borra todo el contenido de la parte jffs, quedando por tanto sólo la parte rom, que contiene el estado original del sistema.

Pues en mi caso por desgracia esto no pasaba. En teoria debería arrancar tal como llegó de fon, con el firmware hackeable, contraseña por defecto y el ssh capado, pero no ocurría esto, arrancaba como si nada. Despues de probar todos los métodos posibles (al arrancar 5 segundos, durante todo el arranque, ya encendida, en dos arranques seguidos, etc.) llegué a la conclusión de que algo no funcionaba bien así que qué mejor que destriparla y mirar. Y ya que no se veía nada raro, caí en que quizá el propio botón de reset estaba estropeado y rescaté una placa de prácticas de electrónica de hace unos años para voler a sacarle partido, con este resultado:

Montaje de los cables

El CD está para poder ver qué luces están encendidas, ya que los leds quedaban mirando hacia abajo y no podía darle la vuelta ya que los cables no estaban soldados a la fonera.


Un poco más cerca:

Como se puede ver es bastante sencillo, dos cables y un pulsador externo. Podría haber hecho simplemente "un puente" pero así es bastante más cómodo.

Con el montaje del pulsador externo el reseteo funcionó a la primera, pulsandolo un ratito mientras arrancaba, luego ya solo quedó abrir ssh, cambiar kernel e instalar una versión nueva de OpenWrt. Aunque para mi disgusto, siguió dando error.

Por suerte, esta vez he descubierto que no soy el único al que le da este error. El problema reside en que el módulo madwifi del kernel y el hostapd comparten alguna porción del código y si se usan versiones de distintas fuentes el resultado no es muy bueno. En caso de la fonera el problema está en que usaba el kernel 2.6.23.1 del 3 de diciembre pero el directorio packages de ese kernel sólo tenía 15 o 20 paquetes ipk, y el hostapd no estaba entre ellos, así que use los ipk del directorio del kernel del 3 de octubre. Así que o bien uso un kernel más antiguo (con sus posibles cuelgues), espero a que el tío que lleva esa página saque más paquetes para el 2.6.23.1 (que no tiene pinta) o bien lo compilo yo solito, que va a ser la solución. Pero eso lo dejo "para después de la publicidad".

Un saludo!