|Ping, keep connection alive||Web||Index|
Normally auto-pinging a host or service provider can prevent disconnection by ISPs who monitor your connection activity. But what happens if your computer is simulating such a behaviour ? Wehn it works, your ISP will never disconnect you again.
A ping is a low level test to see if a remote host or computer is reachable by your PC. Automatic Ping is doing that at a free selectable interval. Just select a time and a host that should be pinged, the best would be your ISP.
Is sending a Ping to a host of your interest, and is waiting a given time, before it stopes with a timeout.
What is Ping:
``Ping'' is one of the most useful network debugging tools available. It takes its name from a submarine sonar search - you send a short sound burst and listen for an echo - a ping - coming back.
In an IP network, `ping' sends a short data burst - a single packet - and listens for a single packet in reply. Since this tests the most basic function of an IP network (delivery of single packet), it's easy to see how you can learn a lot from some `pings'.
Ping is implemented by using the required ICMP Echo function, documented in RFC 792 that all hosts should implement. Of course, administrators can disable ping messages (this is rarely a good idea, unless security considerations dictate that the host should be unreachable anyway), and some implementations have (gasp) even been known not to implement all required functions. However, ping is usually a better bet than almost any other network software.
Many versions of ping are available. For the remainder of this discussion, I assume use of BSD UNIX's ping, a freely available, full-featured ping available for many UNIX systems. Most PC-based pings do not have the advanced features I describe. As always, read the manual of whatever version you use.
What Ping can tell you
Ping places a unique sequence number on each packet
it transmits, and reports which sequence numbers it receives back. Thus, you
can determine if packets have been dropped, duplicated, or reordered.
Ping checksums each packet it exchanges. You can detect some forms of damaged packets.
Ping places a timestamp in each packet, which is echoed back and can easily be used to compute how long each packet exchange took - the Round Trip Time (RTT).
Ping reports other ICMP messages that might otherwise get buried in the system software. It reports, for example, if a router is declaring the target host unreachable.
Some routers may silently discard undeliverable packets.
Others may believe a packet has been transmitted successfully when it has
not been. (This is especially common over Ethernet, which does not provide
link-layer acknowledgements) Therefore, ping may not always provide reasons
why packets go unanswered.
Ping cannot tell you why a packet was damaged, delayed, or duplicated. It can not tell you where this happened either, although you may be able to deduce it.
Ping cannot give you a blow-by-blow description of every host that handled the packet and everything that happened at every step of the way. It is an unfortunate fact that no software can reliably provide this information for a TCP/IP network.
Ping should be your first stop for network troubleshooting. Having problems transferring a file with FTP? Don't fire up your packet analyzer just yet. Leave your TDR in the box for now. Relax. Put on some Yanni. Don't even ``su'' - ping is a non-privileged command on most systems. Start one running and just watch it for at least two minutes. That's enough time for most periodic network problems to show themselves. Once you've seen about a hundred packets, you should be getting a good feeling for how this host is responding. Are the round-trip times consistent? Seeing any packet loss? Are the TTL values sane? Start pinging other hosts. Try the machine next to you - the problem might be closer than you think. Try the last router - maybe the remote system is overloaded (especially if it's a popular Internet site like this one). Don't know what the last router is? Use traceroute or guess - changing the last number in the IP address to 1 usually gets you something interesting. Check other sites with similar network topologies (other remote LAN sites, or other Internet sites, or other sites using the same backbone). Starting to learn something about how your network is responding? Good. And - oh, yeah, go check that FTP. It's probably done by now.
What you might see
A unfortunate fact of life. Detect them by noting when the sequence numbers skip, and the missing number does not appear again later. This is probably caused by a router queueing packets for a relatively slow link, and the queue simply grew too large. Early TCP implementations dropped packets at a truly alarming rate, but things have gotten better. Even so, there are common situations, typically involving crowded wide-area networks, in which even modern TCP implementations can't operate steady-state without dropping packets. There's no reason to pull your out hair over this, since TCP will retransmit missing data, but this won't make your network run faster. Also, if you have fast links that aren't showing much congestion, the cause of trouble may be elsewhere - link-level failures are the next most common cause of packet loss. I'd suggest using the techniques mentioned above to narrow down as much as possible where packets are being dropped, and try to understand why this is happening, even if fixing it is beyond your control.
Fluctuating Round Trip Times
Another fact of life. Pretty much caused by the same things that cause packet loss. Again, not serious cause for alarm, but don't expect optimum performance from TCP. Remember that TCP generates an internal RTT estimate that affects protocol behavior. If the actual RTT changes too much, TCP may never be able to make a satisfactory estimate. Both dropped packets and RTT fluctuations may occur in a periodic nature - a batch of slow packets every 30 seconds, for instance. If you see this symptom, check for routing updates or other periodic traffic with the same period as the problem. Poor network performance can often be traced to slow links being clogged with various kinds of automated updates.
Connectivity that comes and goes
Again, look for periods between problems that are multiples of some common number - 10 and 15 seconds are good things to check. If a router is sending error messages when connectivity disappears, that router's the first place to start looking. However, just because you can always reach hop 5, for instance, doesn't mean that your problem isn't hop 3. Hop 3's router may be erroneously timing out routing information for your target, but handling hop 5's routing information just fine. Of course, check hop 5 first if that's where your packets seem to check out but never leave.
Ping works fine but TELNET/FTP/Mail/News/...
Good news - it's (probably) not a hardware problem. Use a packet tracer of some sort to see what TTL values are being generated by your hosts. If they're too low, you can see this kind of behavior. It could also be a software or configuration problem - can other machines connect to the offending host? Can it talk to itself? On the other hand, it could be a hardware problem, if one of your links is showing data-dependent behavior. The telltale symptom is when FTP (for example) can transfer some files fine, but others always have problems. Once you've found an offending file, trying breaking it into smaller and smaller pieces and see which ones don't work. If the pieces becomes too small to detect problems, duplicate them several times to get a larger file. Once you've found a small pattern that you suspect is causing your grief, see if you can load it into ping packets (BSD PING's `-p' switch) and reproduce trouble.