OS/2 Routes - TCP/IP Part 2
Written by Tom Brown
This month's column is the second in a multipart tutorial on TCP/IP. Readers who are not familiar with IP routing should read my December 1996 column. This month, I will be discussing the IP protocols TCP, UDP and ICMP. I will also be discussing the loopback interface. References to TCPBEUI are an attempt to provide information to the users of this protocol. It is not necessary to understand TCPBEUI in order to gain value from this work.
The SETUP.CMD file which configures IP under OS/2 does not reside in the $(ETC) directory as indicated in my previous column. It resides in one of two places. For anyone using a version of OS/2 prior to WARP Connect v3.0, SETUP.CMD will reside in the \tcpip\bin directory. WARP Connect users will find SETUP.CMD in their \mptn\bin directory.
Network interfaces are the mouth and ears of a network node. Interfaces can be network cards, serial ports and parallel ports. Connections can either be point to point in nature such as serial or parallel connections via null modems, modems or DSU/CSU pairs, or they can be configured in a bus topology such as Ethernet, token ring, and many others.
The IP loopback interface is a unique interface in that it connects to itself. Packets sent to the loopback interface are simply reflected back to the IP stack which then sees them as incoming packets. This interface is used mainly for testing. The definition of the loopback interface is typically found in the SETUP.CMD file. The syntax for defining the loopback interface is:
ifconfig lo 127.0.0.1
The standard host name for this interface is 'localhost'. Once the loopback interface is defined, you can test it with the command 'ping 127.0.0.1 100 1'. This calls the PING application which will test the network path between to the indicated hosts. The path is tested by sending test packets to indicated host and asking this host to send this test packet back. If the packet goes out and comes back, the indicated host is alive. The second parameter is the number of test bytes to send. The third parameter is the number of packets to send. Note that the packets are sent at one second intervals.
[C:\]ifconfig lo 127.0.0.1 [C:\]ping 127.0.0.1 100 3 PING 127.0.0.1: 100 data bytes 108 bytes from 127.0.0.1: icmp_seq=0. time=30. ms 108 bytes from 127.0.0.1: icmp_seq=1. time=0. ms 108 bytes from 127.0.0.1: icmp_seq=2. time=0. ms ----127.0.0.1 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/10/30 [C:\]Figure 1: Example - PING to the loopback interface
Those who are using TCPBEUI (NetBIOS over TCP/IP) should note that they will not be able to start the requester if the loopback interface is defined. With the loopback interface defined, the requester performs a NetBIOS name query to see if there already exists a requester with an identical name. This query is broadcast to all interfaces and if a response is received, the requester knows that it has a duplicate workstation ID and will not start. If no responses are received, the workstation knows that it has a unique ID and can start normally. When the loopback interface is defined the broadcast is sent and the requester answers its own query! Since there is an identically named station attached to the interface 'lo', the requester will not start. The solution to this is to not define the loopback interface until the NetBIOS requester is started.
IP provides a routing and delivery mechanism for packets. The delivery mechanism includes handling any interfaces that may be required. IP is not reliable. This means that IP simply forwards a packet to the appropriate interface and then waits for the next packet. It does not insure that the packet is delivered to its destination. A packet can travel through many nodes before it reaches its destination. Nodes are designed to drop packets when they become congested. Also, it cannot be guaranteed that packets will arrive in the same order in which they were sent. Using IP directly in an application that requires reliable transport (very few applications DON'T require reliable transport) would require a tremendous amount of work. This renders IP roughly useless to applications.
The TCP/IP protocol stack has been designed to allow for the implementation of protocols which sit on top of IP. There have been many protocols defined, but the protocols that are used most commonly are TCP, UDP and ICMP. These protocols are designed to provide many of the services which IP does not. A list of these protocols can be found in $(ETC)\protocol. I would recommend that this file not be altered. You will notice that there are many more protocols which sit on top of IP than the protocols I have listed.
The Internet Control Message Protocol (ICMP) is typically used by the IP stack itself to communicate to another IP stack. ICMP consists of very low level commands which are typically useless to applications. One command of interest is command 08, the echo request. When an IP stack receives an ICMP packet, it passes it to the ICMP protocol. When the ICMP protocol receives a command 08, it simply sends the packet back to the sender through the same interface from which it came in. This is the technology which allows the PING application to function. PING sends ICMP echo requests to the indicated host which will (hopefully) send them back to the original host where PING will listen for them returning (SONAR metaphor). If a packet can be 'ECHOed' off of a remote host we know that the host is alive and that routing is in place between our host and the remote host.
PING is an excellent tool for network debugging. If a remote host is not responding to echo requests, it is either off-line or there is a routing problem. Routing can be tested by PINGing nodes between the two hosts.
There is an enhanced PING for OS/2 at:
This ping has several configuration options which the standard OS/2 ping does not have. I've used this utility to great advantage by exploiting its behavior of setting the errorlevel depending on the echo status. It can be used to test routing between hosts and restore a connection should there be a problem.
Below is a script I use to connect to the Internet. I call it with "PPPConnect ProviderName". Each night, I run a batch file which connects to the Internet, fetches mail, news, etc. and then hangs up. If there are sufficient requests, I can provide an in-depth look at PPP including fully automated connections.
@ECHO off :connection_check C:\Utils\ping -c 1 -q www.ibm.com IF ERRORLEVEL 1 GOTO connect ECHO Already Connected GOTO done :no_answer ECHO Dialing... START /F /C "PPP Internet Connection" PPP com4 115200 file %PPPPATH%\%1.CFG connect "slattach -f %PPPPATH%\%1.rsp" C:\Utils\sleep 60 GOTO connection_check :doneFigure 2: PPPConnect.cmd - Using PING to test PPP connection status [note: START line was wrapped for visual reasons]
Transmission Control Protocol (TCP) is the most common application level protocol by a huge margin. It provides reliable transport which will insure that packets are delivered in sequence, resending if necessary, all without application intervention. TCP is used by FTP, HTTP, Telnet and thousands of other applications.
User Datagram Protocol (UDP) is used as a very lightweight messaging protocol. UDP will not insure that packets are in-sequence, or even that they are delivered. It will allow an application to direct a packet at a specific resource on a remote host. The advantage of UDP over TCP is that there are protocol level acknowledgements using bandwidth and time.
DNS uses UDP in most cases because the query issued by a host and the result issued by a server are both small and granular. If a response is not received, the query can simply be retransmitted. The resolver will use TCP when the request is larger than 556 bytes which is the largest size payload that can be reliably carried in a UDP packet. Since almost every application uses DNS for address resolution, the savings in response packets is significant.
Next month I will be continuing with the IP tutorial. TCP will be covered in greater depth and I may begin discussing some of the standard IP utilities. As always, input is very welcome.