Laptop can ping, but not browse. Clean windows install. Telnet doesn't work. Not the network

Question

The laptop is able to ping and tracert, but not browse the internet. I'll start by saying what I've already ruled out:

• It is a completely fresh windows install
• The network works fine for the other 5 devices, both wifi and wired
• Telnet does not connect
• Pinging domain name and IP address works fine
• am able to browse the laptop via desktop on network, but not vice versa
• have verified that there are no proxy settings active

So, anyone have any ideas what could be causing this, aside from the stuff I've already tried? I've already diagnosed the stuff listed above, so telling me to telnet will be non-productive. Telling me to try a different browser or check for viruses or disable AV also won't help, as I've ruled these things out. I apologize for my tone, but I appear to be getting the same few answers every time I ask this question, at which point my question must be disappearing.

Solution 1

Try this method:

• Click on Start --> In search box, type cmd --> Then "CMD" will be displayed in the search --> Now right-click on "CMD" ---> Select "Run as administrator".

• Now enter this command and press "Enter".

netsh int ip reset resetlog.txt

• Reboot your computer

Good Luck.

Solution 2

Packet size is another possible cause of network issues.

I had a similar problem recently. ping works, so I have internet connectivity, but most TCP-based connections hang and finally time out. It turns out that my wireless card is buggy or under-powered and is not handling large packets properly. One of the differences between ping and most TCP connections is that ping uses small packets by default. To check if large packets are delivered normally, use ping with different packet sizes, by using the -l option^† (on Windows). For example, to ping address 10.0.99.221 with 1000 bytes in the data field, type:

ping -l 1000 10.0.99.221

In my case, pinging with 500 bytes causes a 95% packet loss, while pinging with 56 bytes works normally.

Setting MTU (Maximum Transmission Unit) to a smaller value may temporarily work around the issue. This affects performance negatively, though.

In my case, setting MTU to 400 makes the network temporarily usable. This is rather small and not recommended. Since this is a hardware-related issue, the hardware should be fixed or replaced.
______________
^† That's lower case L; maybe it stands for packet length.

Solution 3

A couple ideas:

1. 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.
2. 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.
3. 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 ping example.com).
4. 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.

Strace(esque) Links: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552060%28v=vs.85%29.aspx

http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

Comments

[Peter Choi]

If you can ping it, you have IP connectivity. If by "browse the laptop" you mean you can see and manipulate files on the laptop, TCP is working file. If you can resolve DNS names on the laptop, UDP is working. Is anything else failing besides telnet?

[Brett]

Hey Fred, the internet browser isn't working. And yeah that's what I meant by browse the laptop. However, while I can see the laptop on the desktop, I can't see the desktop on the laptop.

[Steve Reeder]

FYI to check what type of network connection windows is using, right click on the network icon in the system tray, choose "Open Network And Sharing Center" and when that window opens it will show your ethernet connections and it will say Work, Public or Private under each connection. Sometimes the connection type will get messed up and be unknown or something like that and will refuse to get a proper IP address.

[Bas]

Did you check if a proxy server is activated in your browser settings?<br> If so, remove it....

[MaQleod]

telnet does not connect to what? and on what port? Telnet is a good way to test TCP connectivity on any given port, but only to the address specified - telnet not working to one address is not really proof of anything concerning your internet connection as a whole - so yes, it still may help to use telnet. Futhermore, on-network hostname resolution and SMB connectivity is also not really important when testing internet connectivity.

[MaQleod]

One final thought, and this is because of the SMB connectivity issue, is that you may have some windows firewall rules that might be hindering things.

[barlop]

what do you mean you can't browse? With IPs you can't browse? (then you can't browse) but it's not clear that you've tested that.

[Brett]

Just ran the command. Rebooting now. Cross your fingers for me! edit Nope, no dice. Same issues. Checked connected devices on router and it doesn't appear to be an IP conflict.

[mumair]

In my case only IE was not working other software was fine, then this method was helpful for me.