Unix Tipz & Tricz

Introduction

Ping is a basic Internet program that most of us use daily, but did you ever stop to wonder how it really worked.

I am guessing that you know basically how the TCP/IP ping utility works. It sends an ICMP (Internet Control Message Protocol) Echo Request to a specified interface on the network and, in response, it expects to receive an ICMP Echo Reply. By doing this, the program can test connectivity, gauge response time, and report a variety of errors.

ICMP is a software component of the Internetworking layer of TCP/IP; essentially, it is a companion at that level to IP (Internet Protocol) itself. In fact, ICMP relies on IP for transport across the network. If you observe this sort of network traffic, say on an Ethernet network, then your protocol analyzer would capture an Ethernet frame transporting an IP datagram with an ICMP message inside.

Enter the problem: Since the ping program executes at the Application layer, how does it make ICMP do these tricks? You may recall that the Host-to-Host layer is sandwiched between these entities. Is that bypassed? If so, then how? Who is responsible for formatting these messages (Echo Request and Echo Reply)?

More vexingly, when unexpected ICMP responses, other than the customary Echo Reply, result from the Echo Request, how is it that they find their way to the ping program? This last question may seem obvious, but it is not. ICMP messages contain no addressing information that allows the TCP/IP protocol stack to discern the program that is to receive the message. TCP and UDP use port numbers for this purpose. So, how does this work?

Background

The TCP/IP protocol stack is organized as a four-layer model. The lowest layer, commonly called the Network Interface or Network Access layer, is analogous to OSI layers 1 and 2, the Physical and Data Link Control layers. This includes things like media, connectors, signaling, physical addressing, error detection, and managing shared access to the media. For most of us this translates into Ethernet and our cabling system.

The layer above the Network Access layer, the Internetworking layer, is best likened to OSI layer 3, the Network layer. Here we expect to find logical addressing and routing: things that facilitate communication across network boundaries. This is where IP and its addressing mechanisms reside, as does ICMP. ICMP is a necessary component of any TCP/IP implementation. It does not exist to provide information to the higher-layer protocols (like TCP and UDP) so that they may be more reliable. Rather, ICMP provides network diagnostic capabilities and feedback to those responsible for network administration and operation.

Above the Internetworking layer is the Host-to-Host layer, which is the counterpart of OSI layer 4, the Transport layer.  This is where we expect to find facilities for reliable end-to-end data exchange, additional error checking, and the means to discriminate one program from another (using port numbers). TCP and UDP reside at this level.

At the top of the stack, the Application or Process layer, we find high-level protocols (like SMTP, HTTP, and FTP) implemented. This is where applications execute as well. So when you do a ping, the ping program should be perceived to function at this level.

A Minor Mystery

With ICMP operating at the Internetworking layer and the ping program at the Application layer, how is the Host-to-Host layer bypassed? The answer lies in an understanding of what are known as “raw” sockets. Well, for openers, what is a socket, right? Abstractly, a socket is an endpoint to communication, usually

thought to consist of an IP address and port number, which identify a particular host and program, respectively. There are three commonly encountered types of sockets: stream, datagram, and raw. TCP uses the stream type and UDP uses the datagram type. Raw sockets are used by any application that needs to interact directly with IP, bypassing TCP and UDP in doing so. Customers include routing protocol implementations like routed and gated (that implement RIP and OSPF). It also includes our friend ping.

What Actually Goes On

When the ping program begins execution, it opens a raw socket sensitive only to ICMP. This means two things:

• On output: the sending of ICMP Echo Requests, the program is required to format the ICMP message. The system will provide the IP header and the Ethernet (usually) header.

• On input: the program must examine all ICMP messages coming in and cull out the items of interest. The expected input is ICMP Echo Replies.

Let us take these things in turn.

On the outbound side, the Echo Requests are formatted in the manner shown in Figure 2. The message type is always the coded value eight (8). The code field always contains zero. The checksum is used for error detection. The ICMP message header and data are included in its computation. The ping program performs this calculation and fills in the blank. The identification field follows and is supposed to contain the process ID (PID) that uniquely identifies that execution of the ping program to the operating system. On Windows systems, this field contains the constant value 256. Next is the sequence number field, which starts at 0 and is bumped by one on each Echo Request sent. After these required fields, optional test data will follow. In the ping implementation that I examined (Slackware Linux), this included a timestamp used in the round-trip time calculation upon receipt of the Echo Reply.

As for inbound ICMP messages, ping’s task is a bit more complex. Because ping is using a raw ICMP socket, the program is presented with a copy of all incoming ICMP messages, except for a few special cases like incoming Echo Requests generated by other people pinging us (the latter are handled by the system). This

means that ping sees not only the expected Echo Replies when they arrive but also things like Destination Unreachable, Source Quench, and Time Exceeded messages.

Now think about this for a moment. If you have two copies of the ping program running at the same time, then they are each going to see one another’s Echo Replies and any other “nastygrams” that might show up. Each instance of the program must identify the messages that are relevant to it. If you guessed that this is what the PID (identification) field is used for then you are absolutely right.