TCP/IP Applications FAQ

TCP/IP Applications FAQ

Post by Raz Ur » Fri, 22 Dec 2000 14:46:25

Posting-Frequency: Monthly
Copyright: (c) 1998-2000 Uri Raz
Maintainer: Uri Raz <>
Last-modified: 30/May/2000
Archive-Name: internet/tcp-ip/applications-FAQ

  *                                                                        *
  *  If you have any comments, addition suggestions, corrections, etc,     *
  *  to the article itself, please send them to me at the technion.        *
  *              My email address is     *
  *                                                                        *
  *  If you have any questions about TCP/IP in general, which are not      *
  *  directly related to this article, please post them to an appropriate  *
  *  newsgroup, as my time is limited, and as it will serve you better.    *
  *                                                                        *
  *  WARNING : job offers from outside Israel will be treated as spam.     *
  *                                                                        *

  0. Introduction.

   This document deals mainly with those protocols of the TCP/IP suit of
   protocols which are either undocumented in RFCs, with some treatment
   of utilities and not so well documented protocols.

   If you're interested in RFCs for well documented protocols, see :

    - STD1 : Internet Official Protocols Standards
             Describes the state of standardization of protocols
             used in the Internet, as determined by the IAB.

    - STD2 : Assigned Numbers
             A status report on numbers & keywords used in the
             Internet Community.

    - STD3 : Host Requirements
             This document incorporates by reference, amendment,
             correction, and supplementation the primary protocol
             standards documents relating to hosts.

    - STD4 : Gateway Requirements
             This document is a formal statement of the requirements
             to be met by gateways used in the Internet system.

   [STD numbers rather then RFC numbers, as the later get changed with
    time, while the first does not. STDs can be found under the following
    URL : ]

  1. Of ping & traceroute.

   The ping utility checks whether a host is alive & reachable or not.
   This is done by sending an ICMP Echo Request packet to the host, and
   waiting for an ICMP Echo Reply from the host.

   The traceroute utility works in a different way - UDP packets with
   increasing TTL values are sent to the host, with three packets sent
   for each TTL value. Each trio of packets 'expire' at a succeeding
   router on the path to the host, making the routers reply with an ICMP
   Time Exceeded packet, until the host is reached, at which time it replies
   with an ICMP Port Unreachable packet.

   As UDP packets must be sent to a specific port, traceroute sends the
   first packet to port 33434, and increments the port number for each
   packet sent. Those increments are done in order to differentiate
   between the ICMP packets - the ICMP packets include the offending
   packet's headers, and the port number from those headers tells how
   far (= how many hops) the packet travelled before expiring.
   This number was chosen as UDP ports in that neighbourhood are
   probably unused. As those ports might actually be used, a different
   start number is usually configurable via an appropriate switch.

   Microsoft's TRACERT works a little differently - it sends ICMP Echo Request
   packets, rather then UDP packets, and therefore expects the host to reply
   with an ICMP Echo Reply packet. The logic behind this change is, by
   speculation, that as UDP is commonly filtered, while ICMP is not, so
   using ICMP should work most of the time, when UDP might fail.

   The catch is that the original ICMP specifications dictated that ICMP
   errors should not be sent as replies to ICMP packets, so old routers
   would not respond correctly to Microsoft's TRACERT. The spec has since
   been revised so that ICMP errors are not sent as replies to ICMP error
   packets only, which better solves the problem of errors bouncing back
   and forth across the net.

   Sample output :
    traceroute to (, 30 hops max, 20 byte packets
     1 (               1 ms    1 ms    1 ms
     2 (             6 ms    5 ms    5 ms
     3 (               9 ms    8 ms   10 ms
     4 (    160 ms   57 ms   43 ms
     5 * (          24 ms   15 ms
     6 (         266 ms  173 ms  152 ms
     7 (                 468 ms  408 ms  422 ms
     8 (                 453 ms  446 ms  434 ms
     9 (    453 ms (    514 ms (    525 ms
    10 (    590 ms  536 ms  489 ms
    11 (                 526 ms  465 ms  473 ms

    Failure indications are as following :
     '*'  No response received [= timeout]
     '!H' ICMP Host Unreachable indication received in response to query
     '!N' ICMP Net Unreachable indication received in response to query
     '!'  Response from final destination had TTL set to < 1, usually due
          to a bug in the TCP/IP stack (code derived from BSD 4.2 & 4.3)
          In this case the TTL must be set to twice the number of hops to
          the destination, making it look twice as far as it really is.

     A possible problem is demonstrated in hop 9 in the above example -
     a single hop is replied by different hosts. This might be caused
     by either the path being changed while traced or by a router using
     multipath routing.

     Another possible problem is for a single router to appear in two
     consecutive hops. This is caused by routers forwarding packets
     with TTL decremented to 0, so instead of generating a TTL exceeded
     themselves, the next hop routers do so for them, taking their
     place in the output.

     A possible surprise would be to see a router with an address which
     is, according to RFC1918, reserved to private internets (that is
     an address from the blocks 10/8, 172.16/12, 192.168/16). This can
     happen when somebody assigns a reserved (unroutable) address to
     an internal router, saving himself IP addresses on machines that
     need not be accessible to the Internet.

     Another possible surprise would be that the round trip to one
     router would be larger (even significantly larger) than the
     round trip to the next router. This could happen for several
     reasons - CPU load on the nearer router might be high causing
     a delay in the generation of the ICMP reply, ICMP error generation
     might have a low priority on the nearer router, and it's possible
     the packet that expired on the nearer router took a different and
     more congested route on either way or met temporary congestion
     on the same path.

     Further info can be found in the experimental RFC1393, written by
     G. Malkin on Jan '93.

     See also "The Story of the PING Program", written by it's author,
     at the following page -

    [thanx to Barry Margolin,]
    [corrections and additions based on John T. Moy's OSPF book]
    [addition done based on an article by Mr. Sam]

  2. Of the [n/y]talk protocol.

   The talk protocol has three dialects - [old] talk, new talk, and ytalk.
   The old talk was endianess unaware, so people couldn't talk to each other
   between a small-endian machine and a big-endian machine.

   Michael P. Hunter is currently working on a draft for an RFC describing
   the ntalk protocol. The draft RFC can be found at

   Eric Ludlam's GNU Talk page includes an extended talk implementation.

  3. Of the rexec protocol.

   The rexec protocol works as following :
    1. Client makes TCP connection to REXEC port (512).
    2. Client sends TCP port number (decimal ascii, null-terminated)
       of stderr port.  If the first byte is a NULL, then server
       won't make any stderr connection - skip step 3.
    3. Server makes TCP connection to client's stderr port
    4. Client sends target username (null-terminated).
    5. Client sends target password, NULL, remote command, NULL,
       and then command's stdin, followed by a FIN.
    6. Server sends one null byte (=no error), or a non-null
       byte, followed by error message(s).
    7. Server sends output of command.
    8. Server sends FINs on stdout, stderr connections.

   A sample TCPDUMP for an rexec command :
14:10:14.73 > S 0:0(0) win 3000 <mss 1500>
                 4500 002c e405 0000 4006 98c4 7f00 0001 E..,....@.......
                 7f00 0001 03f8 0200 4ef4 19bb 0000 0000 ........N.......
                 6002 0bb8 1f9d 0000 0204 05dc           `...........
14:10:14.73 > S 0:0(0) ack 1 win 3000 <mss 1500>
                 4500 002c e406 0000 4006 98c3 7f00 0001 E..,....@.......
                 7f00 0001 0200 03f8 4ef4 19bb 4ef4 19bc ........N...N...
                 6012 0bb8 b6dc 0000 0204 05dc           `...........
14:10:14.73 > . ack 1 win 3000
                 4500 0028 e407 0000 4006 98c6 7f00 0001 E..(....@.......
                 7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
                 5010 0bb8 cec1 0000                     P.......
14:10:14.75 > P 1:6(5) ack 1 win 3000
                 4500 002d e408 0000 4006 98c0 7f00 0001 E..-....@.......
                 7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
                 5018 0bb8 6c50 0000 3130 3134 00        P...lP..1014.
14:10:14.82 > . ack 6 win 2995
                 4500 0028 e409 0000 4006 98c4 7f00 0001 E..(....@.......
                 7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c1 ........N...N...
                 5010 0bb3 cec1 0000                     P.......
14:10:15.02 > S 0:0(0) win 3000 <mss 1500>
                 4500 002c e40a 0000 4006 98bf 7f00 0001 E..,....@.......
                 7f00 0001 03f5 03f6 4ef5 13bb 0000 0000 ........N.......
                 6002 0bb8 23a9 0000 0204 05dc           `...#.......
14:10:15.03 > S 0:0(0) ack 1 win 3000 <mss 1500>
                 4500 002c e40b 0000 4006 98be 7f00 0001 E..,....@.......
                 7f00 0001 03f6 03f5 4ef5 13bb 4ef5 13bc ........N...N...
                 6012 0bb8 c0e7 0000 0204 05dc           `...........
14:10:15.03 > . ack 1 win 3000
                 4500 0028 e40c 0000 4006 98c1 7f00 0001 E..(....@.......
                 7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
                 5010 0bb8 d8cc 0000                     P.......
14:10:15.06 > P 6:12(6) ack 1 win 3000
                 4500 002e e40d 0000 4006 98ba 7f00 0001 E.......@.......
                 7f00 0001 03f8 0200 4ef4 19c1 4ef4 19bc ........N...N...
                 5018 0bb8 8cdd 0000 6161 726f 6e00      P.......aaron.
14:10:15.22 > . ack 12 win 3000
                 4500 0028 e40e 0000 4006 98bf 7f00 0001 E..(....@.......
                 7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c7 ........N...N...
                 5010 0bb8 ceb6 0000                     P.......
14:10:15.22 > P 12:37(25) ack 1 win 3000
                 4500 0041 e40f 0000 4006 98a5 7f00 0001 E..A....@.......
                 7f00 0001 03f8 0200 4ef4 19c7 4ef4 19bc ........N...N...
                 5018 0bb8 9cb0 0000 XXXX XXXX XXXX XXXX P.......XXXXXXXX
                 XXXX XX00 5348 4f57 2044 4546 4155 4c54 XXX.SHOW DEFAULT
                 00                                      .
14:10:15.42 > . ack 37 win 3000
                 4500 0028 e410 0000 4006 98bd 7f00 0001 E..(....@.......
                 7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
                 5010 0bb8 ce9d 0000                     P.......
14:10:15.56 > P 1:2(1) ack 37 win 3000
                 4500 0029 e411 0000 4006 98bb 7f00 0001 E..)....@.......
                 7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
                 5018 0bb8 ce94 0000 00                  P........
14:10:15.62 > . ack 2 win 3000
                 4500 0028 e412 0000 4006 98bb 7f00 0001 E..(....@.......
                 7f00 0001 03f8 0200 4ef4 19e0 4ef4 19bd ........N...N...
                 5010 0bb8 ce9c 0000                     P.......
14:10:19.24 > P 2:26(24) ack 37 win 3000
                 4500 0040 e413 0000 4006 98a2 7f00 0001 E..@....@.......
                 7f00 0001 0200 03f8 4ef4 19bd 4ef4 19e0 ........N...N...
                 5018 0bb8 777c 0000 2020 4449 534b 2443 P...w|..  DISK$C
                 5241 575f 4441 443a 5b41 4152 4f4e 5d0a RAW_DAD:[AARON].
14:10:19.39 > F 26:26(0) ack 37 win 3000
                 4500 0028 e414 0000 4006 98b9 7f00 0001 E..(....@.......
                 7f00 0001 0200 03f8 4ef4 19d5 4ef4 19e0 ........N...N...
                 5011 0bb8 ce83 0000                     P.......
14:10:19.40 > . ack 27 win 3000
                 4500 0028 e415 0000 4006 98b8 7f00 0001 E..(....@.......
                 7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
                 5010 0bb8 ce83 0000                     P.......
14:10:19.44 > F 1:1(0) ack 1 win 3000
                 4500 0028 e416 0000 4006 98b7 7f00 0001 E..(....@.......
                 7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
                 5011 0bb8 d8cb 0000                     P.......
14:10:19.44 > . ack 2 win 3000
                 4500 0028 e417 0000 4006 98b6 7f00 0001 E..(....@.......
                 7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
                 5010 0bb8 d8cb 0000                     P.......
14:10:19.45 > F 37:37(0) ack 27 win 3000
                 4500 0028 e418 0000 4006 98b5 7f00 0001 E..(....@.......
                 7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
                 5011 0bb8 ce82 0000                     P.......
14:10:19.45 > . ack 38 win 3000
                 4500 0028 e419 0000 4006 98b4 7f00 0001 E..(....@.......
                 7f00 0001 0200 03f8 4ef4 19d6 4ef4 19e1 ........N...N...
                 5010 0bb8 ce82 0000                     P.......
14:10:19.49 > F 1:1(0) ack 2 win 3000
                 4500 0028 e41a 0000 4006 98b3 7f00 0001 E..(....@.......
                 7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
                 5011 0bb8 d8ca 0000                     P.......
14:10:19.49 > . ack 2 win 3000
                 4500 0028 e41b 0000 4006 98b2 7f00 0001 E..(....@.......
                 7f00 0001 03f5 03f6 4ef5 13bd 4ef5 13bd ........N...N...
                 5010 0bb8 d8ca 0000                     P.......

    [thanx to Aaron Leonard,]

 4. Of the rsh protocol.

  The rshd listens on TCP port #514. The following info is from the unix
  rshd man pages :

  "Service Request Protocol

   When the rshd daemon receives a service request, it initiates the
   following protocol:

    1. The rshd daemon checks the source port number for the request.
       If the port number is not in the range 0 through 1023, the rshd daemon
       terminates the connection.

    2. The rshd daemon reads characters from the socket up to a null byte.
       The string read is interpreted as an ASCII number (base 10). If this
       number is nonzero, the rshd daemon interprets it as the port number
       of a secondary stream to be used as standard error. A second connection
       is created to the specified port on the client host. The source port
       on the local host is in the range 0 through 1023.

    3. The rshd daemon uses the source address of the initial connection
       request to determine the name of the client host. If the name cannot
       be determined, the rshd daemon uses the dotted decimal representation
       of the client host's address.

    4. The rshd daemon retrieves the following information from the initial

        * A null-terminated string of at most 16 bytes interpreted as
          the user name of the user on the client host.

        * A null-terminated string of at most 16 bytes interpreted as
          the user name to be used on the local server host.

        * Another null-terminated string interpreted as a command line
          to be passed to a shell on the local server host.

    5. The rshd daemon attempts to validate the user using the following steps:

        a. The rshd daemon looks up the local user name in the /etc/passwd
           file and tries to switch to the home directory (using the chdir
           subroutine). If either the lookup or the directory change fails,
           the rshd daemon terminates the connection.

        b. If the local user ID is a nonzero value, the rshd daemon searches
           the /etc/hosts.equiv file to see if the name of the client
           workstation is listed. If the client workstation is listed as an
           equivalent host, the rshd daemon validates the user.

        c. If the $HOME/.rhosts file exists, the rshd daemon tries to
           authenticate the user by checking the .rhosts file.

        d. If either the $HOME/.rhosts authentication fails or the
           client host is not an equivalent host, the rshd daemon
           terminates the connection.

    6. Once rshd validates the user, the rshd daemon returns a null byte
       on the initial connection and passes the command line to the user's
       local login shell. The shell then inherits the network connections
       established by the rshd daemon."

 5. Of the rlogin protocol.

  rlogin is standardized - see RFC #1282

 6. Of the rmt protocol.

  The rmt protocol allows manipulation of magnetic tape drives attached
  to remote hosts, enabling backups and restores across a network, and
  is used by such commands as rdump & rrestore.

  The rmt protocol relies on either rexec, rcmd, or rsh - the rmt program
  is started via rexec / rcmd / rsh and then interacted with via ASCII
  commands and responses.

  rmt commands are of the following formats -

    A. S\n                       Return the status of the open device.

    B. C<device>\n               Close the currently open device.
                                 The <device> parameter is ignored.

    C. I<operation>\n<count>\n   Performs MTIOCP IOCTL with the
                                 <operation> and <count> parameters.
                                 If the command succeeds, rmt will respond
                                 with <count> as the return code.

                                 This operation are, under AIX, as following :
                                  MTOFFL  - rewind & unload tape
                                  MTREW   - rewind tape
                                  MTERASE - erase & rewind tape
                                  MTRETEN - retention & rewind tape
                                  MTWEOF  - write and EOF record to tape
                                  MTFSF   - forward space file
                                  MTRSF   - reverse space file
                                  MTFSR   - forward space record
                                  MTRSR   - reverse space record
                                  MTINSRT - pull tape in from loader
                                  MTEJECT - eject tape out to loader

    D. L<offset>\n<whence>\n     Moves the tape to a given location.
                                 The move is done as following :
                                  - If <whence> = SEEK_SET, the file pointer
                                    is positioned <offset> bytes from the
                                    start of the file.
                                  - If <whence> = SEEK_CUR, the file pointer
                                    is moved <offset> bytes forward or
                                    backward, according to <whence>'s sign.
                                  - If <whence> = SEEK_END, the file pointer
                                    is moved <offset> after the file's end.
                                 If the command succeeds, rmt will respond with
                                 a code noting the distance of the head from
                                 the start of the file in bytes.
                                 If the command fails, rmt will respond with
                                 a code of -1.

    E. O<device>\n<mode>\n       Opens the specified device in the specified
                                 mode, with <device> being the device's full
                                 name, and <mode> a numerical parameter.

    F. R<count>\n                Reads <count> bytes of data from the device.
                                 If the command is successful, rmt will respond
                                 with a code noting the number of bytes read,
                                 and sends the data.
                                 If the command fails, an error code is
                                 returned, without any data.

    G. W<count>\n                Writes <count> bytes, read from the
                                 connection, to the current device, aborting
                                 if EOF occurs during the write.

  rmt responses are of two formats. Successful commands are responded
  with "A<code>\n", while unsuccessful commands are responded
  with "E<code>\n<error-message>\n".

  All numbers (codes, modes, etc) are transfered as ASCII strings representing
  decimal numbers with the appropriate numerical values.

  [thanx to James Carlson,]
  [used SunOS & AIX man pages]

 7. Of the rhosts file.

  The rhosts file is used the specify which remote users can use
  the privileges of a host's local user account over a network,
  used as a very weak authentication for the r-services (it saves
  the need to send a password in the clear over the network, relying
  on the remote host's IP address and the username the process
  claims it belongs to. Should be owned by the local user, and be
  set as readable & writable by the user alone)

  From the unix rhosts man page :

   The format of the $HOME/.rhosts file is:

   HostNameField [UserNameField]

   When a remote command executes, the local host uses the local /etc/hosts.equiv
   file and the $HOME/.rhosts file of the local user account to validate
   the remote host and remote user.

   Host-Name Field

   The .rhosts file supports the following host-name entries:

   +             Signifies that any host on the network is trusted.
   HostName      Signifies that any user logging in from HostName is trusted.
   -HostName     Signifie that the host is not trusted.
   +@NetGroup    Signifies that all hosts in the netgroup or no hosts in the
   -@NetGroup     netgroup, respectively, are trusted.
                  The @NetGroup parameter is used by NIS for grouping.

   User-Name Field

   The .rhosts file supports the following user-name entries:

   +             Signifies that any user on the network is trusted.
   UserName      Signifies that the remote user is trusted.
                  If no username is specified, the remote username
                  must match the local username.
   -UserName     Signifies that the remote user is not trusted.
   +@NetGroup    Signifies that all users in the netgroup or no
   -@NetGroup    users in the netgroup, respectively, are trusted.
                  The @NetGroup parameter is used by NIS for grouping.

 8. Of the syslog protocol.

  And James Carlson <> has said :

   'No RFC for it; it's a Unix thing.  The best document for it, like
    most of the Unix-derived protocols, is the BSD implementation (take
    a look at lib/libc/gen/syslog.c and usr.sbin/syslogd/syslogd.c).

    The format is just ASCII text over UDP messages sent to port 514.
    The text has this format:

        "<%d>%.15s %s[%d]: %s"

    The first integer is the priority level and facility code (see
    /usr/include/sys/syslog.h), the first string is the date and time
    (ctime()+4), the next string is the process name, the next integer
    is the PID, and the final string is the text message.

    Syslogd will insert a local date/time if the date code in the
    message appears to be missing (if it has an odd format) and will
    insert the IP address or DNS name of the sender.  It also uses the
    priority level along with the syslog.conf file to determine where
    the message should be delivered (if at all).'

 9. Of the ICQ protocol.

  Magnus Ihse has created a page describing the protocols used by
  Mirabilis' ICQ. This is an unofficial page.

  Details of ICQ's API can be downloaded from Mirabilis' web site,
  subject to certain terms & conditions.

 10. Of the lpd protocol.

  lpd is described in RFC #1179. This RFC is not a standard, but rather
  a description of some implementations at the time. Other vendors have
  implemented lpd that dont support some of the details in the RFC and/or
  with private extentions.

 11. Of the IP checksum.

  The calculation of IP checksums is explained in RFC #1071,
  which is titled "Computing the Internet Checksum", which
  includes calculation examples and code examples in C.

  RFC #1071 is updated by RFC #1624, which is titled
  "Computation of the Internet Checksum viaIncremental Update".

  Other relevant RFCs are :

   - RFC #1936, "Implementing the Internet Checksum in Hardware".

   - RFC #1145, RFC #1146, "TCP Alternate Checksum Options".

   - RFC #1141, "Incremental Updating of the Internet Checksum".