network woes

Wed Dec 23 08:41:49 MST 2009

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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20091223/6a942649/attachment.htm