Stick GPON DFP-34X-2C2 só aparece no dmesg depois de dezenas de segundos e depois linka em 1G
Estou substituindo a ONT da operadora por um stick SFP GPON na máquina Linux que termina nosso WAN, e o stick não se comporta nem perto de um transceptor. Encaixa e a cage fica muda por meio minuto ou mais, tempo suficiente para eu achar duas vezes que o módulo tinha morrido, e quando o kernel finalmente percebe ele, o link se estabiliza em velocidade gigabit, o que anula o propósito do exercício.
A bancada:
- Roteador Linux, cage SFP controlada pela camada SFP do kernel, kernel mainline
- Stick GPON ODI DFP-34X-2C2
- Um stick Huawei MA5671a como segunda amostra
- Um módulo de fibra 1G comum que aparece instantaneamente na mesma cage, então a cage em si está OK
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offO que já tentei:
- reencaixar o stick e deixar quieto por vários minutos antes de mexer na interface, e a espera acontece toda vez, não só na primeira inserção
- dar bounce na interface depois da detecção, o que não muda nada no modo negociado
- o MA5671a mostra o mesmo aparecimento lento, então não é uma amostra ruim isolada
Isso é simplesmente como sticks GPON se comportam num host Linux, ou tem algo errado do meu lado? O que está realmente acontecendo entre a inserção e a detecção aqui?
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 7
Antes de começar a chutar, duas coisas valem a pena confirmar primeiro. Primeiro, posta o dmesg completo, sem cortes, desde a inserção, em vez de um grep de duas linhas. Você diz que a cage fica atrás da camada SFP do kernel e não tenho motivo pra duvidar, mas as linhas que você filtrou são justamente as que mostram quantas vezes o módulo foi sondado, o que falhou no meio do caminho e quanto tempo cada tentativa levou.
Segundo, o que a própria interface diz que consegue fazer quando o stick finalmente sobe, e o 2500baseX aparece em algum lugar nos modos anunciados? E qual velocidade a operadora está entregando no lado PON, porque se for um plano gigabit, o link que você está tendo é o correto e não há nada para consertar.
Comportamento esperado, infelizmente, e o problema não é do seu host.
Um stick GPON não é um transceptor com um chip EEPROM dentro. É um pequeno computador Linux no seu próprio SoC, espremido dentro de uma carcaça SFP, e a EEPROM que seu host lê via I2C é emulada por esse sistema. Nada responde no barramento até o firmware do próprio stick ter dado boot o suficiente pra servir essas páginas, e é por isso que você fica esperando dezenas de segundos enquanto um módulo normal responde na hora. Esse silêncio antes da sua linha do módulo é o boot acontecendo.
A segunda metade do seu problema é que o que as páginas emuladas anunciam frequentemente está simplesmente errado. A interface do lado do host nesses sticks é 2500BASE-X, e a EEPROM diz outra coisa, então a camada SFP aceita isso ao pé da letra e se estabiliza no modo gigabit. As duas metades são tratadas no kernel com quirks por módulo, e não com algo que você configura, e o DFP-34X-2C2 da OEM pegou um desses quirks exatamente por esse motivo.
Se a sua amostra cai nesse caso depende das strings de vendor e de part number que ela reporta, e isso muda entre rebadges, então compare o que a sua linha do dmesg imprime com o que o quirk casa antes de assumir que você está coberto.
Para reforçar por que a abordagem de quirk é necessária: a SFF-8472 assume um dispositivo de memória passivo que responde dentro dos tempos normais de I2C. Nada nela prevê um dispositivo que precisa de meio minuto de boot antes de conseguir falar, então um host que segue o padrão tem todo o direito de desistir do módulo ou de confiar nos bits de modo que eventualmente lê.
O ponto do rebadge acima é a armadilha prática. O casamento é feito pelas strings de vendor e de part number, então o mesmo stick físico vendido sob outro nome escapa do quirk por completo e você volta pro link gigabit sem motivo óbvio. E não construa nada que dependa do módulo estar presente logo depois do boot, porque essa corrida é imperdível aqui.
Ter esperança de que os fabricantes do stick corrijam o conteúdo da EEPROM também é otimismo demais. Quando esses problemas foram levantados, até ISPs grandes conseguiram muito pouco retorno deles.
O mesmo tipo de problema aparece em roteadores domésticos, então pelo menos você não está sozinho. Donos de Archer BE800, BE900 e GE800 com um stick na porta combo SFP+ 10G conseguem 1 Gbit/s em vez dos 2,5 que pagaram, e a própria lista da TP-Link de sticks que funcionam nessas portas traz o ODI DFP-34X-2C2, o Huawei MA5671A e o Nokia G-010SA, a mesma lista curta de peças em que todo mundo acaba esbarrando.
A primeira orientação foi firmware mais reencaixe, e a parte do reencaixe não é bobagem: um módulo que não encaixou até o fim de fato cai de velocidade. Builds beta acabaram expondo a configuração de porta, uma por modelo:
Com uma dessas no aparelho o modo da porta SFP passa a ser configurável por telnet, com a interface derrubada primeiro,
ip link set eth1 downe por aí vai.Ainda é um workaround e não uma correção, importante dizer. Um ano depois as mesmas reclamações continuavam chegando, e não só sobre sticks: uma pessoa tinha um AOC JT-AOC-SFP-15 da JT-COM nessa porta, outra um DAC 10G SFP+ passivo da Ampcom, e os dois ficaram travados em 1 Gbit/s.
Vale saber do outro modo de falha antes que alguém sugira mover o stick para uma NIC. No OpenWrt 19.07 em x86 com uma Intel X520 e kmod-ixgbe, um MA5671a é simplesmente recusado como SFP não suportado. Definir allow_unsupported_sfp pelos arquivos de configuração de módulo de sempre não faz nada ali, o parâmetro precisa ser passado no momento em que o módulo é carregado:
E mesmo assim o driver ainda rejeita, porque a EEPROM do stick não descreve um transceptor normal para começo de conversa, e a flag não consegue disfarçar isso. Se você acabar indo para uma NIC, prove a porta primeiro com um módulo 1000BASE-T, LX ou SX comum, senão você está debugando a placa e o stick ao mesmo tempo.
Só cuidado pra não misturar as duas coisas. O allow_unsupported_sfp vive dentro do ixgbe e decide se aquele driver está disposto a operar uma determinada óptica, o que é uma decisão diferente da que está em jogo aqui. A espera longa e o modo errado vêm da camada SFP genérica lendo as páginas emuladas e passando o resultado pra cima, pro phylink, e é aí que ficam os quirks por módulo.
Em uma placa com uma cage SFP de verdade a flag do ixgbe nem existe e não é a correção, e numa X520 a lista de quirks também não vai te salvar. O sintoma parece igual por fora, mas a camada por baixo é diferente, e misturar as duas é como as pessoas acabam recompilando drivers à toa.
Mais uma distinção que vale a pena fazer já de cara: fazer o host enxergar o stick e fazer a OLT aceitá-lo são problemas independentes, e o segundo pode ser bem pior.
Existe um caso bem documentado de um Xicom DFP-34X-2C2 carregado com a identidade copiada de uma ZTE ZXHN F601 via setmac e consultas OMCI: serial GPON, senha PLOAM, LOID, serial de hardware e string de firmware, tudo. O stick chega ao estado O5 e simplesmente fica ali parado, sem ONU ID atribuído e sem tráfego, porque chegar a O5 só significa que o ranging funcionou, enquanto o upload de MIB ainda precisa bater com o perfil de ONT que a OLT espera. Ninguém naquele tópico chegou a uma solução.
Então, quando você conseguir o 2500BASE-X localmente, não assuma que a parte difícil já passou. Onde a operadora amarra um perfil de serviço a um modelo específico de ONT, pode não existir nenhum conjunto de campos copiados que faça um stick de terceiros ser aceito.