Re: network woes

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Paul Mooring
Date:  
To: Main PLUG discussion list
Subject: Re: network woes
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 -
> 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.
---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss