Algumas ideias:
- Teste de CD ao vivo do Linux. Basta inicializar em um live cd e tentar acessar a rede usando isso. Eu faço isso para ver se a pilha de rede usada para o seu hardware está com defeito.
- Tente navegar no seu próximo salto usando seu navegador. Se você está em uma rede doméstica, geralmente é
192.168.1.1
, mas você pode descobrir com um ipconfig
e ver qual é o seu gateway padrão. Você deve ver uma interface baseada na web.
- Altere seu servidor DNS em seu computador para aqueles que precisam ser acessados na Internet; ao invés de usar seu próximo salto (
192.168.1.1
ou sua laia). Depois de fazer essa alteração, tente resolver o DNS (apenas ping example.com
).
- Execute uma captura de pacote no seu computador (ou roteador) para ver quais pacotes estão deixando o seu computador (poste o pcap ou uma captura de tela dele, se desejar).
Eu recomendo o último porque parecia curioso que o ICMP funcionasse no seu roteador - mas nenhum TCP ou UDP funcionava. No entanto, a resolução de um host é UDP. Após uma inspeção mais aprofundada da sua pergunta antiga, vejo que o seu servidor DNS é o seu próximo salto. Então, mudar isso deve evitar que você resolva o DNS adequadamente (certificando-se de que o problema é consistente).
Se não funcionar no Linux, podemos identificar o problema como definitivamente relacionado ao hardware. Se você quiser nessa etapa, poderemos processar strace
de diferentes processos para descobrir em que ponto está falhando.
Se, no entanto, ele funcionar no Linux, mas não no Windows, teríamos que tentar fazer mais trabalho.
Nesse ponto, você pode tentar usar um strace do Windows (não existe, mas links abaixo). Para ver quais processos estão sendo chamados (e quais não são) quando você executa ping vs telnet.
O problema parece ser que, quando há um pacote TCP ou UDP que precisa deixar a rede (acessar a Internet), a pilha tcp / udp não os está entregando corretamente na camada três. No entanto, o ICMP é um protocolo de camada três, portanto, ele estaria ignorando a pilha tcp / udp. Se, no entanto, concluir o passo 2 acima funcionar, isso mostra que o acesso à rede interna não parece causar esse problema, e concluir a etapa 3 acima deve mostrar isso por inversão (como deveria parar de funcionar). Uma captura de pacotes confirmará isso. Para tentar corrigir isso a partir de um prompt de comando elevado:
netsh int ipv4 uninstall
netsh int ipv6 uninstall
netsh int tcp uninstall
netsh int ipv4 install
netsh int ipv6 install
netsh int tcp install
netsh winsock reset catalog
Eu não recomendaria executá-los apenas sem pesquisar o problema. Mas isso deve ajudar.
Links Strace (esque):
link
link
link
link