Checking whether it reaches

Let us take a returned line apart.

64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.700 ms+--+--+       +---+---+  +-++ +-+-+ +----+-----+ size          the other  no.  left   time it took

All four are worth reading.

seq and time matter most.

seq=0seq=1seq=3   <- 2 is missing! one was lost on the way

A gap in the numbers means things are being dropped. It happens with a damaged cable, or when it is too crowded.

time is the speed itself. Handy to have a rough guide.

under 0.1 ms   yourself (the loopback)about 1 ms     within the same room10 to 30 ms    a server in the same countryover 150 ms    the far side of the world, or something slow

Statistics come at the end.

2 packets transmitted, 2 packets received, 0% packet lossround-trip min/avg/max = 0.600/0.750/0.900 ms

If packet loss is not 0%, something is being dropped somewhere. Often that alone is enough to look at. When you want only the gist, -q leaves just these two lines.

ttl is short for Time To Live, "how long it may live". In practice, though, it is how many machines it may pass.

at the start ttl=64  | passes one     ttl=63  | passes one     ttl=62  ...     ttl=0 -> thrown away

Why such an arrangement? To stop strays.

A -> B -> C -> A -> B -> C -> ...

Get a setting wrong and a packet can go round and round. Pile those up and the network clogs. So it carries a count, and is thrown away when it runs out.

Something interesting can be read from this.

ttl=64   nought machines (yourself, or right next door)ttl=53   it came through 11 (64 - 53)

From the ttl that comes back, you can guess the distance. Starting values are often 64 or 128, so you subtract.

There is a tool that shows you each machine passed, one by one.

~ $ traceroute 127.0.0.1traceroute to 127.0.0.1 (127.0.0.1), 30 hops max 1  localhost (127.0.0.1)  0.100 ms  0.050 ms

Yourself, so only one. Typed on a machine that reaches outside, ten or twenty line up.

The trick of traceroute is a little conjuring with this ttl.

send with ttl=1 -> the first says "it ran out" -> you learn the firstsend with ttl=2 -> the second answers -> you learn the second

It makes them run out on purpose and collects the names of who answers. Neatly thought out, is it not.

ping has many marks, but you use four.

Always add -c. Forget it and it will not stop.

The difference between -W and -w is confusing until you get used to it.

-W  how long to wait for one answer-w  how many seconds before the whole ping gives up

ping -c 3 -W 1 them     send three, wait one second for each answerping -c 100 -w 5 them   means to send a hundred, but ends in five seconds

Why shorten the wait? Because waiting for someone who does not answer takes a long time.

ping -c 1 a dead machine        you are kept ten secondsping -c 1 -W 1 a dead machine   you know in one

Using it inside a script, this decides things. Checking ten machines is a hundred seconds one way and ten the other.

for A in ...; do ping -c 1 -W 1 "$A" ...; done

Paired with the for of chapter 11 you can make a list of who is alive. The end of this lesson does it.

Here is -q as well.

~ $ ping -c 2 -q 127.0.0.1PING 127.0.0.1 (127.0.0.1): 56 data bytes--- 127.0.0.1 ping statistics ---2 packets transmitted, 2 packets received, 0% packet loss

The line-per-packet has gone and only the gist is left. Sending a hundred, this reads better.

You can change the size of what you send.

~ $ ping -c 1 -s 8 127.0.0.1PING 127.0.0.1 (127.0.0.1): 8 data bytes16 bytes from 127.0.0.1: seq=0 ttl=64 time=0.5 ms

You sent 8 bytes and 16 came back. The extra 8 is the ICMP head (the header).

8 (contents) + 8 (head) = 1656 (default) + 8 (head) = 64

So now you know why the default was 64 bytes.

What does changing the size tell you? It finds the fault where only the big packages are dropped.

ping -c 1 -s 56 them     comes backping -c 1 -s 2000 them   does not!

This touches the mtu (how much is carried at once) you saw last lesson.

mtu 1500   an ordinary wiremtu 65536  the loopback (it never goes out, so it is big)

A package bigger than the mtu is split and carried along the way. If the settings make that splitting go wrong, small packages pass and big ones vanish.

ping works, but only file transfers stop partway

That is the cause of that symptom. A leading example of a fault that is very hard to find, and a ping with the size changed is the trump card.

Here the mtu is 65536 so big ones pass, but keep it up your sleeve. It is the move for when someone says "ping works but it will not go".

The most important part of this lesson. There is not one reason for nothing coming back.

All four are mended in different places. Whether you can tell them apart is the worth of this lesson.

Two of them you can actually produce here.

~ $ ping -c 1 example.comping: bad address 'example.com'~ $ ping -c 1 8.8.8.8PING 8.8.8.8 (8.8.8.8): 56 data bytesping: sendto: Network unreachable

Notice whether the first line appeared.

PING 8.8.8.8 ... appeared    -> the name resolved (the address is known)it did not                   -> it stopped at the name

How far it got shows in the number of lines.

The fourth, "no answer", is the nastiest.

PING them (192.168.1.99): 56 data bytes--- them ping statistics ---3 packets transmitted, 0 packets received, 100% packet loss

Not one line of error, and yet nothing comes back. The usual causes are these.

they are set to throw ICMP away (hiding on purpose)a firewall drops it on the waythey are down

The first matters. A ping not coming back does not mean there is no machine there. The next lesson carries this on.

Know the pitfall the other way round too.

ping comes back -> but the site will not show

This happens often. Because what ping checks is only that the machine is alive.

what ping sees       whether the machine answerswhat it does not     whether the application is running

Likened to a house.

ping        is anyone home (knock and see if they answer)the rest    is the shop open (is the door open)

Someone can be home with the shop shut.

the server is alive (ping comes back)but the web program has fallen over (it will not show)

So the order of looking is this.

1. ping        is the machine alive?2. netstat     is the door open?      <- next lesson3. wget        do the contents come?  <- the one after

One rung at a time. If the lower fails the upper must fail, but the lower being fine tells you nothing about the upper.

One more thing: there are more and more machines you cannot ping.

cloud servers        often have ICMP shut by defaultcompany networks     drop all pings from outside

Because hiding is safer. So please do not conclude anything from "the ping did not come back" alone.

no ping back  ->  not necessarily deadping back     ->  not necessarily usable

Hold it as a useful tool that is not enough on its own.

Here are the shapes for this lesson.

ping -c 3 127.0.0.1        send three onlyping -c 2 -q 127.0.0.1     show only the gistping -c 1 -W 1 them        wait one second for an answerping -c 1 -s 8 127.0.0.1   send something smallping -c 1 a name           send by nametraceroute 127.0.0.1       see how many were passed

And the places to read.

seq=      which one (a gap means loss)ttl=      how many more it may pass (the distance shows)time=     the round-trip speed0% packet loss  all came back

Three things to remember most today.

1. always add -c (without it, it does not stop)2. there are four reasons for nothing coming back3. a ping coming back does not mean it is usable

And today's conclusion.

> Check how far it reaches, one rung at a time

Break "it will not connect" into "the name resolved, there was a road, only the answer is missing". Say that much and you can either mend it yourself or ask properly for help.

You cannot go outside here, so the other end is always yourself. Even so, the reading is the same as the real thing, so it carries over after you graduate.

In the last two exercises you combine the for and if of chapter 11 with the logger of the last lesson to make a tool that watches who is alive. Let us type.