Stick ONU GPON FS numa gaiola SFP+ do UDM-Pro: nenhum jeito de alcançar o IP de gerenciamento para escrever o serial
Configuração doméstica, e estou tentando me livrar do roteador do provedor numa linha GPON da Cosmote. A ideia é levar a fibra direto para o UDM-Pro e deixar o stick fazer o trabalho de ONU, mas o provedor só aceita a sessão se o serial de 12 caracteres e a string de modelo do CPE antigo forem apresentados, então tenho que entrar no módulo e escrever os dois.
- Ubiquiti UDM-Pro, stick sentado na porta SFP+ 10
- stick ONU GPON FS com MAC SFP, item 133619
- cordão SC/APC para SC/APC da tomada de parede
- CPE antigo ainda na mesa como referência para o serial e a string de modelo
Meu problema é mais básico do que a clonagem em si: não consigo alcançar o módulo de jeito nenhum. Do shell do gateway, nada responde no endereço de gerenciamento dele.
ssh root@10.10.10.1
# then, from the gateway, with the stick in port 10
ssh ONTUSER@192.168.1.10O segundo comando só fica ali parado até desistir. Sem banner, sem conexão recusada, nada.
O que já fiz:
- reencaixei o stick e troquei o cordão, o módulo liga e o LED dele se comporta
- garanti que nada no UDM-Pro está usando 192.168.1.0/24, minha LAN vive numa sub-rede diferente
- pensei em montar uma VLAN de gerenciamento dedicada para a gaiola, mas é muita encanação para uma escrita só
Tem algum jeito de endereçar a gaiola SFP diretamente do shell do UDM-Pro para eu conseguir logar no stick e escrever o serial e o device ID, sem levantar uma VLAN separada para isso?
Comments 4
Duas coisas separadas estão no seu caminho, e nenhuma delas é o módulo.
Primeiro, o endereçamento. A gaiola SFP é uma interface normal no UDM-Pro, numerada como o número de porta exibido menos um, então a porta 10 é eth9. Dê ao gateway um endereço dentro da sub-rede do módulo e garanta que as respostas saiam com esse endereço como origem:
Depois disso, 192.168.1.10 responde a partir do shell do gateway.
Segundo, o handshake. O firmware desses sticks é velho o suficiente para a lista de troca de chaves dele parar nos algoritmos legados, então você tem que nomear um explicitamente:
Uma vez dentro, o serial do provedor entra com
set_serial_number AVMGXXXXXXXXe a string de modelo do dispositivo é clonada comsfp_i2c -i7 -s. Reinicie o stick e confira o que realmente ficou gravado:Duas ressalvas. Nada disso é uma configuração suportada - você está adicionando na mão um endereço e uma regra de NAT num appliance, então trate como encanação temporária para a sessão de programação e mantenha o CPE antigo até a linha autenticar. A outra metade do aviso é sobre taxa: 2,5 Gbit não é algo que essa plataforma vai aceitar sozinha, então mesmo um módulo que anuncia 2,5G acaba pareado em 1G ou 10G. Se você preferir não mexer no gateway de jeito nenhum, a alternativa é programar o stick em outra caixa com uma porta SFP roteada e mover ele depois.
Como o próprio gateway chama essa gaiola? Nessa caixa as portas SFP são interfaces comuns, mas a nomenclatura não bate com os números impressos no painel frontal, então é fácil estar empurrando pacotes para fora de algo que não é a gaiola de jeito nenhum - e do shell isso parece exatamente o que você tem, uma sessão parada ali sem nada do outro lado.
Cola a lista de interfaces do shell do gateway. Depois que ficar claro qual interface pertence a essa porta, a parte do endereçamento é a metade fácil.
eth9 era exatamente isso, porta 10 menos um. O endereço mais a regra de SNAT fizeram 192.168.1.10 responder na primeira tentativa, e a opção de troca de chaves legada foi a outra metade: sem essa flag meu cliente desistia durante o handshake, com ela eu ganhei o prompt ONTUSER na hora.
Escrevi o serial com
set_serial_number AVMGXXXXXXXX, clonei a string de modelo comsfp_i2c -i7 -s, reiniciei, efw_printenv | grep nSerialdevolve o valor que eu defini. A linha autenticou alguns minutos depois e o CPE antigo agora está desconectado.Uma coisa confirmada do jeito difícil: a porta subiu em 1G, exatamente como avisado sobre 2,5G nessa gaiola. Serve bem para o perfil que o provedor me dá aqui.
Mesmo trabalho, peças diferentes, e o serial é onde a coisa fica feia. Eu estava movendo uma identidade Calix GigaPoint 801Gv2 para um stick G-010S-A com ritool:
O serial da ONT é 372010010470, mas o módulo ecoou de volta como
faltando um zero. O motivo é o layout do campo: o serial GPON tem 8 bytes, os primeiros quatro guardam o vendor ID como caracteres ASCII (3720 lido literalmente como quatro letras) e os últimos quatro guardam a parte numérica empacotada como hex. Uma cauda decimal como 10010470 não entra dígito por dígito, e é por isso que o eco perde um caractere.
Então antes de declarar vitória, confira como o seu provedor registra a ONT em primeiro lugar - serial ou SLID / registration ID. Escrever só o serial nem sempre é o que eles usam para bater.