Linio Alan

Pode ser por causa de driver, de interferência por programas de segurança ou até mesmo sistema infectado por malware, isso levando em consideração o que você relatou apenas. Procure ver se é possível fazer a "Restauração à um ponto anterior" no seu Windows (caso ele tenha salvo um ponto de restauração) e investigue as demais questão: atualizei o driver da placa de rede e faça uma varredura com antivírus atualizado no seu sistema, tudo isso ainda é só um começo do que pode ser feito.

Problema semelhante foi relatado e resolvido neste outro tópico: https://www.clubedohardware.com.br/forums/topic/1691210-velocidade-de-download-no-launcher-da-steam-inferior-a-outros-launchers/

O código de cada tipo de sinalização dos leds da placa de rede são: Led Laranja Apagado: Sem portadora, Sinal Ethernet não detectado Led Laranja Aceso: Com Portadora, Sinal Ethernet OK Led Verde Apagado: Sem link Led Verde Aceso: Link Pronto Led Verde Piscando: Comunicando Led vermelho: Placa danificada Considerando isso e o que foi relatado por você aparentemente o problema foi e continua sendo o cabo de rede ainda já que a atual sinalização indica que a conexão no nível Ethernet está presente (Led Laranja Aceso). Reveja a crimpagem do cabo e certifique que está seguindo uma das normas 568A ou 568B e ainda fazendo teste de continuidade com um testador de cabo.

No seu PC as portas lógicas usadas dá a entender que a faixa usada é entre 52800/52900 TCP/UDP bom sendo assim agora viste https://www meuip.com e veja qual o IP público atual para sua conexão e faça testes externos para o seu IP público disparando para quaisquer das portas do intervalo mencionado acima. Pode usar algum site como https://portchecker.co e insira o IP público e as portas que quer verificar. Desta forma você não precisa aguardar seu provedor lhe passar alguma informação ou pelo menos eles podem só confirmar o que você descobriu. Obs.: caso você tenha acesso à página de configuração do modem/ONT/roteador do provedor tente ver por lá quais as portas estão sendo usadas nas conexões abertas, são informações mais precisas das portas realmente utilizadas.

Entendi, então ai no caso ele está travado mesmo. Talvez nem a página de configuração você consiga acessar mais estando do jeito que está. Aí no caso você pode ainda tentar o reset físico pra ver se algo acontece, veja como no link: https://www.dlink.com/uk/en/support/faq/routers/mobile-routers/dir-series/dir-505/how-do-i-reset-my-dir-505-to-factory-default-settings Caso mesmo isso não funcione, então pode levar à um técnico eletrônico para ver se ainda tem jeito caso contrário pode ter perdido ele.

Olá @zyclow171 Infelizmente hoje o IPv4 público está esgotado já há alguns anos, e o mais provável é que o seu link Fibralink seja configurado baseado em CGNAT que, basicamente significa dizer que as portas abertas estejam numa faixa muito restrita de portas TCP/UDP e o IP público seja compartilhado com dezenas/centenas de outros usuários, mas mesmo assim você pode abrir o CMD no Windows e digitar "netstat -a" e ver algumas das portas em uso para chegar ao range de portas que o seu provedor configurou para o seu link. Isso quer dizer que o seu DVR muito provavelmente irá funcionar baseado em configuração de DDNS (Dynamic DNS) que muitas vezes dá pra configurar diretamente no equipamento DVR e, com as portas abertas mapeadas por você via "netstat -a" aí sim você poderá configurar a porta aberta no DVR. Ainda assim você pode entrar em contato com o suporte da Fibralink e requisitar diretamente para eles qual é a faixa de portas TCP/UDP reservado para o seu link (caso eles tenham CGNAT).

Precisa saber exatamente qual MAC address você bloqueou, na teoria simples e clara de redes o IP só é atribuído à uma interface de rede cujo MAC address foi instalado na tabela ARP, sem isso nenhum IP deveria ser atribuído ao sensor, daí então vem a pergunta: será que esse sensor tem duas interfaces WiFi? Digo isso até porque agora de acordo com a descrição o sensor possui dois endereços IPs: 192.168.x.x e 170.82.1.x.x, e geralmente um único endereço IP é atribuído por interface (há exceções claro mas serão sempre exceções). Fico pensando se a interface cujo endereço MAC você bloqueou não era a interface do IP 170.82.1.x.x. E mais: como e por qual motivo estava tendo acesso negado? Você possui algum firewall na rede para além do firewall embutido nos roteadores? Muito estranho, por regra, o IP da rede LAN -- 192.168.x.x -- apenas deveria ser atribuído quando não houvesse nenhum bloqueio, não o contrário. É o IP 170.82.1.x.x, certo? Você consegue sim, basta fazer o "whois" em cima desse IP: https://ipinfo.io/170.82.1.1 Exato Caio, atualmente infelizmente mesmo com suporte ativo há brechas que ou não são divulgadas/desconhecidas ainda, ou que os fabricantes demora e/ou levam um certo tempo para lançar a correção via atualização de software, daí que surgiu no mercado o framework "Zero Trust" que basicamente é uma filosofia de admitir que você já foi invadido e o invasor está dentro da sua rede, independente se o seu firewall/IPS/IDS etc tenham ou não identificado a ameaça. Desta forma, adotasse os meios de mitigação como "hardening", "Isolation", "traffic inspection by behavior" entre outros... em redes grandes principalmente corporativas, o ideal é ao menos isolar o tráfego de cada host e inspecionar o tráfego por algum 'Intrusion Detection/Protection System" com IA, é bastante complexo mas é o que se tem feito ultimamente em larga escala. No seu caso acredito que se o app de gerência não tiver um servidor interno que colete os dados enviados pelo sensor, e ele precisar ter acesso à internet para lhe atualizar via app pela internet, então isso por si só já seria uma exposição ao sensor à ataques, embora ele esteja atrás da sua rede LAN. Por isso o ideal seria essa coleta de informações ocorrer no modelo "cliente-servidor" com o sensor enviando dados para um syslog/server local dentro da sua rede LAN, e daí sim então o syslog lhe encaminhar os dados coletados para o app, ou ainda você poder acessar o seu sensor apenas via VPN com encriptação ativa, talvez o seu app já ofereça algo nesse sentido. Mas dependendo então da sua rede atual aí, seria interessante já pesquisar por opções de segurança corporativas, um conjunto de ferramentas e tecnologia que lhe dê uma cobertura contra ataques e vazamento de dados, mas sempre vai antes depender tanto do que você tem para proteger internamente quanto do seu orçamento, dependendo do que for pode compensar ou não adquirir soluções mais avançadas de segurança.

Show de bola Caio! Eu também curto imersão nas specs dos devices, realmente sempre tem muito pra assimilar e entender como tudo funciona. Pela sua explicação me parece que você tinha realizado então um bloqueio por MAC e por isso a sinalização dele parou de chegar no app de gerência, e explica o porquê de o endereço MAC dele simplesmente sumir da tabela ARP do seu roteador, mas que é estranho ele ter um IP externo/público isso também é, procure ver de onde é esse IP até pra uma questão de cybersecurity pois esse sensor é um dispositivo IoT e infelizmente alvo fácil principalmente se exposto na internet aberta Parabéns amigo pelo empenho e detalhamento, faz jus à patente de Admim de fórum Abraço Tmj!

Oi @Emanuel onofre O problema amigo é que provavelmente ou a OLT da Oi -- que está do outro lado da fibra conectando à sua ONU -- ou está passando mais parâmetros que infelizmente você não tem acesso para configurar na sua ONT Huawei ou ainda, a OLT na Oi não suporta configuração nem bridge e nem modo router para ONTs que não estejam com SN (Serial Number) inclusos lá no seu cadastro/perfil de usuário (servidor RADIUS) ou no CRM de Telecom que tem integração com a OLT. O ideal mesmo seria você conversar com algum técnico de campo deles, porque no suporte via telefone você realmente não vai conseguir nada, com o técnico de campo você tem mais chances de fazer funcionar ou ao menos saber os detalhes técnicos que impedem sua tentativa de configurar uma ONT "terceira", pois por mais que seja algo até relativamente simples, é uma parte da rede da própria Oi que contratualmente não há previsão legal para ser substituída por outra ao gosto do cliente, a gerência remota de ONTs existe também para se evitar brechas graves de segurança da informação. Então arrume um técnico da Oi, via chamado técnico mesmo, para bater um papo amigável e tentar a troca com a sua ONT.

@Arthurex se importaria de compartilhar os detalhes do que você fez para resolver, assim outros usuários com mesmo ou problema parecido possam ter acesso à solução

"169.254.x.x" é o famoso endereço APIPA (auto-configurado) do Windows quando não houve sucesso na atribuição via DHCP na rede @Arthurex Certifique-se de que a configuração está de acordo com o sugerido pelos colegas e até mesmo, pode haver a necessidade de revisar as configurações do roteador para confirmar se o DHCP-server esta ativadou e/ou se existe de fato. Para efeitos de troubleshooting, atribuir um IP fixo nas propriedades de IPv4 pode ser necessário, claro, desde que dentro do range/faixa de IPs do seu servidor DHCP local. Obs.: dadas as atuais condições aí na sua rede, talvez você precise acessar a página de configuração do roteador de outro dispositivo na rede que esteja com a conexão já estabelecida.

Olá @Helamã bem-vindo ao fórum Poderia postar uma foto para vermos quais leds estão vermehos etc? De qualquer forma, quando um led fica vermelhor em um roteador D-Link a melhor ação que me ocorre é fazer o upgrade de firmware (se achar para download já que é uma linha descontinuada pela D-Link).

Única coisa que me ocorre no momento é o seu sensor ter embutido um VPN_client que fecha túnel VPN externamente mesmo, e o VPN_server atribuir um IP público ao sensor, explicaria porque ele se conecta à internet pela sua rede WiFi com outro IP, só precisa ver se essa empresa GEONAV possui registro na ANATEL até pra ver se os equipamentos de redes deles geram endereços físicos MAC identificáveis, o fato de o MAC não constar na tabela ARP do seu roteador pode ter relação com isso.

Pelos relatos de outros usuários nos fóruns da Google, o problema parece estar associado à uma falha dos servidores do Google em realizar a resolução de nomes (DNS lookup) para o domínio associado ao seu servidor de email, algo que os usuários de lá conseguiram resolver acionando o Google Support: Contact Google Workspace support

Segundo Tommy - MSFT (Microsoft Community Support Specialist) este problema ocorre porque a rede do Window não consegue passar no teste NCSI (Network Connectivity Status Indicator) onde o sistema tem acesso à internet mas indica que não há conexão de rede. Tommy fala que para resolver o problema é necessário salvar o conteúdo abaixo em arquivo formato .reg (salva no bloco de notas e altera a extensão para .reg) antes tendo o cuidado de fazer o backup de todo o Registro do Windows antes de aplicar o patch - Window menu > digite 'Editor de Registro' > opção 'Arquivo" > Exportar (para o backup) Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet] "ActiveDnsProbeContent"="131.107.255.255" "ActiveDnsProbeContentV6"="fd3e:4f5a:5b81::1" "ActiveDnsProbeHost"="dns.msftncsi.com" "ActiveDnsProbeHostV6"="dns.msftncsi.com" "ActiveWebProbeContent"="Microsoft Connect Test" "ActiveWebProbeContentV6"="Microsoft Connect Test" "ActiveWebProbeHost"="www.msftconnecttest.com" "ActiveWebProbeHostV6"="ipv6.msftconnecttest.com" "ActiveWebProbePath"="connecttest.txt" "ActiveWebProbePathV6"="connecttest.txt" "CaptivePortalTimer"=dword:00000000 "CaptivePortalTimerBackOffIncrementsInSeconds"=dword:00000005 "CaptivePortalTimerMaxInSeconds"=dword:0000001e "EnableActiveProbing"=dword:00000001 "PassivePollPeriod"=dword:0000000f "StaleThreshold"=dword:0000001e "WebTimeout"=dword:00000023 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies] [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator] @="" "NoActiveProbe"=dword:00000000 "DisablePassivePolling"=dword:00000001 No entanto à relato de outros usuários dizendo que apenas a entrada abaixo já foi capaz de resolver o problema: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator] @="" "NoActiveProbe"=dword:00000000 "DisablePassivePolling"=dword:00000001 Porém há ainda outros relatos de usuários que também conseguiram resolver este problema de um outro jeito sem ser pelo Registro do Windows, conforme abaixo: 1ª abordagem: Window menu > Configurações > Rede e Internet > Configurações Avançadas de Rede > Redefinição de Rede > [Restaurar Agora = YES] e reinicie 2ª abordagem: - Window menu > digite 'cmd' e clica com botão direito pra opção "Executar como Administrador" - Execute os comandos abaixo: netsh int ip reset c:\resetlog.txt netsh winsoc reset ipconfig /flushdns - Reinicie o sistema 3ª abordagem: - Window menu > digite: Gerenciador de Dispositivos - Expanda "Adaptadores de Rede" e clica com botão direito pra opção "Propriedades" - Passe pra aba "Driver" e clique em "Desinstalar Dispositivo" > Desinstalar - Reinicie o sitema Tome sempre MUITO cuidado ao efetuar alterações no Registro do Windows, sempre lembre-se de fazer o backup antes. Toda e qualquer alteração nele é de sua responsabilidade e risco. Caso não tenha segurança nesta parte recomendo passar para as demais abordagens/alternativas e/ou procurar o técnico de TI/Informática da sua confiança. Lembre-se de atualizar seu tópico de acordo com o progresso obtido para que mais usuários tenham acesso à solução definitiva implementada.

Muito bom! Todos os testes que você fez apontam mesmo para a total normalidade da conectividade IPv4 entre o seu PC e o roteador/gateway padrão e a internet. O fato de o ícone de rede ter mostrado conexão ok após a instalação do driver de rede mostra provavelmente que houve mudança em algum parâmetro que causava o erro, mas logo voltou após o firmware ser reiniciado, posso estar errado mas me parece que pode ser a própria placa de rede (física) com algum funcionamento errático causando falha na comunicação entre "placa <> firmware <> sistema operacional". Certifique-se de que a opção abaixo esteja desativada como aparece: Diante disso eu diria que você não tem muito com o que se preocupar se tudo continuar funcionando como está, chegou à ver se os seus jogos estão conectando agora? P.S.: no fórum da ASUS, há menção quanto serviço ao "ASUS fancontroller" que vem instalado com o "AI Suite" e que causa problema específico de rede semelhante ao seu. Diz que esse serviço "ASUS fancontroller" precisa ser mudado o tipo de inicialização de: automático, para: manual. Para localizar o serviço "ASUS fancontroller" abra o executar com o atalho "Windows + R" e digite: services.msc

Uma interface USB que emula conexão Wi-Fi/Internet 100% compatível com Wii U eu diria que é extremamente improvável já que ou seria um hardware Nintendo original ou devidamente homologado, isso porque um device dessa natureza deverá ser do tipo UPnP (Universal Plug and Play) uma vez que o Wii não teria como instalar driver de rede, tudo que não for oficial da fabricante, caso exista, tem grandes chances de ter problemas SE funcionar de fato.

Me parece mais ser um problema de roteamento ou de DNS do seu provedor de internet do que algo especifico do ONU AN5506, muitos fatores podem estar envolvidos. Entre em contato com a sua operadora e reporte esse problema, esse pode ser um sintoma que provavelmente esta afetando muitos outros sites que voce ainda nem se deu conta ainda.

Esse ícone pode apontar tanto para falhas físicas de rede quanto lógicas, eu já tive experiência em muitos casos que cabo de rede e até sujeira no conectar RJ45 da placa-mãe sujo causou isso, ou mesmo DNS enfim... a lista é longa. Eu recomendaria abrir agora o "cmd" do Windows e fazer um teste de ping para o IP de gateway padrão estendido, assim: ping 192.168.1.1 -t substitua o IP acima pelo IP de gateway padrão da sua rede pelo comando "ipconfig /all" Acompanhe e verifique se já perdas também com estes outros comandos: netstat -e netsh interface ipv4 show interfaces Acompanhe e veja se há incremento de erros nas estatísticas, pode postar em sua próxima mensagem o output se desejar que analisemos também. Na parte de hardware, veja as condições do seu cabo de rede atual, em ambas as pontas e no meio do cabo, e ainda as portas Ethernet em ambos os lados: do PC e do roteador. Em tempo: realize a pesquisa via Windows Update por alguma versão de firmware mais atual da placa de rede, ou visite o site do fabricante e veja se há algum driver de rede e/ou de controlador Ethernet disponível para baixar.

Ok prossiga no reparo proposto pelo Windows, caso seja bem-sucedido o ícone de rede finalmente irá mudar para o normal caso contrário o Windows irá lhe indicar a razão de porquê o erro não pôde ser corrigido.

Esse é o famoso ícone de "Conexão Lenta Ou Limitada" do Windows, costuma aparecer por 'n' fatores de conectividade. Sugiro rodar o "Diagnóstico de Rede/Conexão" do Windows para ele lhe dar um norte do que possa estar ocorrendo, abra o famoso "Conexões de Rede" executando o comando ncpa.cpl via atalho "Win + R" e realize o diagnóstico da interface de rede conectada à sua internet: Ao final será apresentado um breve relatório dos erros encontrados, poste em sua próxima mensagem o que aparecer.

Ola @RexPraum que bom! Fico feliz por você, sinta-se sempre convidado à participar ativamente desta e outras áreas do Fórum do CdH, tmj!

Olá @alexandre.aoliveira o tutorial abaixo pode ser exatamente o que você procura:

ONTs costumam baixar as configurações da OLT à que estão diretamente conectadas, pode ser esta a razão que você estar vendo "configurações antigas" ao resetar. Outro fator pode ser que o firmware dele seja personalizado pelo provedor de internet, dessa forma ao efetuar o resete físico o mesmo irá pré-carregar informações de configuração básicas de acordo com o que o provedor definiu, isso é bem comum também.

Posta print da tela para entenderem melhor o que você quer dizer por "opção da máscara de rede ter sumido", está vago até para quem tem o mesmo roteador. Mencione também qual a atual versão de firmware que foi instalado aí.