Reviviendo un Linksys WRT54GL brickeado
Mi WRT54GL dejó de responder por WiFi, y al intentar limpiar la NVRAM, lo brickié.
Este es un registro de todo lo realizado para volverlo a la vida, ¡exitosamente!
Espero que sirva de ayuda a otros con el mismo problema.
Los desesperados con power parpadeando y demás luces encendidas fijas
pueden ir directo a las
conclusiones.
Cuando compré mi primer notebook a comienzos de 2008,
se hizo necesario poner WiFi en la casa.
Hasta ese momento, todos mis equipos estaban conectados a una red local
usando como router/firewall un modem ADSL Arescom 1000,
capaz de hacer NAT, DHCP, etc.
junto a un miniswitch de 5 bocas,
configuración suficiente para la mayoría de las cosas que realizaba,
incluyendo compartir la impresora y, especialmente, P2P con Bit Torrent.
No quería alterar mucho mi LAN, por lo que investigué un poco... ¡un buen poco!
Había reportes en la web mencionando que varios de los equipos disponibles a la fecha
se bloqueaban con los P2P, debido a que se les llenaba algún buffer (DNS o algo así),
y era rutina tener que reiniciarlos semanalmente o inclusio diariamente.
Llegué a la conclusión que la mejor opción era elegir un equipo al que le pudiera
instalar DD-WRT, y el más apto para ello era el Linksys WRT54GL (CL7C).
Lo busqué en el comercio local... y lo encontré!!!
No era el más barato, pero tampoco estaba tan caro.
Me hice el hara-kiri simplemente por la relación precio/calidad, porque daba buena señal
y porque no quería estar lidiando con bloqueos ni resets periódicos.
Lo primero que hice después de comprarlo fue ponerle DD-WRT,
lo configuré como AP y con él reemplacé el miniswitch.
Mi red local no notó cambio alguno, y el notebook estaba feliz por no estar atado
a un cable de red de unos 8 metros de largo.
Sin embargo, mi paranoia hizo que configurara la seguridad WiFi al máximo,
incluyendo SSID oculto y filtrado por mac address.
En algún momento tuve que actualizar el firmware.
No recuerdo si fue cuando murió mi notebook y lo reemplacé por otro,
cuando cambié mi teléfono por un smartphone,
cuando cambié el modem ADSL por Cable, o qué,
pero el firmware del momento para DD-WRT era el build 13064,
y con ese estuvo hasta hace unos días, cuando...
No sé si fue a raíz de un corte de luz a media mañana
(cuetazo con salto de automáticos),
pero coincidentemente esa tarde noté que no tenía señal WiFi en mi teléfono.
Revisé con el notebook y éste tampoco lograba detectar la red.
Mi primera acción fue desenchufar el router por algunos segundos y rebootearlo,
pero pasados unos 5 minutos, seguía sin poder detectarlo.
Recurrí al cable de red auxiliar para llegar del PC directo al router,
y vi que su interfaz web respondía bien, así que ingresé usando las credenciales.
Después de navegar un poco, noté en el estado de la funcionalidad wireless
que los paquetes transmitidos exitosamente eran cero (TX 0 OK)
y lo errores eran muchos, es decir, la tasa de transmisión OK era 0%.
Comencé a investigar y no tardé en darme cuenta que era un problema ya reportado,
relativo a algún tipo de corrupción de la NVRAM del router,
probablemente asociado a funcionalidades de seguridad WiFi:
si dehabilitaba la seguridad, los dispositivos wireless se podían conectar,
pero el router desaparecía nuevamente al habilitarla.
No quise realizar el reseteo 30/30/30,
simplemente porque me daba lata tener que reconfigurar todo
a como lo tenía, dando buen servicio al resto de la red local.
NOTA: El hard reset 30/30/30 borra la NVRAM del router,
dejando DD-WRT con los valores de configuración iniciales.
Consiste en
presionar el botón de reset por 30 segundos mientras el router está encendido,
luego desconectar la alimentación sin soltar el reset y esperar otros 30 segundos,
para finalmente volver a enchufar el router y esperar 30 segundos más
antes de soltar ese botoncito.
Es decir, el botón de reinicio se mantiene presionado por un minuto y medio,
por lo que recomiendo hacer presion con algo cómodo de tomar y que no canse,
como una tapa de lápiz BIC.
Intenté algunos comandos vía TELNET para limpiar la NVRAM,
sin saber exactamente qué se vería modificado en el router,
pero parecían no afectar en nada la operación del equipo,
pues cada vez que habilitaba la seguridad,
aparecían otra vez mis credenciales wireless.
Fui probando diversos comandos que iban apareciendo en distintos blogs
o foros en el sitio de DD-WRT, pero siempre lo mismo, ¡nada!
hasta que di con uno que tomó demasiado tiempo en responder
(no voy a poner aquí cuál fue para que no cometan el mismo error en el copy&paste).
Lo primero que noté fue que la interfaz web del router
perdió las plantillas de diseño: todo se veía en HTML puro
y algunas funcionalidades dejaron de operar, como el refresco en el estado.
Aquí ocurrió lo que más temía:
al reiniciar el router, la luz de power no dejaba de parpadear
y las 5 luces LAN+WAN quedaban permanentemente encendidas.
¡El WRT54GL estaba brickeado!
Revisando experiencias similares en la red, se confirmaba esta afirmación,
aunque de acuerdo a algunos, existía la esperanza de revivirlo,
y el método a seguir dependía del comportamiento de las luces
y de su respuesta a los PING.
Pero en mi caso, sólo veía el mismo comportamiento en las luces
y los PING no tenían respuesta.
Ni siquiera un reset 30/30/30 logró sacarlo de ese estado.
El firmware estaba corrupto y ni un TFTP con un firmware base
servía al no haber PING.
Encontré algunas referencias a que se habían reportado algunos éxitos
para que un router Linksys (otro modelo) comenzara a responder los PING
mediante el puenteo de un pin 16 de cierto chip con la tierra (GND)
mientras se encendía el equipo.
Esto implicaba abrir físicamente el router y ver si identificaba el mencionado chip.
El WRT54GL está armado a presión, es decir, no tiene tornillos,
por lo que no se requiere ninguna herramienta especial para abrirlo,
excepto en algunas unidades de fabricación más reciente
que incluían un par de tornillos bajo las gomas delanteras (no era mi caso).
El problema es identificar por dónde comenzar a tironear.
Encontré una secuencia de fotos en que se mostraba paso a paso
lo que había que hacer para acceder a la placa,
pero de todos modos los plásticos sufrían y se dañaban seriamente.
Sin embargo, esas mismas fotos me dijeron dónde estaban los seguros
y pude deducir dónde presionar y tirar:
-
Desconectar todos los cables y remover las antenas.
-
Cortar la etiqueta de garantía ubicada por debajo,
adherida en una juntura entre las piezas azul y negra de la cubierta.
-
Presionar simultáneamente la parte negra de la cubierta junto
a la pestaña azul, a cualquiera de los dos lados,
tanto por arriba como por abajo, de modo que la pestaña quede al aire,
y mantener ahí.
-
Presionar por el costado negro haciendo harta fuerza en dirección a la pestaña,
la cual ya no molestará al estar a otro nivel respecto de la cubierta negra,
y mantener también ahí.
-
Empujar la cubierta azul hacia fuera por el costado donde se está presionando,
usando la estructura de las patas como apoyo.
Debiera ser posible desplazarla unos 5 mm,
suficiente para anular el enganche y dejar de hacer presión.
-
Continuar abriendo en ángulo y remover la máscara azul por completo.
-
Deslizar un poco la base y separarla en ángulo de la cubierta.
En alguno de los foros leí una idea creativa:
gastar un poco los ganchos de la cubierta,
de forma que si se desea abrir nuevamente, el esfuerzo sea menor.
Yo opté por no hacerlo...
A pesar de todo el polvo acumulado por años, pude identificar el chip.
No era el mismo que había visto en fotos con el truco del pin 16,
ni tampoco estaba ubicado en el mismo lugar de la tarjeta.
No era INTEL, sino que estaba etiquetado como EON EN29LV320B.
Me llamó la atención que la placa tenía múltiples contactos
numerados del pin 1 al 24 y del pin 25 al 48 en esa misma ubicación,
posiblemente para poner diversos chips compatibles, pero de distintos tamaños.
Lo realmente relevante es que pese a que son contactos relativamente pequeños,
están marcados los múltiplos de 5 en la placa,
por lo que era fácil reconocer el número 16.
El paso siguiente fue conectar el router a un PC con IP estática 192.168.1.5
(en vez de 5, se puede poner cualquier número mayor que 1).
En el PC hay que abrir una ventana de comandos e ingresar "ping -t 192.168.1.1".
La respuesta del comando es un mensaje indicando que no puede llegar al router,
y que se repite al infinito,
pues el router está apagado (desenchufado de la red eléctrica).
Aquí vino la parte complicada: había que encender el router al mismo tiempo
que se hace un puente entre el pin 16 (y ninguno otro) y la tierra,
la que se encuentra por ejemplo en el bloque metálico de la antena que tiene
un cable blindado hacia el otro costado.
Yo utilicé el cable de un tester o multímetro, ya que es fácil de sostener,
y con un trozo de cable de cobre en el otro extremo para anclarlo a
la masa de la antena.
No crucé los dedos ni cerré los ojos,
ya que necesitaba máxima concentración y luz sufuciente
para sostener la punta de medición justo sobre el pin 16,
al tiempo que insertaba el cable de alimentación.
Justo después de encenderse, antes de los 2 segundos,
ya se habían apagado las luces fijas,
y sólo se mantuvieron encendidas y parpadeando irregularmente
la de poder y la correspondiente a la boca conectada al PC.
Ya se podía liberar el puente del pin a tierra.
Por el lado del PC, el PING comenzó a dar éxitos:
el router estaba respondiendo a los 100 ms.
¡Revivió!
Realicé un reseteo 30/30/30, pero en la fase de encendido
me di cuenta que volví a la situación original de los LEDs.
Repetí el proceso de encendido con el pin 16 cueteado a tierra.
Esta vez, sin apagar el router, le envié el firmware oficial usando TFTP.
¡Exito! ¿Veamos? Un reseteo
(obligatorio antes y después de aplicar cualquier upgrade de firmware)
me mostró que el problema persistía: luces fijas y power parpadeando.
Intenté nuevamente usando firmwares de DD-WRT especiales para pasar por TFTP,
pero no lograba pasar el reinicio. Siempre llegaba a lo mismo,
y el PING dejaba de responder. Normalmente se encendía además la luz ámbar.
Buscando alternativas o explicaciones en la red,
me llamó la atención un artículo que mencionó que posiblemente
su fuente de poder podría estar dañada y entregando menos energía a la placa,
obteniendo un firmware corrupto a pesar de ser notificado un éxito en TFTP.
Revisé mis cachureos y encontré la fuente de un grabador externo de DVD
que entrega el doble del amperaje que la fuente original,
pero con el mismo voltaje, polaridad y conector. Llegar y usar.
Repetí el procedimiento de encendido con pin 16 cuetiado usando la nueva fuente.
Apenas se apagaron las luces, liberé el pin y envié el firmware oficial
usando TFTP.
Después de un momento, la luz ambar se encendió y volvió a responder el PING.
No recuerdo si en esta oportunidad alcancé a hacer el reset 30/30/30,
pero noté que la interfaz web oficial también respondía,
y podía navegar por ella identificándome con el usuario en blanco y la contraseña "admin".
Para estar seguro, volví a realizar el 30/30/30,
ingresé a la opción de administración del menú y
cargué el firmware micro más reciente de DD-WRT.
Reconocí su interfaz web apenas me pidió que cambiara usuario y contraseña.
Luego, repetí el procedimiento para cargar un firmware mini
(no el "mega" porque no cabe en la memoria flash del WRT54GL).
Configuré el router como access point,
le cambié la IP a 192.168.1.2 (porque así estaba antes, ya que el modem Arescom tenía la .1),
le cambié el canal a uno menos usado,
le puse mi SSID de siempre,
le habilité la seguridad (con mis credenciales originales),
y revisé mi smartphone para ver si detectaba la red. ¡Tenía WiFi!
La última prueba:
Desconecté la alimentación al router y le conecté su fuente original.
Partió sin problemas.
Ya podía armar el router nuevamente,
poniendo las piezas plásticas en su lugar
y conectando sus antenas.
Una nota adicional:
Algunos de estos cambios requirieron rebooteo automático del router,
lo cual no sucedía.
La interfaz web se quedaba pegada y debía refrescar o volver atrás.
Al revisar los parámetros, todo estaba en los valores por defecto.
Ésta fue una mala jugada del navegador que utilizaba...
aparentemente su caché recordaba ciertas cosas que inhabilitaban
la operación normal,
probablemente por tener muchas pestañas abiertas para recordar los
parámetros que estaba usando.
Simplemente cerrando el browser y abriéndolo nuevamente,
pude reconfigurar.
El router Linksys realmente es un die-hard.
La relación precio/calidad se nota.
El resumen del procedimiento por el camino feliz sería:
- Bajar:
- Utilitario TFTP.
- Firmware oficial de Linksys para el router.
- Firmware versión micro de DD-WRT (opcional pero recomendado).
- Firmware versión mini apropiada de DD-WRT (opcional pero recomendado).
- Utilizar una fuente de poder de 2000 mA (el doble de la normal).
- Abrir el modem y ubicar el pin 16 del chip de memoria flash.
- Conectar el router a un PC con IP fija 192.168.1.5.
- Encender el router mientras se hace un puente entre el pin 16 y la masa de la antena.
- Enviar el firmware oficial Linksys al router con TFTP a la IP 192.168.1.1.
- Realizar reseteo 30/30/30.
- Si se desea, aplicar posteriormente el firmware micro usando la interfaz web del firmware original
y luego uno mejorado de DD-WRT usando la interfaz de la anterior.
- Después de reconfigurado, volver a usar la fuente original.
Revisé demasiadas páginas de los foros de DD-WRT, blogs
y otras publicaciones con información relacionada a mi problema,
así que poner aquí la lista de enlaces de mi historial de navegación
sólo llevaría a entregar horas de lectura sin encontrar nada nuevo.
También sería injusto para algunos autores que publique las páginas de otros...
mejor no pongo ninguno!!!
De todas maneras, Google es un buen aliado para buscar información específica.
Sé que tampoco es buena idea poner enlaces a firmwares específicos,
pues siempre están apareciendo versiones actualizadas, sin bugs reportados.
Sin embargo, dejo documentado lo que utilicé para mi caso,
por si cometo nuevamente el error de transformar mi router en un ladrillo.
Todo lo anterior es sólo para mi router Linksys WRT54GL (CL7C).
Copyright © 2013 por
Víctor Parada
(++Vitoco)
- Creado el 2013-09-15 - Actualizado el 2013-09-17
