Como arreglé los problemas de conexión de mi ADSL de Kolbi ICE

Desde hace rato vengo teniendo problemas con mi conexión ADSL Kolbi, del Instituto Costarricense de Electricidad (ICE). El problema es el mismo siempre: aleatoriamente, el modem se desconecta del servicio. La señal del ADSL sigue llegando al modem (la luz ADSL sigue verde), o sea no hay un fallo en la línea telefónica en sí, pero algún problema de comunicación existe que hace que se pierda el acceso. De repente la luz de Internet se pone roja, y hasta ahí llegó todo. La única alternativa que queda es apagar y volver a encender.

Como pueden imaginarse es algo frustrante llegar a las 6 horas de haber iniciado una descarga, para descubrir que a medio camino el ADSL falló y todo se fue en cero.

El modem en cuestión, es un Pirelli A115, de los blancos que traen el logotipo del ICE impreso en la tapa:

Un Pirelli DRG A115, los del ICE tienen el logo estampado en la tapa.

Hasta el momento el problema lo había tratado de resolver con soporte del ICE, civilizadamente, como cualquier otro cliente. Con el resultado obvio: después de múltiples visitas, de escuchar varias veces “ya quedó solucionado el problema”, al poco tiempo de nuevo estaba sin internet. Y no había posibilidad de hacer nada excepto llamar a soporte de nuevo, porque los técnicos de TenT (el subcontratista que ve los problemas técnicos del ICE) habían dejado bloqueado el acceso al modem, con una contraseña que solo ellos tienen. Por lo que solo ellos podían ver la información de diagnóstico interna del modem y llegar a sus propias conclusiones.

Afortunadamente hace unos días encontré un modem ADSL desocupado por otro cliente en una venta de garaje. Lo cual me permitió hacer algunos experimentos y diagnósticos interesantes.

Y por qué simplemente no le hice factory reset a mi modem viejo? Porque resetearlo hubiera implicado quedarme del todo sin acceso a Internet, sin respaldo. Y si no resultaba la configuración del modem nuevo, estaba en problemas.

Configurar el modem nuevo para que funcionara no fue tan complicado (en otro post hablaré de cómo se hace la configuración en un servicio residencial). Sí fue necesario recurrir a soporte técnico del ICE (1119), pero afortunadamente cuando les conté que era que tenía otro modem que un cliente había desechado, y que estaba viendo si solucionaba un problema de conectividad, me ayudaron a configurarlo por teléfono.

Lo primero que me dí cuenta es que en el ICE habían cambiado mi usuario y contraseña sin avisarme. Los modem ADSL requieren un usuario y contraseña para entrar a la red del ICE. Los que me habían dado hace un par de años, ya no servían. No me dijeron por qué el cambio de usuario/contraseña, pero me suena a que probablemente hicieron un cambio en la infraestructura de red, que implicó trasladarme a otro punto de acceso. Eso explicaba por qué mi modem nuevo no conectaba. Una vez que le puse el user/pass que me indicó el de soporte, logró entrar a la red y funcionar.

Los modem ADSL del ICE funcionan con autenticación tipo CHAP o PAP. Es un proceso bastante simple: el modem hace un broadcast por la red para encontrar el punto de conexión que le toca, se conecta, y se autentica. Y si todo anda bien, el punto de conexión le hace el trámite DHCP, le pasa un Gateway y DNS, y empieza a funcionar internet.

Ya teniendo el modem nuevo en funcionamiento, le habilité las bitácoras internas para ver qué estaba pasando en detalle. Y le habilité la opción de que escribiera a la bitácora el intercambio de autenticación PPP al conectar, lo cual sería muy útil posteriormente:

(La opción se encuentra en el menú de WAN, dentro de las opciones de autenticación del interface)

Unas 24 horas después de haber puesto a trabajar el modem nuevo, perdió la conexión, igual que el anterior. Lo cual sugiere que el modem en sí está bien (ya son 2 modem distintos que dieron el mismo problema), no es un problema de que la unidad esté dañada.

Revisando los logs del modem, encontré algo interesante:el problema aparentemente inicia del lado del ICE. El sistema del ICE bota la conexión, y cuando el modem trata de reconectar, el ICE le niega el acceso. Aunque el modem se vuelva a autenticar correctamente, el punto de conexión no le permite acceso. Y ahí es donde el modem se queda perdido, sin saber qué hacer.

Extrañamente si el modem se reinicia, la autenticación funciona sin problemas. Probablemente sea que al reiniciar, el modem encuentra otro punto de acceso que no es el que tenía anteriormente.

Muy importante: en ningún momento el modem perdía la capacidad de administración remota. Lo único que se afectaba es la autenticación en la red, pero el resto de las interfaces del modem siguen funcionando normalmente. Eso fue crítico en este caso para poder solucionar el tema. Si tienen un modem que además de la conexión pierde todo el sistema de administración remota, el problema es otro distinto al que yo tuve.

Teniendo claro que el problema estaba del lado del ICE, y probablemente fuera un tema a nivel de red, que requiere más que hablar con el de soporte técnico para solucionarlo, decidí buscarle otra salida al asunto. Si al final el tema se reduce a iniciar nuevamente el modem cada vez que falla, lo que ocupaba era automatizar ese reinicio.

Desafortunadamente estos Pirelli A115 no tienen ningún mecanismo automático de reinicio. El modem en sí es algo tonto, y ante un fallo de este tipo no hay forma de que por sí solo reinicie. Lo más que hace el modem es volver a autenticarse con el ICE, que como ya vimos no da resultado.

Lo que sí tiene interesante el A115 es que cuando hace un reinicio, aunque sea por software, es completo. El modem baja todas las interfaces de red, las vuelve a subir, y vuelve a hacer búsqueda de punto y autenticación, como si se hubiera apagado por completo. Y eso es precisamente lo que se ocupa para solucionar el tema en cuestión.

El A115 tiene varias formas de acceso para administrador. Puede llegársele por HTTP, por telnet, ICMP y por TFTP. Típicamente uno usa el HTTP e ignora el resto. Pero por curiosidad, decidí explorar el telnet del modem. La opción que le habilité se encuentra en el menú Management, bajo Access Control:

Me desilusioné un poco cuando entré, y recibí un menú de opciones. Siendo un chip Broadcom (BCM96338 según el mensaje de inicio), estaba esperando que usara algún tipo de micro linux internamente, que lo tirara a uno a línea de comando… y de ahí se pudiera dar o un shutdown, o enviar un Ctrl-Alt-Del. Pero no es así. El A115 usa menus en vez de línea de comando.

El menú de inicio que se obtiene al hacer telnet hacia el modem. La opción 13 es la que reinicia el modem.

Pero entonces se me ocurrió algo. El monitoreo del modem lo estaba pensando manejar via un servidor Linux. Y Linux tiene un paquete llamado expect que sirve para automatizar intercambios de telnet. Sería cuestión de en el momento necesario, correr una sesión de expect, esperar los diferentes menús, e ir guiando al modem para que se reinicie.

No voy a entrar en mucho más detalle. El resto fue pura prueba y error, para terminar mi script de reinicio para Linux:

#!/usr/bin/expect

spawn telnet 10.10.1.1
expect “Login:”
send “myuserr”
sleep 10
expect “Password:”
send “popcorn123r”
sleep 10
expect “>”
send “13r”
sleep 10
expect “Confirm”
send “1r”
sleep 5
expect “reset”
sleep 10

Algunos detalles del script:

  • Noten en la primera línea que el shell que corre los comandos es expect. No es el típico /bin/bash. 
  • Por supuesto, tienen que tener instalado el paquete expect y telnet para que el script funcione.
  • Spawn abre la sesión de telnet hacia el router.
  • Expect simplemente espera a que llegue la hilera de caracteres especificada. Send responde con la hilera indicada.
  • Tienen que reemplazar el intercambio de username/password con los valores que correspondan en su caso.
  • El resto de los expect y send lo que hacen es navegar a través del menú del modem, para reiniciarlo. Les recomiendo que aunque tengan un A115 también, exploren a mano un par de veces el menú interno. Diferentes versiones de firmware pueden tener diferentes menús.
  • Hay varios sleep ahí metidos. El sleep es necesario porque el modem en ocasiones se vuelve lento para responder. Si hay procesos de mantenimiento o diagnóstico corriendo, o si hay mucho tráfico en el modem, el telnet administrativo no camina. Los sleep pausan la ejecución del script, para que el modem tenga tiempo de responder con los prompt que busca expect. En su caso, puede ser necesario jugar un poco con los tiempos, dependiendo de qué tan rápido sea su modem para responder.
  • Es muy importante el sleep final. Haciendo pruebas me di cuenta que si se cerraba el script inmediatamente al recibir el texto “reset”, muchas veces no se completaba el reinicio, aunque se hubiera dado el comando final. Pero con el sleep, el reinicio completa bien.

El resto fue crear el archivo de script en el servidor Linux, ponerlo ejecutable, y correrlo. Puede correrse a mano, o colocarse mediante un cron. Yo puse un cron que lo ejecuta 2 veces al día fuera de horas pico.

Cron puede o no ser buena idea, recuerden que cada vez que reinician el modem, se pierde toda conexión a internet. Y eso puede interrumpir transferencias, sincronizaciones, trámites de web… y generar todo un caos entre los usuarios. Así que hay que pensar bien los momentos de hacer un reset indiscriminado via cron.

Posteriormente decidí mejorar un poco el proceso, para que no fuera tan indiscriminado. Usando wget, se puede revisar si una página existe en internet. Como wget devuelve un valor que depende del éxito de encontrar la página, podemos usarlo para verificar que exista conexión de internet, por lo menos vía http. Hay ocasiones en donde verificar que haya tráfico http no es suficiente, pero para los usuarios caseros, debería serlo.

Así que el script en cuestión lo que tiene que hacer es recuperar alguna página conocida (digamos google.com), y dependiendo del valor devuelto por wget, ejecuta nuestro script para reiniciar el router. Y eso se ve así:

#! /bin/bash

wget -q –spider http://google.com

if [ $? -eq0 ]; then
 echo “Online”

 else
 echo “Offline. Rebooting”
 /home/user/scripts/rebootdsl
fi

Así de fácil. Si el servidor Linux no logra llegarle a google.com, entra al modem y hace el reboot (rebootdsl es el nombre que le puse al script anterior en mi sistema). Este script de monitoreo está corriendo via cron cada 15 minutos. Si llega a fallar en algún momento la conexión, máximo 15 minutos después se reinicia el modem.

Por simplicidad el script anterior solo hace una revisión de google.com, pero uno podría ponerse más fino y hacer una revisión en varios niveles: revisar google.com, si eso no funciona revisar facebook.com, si eso no funciona yahoo.com, y ya si eso no funciona… reboot.

También uno podría crear algún archivo en /tmp para evitar reboot consecutivos, esto es, que si hay un fallo del internet de varias horas que no esté rebooteando el modem infructuosamente cada 15 minutos.

Por supuesto, siempre es bueno agregar una que otra línea para escribir ya sea a syslog, o a algún archivo de bitácora en el servidor… para poder saber cuándo ocurrió el problema.

Y ya si quieren ponerse muy finos, pueden usar algún paquete como gnokii para pedir ayuda via SMS cuando haya un fallo en la conexión. O incluso para poder enviar un comando via SMS al servidor y obligar el reboot del modem.

Si no tienen un servidor linux, podría ser una opción usar una Raspberry Pi. Existe versión ARM de expect, lo cual debería permitir manejar este script en Pi.

También una Pi puede servir para apagar y encender el modem físicamente, controlando la corriente del modem via un relay. Un Arduino podría ser opción también, pero en ese caso existe el problema de cómo determinar si es necesario hacer un reboot… el Arduino no tiene forma de verificar si hay o no conexión de internet, a menos que nos metamos con shields de ethernet, que ya harían demasiado complicada y cara esa solución respecto a una Pi.

2 Comments on "Como arreglé los problemas de conexión de mi ADSL de Kolbi ICE"

  1. Interesante, a mí me sucede similar pero con otro tipo de modem, también del ICE

    Yo estaba pensando en pasar más bien de un esquema de IP dinámica a una IP estática. ¿consideraste eso?

    • De hecho yo estaba con IP estática del ICE. Al final la historia es la misma, porque cualquier cosa que interrumpa la conexión va a ocasionar que el modem haga nuevamente handshake y trate de autenticarse. Y si el problema es del lado del ICE, el cambiar a IP estática no va a hacer mayor diferencia.

      Unos meses después de hacer la modificación, probé cambiar el ADSL de línea, y como parte del cambio el ICE me cambió a uno de los modem nuevos que son redondos. El cambio de línea no mejoró en nada la estabilidad ni la velocidad (de hecho tengo 6 Mbps contratados, estoy entre 1 y 1.5 reales). Pero este nuevo modem si es más inteligente, y se mantiene vivo aún si hay problemas en el servicio, cambios de IP, etc. Ese diría yo que es el primer paso para solucionar el asunto: si uno está con un modem Pirelli de los viejos, pedir cambio a los modelos más nuevos.

Comments are closed.