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 pelo seu próximo salto usando seu navegador. Se você estiver 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.
- Mude o seu servidor DNS no seu computador para aqueles que precisam ser acessados na Internet; ao invés de usar o seu próximo salto (
192.168.1.1
ou sua laia). Depois de fazer essa mudança, tente resolver o DNS (apenas ping example.com
).
- Execute uma captura de pacotes no seu computador (ou roteador) para ver quais pacotes estão deixando o seu computador (coloque o pcap ou uma captura de tela, se desejar).
Eu recomendo o último porque parecia curioso que o ICMP funcionasse em seu roteador - mas nenhum TCP ou UDP funcionava. No entanto, resolver um host é UDP. Após uma inspeção mais aprofundada da sua antiga pergunta, vejo que o seu servidor DNS é o seu próximo salto. Portanto, alterar isso deve impedir que você resolva o DNS adequadamente (certificando-se de que o problema seja consistente).
Se isso não funcionar no Linux, podemos identificar o problema como definitivamente relacionado ao hardware. Se você quiser nessa etapa, poderíamos strace
diferentes processos para descobrir em que ponto está falhando.
Se, no entanto, 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 da 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 em que deve parar de funcionar). Uma captura de pacotes confirmará isso. Para tentar corrigir isso 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.
Strace (esque) Links:
http://msdn.microsoft.com/pt-br/library/windows/hardware/ff552060%28v=vs.85%29.aspx
http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
http://technet.microsoft.com/pt-br/sysinternals/bb896645.aspx
http://technet.microsoft.com/pt-br/sysinternals/bb896647.aspx