ODI DFP-34X-2C2 num Turris Omnia só linka em 1000base-x, ethtool não aceita speed 2500
Troquei a ONU da operadora por um stick GPON ODI DFP-34X-2C2 no meu Turris Omnia para a fibra terminar no roteador em vez de em outra caixa na prateleira. Essa parte funcionou: a linha está registrada, o tráfego passa, sem reclamações. O problema é a taxa. Ela nunca passa de 1Gbps, e 2.5G era o motivo inteiro de eu ter comprado esse stick.
- Turris Omnia, TurrisOS 6.0.4
- stick GPON ODI DFP-34X-2C2 no cage SFP, eth2
- WAN de cobre desconectada, o cage é quem controla a porta
O que o kernel diz depois de um boot, e o que acontece quando tento forçar a taxa:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 com o link up mostra o módulo como 1000baseX/Full e nada além disso, e a recusa acima é o ethtool me dizendo que speed 2500 não pode ser anunciado.
Já tentei:
- entrar via telnet no stick e ajustar a taxa pelo shell dele mesmo; ele aceita o comando e depois volta para 1Gbps
- reboots com e sem a WAN de cobre conectada
- vasculhei o dmesg atrás de qualquer coisa sobre a MAC recebendo oferta de 2.5G, não tem nada
Isso é o roteador limitando a porta, ou é o módulo em si? E tem alguma coisa do lado do host que faça a eth2 subir em 2500base-x com esse stick?
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 5
O teto aqui é o módulo em si, não o Omnia.
O que o host negocia é contra o que o EEPROM do módulo declara que ele sabe fazer, porque no momento da sondagem esse chip é a única coisa que o cage tem para se basear. Nesse stick ele está codificado para 1000Mbps. Então a porta é montada como inband/1000base-x, não existe modo 2500base-x para o phylink oferecer, e o ethtool recusa speed 2500 porque não tem nada para anunciar com ele. Nenhuma chave do lado do host contorna isso: o ethtool só consegue pedir os modos que disseram à porta que existem. O shell dentro do stick configura o lado PON do módulo, não o que o cage anuncia para a MAC, que é exatamente por isso que sua mudança via telnet evapora e você volta para 1Gbps.
Isso deixa duas opções reais: mandar recodificar o módulo para ele anunciar 2.5G, ou trocar por um que já anuncie. Se for pelo caminho da recodificação, mantenha um reserva na mesa. Você está reescrevendo a página de identidade em que o host confia, e um byte errado ali te dá um módulo que o cage para de reconhecer de vez. Também mantenha as duas taxas separadas na cabeça: o que o lado PON entrega e o que o link SFP-para-MAC negocia são números diferentes, então calcule o que você realmente ganha antes de gastar dinheiro nisso.
Antes de culpar o stick, confira qual device tree a caixa está bootando. O cage num Omnia não é uma interface extra: ele e a metade WAN metálica são duas frentes para uma mesma eth2, e só uma delas fica conectada até a MAC por vez. Qual delas é isso depende do dtb que o kernel carrega no boot. Então olhe para onde /boot/dtb aponta: se não for armada-385-turris-omnia-sfp.dtb, você está olhando para o lado de cobre e os números não significam nada.
Também posta o dmesg | grep -i sfp completo, não só a linha do mvneta. O que o kernel lê do módulo no momento da sondagem é a parte interessante aqui, e normalmente resolve a questão numa linha só.
O dtb já é o do SFP, eu fiz o symlink do armada-385-turris-omnia-sfp.dtb quando coloquei o stick pela primeira vez, senão nada subia de jeito nenhum. O cage controla a eth2 e a WAN de cobre fica desconectada.
dmesg | grep -i sfp mostra o módulo identificado e depois a mesma linha que eu postei, eth2 switched to inband/1000base-x link mode. Nada sobre 2500 em lugar nenhum. ethtool eth2 reporta 1000baseX/Full enquanto o link está up e passando tráfego, e ethtool -s eth2 speed 2500 continua voltando com Invalid argument, então não vai anunciar 2500 de jeito nenhum. Ajustar a taxa via telnet dentro do stick se comporta igual a antes, aceita o comando e depois volta para 1Gbps.
História correlata da mesma placa, para quem chegar aqui com um stick que não sobe de jeito nenhum, em vez de um preso em 1G. Um HALNy HL-GSFP num Omnia em Turris OS HBS 6.2.4: o kernel identificou ele, a porta até mudou para inband/1000base-x, e depois o link caiu e a eth2 nunca subiu.
Esse caso não é um problema de EEPROM. Existe todo um sisteminha rodando dentro desse stick, e ele quer quase um minuto sozinho antes de estar em condições de responder ao host. Num cold start o roteador já sondou o cage e desistiu bem antes desse ponto, então a porta volta para os magnetics de cobre. Aumentar o delay do U-Boot resolveu aqui:
O padrão é 3 segundos; em 60 o stick já terminou de subir quando o kernel vai sondar o cage. Desconectar a WAN de cobre e reiniciar uma segunda vez também ajudou na detecção. E se algum dia você precisar olhar dentro de um stick, a serial dele é 38400 8N1.
Concordo com o diagnóstico, com uma ressalva para quem chegar aqui com um sintoma parecido. Nem todo "não faz 2.5G" nessa placa é o módulo. Teve um snapshot do OpenWrt em que o código genérico de validação do phylink foi trazido via backport, e isso quebrou o cage do Omnia de vez: o ethtool continuava anunciando 2500baseX/Full mas reportava Link detected: no. Reverter esse backport devolveu a porta para onde ela estava, com o ethtool lendo Link detected: yes, 2500Mb/s full duplex, e um pull request posterior acertou o backport lá na origem.
O sinal está no que o ethtool lista como supported e advertised. Se 2500baseX/Full está lá e o link simplesmente se recusa a subir, olhe para o kernel e o phylink depois da sua última atualização de imagem, não para a óptica. Se, como aqui, a porta só conhece 1000baseX porque foi isso que o módulo declarou sobre si mesmo, nenhum software do lado do host vai inventar o modo. Isso é o byte de nominal bit rate no EEPROM fazendo exatamente o que o SFF-8472 diz que ele deve fazer.