@ Additional Network TCP/IP Information
There are several other packet headers that don't quite follow the previous description:
10:35:41.552679 2.0.256.256.53 > 10.0.256.256.53: 33259 [b2&3=0x30] (32)
33259 is the ID #
src > dst: flags data-seqno ack window urgent options The fields represent the following: src The destination IP addresses and ports. dst The destination IP addresses and ports. flags The sum combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single period (.) for no flags. data-seqno The portion of sequence space covered by the data in this packet (see the following example). ack The sequence number of the next data expected from the other direction on this connection. window The number of bytes of receive buffer space available from the other direction on this connection. urg Indicates there is urgent data in the packet. options The TCP options enclosed in angle brackets. For example,
The src, dst, and flags fields are always present. The other fields depend on the contents of the packet's TCP protocol header and are out- put only if appropriate. The following example shows the opening portion of an rlogin session from host rtsg to host csam: rtsg.1023 > csam.login: S 768512:768512(0) win 4096 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 rtsg.1023 > csam.login: . ack 1 win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 csam.login > rtsg.1023: . ack 2 win 4096 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1 The first line indicates that TCP port 1023 on system rtsg sent a packet to port login on host csam. The S indicates that the SYN flag was set. The packet sequence number was 768512 and it contained no data. (The notation is first:last(nbytes) which means sequence numbers first up to but not including last which is nbytes bytes of user data.) There was no piggy- backed ack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes. Host csam replies with a similar packet except it includes a piggy-backed ack for the SYN sent by rtsg. Host rtsg then sends an ack reply to the SYN sent by csam. The period (.) means no flags were set. The packet con- tained no data so there is no data sequence number. Note that the ack sequence number is a small integer (1). The first time tcpdump sees a TCP conversation, it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation's data stream (with the first data byte each direction being 1). The -S flag overrides this feature, causing the origi- nal sequence numbers to be output. The sixth line indicates that host rtsg sends host csam 19 bytes of data (bytes 2 through 20 in the rtsg to csam side of the conversation). The PUSH flag is set in the packet. The seventh line indicates that host csam has received data sent by host rtsg up to but not including byte 21. Most of this data is apparently sitting in the socket buffer because the receive window on host csam is 19 bytes smaller. Host csam also sends one byte of data to host rtsg in this packet. The eighth and nineth lines show that host csam sends two bytes of urgent, pushed data to rtsg. UDP Packets The UDP format is illustrated by the following rwho packet: actinide.who > broadcast.who: udp 84 This line of output indicates that port who on host actinide sent a UDP datagram to port who on host broadcast, the Internet broadcast address. The packet contained 84 bytes of user data. Some UDP services are recognized (from the source or destination port num- ber) and the higher level protocol information printed. In particular, Domain Name service requests (RFC 1034 and RFC 1035) and Sun RPC calls (RFC 1050) to NFS. UDP Name Server Requests The following description assumes familiarity with the Domain Service pro- tocol described in RFC-1035. Name server requests are formatted as follows: src > dst: id op? flags qtype qclass name (len) For example: h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37) Host h2opolo queried the domain server on host helios for an address record (qtype=A) associated with the name ucbvax.berkeley.edu. The query ID was 3. The plus sign (+) indicates the recursion desired flag was set. The query length was 37 bytes, not including the UDP and IP protocol headers. The query operation was the normal one, Query, so the op field was omitted. If the op field had been anything else, it would have been printed between the 3 and the plus sign (+). Similarly, the qclass was the normal one, C_IN, and omitted. Any other qclass would have been printed immediately after the A. A following anomalies are checked and may result in extra fields enclosed in square brackets: o If a query contains an answer, name server or authority section, ancount, nscount, or arcount are printed as [na], [nn] or [nau] where n is the appropriate count. o If any of the response bits are set (AA, RA or rcode) or any of the `must be zero' bits are set in bytes and 3, [b2&3=x] is printed, where x is the hex value of header bytes 2 and 3. UDP Name Server Responses Name server responses are formatted as follows: src > dst: id op rcode flags a/n/au type class data (len) For example: helios.domain > h2opolo.1538: 3 3/3/7 A 18.104.22.168 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97) In the first example, host helios responds to query ID 3 from host h2opolo with 3 answer records, 3 name server records, and 7 authority records. The first answer record is type A (address) and its data is Internet address 22.214.171.124. The total size of the response is 273 bytes, excluding UDP and IP headers. The op (Query) and response code (NoError) are omitted, as is the class (C_IN) of the A record. In the second example, host helios responds to query 2 with a response code of nonexistent domain (NXDomain) with no answers, one name server and no authority records. The asterisk (*) indicates that the authoritative answer bit is set. Since there are no answers, no type, class or data are printed. Note that name server requests and responses tend to be large, and the default value of snaplen, 96 bytes, may not capture enough of the packet to print. Use the -s flag to increase the snaplen if you need to seriously investigate name server traffic. NFS Requests and Replies NFS requests and replies are printed as follows: src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results For example: sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.731657119 wrl.nfs > sushi.6709: reply ok 40 readlink "../var" sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150 In the first line, host sushi sends a transaction with ID 6709 to host wrl (the number following the src host is a transaction ID, not the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a readlink (read symbolic link) on file handle (fh) 21,24/10.731657119. (In some cases, the file handle can be interpreted as a major and minor device number pair, followed by the inode number and gen- eration number.) Host wrl replies ok with the contents of the link. In the third line, host sushi asks host wrl to look up the name xcolors in directory file 9,74/4096.6878. Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol specification. If the -v (verbose) flag is given, additional information is printed. For example: sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388 (The -v flag also prints the IP header TTL, ID, and fragmentation fields, that have been omitted from this example.) In the first line, host sushi asks host wrl to read 8192 bytes from file 21,11/12.195, at byte offset 24576. Host Wrl replies ok; the packet shown on the second line is the first fragment of the reply, and therefore is only 1472 bytes long. (The other bytes will follow in subsequent fragments, but these fragments do not have NFS or UDP headers and so might not be printed, depending on the fil- ter expression used.) Because the -v flag is given, some of the file attributes (that are returned in addition to the file data) are printed: the file type (REG, for regular file), the file mode (in octal), the UID and GID, and the file size. If the -v flag is given more than once, even more details are printed. Note that NFS requests are very large and much of the detail is not printed unless the value of snaplen is increased. Try using -s 192 to watch NFS traffic. NFS reply packets do not explicitly identify the RPC operation. Instead, tcpdump keeps track of recent requests, and matches them to the replies using the transaction ID. If a reply does not closely follow the corre- sponding request, it might not be parsable. NFS and Sun are registered trademarks of Sun Microsystems, Inc. A packet with the IP `do not fragment' flag is marked with a trailing (DF). IP Fragmentation Fragmented Internet datagrams are printed as follows: (frag id:size@offset+) (frag id:size@offset) The first line indicates there are more fragments. The second indicates this is the last fragment. The following list explains the fields: id The fragment ID size The fragment size (in bytes) excluding the IP header offset The fragment's offset (in bytes) in the original datagram The fragment information is output for each fragment. The first fragment contains the higher level protocol header and the fragment information is printed after the protocol information. Fragments after the first contain no higher level protocol header and the fragment information is printed after the source and destination addresses. The following example shows part of an FTP session from arizona.edu to lbl-rtsg.arpa over a CSNET connection that does not appear to handle 576 byte datagrams: arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) arizona > rtsg: (frag 595a:204@328) rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560 Note the following: o Addresses in the second line do not include port numbers. This is because the TCP protocol information is in the first fragment and we do not know what the port or sequence numbers are when we print the later fragments. Timestamps By default, all output lines are preceded by a timestamp. The timestamp is the current clock time in the following form: hh:mm:ss.frac It is as accurate as the kernel's clock. The timestamp reflects the time the kernel first saw the packet. No attempt is made to account for the time difference between when the Ethernet interface removed the packet from the wire and when the kernel serviced the new packet interrupt.Z
Copyright ©1996-2001 by the Institute for Visualization and Perception Research. All rights reserved.
Please, send comments and/or questions to Dr. Georges Grinstein.
Last update: April 4, 2001