home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / internet / tcp-ip / applications-FAQ next >
Encoding:
Internet Message Format  |  2004-04-18  |  28.1 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <internet/tcp-ip/applications-FAQ_1082200966@rtfm.mit.edu>
  3. Supersedes: <internet/tcp-ip/applications-FAQ_1079601013@rtfm.mit.edu>
  4. Expires: 31 May 2004 11:22:46 GMT
  5. X-Last-Updated: 2003/06/08
  6. Organization: none
  7. Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.mac.comm,comp.unix.questions,comp.os.ms-windows.networking.tcp-ip,comp.answers,news.answers
  8. Approved: news-answers-request@MIT.EDU
  9. From: uriraz@private.org.il (Uri Raz)
  10. Subject: TCP/IP Applications FAQ 
  11. Followup-To: comp.protocols.tcp-ip
  12. Summary: This document describes the technical sides of not-so-well documented TCP/IP protocols, such as the r-* services, talk, etc, as well as some utilities, such as ping & traceroute.
  13. Originator: faqserv@penguin-lust.MIT.EDU
  14. Date: 17 Apr 2004 11:29:02 GMT
  15. Lines: 559
  16. NNTP-Posting-Host: penguin-lust.mit.edu
  17. X-Trace: 1082201342 senator-bedfellow.mit.edu 569 18.181.0.29
  18. Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip:118104 comp.protocols.tcp-ip.ibmpc:49396 comp.sys.mac.comm:334882 comp.unix.questions:195277 comp.os.ms-windows.networking.tcp-ip:86663 comp.answers:56892 news.answers:270059
  19.  
  20. Posting-Frequency: Monthly
  21. Copyright: (c) 1998-2001 Uri Raz
  22. Maintainer: Uri Raz <uriraz@private.org.il>
  23. Last-modified: 14/Nov/2001
  24. Archive-Name: internet/tcp-ip/applications-FAQ
  25. URL: http://www.private.org.il/mini-tcpip.faq.html
  26.  
  27.   **************************************************************************
  28.   *                                                                        *
  29.   *  If you have any comments, addition suggestions, corrections, etc,     *
  30.   *  to the article itself, please send them to me at the technion.        *
  31.   *              My email address is mailto:uriraz@private.org.il          * 
  32.   *                                                                        *
  33.   *  If you have any questions about TCP/IP in general, which are not      *
  34.   *  directly related to this article, please post them to an appropriate  *
  35.   *  newsgroup, as my time is limited, and as it will serve you better.    *
  36.   *                                                                        *
  37.   **************************************************************************
  38.  
  39.  
  40.   0. Introduction.
  41.   ----------------
  42.  
  43.    This document deals mainly with those protocols of the TCP/IP suit of
  44.    protocols which are either undocumented in RFCs, with some treatment
  45.    of utilities and not so well documented protocols.
  46.  
  47.    If you're interested in RFCs for well documented protocols, see :
  48.  
  49.     - STD1 : Internet Official Protocols Standards
  50.              Describes the state of standardization of protocols
  51.              used in the Internet, as determined by the IAB.
  52.  
  53.     - STD2 : Assigned Numbers
  54.              A status report on numbers & keywords used in the
  55.              Internet Community.
  56.  
  57.     - STD3 : Host Requirements
  58.              This document incorporates by reference, amendment,
  59.              correction, and supplementation the primary protocol
  60.              standards documents relating to hosts.
  61.  
  62.     - STD4 : Gateway Requirements 
  63.              This document is a formal statement of the requirements
  64.              to be met by gateways used in the Internet system. 
  65.  
  66.    [STD numbers rather then RFC numbers, as the later get changed with
  67.     time, while the first does not. STDs can be found under the following
  68.     URL : ftp://venera.isi.edu/in-notes/std/ ]
  69.  
  70.  
  71.   1. Of ping & traceroute.
  72.   ------------------------
  73.  
  74.    The ping utility checks whether a host is alive & reachable or not.
  75.    This is done by sending an ICMP Echo Request packet to the host, and
  76.    waiting for an ICMP Echo Reply from the host.
  77.  
  78.    The traceroute utility works in a different way - UDP packets with
  79.    increasing TTL values are sent to the host, with three packets sent
  80.    for each TTL value. Each trio of packets 'expire' at a succeeding
  81.    router on the path to the host, making the routers reply with an ICMP
  82.    Time Exceeded packet, until the host is reached, at which time it replies
  83.    with an ICMP Port Unreachable packet.
  84.  
  85.    As UDP packets must be sent to a specific port, traceroute sends the
  86.    first packet to port 33434, and increments the port number for each
  87.    packet sent. Those increments are done in order to differentiate
  88.    between the ICMP packets - the ICMP packets include the offending
  89.    packet's headers, and the port number from those headers tells how
  90.    far (= how many hops) the packet travelled before expiring. 
  91.    This number was chosen as UDP ports in that neighbourhood are
  92.    probably unused. As those ports might actually be used, a different
  93.    start number is usually configurable via an appropriate switch. 
  94.  
  95.    Microsoft's TRACERT works a little differently - it sends ICMP Echo Request
  96.    packets, rather then UDP packets, and therefore expects the host to reply
  97.    with an ICMP Echo Reply packet. The logic behind this change is, by
  98.    speculation, that as UDP is commonly filtered, while ICMP is not, so
  99.    using ICMP should work most of the time, when UDP might fail.
  100.  
  101.    The catch is that the original ICMP specifications dictated that ICMP
  102.    errors should not be sent as replies to ICMP packets, so old routers
  103.    would not respond correctly to Microsoft's TRACERT. The spec has since
  104.    been revised so that ICMP errors are not sent as replies to ICMP error
  105.    packets only, which better solves the problem of errors bouncing back
  106.    and forth across the net.
  107.  
  108.    Sample output :
  109.    ---------------
  110.     traceroute to www.ibm.com (204.146.18.33), 30 hops max, 20 byte packets
  111.      1 teg.technion.ac.il (132.68.7.254)               1 ms    1 ms    1 ms
  112.      2 tau-smds.man.ac.il (128.139.210.16)             6 ms    5 ms    5 ms
  113.      3 128.139.198.129 (128.139.198.129)               9 ms    8 ms   10 ms
  114.      4 TAU-shiber.route.ibm.net.il (192.115.73.5)    160 ms   57 ms   43 ms
  115.      5 *
  116.        fe7507.tlv.ibm.net.il (192.116.177.1)          24 ms   15 ms
  117.      6 port1br1.pt.uk.ibm.net (152.158.16.1)         266 ms  173 ms  152 ms
  118.      7 165.87.220.34 (165.87.220.34)                 468 ms  408 ms  422 ms
  119.      8 165.87.28.105 (165.87.28.105)                 453 ms  446 ms  434 ms
  120.      9 colu35-16-br2.oh.us.ibm.net (165.87.35.18)    453 ms
  121.        colu35-32-br2.oh.us.ibm.net (165.87.35.34)    514 ms
  122.        colu35-16-br2.oh.us.ibm.net (165.87.35.18)    525 ms
  123.     10 colu35-64-sf1.oh.us.ibm.net (165.87.35.76)    590 ms  536 ms  489 ms
  124.     11 204.146.18.33 (204.146.18.33)                 526 ms  465 ms  473 ms
  125.  
  126.     Failure indications are as following :
  127.      '*'  No response received [= timeout]
  128.      '!H' ICMP Host Unreachable indication received in response to query
  129.      '!N' ICMP Net Unreachable indication received in response to query
  130.      '!'  Response from final destination had TTL set to < 1, usually due
  131.           to a bug in the TCP/IP stack (code derived from BSD 4.2 & 4.3)
  132.           In this case the TTL must be set to twice the number of hops to
  133.           the destination, making it look twice as far as it really is.
  134.  
  135.      A possible problem is demonstrated in hop 9 in the above example -
  136.      a single hop is replied by different hosts. This might be caused
  137.      by either the path being changed while traced or by a router using
  138.      multipath routing.
  139.  
  140.      Another possible problem is for a single router to appear in two
  141.      consecutive hops. This is caused by routers forwarding packets
  142.      with TTL decremented to 0, so instead of generating a TTL exceeded
  143.      themselves, the next hop routers do so for them, taking their
  144.      place in the output. 
  145.  
  146.      A possible surprise would be to see a router with an address which
  147.      is, according to RFC1918, reserved to private internets (that is
  148.      an address from the blocks 10/8, 172.16/12, 192.168/16). This can
  149.      happen when somebody assigns a reserved (unroutable) address to
  150.      an internal router, saving himself IP addresses on machines that
  151.      need not be accessible to the Internet.
  152.  
  153.      Another possible surprise would be that the round trip to one
  154.      router would be larger (even significantly larger) than the
  155.      round trip to the next router. This could happen for several
  156.      reasons - CPU load on the nearer router might be high causing
  157.      a delay in the generation of the ICMP reply, ICMP error generation
  158.      might have a low priority on the nearer router, and it's possible
  159.      the packet that expired on the nearer router took a different and
  160.      more congested route on either way or met temporary congestion
  161.      on the same path. 
  162.  
  163.      Further info can be found in the experimental RFC1393, written by
  164.      G. Malkin on Jan '93.
  165.  
  166.      See also "The Story of the PING Program", written by it's author,
  167.      at the following page - http://ftp.arl.mil/~mike/ping.html
  168.  
  169.     [thanx to Barry Margolin, barmar@bbnplanet.com]
  170.     [corrections and additions based on John T. Moy's OSPF book]
  171.     [addition done based on an article by Mr. Sam]
  172.  
  173.  
  174.   2. Of the [n/y]talk protocol.
  175.   -----------------------------
  176.  
  177.    The talk protocol has three dialects - [old] talk, new talk, and ytalk.
  178.    The old talk was endianess unaware, so people couldn't talk to each other
  179.    between a small-endian machine and a big-endian machine. 
  180.  
  181.    Michael P. Hunter is currently working on a draft for an RFC describing
  182.    the ntalk protocol. The draft RFC can be found at
  183.     http://www.alternic.org/drafts/drafts-h-i/draft-hunter-talk-00.html
  184.  
  185.    Eric Ludlam's GNU Talk page includes an extended talk implementation.
  186.     http://www.ultranet.com/~zappo/gtalk.shtml
  187.  
  188.  
  189.   3. Of the rexec protocol.
  190.   -------------------------
  191.  
  192.    The rexec protocol works as following :
  193.     1. Client makes TCP connection to REXEC port (512).
  194.     2. Client sends TCP port number (decimal ascii, null-terminated)
  195.        of stderr port.  If the first byte is a NULL, then server
  196.        won't make any stderr connection - skip step 3.
  197.     3. Server makes TCP connection to client's stderr port
  198.     4. Client sends target username (null-terminated).
  199.     5. Client sends target password, NULL, remote command, NULL,
  200.        and then command's stdin, followed by a FIN.
  201.     6. Server sends one null byte (=no error), or a non-null
  202.        byte, followed by error message(s).
  203.     7. Server sends output of command.
  204.     8. Server sends FINs on stdout, stderr connections.
  205.  
  206.    A sample TCPDUMP for an rexec command :
  207.    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  208. 14:10:14.73 127.0.0.1.1016 > 127.0.0.1.512: S 0:0(0) win 3000 <mss 1500>
  209.                  4500 002c e405 0000 4006 98c4 7f00 0001 E..,....@.......
  210.                  7f00 0001 03f8 0200 4ef4 19bb 0000 0000 ........N.......
  211.                  6002 0bb8 1f9d 0000 0204 05dc           `...........
  212. 14:10:14.73 127.0.0.1.512 > 127.0.0.1.1016: S 0:0(0) ack 1 win 3000 <mss 1500>
  213.                  4500 002c e406 0000 4006 98c3 7f00 0001 E..,....@.......
  214.                  7f00 0001 0200 03f8 4ef4 19bb 4ef4 19bc ........N...N...
  215.                  6012 0bb8 b6dc 0000 0204 05dc           `...........
  216. 14:10:14.73 127.0.0.1.1016 > 127.0.0.1.512: . ack 1 win 3000
  217.                  4500 0028 e407 0000 4006 98c6 7f00 0001 E..(....@.......
  218.                  7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
  219.                  5010 0bb8 cec1 0000                     P.......
  220. 14:10:14.75 127.0.0.1.1016 > 127.0.0.1.512: P 1:6(5) ack 1 win 3000
  221.                  4500 002d e408 0000 4006 98c0 7f00 0001 E..-....@.......
  222.                  7f00 0001 03f8 0200 4ef4 19bc 4ef4 19bc ........N...N...
  223.                  5018 0bb8 6c50 0000 3130 3134 00        P...lP..1014.
  224. 14:10:14.82 127.0.0.1.512 > 127.0.0.1.1016: . ack 6 win 2995
  225.                  4500 0028 e409 0000 4006 98c4 7f00 0001 E..(....@.......
  226.                  7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c1 ........N...N...
  227.                  5010 0bb3 cec1 0000                     P.......
  228. 14:10:15.02 127.0.0.1.1013 > 127.0.0.1.1014: S 0:0(0) win 3000 <mss 1500>
  229.                  4500 002c e40a 0000 4006 98bf 7f00 0001 E..,....@.......
  230.                  7f00 0001 03f5 03f6 4ef5 13bb 0000 0000 ........N.......
  231.                  6002 0bb8 23a9 0000 0204 05dc           `...#.......
  232. 14:10:15.03 127.0.0.1.1014 > 127.0.0.1.1013: S 0:0(0) ack 1 win 3000 <mss 1500>
  233.                  4500 002c e40b 0000 4006 98be 7f00 0001 E..,....@.......
  234.                  7f00 0001 03f6 03f5 4ef5 13bb 4ef5 13bc ........N...N...
  235.                  6012 0bb8 c0e7 0000 0204 05dc           `...........
  236. 14:10:15.03 127.0.0.1.1013 > 127.0.0.1.1014: . ack 1 win 3000
  237.                  4500 0028 e40c 0000 4006 98c1 7f00 0001 E..(....@.......
  238.                  7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
  239.                  5010 0bb8 d8cc 0000                     P.......
  240. 14:10:15.06 127.0.0.1.1016 > 127.0.0.1.512: P 6:12(6) ack 1 win 3000
  241.                  4500 002e e40d 0000 4006 98ba 7f00 0001 E.......@.......
  242.                  7f00 0001 03f8 0200 4ef4 19c1 4ef4 19bc ........N...N...
  243.                  5018 0bb8 8cdd 0000 6161 726f 6e00      P.......aaron.
  244. 14:10:15.22 127.0.0.1.512 > 127.0.0.1.1016: . ack 12 win 3000
  245.                  4500 0028 e40e 0000 4006 98bf 7f00 0001 E..(....@.......
  246.                  7f00 0001 0200 03f8 4ef4 19bc 4ef4 19c7 ........N...N...
  247.                  5010 0bb8 ceb6 0000                     P.......
  248. 14:10:15.22 127.0.0.1.1016 > 127.0.0.1.512: P 12:37(25) ack 1 win 3000
  249.                  4500 0041 e40f 0000 4006 98a5 7f00 0001 E..A....@.......
  250.                  7f00 0001 03f8 0200 4ef4 19c7 4ef4 19bc ........N...N...
  251.                  5018 0bb8 9cb0 0000 XXXX XXXX XXXX XXXX P.......XXXXXXXX
  252.                  XXXX XX00 5348 4f57 2044 4546 4155 4c54 XXX.SHOW DEFAULT
  253.                  00                                      .
  254. 14:10:15.42 127.0.0.1.512 > 127.0.0.1.1016: . ack 37 win 3000
  255.                  4500 0028 e410 0000 4006 98bd 7f00 0001 E..(....@.......
  256.                  7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
  257.                  5010 0bb8 ce9d 0000                     P.......
  258. 14:10:15.56 127.0.0.1.512 > 127.0.0.1.1016: P 1:2(1) ack 37 win 3000
  259.                  4500 0029 e411 0000 4006 98bb 7f00 0001 E..)....@.......
  260.                  7f00 0001 0200 03f8 4ef4 19bc 4ef4 19e0 ........N...N...
  261.                  5018 0bb8 ce94 0000 00                  P........
  262. 14:10:15.62 127.0.0.1.1016 > 127.0.0.1.512: . ack 2 win 3000
  263.                  4500 0028 e412 0000 4006 98bb 7f00 0001 E..(....@.......
  264.                  7f00 0001 03f8 0200 4ef4 19e0 4ef4 19bd ........N...N...
  265.                  5010 0bb8 ce9c 0000                     P.......
  266. 14:10:19.24 127.0.0.1.512 > 127.0.0.1.1016: P 2:26(24) ack 37 win 3000
  267.                  4500 0040 e413 0000 4006 98a2 7f00 0001 E..@....@.......
  268.                  7f00 0001 0200 03f8 4ef4 19bd 4ef4 19e0 ........N...N...
  269.                  5018 0bb8 777c 0000 2020 4449 534b 2443 P...w|..  DISK$C
  270.                  5241 575f 4441 443a 5b41 4152 4f4e 5d0a RAW_DAD:[AARON].
  271. 14:10:19.39 127.0.0.1.512 > 127.0.0.1.1016: F 26:26(0) ack 37 win 3000
  272.                  4500 0028 e414 0000 4006 98b9 7f00 0001 E..(....@.......
  273.                  7f00 0001 0200 03f8 4ef4 19d5 4ef4 19e0 ........N...N...
  274.                  5011 0bb8 ce83 0000                     P.......
  275. 14:10:19.40 127.0.0.1.1016 > 127.0.0.1.512: . ack 27 win 3000
  276.                  4500 0028 e415 0000 4006 98b8 7f00 0001 E..(....@.......
  277.                  7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
  278.                  5010 0bb8 ce83 0000                     P.......
  279. 14:10:19.44 127.0.0.1.1013 > 127.0.0.1.1014: F 1:1(0) ack 1 win 3000
  280.                  4500 0028 e416 0000 4006 98b7 7f00 0001 E..(....@.......
  281.                  7f00 0001 03f5 03f6 4ef5 13bc 4ef5 13bc ........N...N...
  282.                  5011 0bb8 d8cb 0000                     P.......
  283. 14:10:19.44 127.0.0.1.1014 > 127.0.0.1.1013: . ack 2 win 3000
  284.                  4500 0028 e417 0000 4006 98b6 7f00 0001 E..(....@.......
  285.                  7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
  286.                  5010 0bb8 d8cb 0000                     P.......
  287. 14:10:19.45 127.0.0.1.1016 > 127.0.0.1.512: F 37:37(0) ack 27 win 3000
  288.                  4500 0028 e418 0000 4006 98b5 7f00 0001 E..(....@.......
  289.                  7f00 0001 03f8 0200 4ef4 19e0 4ef4 19d6 ........N...N...
  290.                  5011 0bb8 ce82 0000                     P.......
  291. 14:10:19.45 127.0.0.1.512 > 127.0.0.1.1016: . ack 38 win 3000
  292.                  4500 0028 e419 0000 4006 98b4 7f00 0001 E..(....@.......
  293.                  7f00 0001 0200 03f8 4ef4 19d6 4ef4 19e1 ........N...N...
  294.                  5010 0bb8 ce82 0000                     P.......
  295. 14:10:19.49 127.0.0.1.1014 > 127.0.0.1.1013: F 1:1(0) ack 2 win 3000
  296.                  4500 0028 e41a 0000 4006 98b3 7f00 0001 E..(....@.......
  297.                  7f00 0001 03f6 03f5 4ef5 13bc 4ef5 13bd ........N...N...
  298.                  5011 0bb8 d8ca 0000                     P.......
  299. 14:10:19.49 127.0.0.1.1013 > 127.0.0.1.1014: . ack 2 win 3000
  300.                  4500 0028 e41b 0000 4006 98b2 7f00 0001 E..(....@.......
  301.                  7f00 0001 03f5 03f6 4ef5 13bd 4ef5 13bd ........N...N...
  302.                  5010 0bb8 d8ca 0000                     P.......
  303.  
  304.     [thanx to Aaron Leonard, aaron@cisco.com]
  305.  
  306.  
  307.  4. Of the rsh protocol.
  308.  -----------------------
  309.  
  310.   The rshd listens on TCP port #514. The following info is from the unix
  311.   rshd man pages :
  312.  
  313.   "Service Request Protocol
  314.  
  315.    When the rshd daemon receives a service request, it initiates the
  316.    following protocol:
  317.  
  318.     1. The rshd daemon checks the source port number for the request.
  319.        If the port number is not in the range 0 through 1023, the rshd daemon
  320.        terminates the connection.
  321.  
  322.     2. The rshd daemon reads characters from the socket up to a null byte.
  323.        The string read is interpreted as an ASCII number (base 10). If this
  324.        number is nonzero, the rshd daemon interprets it as the port number
  325.        of a secondary stream to be used as standard error. A second connection
  326.        is created to the specified port on the client host. The source port
  327.        on the local host is in the range 0 through 1023.
  328.  
  329.     3. The rshd daemon uses the source address of the initial connection
  330.        request to determine the name of the client host. If the name cannot
  331.        be determined, the rshd daemon uses the dotted decimal representation
  332.        of the client host's address.
  333.  
  334.     4. The rshd daemon retrieves the following information from the initial
  335.        socket:
  336.  
  337.         * A null-terminated string of at most 16 bytes interpreted as
  338.           the user name of the user on the client host.
  339.  
  340.         * A null-terminated string of at most 16 bytes interpreted as
  341.           the user name to be used on the local server host.
  342.  
  343.         * Another null-terminated string interpreted as a command line
  344.           to be passed to a shell on the local server host.
  345.  
  346.     5. The rshd daemon attempts to validate the user using the following steps:
  347.  
  348.         a. The rshd daemon looks up the local user name in the /etc/passwd
  349.            file and tries to switch to the home directory (using the chdir
  350.            subroutine). If either the lookup or the directory change fails,
  351.            the rshd daemon terminates the connection.
  352.  
  353.         b. If the local user ID is a nonzero value, the rshd daemon searches
  354.            the /etc/hosts.equiv file to see if the name of the client
  355.            workstation is listed. If the client workstation is listed as an
  356.            equivalent host, the rshd daemon validates the user.
  357.  
  358.         c. If the $HOME/.rhosts file exists, the rshd daemon tries to
  359.            authenticate the user by checking the .rhosts file.
  360.  
  361.         d. If either the $HOME/.rhosts authentication fails or the
  362.            client host is not an equivalent host, the rshd daemon
  363.            terminates the connection.
  364.  
  365.     6. Once rshd validates the user, the rshd daemon returns a null byte
  366.        on the initial connection and passes the command line to the user's
  367.        local login shell. The shell then inherits the network connections
  368.        established by the rshd daemon."
  369.  
  370.  
  371.  5. Of the rlogin protocol.
  372.  --------------------------
  373.  
  374.   rlogin is standardized - see RFC #1282
  375.    http://www.ietf.org/rfc/rfc1282.txt
  376.  
  377.  
  378.  6. Of the rmt protocol.
  379.  -----------------------
  380.  
  381.   The rmt protocol allows manipulation of magnetic tape drives attached 
  382.   to remote hosts, enabling backups and restores across a network, and
  383.   is used by such commands as rdump & rrestore.
  384.  
  385.   The rmt protocol relies on either rexec, rcmd, or rsh - the rmt program
  386.   is started via rexec / rcmd / rsh and then interacted with via ASCII
  387.   commands and responses.
  388.  
  389.   rmt commands are of the following formats -
  390.  
  391.     A. S\n                       Return the status of the open device.
  392.  
  393.     B. C<device>\n               Close the currently open device.
  394.                                  The <device> parameter is ignored.
  395.  
  396.     C. I<operation>\n<count>\n   Performs MTIOCP IOCTL with the
  397.                                  <operation> and <count> parameters.
  398.                                  If the command succeeds, rmt will respond
  399.                                  with <count> as the return code.
  400.  
  401.                                  This operation are, under AIX, as following :
  402.                                   MTOFFL  - rewind & unload tape
  403.                                   MTREW   - rewind tape
  404.                                   MTERASE - erase & rewind tape
  405.                                   MTRETEN - retention & rewind tape
  406.                                   MTWEOF  - write and EOF record to tape
  407.                                   MTFSF   - forward space file
  408.                                   MTRSF   - reverse space file
  409.                                   MTFSR   - forward space record
  410.                                   MTRSR   - reverse space record
  411.                                   MTINSRT - pull tape in from loader
  412.                                   MTEJECT - eject tape out to loader
  413.  
  414.     D. L<offset>\n<whence>\n     Moves the tape to a given location.
  415.                                  The move is done as following :
  416.                                   - If <whence> = SEEK_SET, the file pointer
  417.                                     is positioned <offset> bytes from the
  418.                                     start of the file.
  419.                                   - If <whence> = SEEK_CUR, the file pointer
  420.                                     is moved <offset> bytes forward or
  421.                                     backward, according to <whence>'s sign.
  422.                                   - If <whence> = SEEK_END, the file pointer
  423.                                     is moved <offset> after the file's end.
  424.                                  If the command succeeds, rmt will respond with
  425.                                  a code noting the distance of the head from
  426.                                  the start of the file in bytes.
  427.                                  If the command fails, rmt will respond with
  428.                                  a code of -1.
  429.  
  430.     E. O<device>\n<mode>\n       Opens the specified device in the specified
  431.                                  mode, with <device> being the device's full
  432.                                  name, and <mode> a numerical parameter.
  433.  
  434.     F. R<count>\n                Reads <count> bytes of data from the device.
  435.                                  If the command is successful, rmt will respond
  436.                                  with a code noting the number of bytes read,
  437.                                  and sends the data.
  438.                                  If the command fails, an error code is
  439.                                  returned, without any data.
  440.  
  441.     G. W<count>\n                Writes <count> bytes, read from the
  442.                                  connection, to the current device, aborting
  443.                                  if EOF occurs during the write.
  444.  
  445.   rmt responses are of two formats. Successful commands are responded
  446.   with "A<code>\n", while unsuccessful commands are responded
  447.   with "E<code>\n<error-message>\n".
  448.  
  449.   All numbers (codes, modes, etc) are transfered as ASCII strings representing
  450.   decimal numbers with the appropriate numerical values.
  451.  
  452.   [thanx to James Carlson, carlson@ironbridgenetworks.com]
  453.   [used SunOS & AIX man pages]
  454.  
  455.  
  456.  7. Of the rhosts file.
  457.  ----------------------
  458.  
  459.   The rhosts file is used the specify which remote users can use
  460.   the privileges of a host's local user account over a network,
  461.   used as a very weak authentication for the r-services (it saves
  462.   the need to send a password in the clear over the network, relying
  463.   on the remote host's IP address and the username the process
  464.   claims it belongs to. Should be owned by the local user, and be
  465.   set as readable & writable by the user alone)
  466.  
  467.   From the unix rhosts man page :
  468.  
  469.    The format of the $HOME/.rhosts file is:
  470.  
  471.    HostNameField [UserNameField]
  472.  
  473.    When a remote command executes, the local host uses the local /etc/hosts.equiv
  474.    file and the $HOME/.rhosts file of the local user account to validate
  475.    the remote host and remote user.
  476.  
  477.    Host-Name Field
  478.  
  479.    The .rhosts file supports the following host-name entries:
  480.  
  481.    +             Signifies that any host on the network is trusted.
  482.    HostName      Signifies that any user logging in from HostName is trusted.
  483.    -HostName     Signifie that the host is not trusted.
  484.    +@NetGroup    Signifies that all hosts in the netgroup or no hosts in the
  485.    -@NetGroup     netgroup, respectively, are trusted.
  486.                   The @NetGroup parameter is used by NIS for grouping.
  487.  
  488.    User-Name Field
  489.  
  490.    The .rhosts file supports the following user-name entries:
  491.  
  492.    +             Signifies that any user on the network is trusted. 
  493.    UserName      Signifies that the remote user is trusted.
  494.                   If no username is specified, the remote username
  495.                   must match the local username.
  496.    -UserName     Signifies that the remote user is not trusted. 
  497.    +@NetGroup    Signifies that all users in the netgroup or no 
  498.    -@NetGroup    users in the netgroup, respectively, are trusted.
  499.                   The @NetGroup parameter is used by NIS for grouping.
  500.  
  501.  
  502.  8. Of the syslog protocol.
  503.  --------------------------
  504.  
  505.   And James Carlson <carlson@ironbridgenetworks.com> has said :
  506.  
  507.    'No RFC for it; it's a Unix thing.  The best document for it, like 
  508.     most of the Unix-derived protocols, is the BSD implementation (take 
  509.     a look at lib/libc/gen/syslog.c and usr.sbin/syslogd/syslogd.c).
  510.  
  511.     The format is just ASCII text over UDP messages sent to port 514.
  512.     The text has this format:
  513.  
  514.     "<%d>%.15s %s[%d]: %s"
  515.  
  516.     The first integer is the priority level and facility code (see
  517.     /usr/include/sys/syslog.h), the first string is the date and time
  518.     (ctime()+4), the next string is the process name, the next integer 
  519.     is the PID, and the final string is the text message.
  520.  
  521.     Syslogd will insert a local date/time if the date code in the 
  522.     message appears to be missing (if it has an odd format) and will
  523.     insert the IP address or DNS name of the sender.  It also uses the
  524.     priority level along with the syslog.conf file to determine where
  525.     the message should be delivered (if at all).'
  526.  
  527.   Syslog is now standartized in RFC #3164
  528.    http://www.ietf.org/rfc/rfc3164.txt
  529.  
  530.  
  531.  9. Of the ICQ protocol.
  532.  -----------------------
  533.  
  534.   Magnus Ihse has created a page describing the protocols used by
  535.   Mirabilis' ICQ. This is an unofficial page.
  536.  
  537.    http://www.student.nada.kth.se/~d95-mih/icq/
  538.  
  539.   Details of ICQ's API can be downloaded from Mirabilis' web site,
  540.   subject to certain terms & conditions.
  541.  
  542.  
  543.  10. Of the lpd protocol.
  544.  ------------------------
  545.  
  546.   lpd is described in RFC #1179. This RFC is not a standard, but rather
  547.   a description of some implementations at the time. Other vendors have
  548.   implemented lpd that dont support some of the details in the RFC and/or
  549.   with private extentions. 
  550.    http://www.ietf.org/rfc/rfc1179.txt
  551.  
  552.  
  553.  11. Of the IP checksum.
  554.  -----------------------
  555.  
  556.   The calculation of IP checksums is explained in RFC #1071,
  557.   which is titled "Computing the Internet Checksum", which
  558.   includes calculation examples and code examples in C.
  559.    http://www.ietf.org/rfc/rfc1071.txt
  560.  
  561.   RFC #1071 is updated by RFC #1624, which is titled
  562.   "Computation of the Internet Checksum viaIncremental Update".
  563.    http://www.ietf.org/rfc/rfc1624.txt
  564.  
  565.   Other relevant RFCs are :
  566.  
  567.    - RFC #1936, "Implementing the Internet Checksum in Hardware".
  568.       http://www.ietf.org/rfc/rfc1936.txt
  569.  
  570.    - RFC #1145, RFC #1146, "TCP Alternate Checksum Options".
  571.       http://www.ietf.org/rfc/rfc1145.txt
  572.       http://www.ietf.org/rfc/rfc1146.txt
  573.  
  574.    - RFC #1141, "Incremental Updating of the Internet Checksum".
  575.       http://www.ietf.org/rfc/rfc1141.txt
  576.  
  577.  
  578.  
  579.