On May 29, 2:21pm, phil wrote: > I'm not very knowledable about networking/internet type things. How > would I go about testing for packet loss? Your first clue that there's a problem is that things like http accesses, telnet sessions, ssh sessions, etc. will inexplicably hang for a short (or long) periods of time and then resume again (or not). Once that happens, you need to determine just how close the problem is to you. I.e, if it's between you and your ISP or in some route through your ISP, you can call your ISP and have them do something about it. If the problem is beyond that point, chances are good that a whole lot of people already know about it and will do something automatically (for both you and themselves). And, of course, it's possible that the problem is due to mis-configuration on your end, in which case it's your responsibility to fix it. In order to diagnose such a problem, tools like traceroute and ping are your friends. First you do a traceroute (if you can). E.g, redrock:kev$ /usr/sbin/traceroute primenet.com traceroute: Warning: primenet.com has multiple addresses; using 206.165.6.207 traceroute to primenet.com (206.165.6.207), 30 hops max, 40 byte packets 1 pipeline (192.168.200.100) 6.037 ms 6.133 ms 5.666 ms 2 is06.phx.gblx.net (206.165.11.206) 33.063 ms 27.139 ms 37.184 ms 3 fe2-0.cr3.PHX.gblx.net (206.165.11.254) 30.709 ms 29.241 ms 28.518 ms 4 fe8-1-0.cr1.PHX.gblx.net (206.165.6.113) 29.633 ms 27.950 ms 27.802 ms 5 usr07.primenet.com (206.165.6.207) 30.717 ms 30.100 ms 29.600 ms I chose to do my traceroute to one of the user machines at primenet because that's where my ssh session was hanging. Also, fetchmail was connecting but getting hung prior to transferring any messages. The first machine on the list (pipeline) is my ISDN router. It's actually a Netgear RT328, but I used to have an Ascend Pipeline P50 there and have been too lazy to update my nameserver. (Yes, I know it's easy to change the name, but it doesn't really bother me.) My next step was to ping pipeline: redrock:kev$ ping 192.168.200.100 PING 192.168.200.100 (192.168.200.100): 56 data bytes 64 bytes from 192.168.200.100: icmp_seq=0 ttl=59 time=4.8 ms 64 bytes from 192.168.200.100: icmp_seq=1 ttl=59 time=4.5 ms 64 bytes from 192.168.200.100: icmp_seq=2 ttl=59 time=3.7 ms --- 192.168.200.100 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 3.7/4.3/4.8 ms Next, I ping the next machine in the route, which in this case was is06.phx.gblx.net: redrock:kev$ 206.165.11.206 PING primenet.com (206.165.11.206): 56 data bytes 64 bytes from 206.165.11.206: icmp_seq=0 ttl=251 time=111.2 ms 64 bytes from 206.165.11.206: icmp_seq=1 ttl=251 time=33.1 ms 64 bytes from 206.165.11.206: icmp_seq=2 ttl=251 time=33.0 ms 64 bytes from 206.165.11.206: icmp_seq=3 ttl=251 time=31.9 ms 64 bytes from 206.165.11.206: icmp_seq=4 ttl=251 time=33.6 ms 64 bytes from 206.165.11.206: icmp_seq=5 ttl=251 time=32.8 ms 64 bytes from 206.165.11.206: icmp_seq=6 ttl=251 time=33.4 ms 64 bytes from 206.165.11.206: icmp_seq=7 ttl=251 time=32.1 ms 64 bytes from 206.165.11.206: icmp_seq=8 ttl=251 time=32.9 ms 64 bytes from 206.165.11.206: icmp_seq=9 ttl=251 time=32.9 ms 64 bytes from 206.165.11.206: icmp_seq=10 ttl=251 time=102.1 ms 64 bytes from 206.165.11.206: icmp_seq=16 ttl=251 time=33.3 ms 64 bytes from 206.165.11.206: icmp_seq=17 ttl=251 time=32.8 ms 64 bytes from 206.165.11.206: icmp_seq=18 ttl=251 time=32.7 ms 64 bytes from 206.165.11.206: icmp_seq=19 ttl=251 time=32.1 ms 64 bytes from 206.165.11.206: icmp_seq=20 ttl=251 time=86.8 ms 64 bytes from 206.165.11.206: icmp_seq=21 ttl=251 time=34.8 ms 64 bytes from 206.165.11.206: icmp_seq=22 ttl=251 time=35.6 ms 64 bytes from 206.165.11.206: icmp_seq=23 ttl=251 time=32.1 ms 64 bytes from 206.165.11.206: icmp_seq=24 ttl=251 time=33.1 ms 64 bytes from 206.165.11.206: icmp_seq=25 ttl=251 time=32.9 ms [...] --- primenet.com ping statistics --- 166 packets transmitted, 101 packets received, 39% packet loss round-trip min/avg/max = 31.4/42.5/150.6 ms The final statistics tell you the packet loss. In this case, it was 39%. (I got quite a variety of results though ranging from 19% to greater than 50%.) After primenet got the problem resolved, I was able to ping a primenet machine continuously *for several hours* with *no* packet loss. If you are having DNS problems, or if you're seeing extremely severe packet loss, you will want to use the -n switch with ping and with traceroute in order to avoid nameserver lookups. (Otherwise, these utilities will simply hang before they get very far at all.) There are times when you won't be able to ping a remote machine because the site (or some machine along the way) blocks the ICMP protocol packets needed to do the ping. The reason for this is that malformed ping packets have been used for a variety of denial of service attacks. (At one time Linux was susceptible to some of these attacks, but once they became known the problem was quickly fixed.) Many times though, traceroute will still work - at least partially - so that you'll be able to see (some of) the machines along the route. And you'll frequently be able to ping these intermediate machines too for the simple reason that network administrators need to use ping to diagnose network problems. Kevin