Turris Omnia recusa um stick GPON MA5671A desbloqueado: a eth2 nunca sobe no Turris OS 5.0.3
Estou tentando substituir o terminal da operadora no meu rack de casa por um stick GPON direto no roteador, para a fibra cair numa caixa só em vez de duas. O stick é reconhecido, e é aí que as boas notícias acabam.
- Turris Omnia no Turris OS 5.0.3, kernel de fábrica
- stick GPON Huawei MA5671A com firmware desbloqueado, configurado para SGMII 1G
- pigtail SC/APC da tomada de parede até o stick
- eth2 é a porta SFP
O módulo é detectado, mas a interface nunca ativa:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bA eth2 fica down depois disso, sem carrier, nada nos contadores.
O que já tentei até agora:
- regravei o stick de volta para o firmware de fábrica, o que me dá um erro de leitura de EEPROM em vez disso
- forcei a taxa com ethtool -s eth2 1000 autoneg off duplex full, depois disso a interface fica em 10 Mbit half duplex
- movi o mesmo stick para um roteador MikroTik, onde ele sobe assim que a velocidade da porta é configurada manualmente
Então o módulo em si está vivo e o lado da fibra está bem. O que tem no stick que o kernel rejeita, e quais sticks GPON realmente sobem num Omnia em vez de serem recusados?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Isso é um problema do lado do host, não um módulo morto. A EEPROM nesses sticks GPON reaproveitados declara um encoding que o driver sfp mainline não mapeia, o phylink por isso recusa subir a porta, e a linha que você colou é o driver dizendo exatamente isso. Sua própria evidência aponta na mesma direção: o mesmo stick linka num MikroTik assim que a velocidade da porta é configurada manualmente, então o óptico e o lado PON estão bons.
A única coisa que fez diferença de verdade pra mim foi um kernel novo o bastante para carregar as particularidades por módulo, que no Omnia significou o branch de teste HBD com kernel 5.4. Aviso que essa é uma vitória parcial e depende muito de qual stick você tem. Nesse kernel:
Então, se você quer o Omnia funcionando agora em vez de eventualmente, o DFP-34G-2C2 é o que eu colocaria na cage. Teste na sua própria caixa antes de se comprometer, os resultados aqui claramente variam entre sticks e até entre revisões de firmware do mesmo stick.
Duas coisas vale a pena confirmar antes de qualquer um começar a chutar. Primeiro, de qual branch vem esse 5.0.3 e o que o uname reporta como kernel? As particularidades de SFP por módulo que esses sticks GPON reaproveitados precisam entraram depois, então um kernel estável lançado e um de teste se comportam muito diferente com exatamente o mesmo módulo.
Segundo, o serial da ONU está registrado do lado da operadora? Um stick que nunca é autorizado na OLT vai ficar ali parecendo morto, e muitas operadoras se recusam a registrar uma ONU de terceiros.
E quando você conecta, a porta chega a mudar para inband/1000base-x, ou o log para exatamente nessa mensagem de encoding?
Branch estável, kernel de fábrica do 5.0.3, nada customizado em cima. O lado da operadora não é o problema aqui, é a mesma fibra e o stick carrega o serial registrado.
O log para na linha de encoding, a porta nunca vira inband/1000base-x. O que aparece depende do firmware. Com o desbloqueado:
mais uma falha de transmissão reportada pelo módulo. Com o firmware de fábrica nem chega até aí:
E como eu disse, forçar a taxa não faz nada: depois de ethtool -s eth2 1000 autoneg off duplex full a interface continua em 10 Mbit half duplex.
Mais um modo de falha para descartar no mesmo roteador, porque parece parecido e não tem nada a ver com o encoding. Um HALNy HL-GSFP no Turris OS HBS 6.2.4 foi detectado, a porta até mudou para inband/1000base-x, aí o link caiu e a eth2 ficou down.
Causa: esse stick é um computador pequeno por conta própria. Ele gasta algo como um minuto subindo o próprio firmware, e só depois disso responde à cage com alguma coisa que faça sentido. Um boot frio faz o roteador olhar para a cage bem antes desse ponto, então a detecção falha e a caixa volta silenciosamente para a magnética da WAN de cobre. Aumentar o delay do boot resolveu:
Sessenta segundos em vez dos três padrão, e outra pessoa com o mesmo stick confirmou. Mais duas coisas que ajudaram: desconectar o cabo WAN de cobre e reiniciar mais uma vez, e entrar no próprio módulo para ver em que estado ele está, via serial em 38400 8N1 ou via SSH em 192.168.77.154 porta 22666.