Trent Shipley wrote: 
Eric Shubert wrote:

  
Trent Shipley wrote:
  
    
Somewhere my connection to the Internet is borken.  Load times take
forever.  It doesn't seem to effect the wireless client routers, but I
have had trouble on both the wired machines under Ubuntu 9.10 and
Windows Vista.  Sometimes the Linux machine effectively looses
connectivity with the Internet.  It comes back if I log out of my X
session and log back in ... most of the time.  I have a firewall router,
but effectively no household LAN since I've been too lazy to really
figure out how to configure the Ubuntu desktop machine as a primary
domain controller, then adjust it's firewall to suit.


I'd like an idiot friendly tool to help track this problem down,
preferably on the Linux machine which seems to experience the problem
most consistently.

Baring a GUI tool friendly to mortal users, I am not above using the
@#$% command line and a text editor.


I am not too network savvy.  I have to look up the layers of the OSI
stack every time.  What is a reasonable diagnostic or fault tree for
approaching my symptoms.

It is also worth noting that this problem seems to date back to
precisely when I upgraded from Ubuntu 9.04 to 9.10.

    
      
I'd start with the tracert command.

  
    
Konqueror finds no info or man page for tracert.  tracert was not found
in any package name or description using KPackageManager or Synaptic.
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
tracert.exe is the windows command for traceroute. On linux it might look something like this:
  paul@paulbox:~ $ traceroute 4.2.2.2
  traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 40 byte packets
   1  myrouter.dns.lan (192.168.1.1)  0.160 ms  0.128 ms  0.108 ms
   2  airband-66-226-239-166.airband.net (66.226.239.166)  2.898 ms  1.295 ms  1.088 ms
   3  airband-69-26-225-125.airband.net (69.26.225.125)  3.203 ms  3.016 ms  3.435 ms
   4  airband-69-26-195-98.airband.net (69.26.195.98)  6.012 ms  4.424 ms  4.014 ms
   5  ge-6-12.car1.Phoenix1.Level3.net (4.53.104.185)  4.932 ms  4.901 ms  5.386 ms
   6  ae-8-8.ebr1.Dallas1.Level3.net (4.69.133.30)  31.993 ms  41.412 ms  36.033 ms
   7  ae-11-60.car1.Dallas1.Level3.net (4.69.145.3)  28.965 ms  29.329 ms ae-41-90.car1.Dallas1.Level3.net (4.69.145.195)  30.045 ms
   8  vnsc-bak.sys.gtei.net (4.2.2.2)  29.641 ms  29.706 ms  30.270 ms

from there you might see some inconsistencies along a hop, for instance if something on my internal network (number 1 in this case) said some response larger than 5 ms I'd check that out probably with a ping looking for packet loss for example:
  paul@paulbox:~ $ ping -c 10 -s 1500 192.168.1.1
  PING 192.168.1.1 (192.168.1.1) 1500(1528) bytes of data.
  1508 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.712 ms
  1508 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.676 ms
  1508 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.676 ms
  1508 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.671 ms
  1508 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.672 ms
  1508 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.675 ms
  1508 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.667 ms
  1508 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.672 ms
  1508 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.671 ms
  1508 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.659 ms

  --- 192.168.1.1 ping statistics ---
  10 packets transmitted, 10 received, 0% packet loss, time 8999ms
  rtt min/avg/max/mdev = 0.659/0.675/0.712/0.017 ms

the -c 10 is count 10, you might want to make this higher like 50 or so, and -s 1500 is for packet size the default is 56 but I find if it a bad switch larger packet sometimes create more packet loss make it easier to identify.  The bottom section is what's important it shows 0% packet loss and an average latency of .675ms which means there's no problem here.  Then I could just repeat this process on each hop from the traceroute until the problem is found.