Para descobrir sua região acesse a página no navegador: 192.168.15.1/instalador
Meu Deus.
Estou tendo o mesmo problema em sincronizar horario windows 11, uso somente o HGU Modelo: GPT-2742GX4X5v6 - FIRMWARE GL_g1.9_100XNT0b13_1O time.windows.com não tem jeito de funcionar no Windows com a Vivo, mesmo, pois ele é somente IPv4, então sempre cai em algum dos bloqueios.
Já o time.nist.gov (que é IPv4 e IPv6) no Windows só funcionou aqui depois que coloquei a regra de Source NAT IPv6 que mencionei lá (assim como qualquer outro servidor NTP com suporte a IPv6, depois disso).
====================
Em tempo... Não consigo mais editar a publicação original, mas só preciso fazer uma correção no cenário "IPv4 > De/para IPs de servidores NTP whitelistados pela Vivo > NTP versão 4":
IPv4:
IPv6:
- De/para IPs de servidores NTP whitelistados pela Vivo
- NTP versão 3
Permite requisições NTP (UDP outbound) com porta origem 123 e porta destino 123. Também permite a respectiva resposta NTP (UDP inbound), que igualmente tem porta origem 123 e porta destino 123
Parece bloquear demais requisições NTP (UDP outbound) com porta destino 123 e porta origem diferente de 123 e/ou respostas NTP (UDP inbound) com porta origem 123 e porta destino diferente de 123
- NTP versão 4
- De/para demais IPs
- NTP versão 3
- NTP versão 4
Lembrando que a análise é da perspectiva do roteador do cliente. E caso alguém note algum comportamento diferente do que observei e queira conferir como é no seu próprio caso, vou deixar os filtros do Wireshark que usei pra analisar cada cenário e a relação de IPs que julgo serem whitelistados:
Código:Cenário: IPv4 > De/para IPs de servidores NTP whitelistados pela Vivo > NTP versão 3 Permite: ip && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport == 123 && (ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Bloqueia: ip && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport != 123 && (ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Cenário: IPv4 > De/para IPs de servidores NTP whitelistados pela Vivo > NTP versão 4 Permite: ip && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport != 123 && (ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Permite: ip && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport == 123 && (ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Cenário: IPv4 > De/para demais IPs > NTP versão 3 Bloqueia: ip && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport != 123 && !(ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Bloqueia: ip && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport == 123 && !(ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Cenário: IPv4 > De/para demais IPs > NTP versão 4 Permite: ip && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport != 123 && !(ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Bloqueia: ip && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport == 123 && !(ip.src == 200.160.0.8 || ip.src == 200.189.40.8 || ip.src == 200.192.232.8 || ip.src == 200.160.7.186 || ip.src == 201.49.148.135 || ip.src == 200.186.125.195 || ip.src == 200.20.186.76 || ip.src == 200.160.7.197) Cenário: IPv6 > NTP versão 3 Permite: ipv6 && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport != 123 Bloqueia: ipv6 && ntp.flags.vn == 3 && ntp.flags.mode == 4 && udp.dstport == 123 Cenário: IPv6 > NTP versão 4 Permite: ipv6 && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport != 123 Bloqueia: ipv6 && ntp.flags.vn == 4 && ntp.flags.mode == 4 && udp.dstport == 123 Endereços IPv4 whitelistados: 200.160.0.8 (a.ntp.br) 200.189.40.8 (b.ntp.br) 200.192.232.8 (c.ntp.br) 200.160.7.186 (a.st1.ntp.br) 201.49.148.135 (b.st1.ntp.br) 200.186.125.195 (c.st1.ntp.br) 200.20.186.76 (d.st1.ntp.br) 200.160.7.197 (gps.ntp.br)
sua hgu por acaso bloqueou a opcção de bridge?
Eu uso o pool.ntp.br e vai de boa.
so foi la pela anatel. Pelo app, tecnico NAO FOI, nem me ligou e nada. PIOR parte que e na area externa do meu apartamento/cohab. Mas "cabeca" do tecnico passar BEM no meio do alsapao do predio kkkkkk
sempre usei aqui em modo router
Tá aparecendo a opção no 15.1 normal ou tá em bridge pelo 15.1/padrao ?? Pq aqui sumiu a opção modo da wan em configurações e o /padrao não acessa pra por a vlan em bridge =(
O meu irmão tbm o modem wifi6 mitra, o dele não acessava as configurações padrão avançada ficava branco a tela com erro, ele falou que mudou o idioma para inglês atualizou a página, clicou de novo a apareceu as opções tudo, ele precisou mudar o idioma, aparece no canto pra mudar o idioma para inglês.
Eu acho que sou o cara mais azarado do mundo kkkk Tá em ingles mas nao apareceu a opçao no 15.1 e padrao nem entra
TL; DR: Recomendo que usem um destes servidores NTP aqui:
(Ao longo deste post eu contextualizo o motivo desta recomendação. É que como ele acabou ficando muito extenso, eu não queria que o ponto mais importante ficasse perdido no meio de um mar de letras)
- b.st1.ntp.br
- c.st1.ntp.br
- d.st1.ntp.br
Cara, eu te juro que não é nada pessoal, mas vou ter que te refutar novamente, igual tive que fazer na oportunidade anterior. Não há relação nenhuma com o suporte ou não ao NTS. Vou colocar aqui a explicação que já dei anteriormente aqui:
Pra matar essa charada de uma vez por todas, há uns meses atrás eu escrevi um pequeno código em Python pra testar vários servidores NTP (incluindo todos os IPs por trás de cada DNS) , IPv4 e IPv6, NTP v3 e v4, e com source port 123 e aleatórias (no range que chamam de "Dynamic Ports" - de 49152 a 65535 - na RFC 6335).
Pra quem mais quiser fazer o teste na sua rede, o código tá aqui (apenas 78 linhas) e é bem simples de rodar (só tem dnspython e scapy como dependências):
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test.py
E o resultado do teste executado na minha rede (Vivo em Porto Alegre/RS) está nesse CSV aqui:
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test_output_vivo.csv
Agora com esta metodologia muito mais precisa, prevendo todos os cenários do meu interesse em código, a visão ficou 100% clara.
(Antes meus testes foram meio imprecisos pois eu tentei utilizar vários dispositivos diferentes mas as coisas meio que saíram do controle - Sincronização de relógio do Windows, ntpd no Debian do roteador Ubiquiti EdgeRouter, chrony no Ubuntu Linux que uso no dia-a-dia, NTP Client no roteador MikroTik, entre outros - acabou que ficou muito confuso na hora de tirar conclusões, e eu achei, erroneamente, que havia distinção de comportamento entre NTP versão 3 e versão 4, enquanto que isso não se confirmou no teste mais recente com melhor metodologia)
Em resumo: a Vivo bloqueia tráfego UDP inbound na porta 123 (tanto em IPv4 quanto em IPv6), porém whitelista IPs (todos IPv4) de alguns servidores específicos do NTP.br.
No cenário do Windows, que usa porta origem 123, a sincronização funcionou com estes IPs do NTP.br (aparentemente whitelistados):
Porém a sincronização não funcionou com estes IPs do NTP.br:
Ou seja:
Posto isso, minha recomendação para configurar no Windows é nesta ordem:
- Nenhum endereço IPv6 do NTP.br está whitelistado, então nenhum deles funciona
- O gps.ntp.br possui 2 endereços IPv4, porém a Vivo só whitelista 1 deles (apenas o que o NTP.br divulga no site deles)
- b.st1.ntp.br / c.st1.ntp.br / d.st1.ntp.br - Possuem apenas endereços IPv4 e todos estão whitelistados pela Vivo, portanto todos funcionam. Estes devem funcionar para todo mundo e são as opções que eu recomendo
- a.ntp.br / b.ntp.br / c.ntp.br / a.st1.ntp.br - Possuem endereços IPv4 e IPv6, com todos os IPv4 whitelistados pela Vivo e funcionando, enquanto que nenhum dos IPv6 o são e, portanto, não funcionam. Para quem só tem IPv4 configurado, estes também devem funcionar normalmente. Já para quem possui conectividade IPv6, estes podem apresentar problemas esporádicos pois funcionará quando o cliente NTP fizer uso de IPv4 mas não funcionará quando fizer uso de IPv6
- gps.ntp.br - Este é o que eu menos recomendo pois possui 4 IPs, sendo 2 IPv4 e dois IPv6, porém apenas 1 endereço IPv4 está whitelistado pela Vivo e funcionando, enquanto os demais 3 não funcionam
O NTP Pool Project é um caso bem curioso. Ele "funciona", mas só quando entrega um IP que é do próprio NTP.br. Como ele agrupa um punhado de servidores NTP públicos e os entrega num DNS deles, ele pode te entregar vários IPs que não funcionam, até entregar um IP do NTP.br que vai funcionar.
No último teste que eu conduzi, o DNS deles me entregou 4 IPs, sendo 1 deles pertencente ao NTP.br. E, veja só, este IP foi o único que funcionou no cenarário do Windows (porta origem 123). Testei tanto o pool.ntp.br quanto o br.pool.ntp.br:
Então, no final das contas, se os únicos IPs que funcionam são do NTP.br, então é melhor eu apontar pra um servidor do NTP.br logo ehheheheheh
(O nome da interface de saída da WAN e a prioridade da regra de NAT IPv4 devem ser ajustadas de acordo com a sua configuração em particular)
IPv4:
set service nat rule 6250 outbound-interface pppoe0
set service nat rule 6250 outside-address port 49152-65535
set service nat rule 6250 protocol udp
set service nat rule 6250 source port 123
set service nat rule 6250 type masquerade
IPv6:
$ sudo ip6tables -t nat -A POSTROUTING -o pppoe0 -p udp --sport 123 -j SNAT --to-source :49152-65535(O nome da interface ou da lista de interfaces de saída da WAN e a ordem da regra de NAT IPv4 devem ser ajustadas de acordo com a sua configuração em particular)
IPv4:
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535
IPv6:
/ipv6 firewall nat add action=src-nat chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535Nada pessoal, eu não lembro de ter visto sua mensagem a mim sobre o assunto.TL; DR: Recomendo que usem um destes servidores NTP aqui:
(Ao longo deste post eu contextualizo o motivo desta recomendação. É que como ele acabou ficando muito extenso, eu não queria que o ponto mais importante ficasse perdido no meio de um mar de letras)
- b.st1.ntp.br
- c.st1.ntp.br
- d.st1.ntp.br
Cara, eu te juro que não é nada pessoal, mas vou ter que te refutar novamente, igual tive que fazer na oportunidade anterior. Não há relação nenhuma com o suporte ou não ao NTS. Vou colocar aqui a explicação que já dei anteriormente aqui:
Pra matar essa charada de uma vez por todas, há uns meses atrás eu escrevi um pequeno código em Python pra testar vários servidores NTP (incluindo todos os IPs por trás de cada DNS) , IPv4 e IPv6, NTP v3 e v4, e com source port 123 e aleatórias (no range que chamam de "Dynamic Ports" - de 49152 a 65535 - na RFC 6335).
Pra quem mais quiser fazer o teste na sua rede, o código tá aqui (apenas 78 linhas) e é bem simples de rodar (só tem dnspython e scapy como dependências):
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test.py
E o resultado do teste executado na minha rede (Vivo em Porto Alegre/RS) está nesse CSV aqui:
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test_output_vivo.csv
Agora com esta metodologia muito mais precisa, prevendo todos os cenários do meu interesse em código, a visão ficou 100% clara.
(Antes meus testes foram meio imprecisos pois eu tentei utilizar vários dispositivos diferentes mas as coisas meio que saíram do controle - Sincronização de relógio do Windows, ntpd no Debian do roteador Ubiquiti EdgeRouter, chrony no Ubuntu Linux que uso no dia-a-dia, NTP Client no roteador MikroTik, entre outros - acabou que ficou muito confuso na hora de tirar conclusões, e eu achei, erroneamente, que havia distinção de comportamento entre NTP versão 3 e versão 4, enquanto que isso não se confirmou no teste mais recente com melhor metodologia)
Em resumo: a Vivo bloqueia tráfego UDP inbound na porta 123 (tanto em IPv4 quanto em IPv6), porém whitelista IPs (todos IPv4) de alguns servidores específicos do NTP.br.
No cenário do Windows, que usa porta origem 123, a sincronização funcionou com estes IPs do NTP.br (aparentemente whitelistados):
Porém a sincronização não funcionou com estes IPs do NTP.br:
Ou seja:
Posto isso, minha recomendação para configurar no Windows é nesta ordem:
- Nenhum endereço IPv6 do NTP.br está whitelistado, então nenhum deles funciona
- O gps.ntp.br possui 2 endereços IPv4, porém a Vivo só whitelista 1 deles (apenas o que o NTP.br divulga no site deles)
- b.st1.ntp.br / c.st1.ntp.br / d.st1.ntp.br - Possuem apenas endereços IPv4 e todos estão whitelistados pela Vivo, portanto todos funcionam. Estes devem funcionar para todo mundo e são as opções que eu recomendo
- a.ntp.br / b.ntp.br / c.ntp.br / a.st1.ntp.br - Possuem endereços IPv4 e IPv6, com todos os IPv4 whitelistados pela Vivo e funcionando, enquanto que nenhum dos IPv6 o são e, portanto, não funcionam. Para quem só tem IPv4 configurado, estes também devem funcionar normalmente. Já para quem possui conectividade IPv6, estes podem apresentar problemas esporádicos pois funcionará quando o cliente NTP fizer uso de IPv4 mas não funcionará quando fizer uso de IPv6
- gps.ntp.br - Este é o que eu menos recomendo pois possui 4 IPs, sendo 2 IPv4 e dois IPv6, porém apenas 1 endereço IPv4 está whitelistado pela Vivo e funcionando, enquanto os demais 3 não funcionam
O NTP Pool Project é um caso bem curioso. Ele "funciona", mas só quando entrega um IP que é do próprio NTP.br. Como ele agrupa um punhado de servidores NTP públicos e os entrega num DNS deles, ele pode te entregar vários IPs que não funcionam, até entregar um IP do NTP.br que vai funcionar.
No último teste que eu conduzi, o DNS deles me entregou 4 IPs, sendo 1 deles pertencente ao NTP.br. E, veja só, este IP foi o único que funcionou no cenarário do Windows (porta origem 123). Testei tanto o pool.ntp.br quanto o br.pool.ntp.br:
Então, no final das contas, se os únicos IPs que funcionam são do NTP.br, então é melhor eu apontar pra um servidor do NTP.br logo ehheheheheh
Como posso rodar script python no windows? Podemos ver se teremos os mesmos resultadosTL; DR: Recomendo que usem um destes servidores NTP aqui:
(Ao longo deste post eu contextualizo o motivo desta recomendação. É que como ele acabou ficando muito extenso, eu não queria que o ponto mais importante ficasse perdido no meio de um mar de letras)
- b.st1.ntp.br
- c.st1.ntp.br
- d.st1.ntp.br
Cara, eu te juro que não é nada pessoal, mas vou ter que te refutar novamente, igual tive que fazer na oportunidade anterior. Não há relação nenhuma com o suporte ou não ao NTS. Vou colocar aqui a explicação que já dei anteriormente aqui:
Pra matar essa charada de uma vez por todas, há uns meses atrás eu escrevi um pequeno código em Python pra testar vários servidores NTP (incluindo todos os IPs por trás de cada DNS) , IPv4 e IPv6, NTP v3 e v4, e com source port 123 e aleatórias (no range que chamam de "Dynamic Ports" - de 49152 a 65535 - na RFC 6335).
Pra quem mais quiser fazer o teste na sua rede, o código tá aqui (apenas 78 linhas) e é bem simples de rodar (só tem dnspython e scapy como dependências):
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test.py
E o resultado do teste executado na minha rede (Vivo em Porto Alegre/RS) está nesse CSV aqui:
https://github.com/yuripg1/network-toolbox/blob/main/ntp_test_output_vivo.csv
Agora com esta metodologia muito mais precisa, prevendo todos os cenários do meu interesse em código, a visão ficou 100% clara.
(Antes meus testes foram meio imprecisos pois eu tentei utilizar vários dispositivos diferentes mas as coisas meio que saíram do controle - Sincronização de relógio do Windows, ntpd no Debian do roteador Ubiquiti EdgeRouter, chrony no Ubuntu Linux que uso no dia-a-dia, NTP Client no roteador MikroTik, entre outros - acabou que ficou muito confuso na hora de tirar conclusões, e eu achei, erroneamente, que havia distinção de comportamento entre NTP versão 3 e versão 4, enquanto que isso não se confirmou no teste mais recente com melhor metodologia)
Em resumo: a Vivo bloqueia tráfego UDP inbound na porta 123 (tanto em IPv4 quanto em IPv6), porém whitelista IPs (todos IPv4) de alguns servidores específicos do NTP.br.
No cenário do Windows, que usa porta origem 123, a sincronização funcionou com estes IPs do NTP.br (aparentemente whitelistados):
Porém a sincronização não funcionou com estes IPs do NTP.br:
Ou seja:
Posto isso, minha recomendação para configurar no Windows é nesta ordem:
- Nenhum endereço IPv6 do NTP.br está whitelistado, então nenhum deles funciona
- O gps.ntp.br possui 2 endereços IPv4, porém a Vivo só whitelista 1 deles (apenas o que o NTP.br divulga no site deles)
- b.st1.ntp.br / c.st1.ntp.br / d.st1.ntp.br - Possuem apenas endereços IPv4 e todos estão whitelistados pela Vivo, portanto todos funcionam. Estes devem funcionar para todo mundo e são as opções que eu recomendo
- a.ntp.br / b.ntp.br / c.ntp.br / a.st1.ntp.br - Possuem endereços IPv4 e IPv6, com todos os IPv4 whitelistados pela Vivo e funcionando, enquanto que nenhum dos IPv6 o são e, portanto, não funcionam. Para quem só tem IPv4 configurado, estes também devem funcionar normalmente. Já para quem possui conectividade IPv6, estes podem apresentar problemas esporádicos pois funcionará quando o cliente NTP fizer uso de IPv4 mas não funcionará quando fizer uso de IPv6
- gps.ntp.br - Este é o que eu menos recomendo pois possui 4 IPs, sendo 2 IPv4 e dois IPv6, porém apenas 1 endereço IPv4 está whitelistado pela Vivo e funcionando, enquanto os demais 3 não funcionam
O NTP Pool Project é um caso bem curioso. Ele "funciona", mas só quando entrega um IP que é do próprio NTP.br. Como ele agrupa um punhado de servidores NTP públicos e os entrega num DNS deles, ele pode te entregar vários IPs que não funcionam, até entregar um IP do NTP.br que vai funcionar.
No último teste que eu conduzi, o DNS deles me entregou 4 IPs, sendo 1 deles pertencente ao NTP.br. E, veja só, este IP foi o único que funcionou no cenarário do Windows (porta origem 123). Testei tanto o pool.ntp.br quanto o br.pool.ntp.br:
Então, no final das contas, se os únicos IPs que funcionam são do NTP.br, então é melhor eu apontar pra um servidor do NTP.br logo ehheheheheh
Também não consegui subir a VIVO 2 no G7, mais vou deixar ele aqui para numa emergência usar na Live Tim (IHS).
pip install dnspython
pip install scapypython ntp_test.pySe for antigo com wifi5 sim, os novos com wifi6 a galera ta recebendo capada ou sendo capado em atualização. Algumas pessoas conseguiram burlar isso mudando a linguagem da pagina do modem, mas eu mesmo nao consegui, sigo com hgu wifi capado 6, nao da pra por em bridge pela 15.1 normal e na 15.1/padrao nem acessa.
