El módulo ALLNET ALL4781-VDSL2-SFP en un Turris Omnia resincroniza cada 30 a 120 minutos
Finalmente moví mi línea VDSL2 fuera del equipo del proveedor y la terminé en el propio Turris Omnia, sobre todo para que PPPoE corra en el router en vez de en un segundo dispositivo en modo puente. La parte de configuración fue agradable: insertar el módulo en el zócalo y la interfaz WAN simplemente se traslada al módulo, dejando fuera de escena el zócalo metálico, con el enlace interno subiendo por sí solo. El LED verde sigue la sincronización DSL, el naranja el lado hacia el router.
- Turris Omnia, PPPoE configurado en la interfaz orientada al módem
- módulo módem ALLNET ALL4781-VDSL2-SFP en el zócalo SFP
- línea VDSL2 que sincroniza a los 100 Mbit completos de bajada
option ifname 'eth1.7', porque mi línea quiere la etiqueta VLAN 7
Diez minutos de configuración más un reinicio y estaba arriba a la velocidad de línea. El problema es que no se mantiene. En algún punto entre media hora y dos horas el DSL se desincroniza, y necesita de dos a tres minutos para volver:
LCP terminated by peer
Modem hangup
eth1: link is downQué he probado ya:
- reinserté el módulo y reinicié el router, el intervalo después es el mismo
- cambié el cable de parcheo DSL y moví el módulo a la primera roseta de la línea
- desconecté el cable WAN de cobre para que nada pudiera competir por la interfaz
Nada de eso cambia el patrón. ¿Es esto el módulo, mi línea, o la forma en que el Omnia maneja el zócalo? ¿Alguien está usando este módulo módem a largo plazo sin resincronizaciones?
Comments 4
Esa es la mala combinación conocida: firmware 3.4 en una línea que realmente puede hacer 100 Mbit. El módulo no está roto como tal -otro Omnia que conozco lleva mucho tiempo corriendo el mismo módulo en una línea VDSL2 perfil 17a y nunca ha resincronizado una sola vez, que es por qué los reportes sobre esto se dividen como se dividen. Qué línea cae en qué grupo no es algo que se pueda leer de antemano en una hoja de datos.
Dos cosas, en este orden.
Primero, ve al fabricante por el firmware. Han reconocido que el 3.4 se comporta mal cuando la línea puede alcanzar 100 Mbit, y la versión más nueva no cuesta nada, así que no hay razón para no usarla.
Segundo, sigue vigilando los LED después. Que el verde se apague primero significa DSL, que el naranja se apague significa el lado del zócalo. Si el verde sigue cayendo en la versión nueva, el firmware no era toda la historia en tu línea.
Siendo honesto sobre el resultado, ya que lo vas a preguntar de todos modos: conozco al menos una línea donde la actualización no cambió nada y las resincronizaciones continuaron en el mismo rango de treinta minutos a dos horas. La estabilidad con este módulo parece depender tanto de las características de la línea como de la versión, así que trata el firmware como lo más barato de probar y no como una solución garantizada. Si sigue cayendo después de eso, el recurso poco glamuroso es volver a poner un módem delante y mantener la sesión PPPoE en el router sobre
eth1.7-conservas la configuración que ya tienes y dejas de perseguir la sincronización.¿Qué firmware tiene el módulo? Hay más de una versión en circulación y no se comportan igual en líneas rápidas, así que eso es lo primero que hay que fijar.
Dos cosas más antes de culpar al router. En el momento en que se cae, ¿se apaga el LED verde, o se queda encendido mientras el naranja se mueve? Eso te dice si se pierde la sincronización DSL o solo el enlace hacia el Omnia. ¿Y puedes sacar algo útil del propio módulo en los minutos previos a una caída -tasa alcanzable, margen SNR, contadores de error? Una sincronización que mantiene su tasa hasta el segundo mismo en que muere se lee muy distinto de una que primero se va arrastrando hacia abajo.
Firmware 3.4 en el módulo.
Me senté junto al equipo y capturé tres caídas seguidas: el verde se apaga primero, el naranja se mantiene encendido todo el tiempo. Así que el enlace hacia el router nunca se mueve, es la sincronización DSL la que muere y la sesión PPPoE la sigue hacia abajo. Eso también hace de
LCP terminated by peeruna consecuencia y no una causa, que es lo que sospechaba pero no había probado.En cuanto a contadores no tengo nada que darte. Tasa alcanzable, margen, contadores de error -el módulo no expone nada de eso en ningún sitio que encuentre, y el router me muestra la tasa de sincronización y nada más. Esa cifra se mantiene a la tasa de línea hasta el segundo mismo en que desaparece, así que nada se arrastra hacia abajo antes, simplemente se va. El perfil tampoco ha cambiado desde que el módem del proveedor estaba delante de la línea.
Módulo distinto, mismo zócalo, vale la pena saberlo mientras estás probando.
Tuve un módulo GPON HALNy HL-GSFP en un Omnia: el kernel lo detectó sin quejarse, el puerto pasó a inband/1000base-x, y luego eth2 se quedó caído para siempre. Es cuestión de tiempos, no de compatibilidad. El módulo lleva su propio pequeño sistema operativo y quiere casi un minuto entero antes de responder a nada, mientras que el zócalo se sondea a los pocos segundos de encender. El sondeo no encuentra a nadie en casa, el router se queda tranquilamente en el WAN metálico y la interfaz SFP nunca despierta.
fw_setenv bootdelay 60en u-boot lo resolvió definitivamente.Eso no explicará una resincronización a mitad de sesión, así que no es tu respuesta. Pero si alguna vez reinicias tras una caída y te encuentras de vuelta en cobre, ese es el mecanismo que estás viendo, no un módulo muerto.