I'm having enough problems with certain sites that I need to find out what the problems is. I have the newest browsers on XP , outdated by one release on my newest Linux distros and some sites are so problematic that they are almost useless ,images won't load ,java won't work etcetera.I think it's my ISP but I would like to know specifically. I'd like to be able to know the entire route of the packet I guess.

What is the basic approach to poking at this problem in what I would imagine is BASH commands?

Thanks in advance!

Are you saying web sites load in one OS but not the other? If so, it's unlikely your ISP is to blame.

In order to load a web page, the browser must first resolve the site name into an IP address. That requires a working DNS resolver in the OS, which means the OS must be configured to use one or more working DNS servers. An incorrect DNS server entry can cause considerable delays as the OS waits for the request to time out.

You can test the DNS resolver with the host, dig or nslookup commands. nslookup www.somesite.com should return the IP address of the web server. If it doesn't or if it takes more than a second or two, check your DNS settings.

Once the name has been resolved, a TCP connection must be established to the web server. Since the server is not on your local network, the IP packet must be routed through a gateway. Misconfigured IP parameters (wrong netmask, more than one default gateway) can cause failures and/or delays.

traceroute www.somesite.com will show you the path an IP packet has to traverse to reach the server.

You can use telnet or nc (netcat) to simulate a web browser connection to TCP port 80. telnet www.somesite.com 80 should return "Connected to www.somesite.com". An error message means no TCP connection could be established.

A possible source of TCP connection delays is a non-functional dual stack configuration. As you may know, the next-generation IP protocol, IPv6, is being deployed on the Internet. Not all ISPs support IPv6, though. If your OS is configured to use both IPv4 and IPv6 (dual stack) and the site in question supports IPv6, the web browser may attempt to connect using IPv6 rather than IPv4. If your ISP is still stuck in the dark ages doesn't yet support IPv6, the browser will have to wait for the IPv6 connection to time out before falling back to IPv4.

ping6 ipv6.google.com should tell you if your OS supports IPv6. A reply means all is fine, "timeout" or "destination unreachable" means you have no IPv6 route and should probably just disable IPv6 altogether.

Finally, you may also want to check the proxy settings in the browser, although an incorrectly configured proxy setting would usually result in total loss of web connectivity.

1 members found this post helpful.

...additionally
If you want the "route" a packet takes then forget about ping (ICMP) and traceroute (UDP) and instead tcptraceroute to the web server address and port (or use lft or maybe hping).


...exactly like it should. Given the recent "unfortunate incidents" I wouldn't change that.


Checking if something goes missing along the way could be done by fetching the page with cURL and comparing it with the source the browser shows. That's 'diff' usage basically. An on-line HTTP page or header checker may come in handy as autonomous reference. On top of that you can use on-line tools like tools.pingdom.com/fpt/ or in-browser tools like Firebug (Firefox) or Dragonfly (Opera) for page load analysis.

1 members found this post helpful.

I'll put your advice to work in the next couple of days and will post back with the results.