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.