HP OpenVMS systems documentation

To access data inside the packet, use the following syntax:

proto [expr : size]

The following list describes the variables.

• The proto variable is one of the following:
  • ether
  • fddi
  • ip
  • arp
  • rarp
  • tcp
  • udp
  • icmp
  
  The proto variable indicates the protocol layer for the index operation.
• The byte offset, relative to the indicated protocol layer, is specified by expr.
• The size variable is optional and indicates the number of bytes in the field of interest; it can be:
  • one
  • two
  • or
  • four
  
  The default size is one .

For example:

• ether[0] & 1 != 0 detects all multicast traffic.
• ip[0] & 0xf != 5 detects all IP packets with options.
• ip[2:2] & 0x1fff = 0 detects only unfragmented datagrams and fragment zero of fragmented datagrams. This check is implicitly applied to the TCP and UDP index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment.

Keywords can be combined using:

• A parenthesized group of primitives and operators
• Negation ( ! or not )
• Concatenation ( and )
• Alternation ( or )

Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens (not juxtaposition) are required for concatenation.

If an identifier is given without a keyword, the most recent keyword is assumed. For example, the following two examples are equivalent:

not host vs and ace not host vs and host ace

However, the following example is not equivalent to the previous two:

not ( host vs or ace )

Expression arguments can be passed to tcpdump as either a single argument or as multiple arguments, whichever is more convenient. Multiple arguments are concatenated with spaces before being parsed.

1.2.5.3 Analyzing Output

The output of the tcpdump utility is protocol dependent. The following sections describe the formats and provide examples.

1.2.5.3.1 Link Level Headers

The -e option is used to display the link level header. On Ethernet networks, the source and destination addresses, protocol, and packet length are displayed.

Only Ethernet frame types are supported with tcpdump .

1.2.5.3.2 ARP Packets

ARP output shows the type of request and its arguments. The format is intended to be self explanatory. The following example is taken from the start of an RLOGIN session from host rtsg to host csam :

arp who-has csam tell rtsg arp reply csam is-at CSAM

The first line indicates that host rtsg sent an ARP packet asking for the Ethernet address of Internet host csam. Host csam replies with its Ethernet address (in this example, Ethernet addresses are uppercase and Internet addresses in lowercase).

This is equivalent to:

arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

If you issue the tcpdump -e command, the first packet is explicitly a broadcast packet and the second is a point-to-point packet:

RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM

For the first packet, the Ethernet source address is RTSG, the destination is the broadcast address, the type field contain hex 0806 (type ETHER_ARP) and the total length is 64 bytes.

1.2.5.3.3 TCP Packets

The following description assumes familiarity with the TCP protocol described in RFC 793.

The general format of a TCP protocol line is:

src > dst: flags data-seqno ack window options

The fields represent the following:

• src
  The source 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 example below).
• 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.
• urgent
  Indicates there is urgent data in the packet.
• options
  The TCP options enclosed in angle brackets. For example:

  <mss 1024>

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 output only if appropriate.

Examples

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 <mss 1024> csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> 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 example shows the following sequence of communication:

• 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 that 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 contained 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 displays 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 displayed. Thus, 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 option overrides this feature, causing the original 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 ninth lines show that host csam sends two bytes of urgent, pushed data to rtsg.

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 number) and the higher level protocol information displayed, specifically Domain Name service requests (RFC 1034 and RFC 1035) and Sun RPC calls (RFC 1050) to NFS.

1.2.5.3.5 UDP Name Server Requests

The following description assumes familiarity with the Domain Service protocol 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 displayed between the 3 and the plus sign (+). Similarly, the qclass was the normal one, C_IN, and omitted. Any other qclass would have been displayed immediately after the A.

The following anomalies are checked and may result in extra fields enclosed in square brackets:

• If a query contains an answer, name server, or authority section, ancount, nscount, or arcount are displayed as [na], [nn] or [nau], where n is the appropriate count.
• If any of the response bits are set (AA, RA or rcode) or any of the "must be zero" bits are set in bytes 2 and 3, [b2&3=x]) is displayed, where x is the hexadecimal value of header bytes 2 and 3.

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 128.32.137.3 (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 128.32.137.3. 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 displayed.

Other flag characters that might appear are the minus sign (-) (recursion available, RA, not set) and vertical bar (|) (truncated message, TC, set). If the "question" section does not contain exactly one entry, [nq] is displayed.

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 option to increase the snaplen if you need to seriously investigate name server traffic.

1.2.5.3.7 Sun RPC Requests and Replies

Sun RPC (RFC 1057) is decoded as described in Table 1-4, as are several of the protocols that use Sun RPC.

Table 1-4 SUN RPC Requests

Name	Users	Description
PORTMAP	libc.a, portmap	Maps RPC program numbers to TCP/UDP ports.
MOUNT	mount, mountd	Maps file names to NFS file handles.
NLM	rpc.lockd	NFS remote file locking.
STAT	rpc.statd, rpc.lockd	Remote status monitor.
YP	libc.a, ypserv	Network Information Services.
YPBIND	ypbind, ypset	NIS domain manipulation.
NFS	UNIX	Network File System.

Requests sent using TCP must start at the beginning of a packet to be decoded. Normally they are; however, applications that have multiple requests outstanding (for example, NFS) may not always do this.

Replies can only be decoded if the request was found and only if they start a packet.

The form of an RPC request and reply is as follows:

src.xid > dst.prot-vn: len call op args src.xid > dst.prot-vn: len reply op results

For example, NFS mounting a file system generates:

clnt.312dbc68 > svc.pmap-v2: 56 call getport prog "nfs" V3 prot UDP po0 svc.312dbc68 > clnt.pmap-v2: 28 reply getport 2049 clnt.312deff8 > svc.pmap-v2: 56 call getport prog "mount" V3 prot UDP 0 svc.312deff8 > clnt.pmap-v2: 28 reply getport 1034 clnt.312deff8 > svc.mount-v3: 124 call mount "/build" svc.312deff8 > clnt.mount-v3: 68 reply mount OSF/1 fh 8,3079/1.2 clnt.907312 > svc.nfs-v3: 148 call getattr OSF/1 fh 8,3079/1.2 svc.907312 > clnt.nfs-v3: 112 reply getattr {dir size 1024 mtime ... }

The UDP or TCP protocol information is not displayed. This is generally not important for UDP; however, it can be important for TCP. If the -m and -v options are in effect, both RPC and TCP decoding are done. For example, the UNIX command showmount -e srv generates information such as the following:

clnt.3123f473 > svc.pmap-v2: 56 call getport prog "mount" V1 prot TCP 0 (ttl 29, id 19672) svc.3123f473 > clnt.pmap-v2: 28 reply getport 892 (ttl 30, id 31644) clnt.1032 > svc.892: S 25280000:25280000(0) win 32768 <mss 1460,nop,wsca> (DF) (ttl 59, id 19674) svc.892 > clnt.1032: S 483136000:483136000(0) ack 25280001 win 33580 <mss 1460,nop,wscale 0> (ttl 60, id 31645) clnt.1032 > svc.892: . ack 1 win 33580 (DF) (ttl 59, id 19675) clnt.2f221c23 > svc.mount-v1: 40 call return export list TCP: clnt.1032 > svc.892: P 1:45(44) ack 1 win 33580 (DF) (ttl 59, id 19) svc.2f221c23 > clnt.mount-v1: 184 reply export "/usr": "client" "clnt" "/build": ... TCP: svc.892 > clnt.1032: P 1:189(188) ack 45 win 33580 (ttl 60, id 3164) clnt.1032 > svc.892: F 45:45(0) ack 189 win 33580 (DF) (ttl 59, id 19679) svc.892 > clnt.1032: . ack 46 win 33580 (ttl 60, id 31649) svc.892 > clnt.1032: F 189:189(0) ack 46 win 33580 (ttl 60, id 31650) clnt.1032 > svc.892: . ack 190 win 33580 (DF) (ttl 59, id 19681)

The following is another NFS sample:

sushi.6709 > wrl.nfs-v2: 112 call readlink fh 21,24/10.731657119 wrl.6709 > sushi.nfs-v2: 40 reply readlink "../var" sushi.201b > wrl.nfs-v2: 144 call lookup fh 9,74/4096.6878 "xcolors" wrl.201b > sushi.nfs-v2: 128 reply lookup fh 9,74/4134.3150

The example shows the following sequence of communication:

• 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 generation number.) Host wrl replies 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.
• The data displayed depends on the operation type. The format is intended to be self explanatory if read in conjunction with a protocol specification rpcgen .x file.

If the -v (verbose) option is given, additional information is displayed.

If the -v option is given more than once, more details may be displayed.

Note that RPC requests are very large and much of the detail is not displayed. Property list information may also be obtained using tcpdump . For example:

node1.abc.com.da31fba5 > node2.abc.com.proplist-v3: \ 276 call proproc3_get OSF/1 fh 8,18434/1.4 mask:-1 11 entries node2.abc.com.da31fba5 > node1.abc.com.proplist-v3: \ 296 reply proproc3_get status OK 368 bytes 11 entries

For property list calls, you can request the mask value and the number of property list entries. Property list replies return the status, the number of bytes in the property list and the number of entries in property list.

Note that NFS requests are very large and much of the detail is not displayed unless the value of snaplen is increased. Use -s 192 to watch RPC traffic.

RPC 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 corresponding request, it might not be parsable.

1.2.5.3.8 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 is the fragment ID.
• size is the fragment size (in bytes), excluding the IP header.
• offset is 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 displayed 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:

• Addresses in the second line do not include port numbers. This is because the TCP protocol information is in the first fragment and tcpdump does not know what the port or sequence numbers are when it displays the later fragments.
• TCP sequence information in the first line is displayed as if there were 308 bytes of user data; however, there are 512 bytes (308 in the first fragment and 204 in the second). If you are looking for holes in the sequence space or trying to match up acknowledgements with packets, this can be misleading.
  A packet with the IP "do not fragment" flag is marked with a trailing (DF).

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.