A couple ideas:
- Linux live CD test. Simply boot to a live cd and try accessing the network using that. I do this to see if the network stack used for your hardware is faulty.
- Try to browse your next hop using your browser. If you are on a home network it is usually
192.168.1.1 but you can find out with an
ipconfig and seeing what your default gateway is. You should see a web based interface.
- Change your DNS server on your computer to ones that have to be accessed on the Internet; as opposed to using your next hop (
192.168.1.1 or its ilk). After making that change try to resolve DNS (just
- Run a packet capture on your computer (or router) to see what packets are leaving your computer (post the pcap or a screenshot of that if you wish).
I recommend the last one because it seemed curious that ICMP worked across your router - but no TCP or UDP did. However, resolving a host is UDP. Upon further inspection of your old question I see that your DNS server is your next hop. So changing this should keep you from resolving DNS properly (making sure the problem is consistent).
If it does not work on Linux then we can identify the problem as hardware-related definitively. If you wish at that step we could
strace different processes to find out at what point it is failing.
If however, it works on Linux but not on Windows we would have to try to do more of work.
At that point you can try using a Windows strace (does not exist but links below). To see what processes are being called (and what are not) when you run ping vs telnet.
The problem would seem to be that when there is a TCP or UDP packet that needs to leave the network (access the Internet) the tcp/udp stack is not handing them off properly to the layer three. However, ICMP is a layer three protocol so it would be bypassing the tcp/udp stack. If however, completing step 2 above works, it shows that accessing the internal network does not seem to cause this problem, and completing step 3 above should show this by inversion (as in it should stop working). A packet capture will confirm this. To try and correct this from an elevated command prompt:
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
I would not recommend running those just without researching the problem. But that should help.