[TÓPICO DEDICADO] Eliminar ou trocar ONU/ONT/HGU da operadora/provedor
- Iniciador de Tópicos _Piccini_
- Data de Início
Até aonde eu sei no ODI, não precisa de nenhuma configuração. Tu ativou o IPv6 no udm pro? Eu fiz a configuração somente no meu UDM-SE e passou o IPv6 tranquilo. Eu estou usando uma vsol e não fiz nada de configuração nela ...
Postei lá no tópico da Claro um problema que estou observando onde estou verificando uma grande quantidade de pacotes ARP que a Claro está mandando via broadcast (ver aqui).
Nessa análise estava verificando também uma grande quantidade de dropped RX packets na interface WAN do meu roteador (mais detalhes no tópico do OpenWrt aqui).
O que eu notei é que a interface WAN do meu OpenWrt está recebendo pacotes de protocolo desconhecido que são dropados automaticamente e entram nessa contabildiade do dropped RX.
Porém analisando esses pacotes capturados, percebi que o MAC address do equipamento que enviando esses alguns desses pacotes inválidos é de um fabricante chamado Guangzhou V-Solution Telecommunication:
Curiosamente, pesquisando por essa empresa cheguei nessa página do LinkedIn que indica que é VSOL!
Só então fui ver, e é o MAC address da minha ONU VSOL... Então algo a investigar, não esperava que a ONU VSOL ficasse gerando esse tipo de tráfego na porta WAN do meu router...
Agora estou desconfiado se o filtro de VLAN do VSOL está deixando passar outras coisas também. Quando der, vou fazer um teste de tirar o filtro da VLAN do VSOL e colocar no OpenWrt (teoricamente esses pacotes teriam de desaparecer)...
Nessa análise estava verificando também uma grande quantidade de dropped RX packets na interface WAN do meu roteador (mais detalhes no tópico do OpenWrt aqui).
O que eu notei é que a interface WAN do meu OpenWrt está recebendo pacotes de protocolo desconhecido que são dropados automaticamente e entram nessa contabildiade do dropped RX.
Porém analisando esses pacotes capturados, percebi que o MAC address do equipamento que enviando esses alguns desses pacotes inválidos é de um fabricante chamado Guangzhou V-Solution Telecommunication:
Curiosamente, pesquisando por essa empresa cheguei nessa página do LinkedIn que indica que é VSOL!
Só então fui ver, e é o MAC address da minha ONU VSOL... Então algo a investigar, não esperava que a ONU VSOL ficasse gerando esse tipo de tráfego na porta WAN do meu router...
Agora estou desconfiado se o filtro de VLAN do VSOL está deixando passar outras coisas também. Quando der, vou fazer um teste de tirar o filtro da VLAN do VSOL e colocar no OpenWrt (teoricamente esses pacotes teriam de desaparecer)...
Tentei com essas configurações abaixo mas sem sucesso. Prefix delegation em 64 e 52.
Voltei a fibra para o modem mas aparentemente nao recebe ipv6 do provedor.
Postei lá no tópico da Claro um problema que estou observando onde estou verificando uma grande quantidade de pacotes ARP que a Claro está mandando via broadcast (ver aqui).
Nessa análise estava verificando também uma grande quantidade de dropped RX packets na interface WAN do meu roteador (mais detalhes no tópico do OpenWrt aqui).
O que eu notei é que a interface WAN do meu OpenWrt está recebendo pacotes de protocolo desconhecido que são dropados automaticamente e entram nessa contabildiade do dropped RX.
Porém analisando esses pacotes capturados, percebi que o MAC address do equipamento que enviando esses alguns desses pacotes inválidos é de um fabricante chamado Guangzhou V-Solution Telecommunication:
Curiosamente, pesquisando por essa empresa cheguei nessa página do LinkedIn que indica que é VSOL!
Só então fui ver, e é o MAC address da minha ONU VSOL... Então algo a investigar, não esperava que a ONU VSOL ficasse gerando esse tipo de tráfego na porta WAN do meu router...
Agora estou desconfiado se o filtro de VLAN do VSOL está deixando passar outras coisas também. Quando der, vou fazer um teste de tirar o filtro da VLAN do VSOL e colocar no OpenWrt (teoricamente esses pacotes teriam de desaparecer)...
Achei aqui como fazer e no pfSence mostra assim:
Código:
23:17:23.582207 1c:ef:03:ca:d5:8c > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xfffa), length 60:
0x0000: dead beef 0172 6561 6c74 656b 5f6c 6f6f .....realtek_loo
0x0010: 7062 6163 6b5f 6465 7465 6374 5f70 6163 pback_detect_pac
0x0020: 6b65 7400 0000 0000 0000 0000 0000 ket...........E a ONU VSOL usa um chip da Realtek:
å¼ç®±ä½éª2.5G åç«VSOL V2802RH--æ§ä»·æ¯é¦é_è·¯ç±å¨_ä»ä¹å¼å¾ä¹°
开箱简介VSOL 简称（芯德）成立于2007年，长期从事于光通信网络接入和终端的开发，专注于光通信网络接入领域综合应用解决方案的研究和开发。V280
Última edição:
Pediu ativação do IPv6 na TIM? Se não, tem q pedir... via chat, via N2.... onde der.. pois tem gente q consegue via chat, tem gente q só nível 2 e etc...Tentei com essas configurações abaixo mas sem sucesso. Prefix delegation em 64 e 52.
Voltei a fibra para o modem mas aparentemente nao recebe ipv6 do provedor.
Tem como verificar isso no pfSense também? Fiquei curiosos pois a VSOL aqui também.
Achei aqui como fazer e no pfSence mostra assim:
Código:23:17:23.582207 1c:ef:03:ca:d5:8c > ff:ff:ff:ff:ff:ff, ethertype Unknown (0xfffa), length 60: 0x0000: dead beef 0172 6561 6c74 656b 5f6c 6f6f .....realtek_loo 0x0010: 7062 6163 6b5f 6465 7465 6374 5f70 6163 pback_detect_pac 0x0020: 6b65 7400 0000 0000 0000 0000 0000 ket...........
E a ONU VSOL usa um chip da Realtek:
å¼ç®±ä½éª2.5G åç«VSOL V2802RH--æ§ä»·æ¯é¦é_è·¯ç±å¨_ä»ä¹å¼å¾ä¹°
开箱简介VSOL 简称（芯德）成立于2007年，长期从事于光通信网络接入和终端的开发，专注于光通信网络接入领域综合应用解决方案的研究和开发。V280post.smzdm.com
O VSOL manda esses 4 pacotes a cada 5 segundos (69120 pacotes por dia). Como é um protocolo "desconhecido", os mesmos são dropados direto no OpenWrt. Por isso ao longo do tempo vai acumulando e o número de RX dropped frames cresce.
Bem suspeito né cara, conseguiu investigar mais? Será que enviam alguma informação para a central na china?
Eu tinha um roteador wifi da Xiaomi e ficava assustado da quantidade de bloqueio de requisição (para a china) que o pihole bloqueava dele.
Preocupante, minha Vsol tambem esta enviando informações para a china, meu roteador bloqueia, mais quando voce vai investigar é tudo site chinês.
O AX3000 que uso tem uma trigger que manda um ping para o 114.114.114.114 para saber se tem internet. Quando bloqueio essa trigger a luz do roteador fica laranja e quando ativo ela fica branca normal. Então o que eu fiz? Bloqueei tudo vindo do roteador e liberei apenas o protocolo ICMP para este IP. Realmente ele se comunica com uns endereços chineses. Mas sobre a VSOL, como ela está em bridge aqui creio que não há risco
Sim, investiguei mais. Tenho uma outra conexão (em outro local) com um provedor local que usa a HGU FiberHome HG6143D. Essa HGU está toda bloqueada, e tenho meu OpenWrt conectado na mesma em duplo NAT (já que não consigo colocar em bridge e nem configurar DMZ).
Nessa rede estava observando o mesmo problema de aumento de dropped RX frames na porta WAN. Fiquei pasmo ao descobrir que a razão é a mesma do VSOL! A única diferença é que o VSOL manda 4 pacotes a cada 5 segundos, e o Fiberhome manda 1 pacote a cada 3 segundos.
Por um lado fiquei mais tranquilo, já que parece ser algo comum e não é nenhum tipo de backdoor chinês. Por outro lado estou curioso, pois procurei documentação sobre esse protocolo e o mesmo não existe...
Será que é algum tipo de broadcast das OLTs que é repassado para as redes locais das ONUs/ONTs/HGUs?
Última edição:
Como eu vejo esse drop pelo openwrt? Tem os gráficos na interface web, ou preciso rodar comando por ssh?Sim, investiguei mais. Tenho uma outra conexão (em outro local) com um provedor local que usa a HGU FiberHome HG6143D. Essa HGU está toda bloqueada, e tenho meu OpenWrt conectado na mesma em duplo NAT (já que não consigo colocar em bridge e nem configurar DMZ).
Nessa rede estava observando o mesmo problema de aumento de dropped RX frames na porta WAN. Fiquei pasmo ao descobrir que a razão é a mesma do VSOL! A única diferença é que o VSOL manda 4 pacotes a cada 5 segundos, e o Fiberhome manda 1 pacote a cada 3 segundos.
Por um lado fiquei mais tranquilo, já que parece ser algo comum e não é nenhum tipo de backdoor chinês. Por outro lado estou curioso, pois procurei documentação sobre esse protocolo e o mesmo não existe...
Será que é algum tipo de broadcast das OLTs que é repassado para as redes locais das ONUs/ONTs/HGUs?
Gente, isso é apenas um pacote de broadcast.Sim, investiguei mais. Tenho uma outra conexão (em outro local) com um provedor local que usa a HGU FiberHome HG6143D. Essa HGU está toda bloqueada, e tenho meu OpenWrt conectado na mesma em duplo NAT (já que não consigo colocar em bridge e nem configurar DMZ).
Nessa rede estava observando o mesmo problema de aumento de dropped RX frames na porta WAN. Fiquei pasmo ao descobrir que a razão é a mesma do VSOL! A única diferença é que o VSOL manda 4 pacotes a cada 5 segundos, e o Fiberhome manda 1 pacote a cada 3 segundos.
Por um lado fiquei mais tranquilo, já que parece ser algo comum e não é nenhum tipo de backdoor chinês. Por outro lado estou curioso, pois procurei documentação sobre esse protocolo e o mesmo não existe...
Será que é algum tipo de broadcast das OLTs que é repassado para as redes locais das ONUs/ONTs/HGUs?
Do jeito que tá não é nenhum problema e tão menos é uma tentativa de contato com um backdoor chines. Só precisa ficar atento se tiver muito pacote mesmo ou fosse vários dispositivos gerando isso na mesma rede, quem tem redes grandes e com muitos dispositivos sabe o problema que é o broadcast e de ter de fazer varias técnicas para reduzir isso.
--- Post duplo é unido automaticamente: ---
Fique frio, os chines não tão nem ai para quais pornos tu baixa meu amigo.
É mais que normal esses equipamentos fazer conexões a IPs e sites chines afinal eles são de lá para verificar se tudo tá funcionando corretamente como a sua conexão, dns, atualizações do sistema e/ou módulos do sistema e etc
Não quer dizer que o roteador tá se comunicando com a nave mãe com planos maléficos de dominação mundial, tão menos que ele esteja mantendo um backdoor chines, spyware e etc
Vários roteadores fazem isso como os "TP-Link" que é chines inclusive, mas ninguém se preocupa.
Até mesmo os Linksys/Cisco que é "America fuck yeah!" faz contato com os servidores da empresa igual mas ninguém tá preocupado se tem backdoor do governo americano mesmo inclusive tendo vários vazamentos que afirmam que teria sim por imposição do governo porque os gingos são bonzinhos e os chineses maleficos.
No final só tem vilão ai, a questão é a nossa educação que a vida toda forma opinião que um lado é 100% bom e o outro 100% ruim.
Última edição:
O campo GPON_PLOAM_PASSWD, é o mesmo do GPON_SN? Essa intelbras R1, tem telnet ou é obrigatório soldar um serial nela? Obrigado!!!
O número de dropped ethernet frames é via SSH via comando
ifconfig e o nome da interface wan. Por exemplo:
Rich (BB code):
root@ap1-router:~# ifconfig wan
wan Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2804:XXXX:XX14/64 Scope:Global
inet6 addr: 2804:XXXX::2/128 Scope:Global
inet6 addr: fe80::XX14/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:710201 errors:0 dropped:12120 overruns:0 frame:0
TX packets:448653 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:776520631 (740.5 MiB) TX bytes:559289126 (533.3 MiB)
root@ap1-router:~#Note que o nome da interface
wan pode mudar dependendo do modelo do roteador. No NanoPi R4S por exemplo não tem essa interface, é direto via eth0, e aí o comando é ifconfig eth0 por exemplo.Para analisar o tráfego, eu capturo rodando o comando
tcpdump via SSH no OpenWrt, salvo a captura num arquivo e depois abro no Wireshark no PC.Tem que instalar o
tcpdump via opkg update e depois opkg install tcpdump.Depois para capturar os pacotes e salvar num arquivo basta usar o comando
tcpdump -i wan -w /tmp/tcpdump.cap. Para finalizar a captura basta pressionar CTRL+C. Depois é só copiar o arquivo /tmp/tcpdump.cap para um PC (pode usar o comando scp) e abrir o mesmo no Wireshark.Da mesma maneira que o
ifconfig o nome da interface wan no tcpdump pode variar. No R4S ao invés de tem que ser eth0 por exemplo: tcpdump -i wan -w /tmp/tcpdump.cap.
--- Post duplo é unido automaticamente: ---
Um pequeno complemento: é broadcast com protocolo inválido na rede WAN (não é na rede local), por isso aparece como "dropped frame". Nesse caso de fato não é problema sério (fora um flood desnecessário na porta WAN), mas tem outros casos que dropped frames podem significar algum problema.
Mais detalhes nesse artigo do Suse Linux:
ifconfig shows dropped rx packets | Support | SUSE
Em resumo, dropped frames aparecem quando:
Que no caso acima é por causa do item (3) (broadcast de pacote com protocolo desconhecido).
Última edição:
Sim sem changelog, atualizei aqui e parece tudo do mesmo jeito
E concluindo o assunto do broadcast na WAN de pacotes de protocolo desconhecido "0xffa". Via Wireshark peguei o payload em hexadecimal desses pacotes e converti para ASCII.
E a charada está resolvida: são pacotes enviados pelos switches das ONTs para detecção de loops de ethernet:
E a charada está resolvida: são pacotes enviados pelos switches das ONTs para detecção de loops de ethernet:
- Payload do pacote "0xffa" do VSOL V2802RH: "realtek_loopback_detect_packet"
- Payload do pacote "0xffa" do Fiberhome HG6143D: "This is loop detect frame send from 00:00:00:00:00:00 port 01"
Última edição:
E concluindo o assunto do broadcast na WAN de pacotes de protocolo desconhecido "0xffa". Via Wireshark peguei o payload em hexadecimal desses pacotes e converti para ASCII.
E a charada está resolvida: são pacotes enviados pelos switches das ONTs para detecção de loops de ethernet:
O mais interessante é que não existe nenhuma referência pesquisando no Google sobre esse tipo de pacote. Então se o Google indexar o forum, quem pesquisar no futuro sobre "broadcast", "0xffa" e "dropped frame" vai chegar nesse post aqui (ou no do forum do OpenWrt)...
- Payload do pacote "0xffa" do VSOL V2802RH: "realtek_loopback_detect_packet"
- Payload do pacote "0xffa" do Fiberhome HG6143D: "This is loop detect frame send from 00:00:00:00:00:00 port 01"
Parece ser algo comum, apesar da pouca informação na internet:
Última edição:
use apenas os 10 primeiros caracteres do GPON SN, isso foi a forma que configurei.
Nomenclatura do arquivo mudou, começando 2801P ao invés de V2802RH. Mas se funcionou aí, vou testar aqui também. Fiquei com medo de ser para outro equipamento e dar softbrick.
--- Post duplo é unido automaticamente: ---
Boa, desabilitei aqui também.Fui olhar o VSOL e tem opção para desabilitar loop detection!!!!
Sim eu estranhei, mas deu tudo certo
