SV: flowchart info for ping
David Whelan [dwhelan@auracom.com] wrote:
> >> Does anyone know where can find high-level "what happens when"
> >> documentation for ping? I mean clear information about what exactly
> >> happens from the moment you enter a ping command to the returned message.
> >>
> >
> > I don't know any good high-level doc. Most books about TCP/IP will cover it, but you will have to read quite much before you have the picture.
> >
> > I could try a brief description:
> >
> >
> Thanks very much for your excellent description Enrique.
> On a new installation of an old version of Debian, I have a problem
> reaching any Internet address and, trying to work through the problem on
> my own, I thought that such a high-level doc for ping would be useful in
> troubleshooting it; but I couldn't find anything suitable either.
Ah, that's why you needed it.
>I
> wanted something that concentrates on the user's box rather than getting
> into the whole network theory; i.e., what happens when you enter the
> ping command: the chain of processes, what they do, and how to find out
> if they were successful, and what goes out and what comes into the box.
OK, ping sends messages on the wire to the specified IP address, requesting responses.
If you get any responses, the connectivity is there. If you don't, there are a couple of possible explanations. First, perhaps your network card is not configured.
Try the command "ifconfig"
This will show some data about each of the interfaces. Some interfaces are artificial and software-only. You probably know the name of the real interface(s).
The artificial interface "lo" (loopback) must also be running.
Each description has a line in mostly uppercase, like "UP LOOPBACK RUNNING MTU:16436 Metric:1"
(This was my loopback interface).
The real inteface should have "UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1".
You need UP, BROADCAST, RUNNING. You need a nonzero MTU.
The interfaces must have an IP address: inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0
The loopback must have IP 127.0.0.1. Beware of non-routable addresses. 169.* are zero-conf addresses, but I don't know how to make them work if they don't already. Addresses 168.192.*.* and 10.*.*.* are non-routable, but that is OK if you have a router that does NAT (network address translation).
Your computer must have configured a default gateway.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ath0
0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 ath0
Do not forget the "-n" option!!!!
Next, perhaps your computer does not have a DNS server configured. You do not need a DNS server to use ping, but then you must use the -n option and use nummeric addresses, otherwise ping will try to translate back and forth, and get stuck waiting for an answer.
Try "cat /etc/resolv.conf"
It should say "nameserver 201.11.113.2" or similar. You could now check with ping, first the gateway 10.0.0.138:
# ping -n 10.0.0.138
and then the dns server
# ping -n 201.11.113.2
Remember "-n"!!! Otherwise ping tries to do DNS lookups.
If resolv.conf says 127.0.0.*, then there should be a DNS server on your own computer. To check that,
# netstat -atue| grep domain
tcp 0 0 *:domain *:* LISTEN root 15271
udp 0 0 *:domain *:* root 15272
If it is there, you have to determine what program is running the server. Supposing you don't have the program lsof installed, try
# ls -l /proc/[1-9]*/fd | grep -B 10 '1527[12]'
/proc/4/fd:
total 0
/proc/5025/fd:
total 6
lr-x------ 1 root root 64 2007-06-06 15:44 0 -> /dev/null
l-wx------ 1 root root 64 2007-06-06 15:44 1 -> /dev/null
l-wx------ 1 root root 64 2007-06-06 15:44 2 -> /dev/null
lrwx------ 1 root root 64 2007-06-06 15:44 3 -> socket:[15300]
lrwx------ 1 root root 64 2007-06-06 15:44 4 -> socket:[15271]
lrwx------ 1 root root 64 2007-06-06 15:44 5 -> socket:[15272]
This shows that the sockets are held by process 5025. Then
$ ps -p 5025
PID TTY TIME CMD
5025 ? 00:00:00 pdnsd
So the server is called pdnsd. Whatever it is, check it's configuration. In this case, pdnsd wants to be notified whenever a network interface is configured, and the result can be checked with this command:
$ pdnsd-ctl status
... (snip long output)
label: resolvconf
ip: 10.0.0.138
server assumed available: yes
...
Ha! That is the actual dns server. try a ping -n 10.0.0.138
> Because ping requires so many other processes to work, this might be a
> useful way to troubleshoot a connectivity problem like mine.
Actually, the nice thing about ping is that is requires less things to run, so it is easier to draw conclusions if it does not work, and if the problem is not really the network, ping is likely to work.
If all the tests above come through with positive results, the problem is more likely in the network itself.
Rather than "ping", try "traceroute"
Traceroute sends probing packets similar to "ping", but it plays another trick with the time-to-live field: The first probe is sent with ttl=1, the next with ttl=2, etc. Traceroute does not use the ICMP echo request datagrams, because ICMP datagrams that count their ttl down to zero are just discarded, while if a non-icmp datagram expires its TTL, the router where this happens is supposed to send back a notification, another kind of ICMP. In this way, traceroute triggers responses from each router along the path to the target. That allows you to see where the problem arises.
A last reason why the connectivity is not there may be firewalls. Notice that nowadays many computers are configured to not respond to ping or traceroute, and most firewalls stop traceroute probes.
> Would this
> approach be useful to other people do you think? If it would, and I
> could get some technical help with it, I would be prepared to produce
> such a document. Would this be useful?
Certainly.
There are a couple of network troubleshooting guides on the net, that you could try. The problem is that network configuration is very much a moving taqrget, so many old guides are useless. The techiques I have used above are even worse, extremely old, but, ironically, by being so old they are so basic that they do not get out of fashion. What these commands can pinpoint is, if the connectivity is there, if the network card is configured somehow, etc. If not, it does not say why not. All modern distributions have sophisticated program suites that pass bits of information around, notifying eachother of plug-and-play cards coming up and going away, roaming wirless connections, etc. Their components are generally poorly documented, described in a way that you must already know (almost) everything to understand it. For each piece there may be two or three obsolete alternatives, and it is almost impossible to figure out which ones to read more about.
Anyone who tracks down how a caching DNS server like pdnsd gets its notifications when a roaming wireless gets connected, and describes it in an intelligible language will be doing the community a big favor - until the whole thing changes again in three months. (Actually I think the moment is a good one. Precisely the plug-and-play nature of modern computer is what has caused most of the dramatic changes, but I tend to think it must be settling a bit now. Describe it, and I give it four months and a half :).
But that brings up the question: Why an old version of debian on a new installation?
Perhaps the most usefull thing would be a table of end-user configuration tools. What is the name of the conf tool du jour? Which are obsolete, when did they become that? What tools are incompatible or require tinkering to reconcile?
Regards
Reply to: