TCP/IP Applications FAQ

Message-ID: <internet/tcp-ip/applications-FAQ_1060423754@rtfm.mit.edu> X-Last-Updated: 2003/06/08 Newsgroups: comp.protocols.tcp-ip, comp.protocols.tcp-ip.ibmpc, comp.sys.mac.comm, comp.unix.questions, comp.os.ms-windows.networking.tcp-ip From: uriraz@private.org.il (Uri Raz) Subject: TCP/IP Applications FAQ 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. Date: 09 Aug 2003 10:13:58 GMT Posting-Frequency: Monthly Copyright: (c) 1998-2001 Uri Raz Maintainer: Uri Raz <uriraz@private.org.il> Last-modified: 14/Nov/2001 Archive-Name: internet/tcp-ip/applications-FAQ URL: http://www.private.org.il/mini-tcpip.faq.html ************************************************************************** * * * 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 mailto:uriraz@private.org.il * * * * 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. * * * ************************************************************************** 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 : ftp://venera.isi.edu/in-notes/std/ ] 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 www.ibm.com (204.146.18.33), 30 hops max, 20 byte packets 1 teg.technion.ac.il (132.68.7.254) 1 ms 1 ms 1 ms 2 tau-smds.man.ac.il (128.139.210.16) 6 ms 5 ms 5 ms 3 128.139.198.129 (128.139.198.129) 9 ms 8 ms 10 ms 4 TAU-shiber.route.ibm.net.il (192.115.73.5) 160 ms 57 ms 43 ms 5 * fe7507.tlv.ibm.net.il (192.116.177.1) 24 ms 15 ms 6 port1br1.pt.uk.ibm.net (152.158.16.1) 266 ms 173 ms 152 ms 7 165.87.220.34 (165.87.220.34) 468 ms 408 ms 422 ms 8 165.87.28.105 (165.87.28.105) 453 ms 446 ms 434 ms 9 colu35-16-br2.oh.us.ibm.net (165.87.35.18) 453 ms colu35-32-br2.oh.us.ibm.net (165.87.35.34) 514 ms colu35-16-br2.oh.us.ibm.net (165.87.35.18) 525 ms 10 colu35-64-sf1.oh.us.ibm.net (165.87.35.76) 590 ms 536 ms 489 ms 11 204.146.18.33 (204.146.18.33) 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 - http://ftp.arl.mil/~mike/ping.html [thanx to Barry Margolin, barmar@bbnplanet.com] [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 http://www.alternic.org/drafts/drafts-h-i/draft-hunter-talk-00.html Eric Ludlam's GNU Talk page includes an extended talk implementation. http://www.ultranet.com/~zappo/gtalk.shtml 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 127.0.0.1.1016 > 127.0.0.1.512: 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 127.0.0.1.512 > 127.0.0.1.1016: 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 127.0.0.1.1016 > 127.0.0.1.512: . 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 127.0.0.1.1016 > 127.0.0.1.512: 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 127.0.0.1.512 > 127.0.0.1.1016: . 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 127.0.0.1.1013 > 127.0.0.1.1014: 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 127.0.0.1.1014 > 127.0.0.1.1013: 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 127.0.0.1.1013 > 127.0.0.1.1014: . 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 127.0.0.1.1016 > 127.0.0.1.512: 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 127.0.0.1.512 > 127.0.0.1.1016: . 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 127.0.0.1.1016 > 127.0.0.1.512: 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 127.0.0.1.512 > 127.0.0.1.1016: . 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 127.0.0.1.512 > 127.0.0.1.1016: 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 127.0.0.1.1016 > 127.0.0.1.512: . 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 127.0.0.1.512 > 127.0.0.1.1016: 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 127.0.0.1.512 > 127.0.0.1.1016: 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 127.0.0.1.1016 > 127.0.0.1.512: . 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 127.0.0.1.1013 > 127.0.0.1.1014: 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 127.0.0.1.1014 > 127.0.0.1.1013: . 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 127.0.0.1.1016 > 127.0.0.1.512: 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 127.0.0.1.512 > 127.0.0.1.1016: . 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 127.0.0.1.1014 > 127.0.0.1.1013: 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 127.0.0.1.1013 > 127.0.0.1.1014: . 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, aaron@cisco.com] 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 socket: * 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 http://www.ietf.org/rfc/rfc1282.txt 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, carlson@ironbridgenetworks.com] [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 <carlson@ironbridgenetworks.com> 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).' Syslog is now standartized in RFC #3164 http://www.ietf.org/rfc/rfc3164.txt 9. Of the ICQ protocol. ----------------------- Magnus Ihse has created a page describing the protocols used by Mirabilis' ICQ. This is an unofficial page. http://www.student.nada.kth.se/~d95-mih/icq/ 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. http://www.ietf.org/rfc/rfc1179.txt 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. http://www.ietf.org/rfc/rfc1071.txt RFC #1071 is updated by RFC #1624, which is titled "Computation of the Internet Checksum viaIncremental Update". http://www.ietf.org/rfc/rfc1624.txt Other relevant RFCs are : - RFC #1936, "Implementing the Internet Checksum in Hardware". http://www.ietf.org/rfc/rfc1936.txt - RFC #1145, RFC #1146, "TCP Alternate Checksum Options". http://www.ietf.org/rfc/rfc1145.txt http://www.ietf.org/rfc/rfc1146.txt - RFC #1141, "Incremental Updating of the Internet Checksum". http://www.ietf.org/rfc/rfc1141.txt

Are you an expert in some area? Share your knowledge and earn expert points by giving answers or rating people's questions and answers! This section of FAQS.ORG is not sanctioned in any way by FAQ authors or maintainers.

Questions awaiting answers:

[ Usenet FAQs | Search | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
uriraz@private.org.il (Uri Raz)

Last Update August 26 2003 @ 00:20 AM