Flatten vendor/tcpdump and remove keyword expansion.

1 files changed, 0 insertions, 2359 deletions

diff --git a/contrib/tcpdump/tcpdump.1 b/contrib/tcpdump/tcpdump.1
deleted file mode 100644
index d13b4de..0000000
--- a/contrib/tcpdump/tcpdump.1
+++ /dev/null
@@ -1,2359 +0,0 @@
-.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.167.2.11 2007/06/15 20:13:49 guy Exp $ (LBL)
-.\"
-.\"	$NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $
-.\"
-.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
-.\"	The Regents of the University of California.  All rights reserved.
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that: (1) source code distributions
-.\" retain the above copyright notice and this paragraph in its entirety, (2)
-.\" distributions including binary code include the above copyright notice and
-.\" this paragraph in its entirety in the documentation or other materials
-.\" provided with the distribution, and (3) all advertising materials mentioning
-.\" features or use of this software display the following acknowledgement:
-.\" ``This product includes software developed by the University of California,
-.\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
-.\" the University nor the names of its contributors may be used to endorse
-.\" or promote products derived from this software without specific prior
-.\" written permission.
-.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
-.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
-.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-.\"
-.TH TCPDUMP 1  "18 April 2005"
-.SH NAME
-tcpdump \- dump traffic on a network
-.SH SYNOPSIS
-.na
-.B tcpdump
-[
-.B \-AdDeflLnNOpqRStuUvxX
-] [
-.B \-c
-.I count
-]
-.br
-.ti +8
-[
-.B \-C
-.I file_size
-] [
-.B \-F
-.I file
-]
-.br
-.ti +8
-[
-.B \-i
-.I interface
-]
-[
-.B \-m
-.I module
-]
-[
-.B \-M
-.I secret
-]
-.br
-.ti +8
-[
-.B \-r
-.I file
-]
-[
-.B \-s
-.I snaplen
-]
-[
-.B \-T
-.I type
-]
-[
-.B \-w
-.I file
-]
-.br
-.ti +8
-[
-.B \-W
-.I filecount
-]
-.br
-.ti +8
-[
-.B \-E
-.I spi@ipaddr algo:secret,...
-]
-.br
-.ti +8
-[
-.B \-y
-.I datalinktype
-]
-[
-.B \-Z
-.I user
-]
-.ti +8
-[
-.I expression
-]
-.br
-.ad
-.SH DESCRIPTION
-.LP
-\fITcpdump\fP prints out a description of the contents of packets on a
-network interface that match the boolean \fIexpression\fP.  It can also
-be run with the
-.B \-w
-flag, which causes it to save the packet data to a file for later
-analysis, and/or with the
-.B \-r
-flag, which causes it to read from a saved packet file rather than to
-read packets from a network interface.  In all cases, only packets that
-match
-.I expression
-will be processed by
-.IR tcpdump .
-.LP
-.I Tcpdump
-will, if not run with the
-.B \-c
-flag, continue capturing packets until it is interrupted by a SIGINT
-signal (generated, for example, by typing your interrupt character,
-typically control-C) or a SIGTERM signal (typically generated with the
-.BR kill (1)
-command); if run with the
-.B \-c
-flag, it will capture packets until it is interrupted by a SIGINT or
-SIGTERM signal or the specified number of packets have been processed.
-.LP
-When
-.I tcpdump
-finishes capturing packets, it will report counts of:
-.IP
-packets ``captured'' (this is the number of packets that
-.I tcpdump
-has received and processed);
-.IP
-packets ``received by filter'' (the meaning of this depends on the OS on
-which you're running
-.IR tcpdump ,
-and possibly on the way the OS was configured - if a filter was
-specified on the command line, on some OSes it counts packets regardless
-of whether they were matched by the filter expression and, even if they
-were matched by the filter expression, regardless of whether
-.I tcpdump
-has read and processed them yet, on other OSes it counts only packets that were
-matched by the filter expression regardless of whether
-.I tcpdump
-has read and processed them yet, and on other OSes it counts only
-packets that were matched by the filter expression and were processed by
-.IR tcpdump );
-.IP
-packets ``dropped by kernel'' (this is the number of packets that were
-dropped, due to a lack of buffer space, by the packet capture mechanism
-in the OS on which
-.I tcpdump
-is running, if the OS reports that information to applications; if not,
-it will be reported as 0).
-.LP
-On platforms that support the SIGINFO signal, such as most BSDs
-(including Mac OS X) and Digital/Tru64 UNIX, it will report those counts
-when it receives a SIGINFO signal (generated, for example, by typing
-your ``status'' character, typically control-T, although on some
-platforms, such as Mac OS X, the ``status'' character is not set by
-default, so you must set it with
-.BR stty (1)
-in order to use it) and will continue capturing packets.
-.LP
-Reading packets from a network interface may require that you have
-special privileges:
-.TP
-.B Under SunOS 3.x or 4.x with NIT or BPF:
-You must have read access to
-.I /dev/nit
-or
-.IR /dev/bpf* .
-.TP
-.B Under Solaris with DLPI:
-You must have read/write access to the network pseudo device, e.g.
-.IR /dev/le .
-On at least some versions of Solaris, however, this is not sufficient to
-allow
-.I tcpdump
-to capture in promiscuous mode; on those versions of Solaris, you must
-be root, or
-.I tcpdump
-must be installed setuid to root, in order to capture in promiscuous
-mode.  Note that, on many (perhaps all) interfaces, if you don't capture
-in promiscuous mode, you will not see any outgoing packets, so a capture
-not done in promiscuous mode may not be very useful.
-.TP
-.B Under HP-UX with DLPI:
-You must be root or
-.I tcpdump
-must be installed setuid to root.
-.TP
-.B Under IRIX with snoop:
-You must be root or
-.I tcpdump
-must be installed setuid to root.
-.TP
-.B Under Linux:
-You must be root or
-.I tcpdump
-must be installed setuid to root (unless your distribution has a kernel
-that supports capability bits such as CAP_NET_RAW and code to allow
-those capability bits to be given to particular accounts and to cause
-those bits to be set on a user's initial processes when they log in, in
-which case you  must have CAP_NET_RAW in order to capture and
-CAP_NET_ADMIN to enumerate network devices with, for example, the
-.B \-D
-flag).
-.TP
-.B Under ULTRIX and Digital UNIX/Tru64 UNIX:
-Any user may capture network traffic with
-.IR tcpdump .
-However, no user (not even the super-user) can capture in promiscuous
-mode on an interface unless the super-user has enabled promiscuous-mode
-operation on that interface using
-.IR pfconfig (8),
-and no user (not even the super-user) can capture unicast traffic
-received by or sent by the machine on an interface unless the super-user
-has enabled copy-all-mode operation on that interface using
-.IR pfconfig ,
-so
-.I useful
-packet capture on an interface probably requires that either
-promiscuous-mode or copy-all-mode operation, or both modes of
-operation, be enabled on that interface.
-.TP
-.B Under BSD (this includes Mac OS X):
-You must have read access to
-.I /dev/bpf*
-on systems that don't have a cloning BPF device, or to
-.I /dev/bpf
-on systems that do.
-On BSDs with a devfs (this includes Mac OS X), this might involve more
-than just having somebody with super-user access setting the ownership
-or permissions on the BPF devices - it might involve configuring devfs
-to set the ownership or permissions every time the system is booted,
-if the system even supports that; if it doesn't support that, you might
-have to find some other way to make that happen at boot time.
-.LP
-Reading a saved packet file doesn't require special privileges.
-.SH OPTIONS
-.TP
-.B \-A
-Print each packet (minus its link level header) in ASCII.  Handy for
-capturing web pages.
-.TP
-.B \-c
-Exit after receiving \fIcount\fP packets.
-.TP
-.B \-C
-Before writing a raw packet to a savefile, check whether the file is
-currently larger than \fIfile_size\fP and, if so, close the current
-savefile and open a new one.  Savefiles after the first savefile will
-have the name specified with the
-.B \-w
-flag, with a number after it, starting at 1 and continuing upward.
-The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
-not 1,048,576 bytes).
-.TP
-.B \-d
-Dump the compiled packet-matching code in a human readable form to
-standard output and stop.
-.TP
-.B \-dd
-Dump packet-matching code as a
-.B C
-program fragment.
-.TP
-.B \-ddd
-Dump packet-matching code as decimal numbers (preceded with a count).
-.TP
-.B \-D
-Print the list of the network interfaces available on the system and on
-which
-.I tcpdump
-can capture packets.  For each network interface, a number and an
-interface name, possibly followed by a text description of the
-interface, is printed.  The interface name or the number can be supplied
-to the
-.B \-i
-flag to specify an interface on which to capture.
-.IP
-This can be useful on systems that don't have a command to list them
-(e.g., Windows systems, or UNIX systems lacking
-.BR "ifconfig \-a" );
-the number can be useful on Windows 2000 and later systems, where the
-interface name is a somewhat complex string.
-.IP
-The
-.B \-D
-flag will not be supported if
-.I tcpdump
-was built with an older version of
-.I libpcap
-that lacks the
-.B pcap_findalldevs()
-function.
-.TP
-.B \-e
-Print the link-level header on each dump line.
-.TP
-.B \-E
-Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that
-are addressed to \fIaddr\fP and contain Security Parameter Index value
-\fIspi\fP. This combination may be repeated with comma or newline seperation.
-.IP
-Note that setting the secret for IPv4 ESP packets is supported at this time.
-.IP
-Algorithms may be
-\fBdes-cbc\fP,
-\fB3des-cbc\fP,
-\fBblowfish-cbc\fP,
-\fBrc3-cbc\fP,
-\fBcast128-cbc\fP, or
-\fBnone\fP.
-The default is \fBdes-cbc\fP.
-The ability to decrypt packets is only present if \fItcpdump\fP was compiled
-with cryptography enabled.
-.IP
-\fIsecret\fP is the ASCII text for ESP secret key. 
-If preceeded by 0x, then a hex value will be read.
-.IP
-The option assumes RFC2406 ESP, not RFC1827 ESP.
-The option is only for debugging purposes, and
-the use of this option with a true `secret' key is discouraged.
-By presenting IPsec secret key onto command line
-you make it visible to others, via
-.IR ps (1)
-and other occasions.
-.IP
-In addition to the above syntax, the syntax \fIfile name\fP may be used
-to have tcpdump read the provided file in. The file is opened upon 
-receiving the first ESP packet, so any special permissions that tcpdump
-may have been given should already have been given up.
-.TP
-.B \-f
-Print `foreign' IPv4 addresses numerically rather than symbolically
-(this option is intended to get around serious brain damage in
-Sun's NIS server \(em usually it hangs forever translating non-local
-internet numbers).
-.IP
-The test for `foreign' IPv4 addresses is done using the IPv4 address and
-netmask of the interface on which capture is being done.  If that
-address or netmask are not available, available, either because the
-interface on which capture is being done has no address or netmask or
-because the capture is being done on the Linux "any" interface, which
-can capture on more than one interface, this option will not work
-correctly.
-.TP
-.B \-F
-Use \fIfile\fP as input for the filter expression.
-An additional expression given on the command line is ignored.
-.TP
-.B \-i
-Listen on \fIinterface\fP.
-If unspecified, \fItcpdump\fP searches the system interface list for the
-lowest numbered, configured up interface (excluding loopback).
-Ties are broken by choosing the earliest match.
-.IP
-On Linux systems with 2.2 or later kernels, an
-.I interface
-argument of ``any'' can be used to capture packets from all interfaces.
-Note that captures on the ``any'' device will not be done in promiscuous
-mode.
-.IP
-If the
-.B \-D
-flag is supported, an interface number as printed by that flag can be
-used as the
-.I interface
-argument.
-.TP
-.B \-l
-Make stdout line buffered.
-Useful if you want to see the data
-while capturing it.
-E.g.,
-.br
-``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
-``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
-.TP
-.B \-L
-List the known data link types for the interface and exit.
-.TP
-.B \-m
-Load SMI MIB module definitions from file \fImodule\fR.
-This option
-can be used several times to load several MIB modules into \fItcpdump\fP.
-.TP
-.B \-M
-Use \fIsecret\fP as a shared secret for validating the digests found in
-TCP segments with the TCP-MD5 option (RFC 2385), if present.
-.TP
-.B \-n
-Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
-.TP
-.B \-N
-Don't print domain name qualification of host names.
-E.g.,
-if you give this flag then \fItcpdump\fP will print ``nic''
-instead of ``nic.ddn.mil''.
-.TP
-.B \-O
-Do not run the packet-matching code optimizer.
-This is useful only
-if you suspect a bug in the optimizer.
-.TP
-.B \-p
-\fIDon't\fP put the interface
-into promiscuous mode.
-Note that the interface might be in promiscuous
-mode for some other reason; hence, `-p' cannot be used as an abbreviation for
-`ether host {local-hw-addr} or ether broadcast'.
-.TP
-.B \-q
-Quick (quiet?) output.
-Print less protocol information so output
-lines are shorter.
-.TP
-.B \-R
-Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
-If specified, \fItcpdump\fP will not print replay prevention field.
-Since there is no protocol version field in ESP/AH specification,
-\fItcpdump\fP cannot deduce the version of ESP/AH protocol.
-.TP
-.B \-r
-Read packets from \fIfile\fR (which was created with the
-.B \-w
-option).
-Standard input is used if \fIfile\fR is ``-''.
-.TP
-.B \-S
-Print absolute, rather than relative, TCP sequence numbers.
-.TP
-.B \-s
-Snarf \fIsnaplen\fP bytes of data from each packet rather than the
-default of 68 (with SunOS's NIT, the minimum is actually 96).
-68 bytes is adequate for IP, ICMP, TCP
-and UDP but may truncate protocol information from name server and NFS
-packets (see below).
-Packets truncated because of a limited snapshot
-are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
-is the name of the protocol level at which the truncation has occurred.
-Note that taking larger snapshots both increases
-the amount of time it takes to process packets and, effectively,
-decreases the amount of packet buffering.
-This may cause packets to be
-lost.
-You should limit \fIsnaplen\fP to the smallest number that will
-capture the protocol information you're interested in.
-Setting
-\fIsnaplen\fP to 0 means use the required length to catch whole packets.
-.TP
-.B \-T
-Force packets selected by "\fIexpression\fP" to be interpreted the
-specified \fItype\fR.
-Currently known types are
-\fBaodv\fR (Ad-hoc On-demand Distance Vector protocol),
-\fBcnfp\fR (Cisco NetFlow protocol),
-\fBrpc\fR (Remote Procedure Call),
-\fBrtp\fR (Real-Time Applications protocol),
-\fBrtcp\fR (Real-Time Applications control protocol),
-\fBsnmp\fR (Simple Network Management Protocol),
-\fBtftp\fR (Trivial File Transfer Protocol),
-\fBvat\fR (Visual Audio Tool),
-and
-\fBwb\fR (distributed White Board).
-.TP
-.B \-t
-\fIDon't\fP print a timestamp on each dump line.
-.TP
-.B \-tt
-Print an unformatted timestamp on each dump line.
-.TP
-.B \-ttt
-Print a delta (in micro-seconds) between current and previous line
-on each dump line.
-.TP
-.B \-tttt
-Print a timestamp in default format proceeded by date on each dump line.
-.TP
-.B \-u
-Print undecoded NFS handles.
-.TP
-.B \-U
-Make output saved via the
-.B \-w
-option ``packet-buffered''; i.e., as each packet is saved, it will be
-written to the output file, rather than being written only when the
-output buffer fills.
-.IP
-The
-.B \-U
-flag will not be supported if
-.I tcpdump
-was built with an older version of
-.I libpcap
-that lacks the
-.B pcap_dump_flush()
-function.
-.TP
-.B \-v
-When parsing and printing, produce (slightly more) verbose output.
-For example, the time to live,
-identification, total length and options in an IP packet are printed.
-Also enables additional packet integrity checks such as verifying the
-IP and ICMP header checksum.
-.IP
-When writing to a file with the
-.B \-w
-option, report, every 10 seconds, the number of packets captured.
-.TP
-.B \-vv
-Even more verbose output.
-For example, additional fields are
-printed from NFS reply packets, and SMB packets are fully decoded.
-.TP
-.B \-vvv
-Even more verbose output.
-For example,
-telnet \fBSB\fP ... \fBSE\fP options
-are printed in full.
-With
-.B \-X
-Telnet options are printed in hex as well.
-.TP
-.B \-w
-Write the raw packets to \fIfile\fR rather than parsing and printing
-them out.
-They can later be printed with the \-r option.
-Standard output is used if \fIfile\fR is ``-''.
-.TP
-.B \-W
-Used in conjunction with the 
-.B \-C 
-option, this will limit the number
-of files created to the specified number, and begin overwriting files
-from the beginning, thus creating a 'rotating' buffer. 
-In addition, it will name
-the files with enough leading 0s to support the maximum number of
-files, allowing them to sort correctly.
-.TP
-.B \-x
-When parsing and printing,
-in addition to printing the headers of each packet, print the data of
-each packet (minus its link level header) in hex. 
-The smaller of the entire packet or
-.I snaplen
-bytes will be printed.  Note that this is the entire link-layer
-packet, so for link layers that pad (e.g. Ethernet), the padding bytes
-will also be printed when the higher layer packet is shorter than the
-required padding.
-.TP
-.B \-xx
-When parsing and printing,
-in addition to printing the headers of each packet, print the data of
-each packet,
-.I including
-its link level header, in hex.
-.TP
-.B \-X
-When parsing and printing,
-in addition to printing the headers of each packet, print the data of
-each packet (minus its link level header) in hex and ASCII.
-This is very handy for analysing new protocols.
-.TP
-.B \-XX
-When parsing and printing,
-in addition to printing the headers of each packet, print the data of
-each packet,
-.I including
-its link level header, in hex and ASCII.
-.TP
-.B \-y
-Set the data link type to use while capturing packets to \fIdatalinktype\fP.
-.TP
-.B \-Z
-Drops privileges (if root) and changes user ID to
-.I user
-and the group ID to the primary group of
-.IR user .
-.IP
-This behavior can also be enabled by default at compile time.
-.IP "\fI expression\fP"
-.RS
-selects which packets will be dumped.
-If no \fIexpression\fP
-is given, all packets on the net will be dumped.
-Otherwise,
-only packets for which \fIexpression\fP is `true' will be dumped.
-.LP
-The \fIexpression\fP consists of one or more
-.I primitives.
-Primitives usually consist of an
-.I id
-(name or number) preceded by one or more qualifiers.
-There are three
-different kinds of qualifier:
-.IP \fItype\fP
-qualifiers say what kind of thing the id name or number refers to.
-Possible types are
-.BR host ,
-.B net ,
-.B port
-and
-.BR portrange .
-E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'.
-If there is no type
-qualifier,
-.B host
-is assumed.
-.IP \fIdir\fP
-qualifiers specify a particular transfer direction to and/or from
-.IR id .
-Possible directions are
-.BR src ,
-.BR dst ,
-.B "src or dst"
-and
-.B "src and"
-.BR dst .
-E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.
-If
-there is no dir qualifier,
-.B "src or dst"
-is assumed.
-For some link layers, such as SLIP and the ``cooked'' Linux capture mode
-used for the ``any'' device and for some other device types, the
-.B inbound
-and
-.B outbound
-qualifiers can be used to specify a desired direction.
-.IP \fIproto\fP
-qualifiers restrict the match to a particular protocol.
-Possible
-protos are:
-.BR ether ,
-.BR fddi ,
-.BR tr ,
-.BR wlan ,
-.BR ip ,
-.BR ip6 ,
-.BR arp ,
-.BR rarp ,
-.BR decnet ,
-.B tcp
-and
-.BR udp .
-E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange
-7000-7009'.
-If there is
-no proto qualifier, all protocols consistent with the type are
-assumed.
-E.g., `src foo' means `(ip or arp or rarp) src foo'
-(except the latter is not legal syntax), `net bar' means `(ip or
-arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
-.LP
-[`fddi' is actually an alias for `ether'; the parser treats them
-identically as meaning ``the data link level used on the specified
-network interface.''  FDDI headers contain Ethernet-like source
-and destination addresses, and often contain Ethernet-like packet
-types, so you can filter on these FDDI fields just as with the
-analogous Ethernet fields.
-FDDI headers also contain other fields,
-but you cannot name them explicitly in a filter expression.
-.LP
-Similarly, `tr' and `wlan' are aliases for `ether'; the previous
-paragraph's statements about FDDI headers also apply to Token Ring
-and 802.11 wireless LAN headers.  For 802.11 headers, the destination
-address is the DA field and the source address is the SA field; the
-BSSID, RA, and TA fields aren't tested.]
-.LP
-In addition to the above, there are some special `primitive' keywords
-that don't follow the pattern:
-.BR gateway ,
-.BR broadcast ,
-.BR less ,
-.B greater
-and arithmetic expressions.
-All of these are described below.
-.LP
-More complex filter expressions are built up by using the words
-.BR and ,
-.B or
-and
-.B not
-to combine primitives.
-E.g., `host foo and not port ftp and not port ftp-data'.
-To save typing, identical qualifier lists can be omitted.
-E.g.,
-`tcp dst port ftp or ftp-data or domain' is exactly the same as
-`tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
-.LP
-Allowable primitives are:
-.IP "\fBdst host \fIhost\fR"
-True if the IPv4/v6 destination field of the packet is \fIhost\fP,
-which may be either an address or a name.
-.IP "\fBsrc host \fIhost\fR"
-True if the IPv4/v6 source field of the packet is \fIhost\fP.
-.IP "\fBhost \fIhost\fP
-True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
-.IP
-Any of the above host expressions can be prepended with the keywords,
-\fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in:
-.in +.5i
-.nf
-\fBip host \fIhost\fR
-.fi
-.in -.5i
-which is equivalent to:
-.in +.5i
-.nf
-\fBether proto \fI\\ip\fB and host \fIhost\fR
-.fi
-.in -.5i
-If \fIhost\fR is a name with multiple IP addresses, each address will
-be checked for a match.
-.IP "\fBether dst \fIehost\fP
-True if the Ethernet destination address is \fIehost\fP.
-\fIEhost\fP
-may be either a name from /etc/ethers or a number (see
-.IR ethers (3N)
-for numeric format).
-.IP "\fBether src \fIehost\fP
-True if the Ethernet source address is \fIehost\fP.
-.IP "\fBether host \fIehost\fP
-True if either the Ethernet source or destination address is \fIehost\fP.
-.IP "\fBgateway\fP \fIhost\fP
-True if the packet used \fIhost\fP as a gateway.
-I.e., the Ethernet
-source or destination address was \fIhost\fP but neither the IP source
-nor the IP destination was \fIhost\fP.
-\fIHost\fP must be a name and
-must be found both by the machine's host-name-to-IP-address resolution
-mechanisms (host name file, DNS, NIS, etc.) and by the machine's
-host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.).
-(An equivalent expression is
-.in +.5i
-.nf
-\fBether host \fIehost \fBand not host \fIhost\fR
-.fi
-.in -.5i
-which can be used with either names or numbers for \fIhost / ehost\fP.)
-This syntax does not work in IPv6-enabled configuration at this moment.
-.IP "\fBdst net \fInet\fR"
-True if the IPv4/v6 destination address of the packet has a network
-number of \fInet\fP.
-\fINet\fP may be either a name from the networks database
-(/etc/networks, etc.) or a network number.
-An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0),
-dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single
-number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad
-(which means that it's really a host match), 255.255.255.0 for a dotted
-triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number.
-An IPv6 network number must be written out fully; the netmask is
-ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always
-host matches, and a network match requires a netmask length.
-.IP "\fBsrc net \fInet\fR"
-True if the IPv4/v6 source address of the packet has a network
-number of \fInet\fP.
-.IP "\fBnet \fInet\fR"
-True if either the IPv4/v6 source or destination address of the packet has a network
-number of \fInet\fP.
-.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
-True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR.
-May be qualified with \fBsrc\fR or \fBdst\fR.
-Note that this syntax is not valid for IPv6 \fInet\fR.
-.IP "\fBnet \fInet\fR/\fIlen\fR"
-True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR
-bits wide.
-May be qualified with \fBsrc\fR or \fBdst\fR.
-.IP "\fBdst port \fIport\fR"
-True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
-destination port value of \fIport\fP.
-The \fIport\fP can be a number or a name used in /etc/services (see
-.IR tcp (4P)
-and
-.IR udp (4P)).
-If a name is used, both the port
-number and protocol are checked.
-If a number or ambiguous name is used,
-only the port number is checked (e.g., \fBdst port 513\fR will print both
-tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
-both tcp/domain and udp/domain traffic).
-.IP "\fBsrc port \fIport\fR"
-True if the packet has a source port value of \fIport\fP.
-.IP "\fBport \fIport\fR"
-True if either the source or destination port of the packet is \fIport\fP.
-.IP "\fBdst portrange \fIport1\fB-\fIport2\fR"
-True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
-destination port value between \fIport1\fP and \fIport2\fP.
-.I port1
-and
-.I port2
-are interpreted in the same fashion as the
-.I port
-parameter for
-.BR port .
-.IP "\fBsrc portrange \fIport1\fB-\fIport2\fR"
-True if the packet has a source port value between \fIport1\fP and
-\fIport2\fP.
-.IP "\fBportrange \fIport1\fB-\fIport2\fR"
-True if either the source or destination port of the packet is between
-\fIport1\fP and \fIport2\fP.
-.IP
-Any of the above port or port range expressions can be prepended with
-the keywords, \fBtcp\fP or \fBudp\fP, as in:
-.in +.5i
-.nf
-\fBtcp src port \fIport\fR
-.fi
-.in -.5i
-which matches only tcp packets whose source port is \fIport\fP.
-.IP "\fBless \fIlength\fR"
-True if the packet has a length less than or equal to \fIlength\fP.
-This is equivalent to:
-.in +.5i
-.nf
-\fBlen <= \fIlength\fP.
-.fi
-.in -.5i
-.IP "\fBgreater \fIlength\fR"
-True if the packet has a length greater than or equal to \fIlength\fP.
-This is equivalent to:
-.in +.5i
-.nf
-\fBlen >= \fIlength\fP.
-.fi
-.in -.5i
-.IP "\fBip proto \fIprotocol\fR"
-True if the packet is an IPv4 packet (see
-.IR ip (4P))
-of protocol type \fIprotocol\fP.
-\fIProtocol\fP can be a number or one of the names
-\fBicmp\fP, \fBicmp6\fP, \fBigmp\fP, \fBigrp\fP, \fBpim\fP, \fBah\fP,
-\fBesp\fP, \fBvrrp\fP, \fBudp\fP, or \fBtcp\fP.
-Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also
-keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
-Note that this primitive does not chase the protocol header chain.
-.IP "\fBip6 proto \fIprotocol\fR"
-True if the packet is an IPv6 packet of protocol type \fIprotocol\fP.
-Note that this primitive does not chase the protocol header chain.
-.IP "\fBip6 protochain \fIprotocol\fR"
-True if the packet is IPv6 packet,
-and contains protocol header with type \fIprotocol\fR
-in its protocol header chain.
-For example,
-.in +.5i
-.nf
-\fBip6 protochain 6\fR
-.fi
-.in -.5i
-matches any IPv6 packet with TCP protocol header in the protocol header chain.
-The packet may contain, for example,
-authentication header, routing header, or hop-by-hop option header,
-between IPv6 header and TCP header.
-The BPF code emitted by this primitive is complex and
-cannot be optimized by BPF optimizer code in \fItcpdump\fP,
-so this can be somewhat slow.
-.IP "\fBip protochain \fIprotocol\fR"
-Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
-.IP "\fBether broadcast\fR"
-True if the packet is an Ethernet broadcast packet.
-The \fIether\fP
-keyword is optional.
-.IP "\fBip broadcast\fR"
-True if the packet is an IPv4 broadcast packet.
-It checks for both the all-zeroes and all-ones broadcast conventions,
-and looks up the subnet mask on the interface on which the capture is
-being done.
-.IP
-If the subnet mask of the interface on which the capture is being done
-is not available, either because the interface on which capture is being
-done has no netmask or because the capture is being done on the Linux
-"any" interface, which can capture on more than one interface, this
-check will not work correctly.
-.IP "\fBether multicast\fR"
-True if the packet is an Ethernet multicast packet.
-The \fBether\fP
-keyword is optional.
-This is shorthand for `\fBether[0] & 1 != 0\fP'.
-.IP "\fBip multicast\fR"
-True if the packet is an IPv4 multicast packet.
-.IP "\fBip6 multicast\fR"
-True if the packet is an IPv6 multicast packet.
-.IP  "\fBether proto \fIprotocol\fR"
-True if the packet is of ether type \fIprotocol\fR.
-\fIProtocol\fP can be a number or one of the names
-\fBip\fP, \fBip6\fP, \fBarp\fP, \fBrarp\fP, \fBatalk\fP, \fBaarp\fP,
-\fBdecnet\fP, \fBsca\fP, \fBlat\fP, \fBmopdl\fP, \fBmoprc\fP,
-\fBiso\fP, \fBstp\fP, \fBipx\fP, or \fBnetbeui\fP.
-Note these identifiers are also keywords
-and must be escaped via backslash (\\).
-.IP
-[In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), Token Ring
-(e.g., `\fBtr protocol arp\fR'), and IEEE 802.11 wireless LANS (e.g.,
-`\fBwlan protocol arp\fR'), for most of those protocols, the
-protocol identification comes from the 802.2 Logical Link Control (LLC)
-header, which is usually layered on top of the FDDI, Token Ring, or
-802.11 header.
-.IP
-When filtering for most protocol identifiers on FDDI, Token Ring, or
-802.11, \fItcpdump\fR checks only the protocol ID field of an LLC header
-in so-called SNAP format with an Organizational Unit Identifier (OUI) of
-0x000000, for encapsulated Ethernet; it doesn't check whether the packet
-is in SNAP format with an OUI of 0x000000.
-The exceptions are:
-.RS
-.TP
-\fBiso\fP
-\fItcpdump\fR checks the DSAP (Destination Service Access Point) and
-SSAP (Source Service Access Point) fields of the LLC header;
-.TP
-\fBstp\fP and \fBnetbeui\fP
-\fItcpdump\fR checks the DSAP of the LLC header;
-.TP
-\fBatalk\fP
-\fItcpdump\fR checks for a SNAP-format packet with an OUI of 0x080007
-and the AppleTalk etype.
-.RE
-.IP
-In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field
-for most of those protocols.  The exceptions are:
-.RS
-.TP
-\fBiso\fP, \fBstp\fP, and \fBnetbeui\fP
-\fItcpdump\fR checks for an 802.3 frame and then checks the LLC header as
-it does for FDDI, Token Ring, and 802.11;
-.TP
-\fBatalk\fP
-\fItcpdump\fR checks both for the AppleTalk etype in an Ethernet frame and
-for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11;
-.TP
-\fBaarp\fP
-\fItcpdump\fR checks for the AppleTalk ARP etype in either an Ethernet
-frame or an 802.2 SNAP frame with an OUI of 0x000000;
-.TP
-\fBipx\fP
-\fItcpdump\fR checks for the IPX etype in an Ethernet frame, the IPX
-DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of
-IPX, and the IPX etype in a SNAP frame.
-.RE
-.IP "\fBdecnet src \fIhost\fR"
-True if the DECNET source address is
-.IR host ,
-which may be an address of the form ``10.123'', or a DECNET host
-name.
-[DECNET host name support is only available on ULTRIX systems
-that are configured to run DECNET.]
-.IP "\fBdecnet dst \fIhost\fR"
-True if the DECNET destination address is
-.IR host .
-.IP "\fBdecnet host \fIhost\fR"
-True if either the DECNET source or destination address is
-.IR host .
-.IP "\fBifname \fIinterface\fR"
-True if the packet was logged as coming from the specified interface (applies
-only to packets logged by OpenBSD's
-.BR pf (4)).
-.IP "\fBon \fIinterface\fR"
-Synonymous with the
-.B ifname
-modifier.
-.IP "\fBrnr \fInum\fR"
-True if the packet was logged as matching the specified PF rule number
-(applies only to packets logged by OpenBSD's
-.BR pf (4)).
-.IP "\fBrulenum \fInum\fR"
-Synonomous with the
-.B rnr
-modifier.
-.IP "\fBreason \fIcode\fR"
-True if the packet was logged with the specified PF reason code.  The known
-codes are:
-.BR match ,
-.BR bad-offset ,
-.BR fragment ,
-.BR short ,
-.BR normalize ,
-and
-.B memory
-(applies only to packets logged by OpenBSD's
-.BR pf (4)).
-.IP "\fBrset \fIname\fR"
-True if the packet was logged as matching the specified PF ruleset
-name of an anchored ruleset (applies only to packets logged by
-.BR pf (4)).
-.IP "\fBruleset \fIname\fR"
-Synonomous with the
-.B rset
-modifier.
-.IP "\fBsrnr \fInum\fR"
-True if the packet was logged as matching the specified PF rule number
-of an anchored ruleset (applies only to packets logged by
-.BR pf (4)).
-.IP "\fBsubrulenum \fInum\fR"
-Synonomous with the
-.B srnr
-modifier.
-.IP "\fBaction \fIact\fR"
-True if PF took the specified action when the packet was logged.  Known actions
-are:
-.B pass
-and
-.B block
-(applies only to packets logged by OpenBSD's
-.BR pf (4)).
-.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
-Abbreviations for:
-.in +.5i
-.nf
-\fBether proto \fIp\fR
-.fi
-.in -.5i
-where \fIp\fR is one of the above protocols.
-.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
-Abbreviations for:
-.in +.5i
-.nf
-\fBether proto \fIp\fR
-.fi
-.in -.5i
-where \fIp\fR is one of the above protocols.
-Note that
-\fItcpdump\fP does not currently know how to parse these protocols.
-.IP "\fBvlan \fI[vlan_id]\fR"
-True if the packet is an IEEE 802.1Q VLAN packet.
-If \fI[vlan_id]\fR is specified, only true if the packet has the specified
-\fIvlan_id\fR.
-Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR
-changes the decoding offsets for the remainder of \fIexpression\fR on
-the assumption that the packet is a VLAN packet.  The \fBvlan
-\fI[vlan_id]\fR expression may be used more than once, to filter on VLAN
-hierarchies.  Each use of that expression increments the filter offsets
-by 4.
-.IP
-For example:
-.in +.5i
-.nf
-\fBvlan 100 && vlan 200\fR
-.fi
-.in -.5i
-filters on VLAN 200 encapsulated within VLAN 100, and
-.in +.5i
-.nf
-\fBvlan && vlan 300 && ip\fR
-.fi
-.in -.5i
-filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any
-higher order VLAN.
-.IP "\fBmpls \fI[label_num]\fR"
-True if the packet is an MPLS packet.
-If \fI[label_num]\fR is specified, only true is the packet has the specified
-\fIlabel_num\fR.
-Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR
-changes the decoding offsets for the remainder of \fIexpression\fR on
-the assumption that the packet is a MPLS-encapsulated IP packet.  The
-\fBmpls \fI[label_num]\fR expression may be used more than once, to
-filter on MPLS hierarchies.  Each use of that expression increments the
-filter offsets by 4. 
-.IP
-For example:
-.in +.5i
-.nf
-\fBmpls 100000 && mpls 1024\fR
-.fi
-.in -.5i
-filters packets with an outer label of 100000 and an inner label of
-1024, and
-.in +.5i
-.nf
-\fBmpls && mpls 1024 && host 192.9.200.1\fR
-.fi
-.in -.5i
-filters packets to or from 192.9.200.1 with an inner label of 1024 and
-any outer label.
-.IP \fBpppoed\fP
-True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet
-type 0x8863).
-.IP \fBpppoes\fP
-True if the packet is a PPP-over-Ethernet Session packet (Ethernet
-type 0x8864).
-Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR
-changes the decoding offsets for the remainder of \fIexpression\fR on
-the assumption that the packet is a PPPoE session packet.
-.IP
-For example:
-.in +.5i
-.nf
-\fBpppoes && ip\fR
-.fi
-.in -.5i
-filters IPv4 protocols encapsulated in PPPoE.
-.IP  "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
-Abbreviations for:
-.in +.5i
-.nf
-\fBip proto \fIp\fR\fB or ip6 proto \fIp\fR
-.fi
-.in -.5i
-where \fIp\fR is one of the above protocols.
-.IP "\fBiso proto \fIprotocol\fR"
-True if the packet is an OSI packet of protocol type \fIprotocol\fP.
-\fIProtocol\fP can be a number or one of the names
-\fBclnp\fP, \fBesis\fP, or \fBisis\fP.
-.IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR"
-Abbreviations for:
-.in +.5i
-.nf
-\fBiso proto \fIp\fR
-.fi
-.in -.5i
-where \fIp\fR is one of the above protocols.
-.IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR"
-Abbreviations for IS-IS PDU types.
-.IP "\fBvpi\fP \fIn\fR
-True if the packet is an ATM packet, for SunATM on Solaris, with a
-virtual path identifier of
-.IR n .
-.IP "\fBvci\fP \fIn\fR
-True if the packet is an ATM packet, for SunATM on Solaris, with a
-virtual channel identifier of
-.IR n .
-.IP \fBlane\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-an ATM LANE packet.
-Note that the first \fBlane\fR keyword encountered in \fIexpression\fR
-changes the tests done in the remainder of \fIexpression\fR
-on the assumption that the packet is either a LANE emulated Ethernet
-packet or a LANE LE Control packet.  If \fBlane\fR isn't specified, the
-tests are done under the assumption that the packet is an
-LLC-encapsulated packet.
-.IP \fBllc\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-an LLC-encapsulated packet.
-.IP \fBoamf4s\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-a segment OAM F4 flow cell (VPI=0 & VCI=3).
-.IP \fBoamf4e\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-an end-to-end OAM F4 flow cell (VPI=0 & VCI=4).
-.IP \fBoamf4\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
-.IP \fBoam\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
-.IP \fBmetac\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on a meta signaling circuit (VPI=0 & VCI=1).
-.IP \fBbcc\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on a broadcast signaling circuit (VPI=0 & VCI=2).
-.IP \fBsc\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on a signaling circuit (VPI=0 & VCI=5).
-.IP \fBilmic\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on an ILMI circuit (VPI=0 & VCI=16).
-.IP \fBconnectmsg\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
-Connect Ack, Release, or Release Done message.
-.IP \fBmetaconnect\fP
-True if the packet is an ATM packet, for SunATM on Solaris, and is
-on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
-Release, or Release Done message.
-.IP  "\fIexpr relop expr\fR"
-True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =,
-!=, and \fIexpr\fR is an arithmetic expression composed of integer
-constants (expressed in standard C syntax), the normal binary operators
-[+, -, *, /, &, |, <<, >>], a length operator, and special packet data
-accessors.  Note that all comparisons are unsigned, so that, for example,
-0x80000000 and 0xffffffff are > 0.
-To access
-data inside the packet, use the following syntax:
-.in +.5i
-.nf
-\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
-.fi
-.in -.5i
-\fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link,
-ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and
-indicates the protocol layer for the index operation.
-(\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the
-link layer. \fBradio\fR refers to the "radio header" added to some
-802.11 captures.)
-Note that \fItcp, udp\fR and other upper-layer protocol types only
-apply to IPv4, not IPv6 (this will be fixed in the future).
-The byte offset, relative to the indicated protocol layer, is
-given by \fIexpr\fR.
-\fISize\fR is optional and indicates the number of bytes in the
-field of interest; it can be either one, two, or four, and defaults to one.
-The length operator, indicated by the keyword \fBlen\fP, gives the
-length of the packet.
-
-For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
-The expression `\fBip[0] & 0xf != 5\fP'
-catches all IPv4 packets with options.
-The expression
-`\fBip[6:2] & 0x1fff = 0\fP'
-catches only unfragmented IPv4 datagrams and frag zero of fragmented
-IPv4 datagrams.
-This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
-index operations.
-For instance, \fBtcp[0]\fP always means the first
-byte of the TCP \fIheader\fP, and never means the first byte of an
-intervening fragment.
-
-Some offsets and field values may be expressed as names rather than
-as numeric values.
-The following protocol header field offsets are
-available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP
-code field), and \fBtcpflags\fP (TCP flags field).
-
-The following ICMP type field values are available: \fBicmp-echoreply\fP,
-\fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
-\fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
-\fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
-\fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
-\fBicmp-maskreq\fP, \fBicmp-maskreply\fP.
-
-The following TCP flags field values are available: \fBtcp-fin\fP,
-\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
-\fBtcp-ack\fP, \fBtcp-urg\fP.
-.LP
-Primitives may be combined using:
-.IP
-A parenthesized group of primitives and operators
-(parentheses are special to the Shell and must be escaped).
-.IP
-Negation (`\fB!\fP' or `\fBnot\fP').
-.IP
-Concatenation (`\fB&&\fP' or `\fBand\fP').
-.IP
-Alternation (`\fB||\fP' or `\fBor\fP').
-.LP
-Negation has highest precedence.
-Alternation and concatenation have equal precedence and associate
-left to right.
-Note that explicit \fBand\fR tokens, not juxtaposition,
-are now required for concatenation.
-.LP
-If an identifier is given without a keyword, the most recent keyword
-is assumed.
-For example,
-.in +.5i
-.nf
-\fBnot host vs and ace\fR
-.fi
-.in -.5i
-is short for
-.in +.5i
-.nf
-\fBnot host vs and host ace\fR
-.fi
-.in -.5i
-which should not be confused with
-.in +.5i
-.nf
-\fBnot ( host vs or ace )\fR
-.fi
-.in -.5i
-.LP
-Expression arguments can be passed to \fItcpdump\fP as either a single
-argument or as multiple arguments, whichever is more convenient.
-Generally, if the expression contains Shell metacharacters, it is
-easier to pass it as a single, quoted argument.
-Multiple arguments are concatenated with spaces before being parsed.
-.SH EXAMPLES
-.LP
-To print all packets arriving at or departing from \fIsundown\fP:
-.RS
-.nf
-\fBtcpdump host sundown\fP
-.fi
-.RE
-.LP
-To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
-.RS
-.nf
-\fBtcpdump host helios and \\( hot or ace \\)\fP
-.fi
-.RE
-.LP
-To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
-.RS
-.nf
-\fBtcpdump ip host ace and not helios\fP
-.fi
-.RE
-.LP
-To print all traffic between local hosts and hosts at Berkeley:
-.RS
-.nf
-.B
-tcpdump net ucb-ether
-.fi
-.RE
-.LP
-To print all ftp traffic through internet gateway \fIsnup\fP:
-(note that the expression is quoted to prevent the shell from
-(mis-)interpreting the parentheses):
-.RS
-.nf
-.B
-tcpdump 'gateway snup and (port ftp or ftp-data)'
-.fi
-.RE
-.LP
-To print traffic neither sourced from nor destined for local hosts
-(if you gateway to one other net, this stuff should never make it
-onto your local net).
-.RS
-.nf
-.B
-tcpdump ip and not net \fIlocalnet\fP
-.fi
-.RE
-.LP
-To print the start and end packets (the SYN and FIN packets) of each
-TCP conversation that involves a non-local host.
-.RS
-.nf
-.B
-tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
-.fi
-.RE
-.LP
-To print all IPv4 HTTP packets to and from port 80, i.e. print only
-packets that contain data, not, for example, SYN and FIN packets and
-ACK-only packets.  (IPv6 is left as an exercise for the reader.)
-.RS
-.nf
-.B
-tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
-.fi
-.RE
-.LP
-To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
-.RS
-.nf
-.B
-tcpdump 'gateway snup and ip[2:2] > 576'
-.fi
-.RE
-.LP
-To print IP broadcast or multicast packets that were
-.I not
-sent via Ethernet broadcast or multicast:
-.RS
-.nf
-.B
-tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
-.fi
-.RE
-.LP
-To print all ICMP packets that are not echo requests/replies (i.e., not
-ping packets):
-.RS
-.nf
-.B
-tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
-.fi
-.RE
-.SH OUTPUT FORMAT
-.LP
-The output of \fItcpdump\fP is protocol dependent.
-The following
-gives a brief description and examples of most of the formats.
-.de HD
-.sp 1.5
-.B
-..
-.HD
-Link Level Headers
-.LP
-If the '-e' option is given, the link level header is printed out.
-On Ethernets, the source and destination addresses, protocol,
-and packet length are printed.
-.LP
-On FDDI networks, the  '-e' option causes \fItcpdump\fP to print
-the `frame control' field,  the source and destination addresses,
-and the packet length.
-(The `frame control' field governs the
-interpretation of the rest of the packet.
-Normal packets (such
-as those containing IP datagrams) are `async' packets, with a priority
-value between 0 and 7; for example, `\fBasync4\fR'.
-Such packets
-are assumed to contain an 802.2 Logical Link Control (LLC) packet;
-the LLC header is printed if it is \fInot\fR an ISO datagram or a
-so-called SNAP packet.
-.LP
-On Token Ring networks, the '-e' option causes \fItcpdump\fP to print
-the `access control' and `frame control' fields, the source and
-destination addresses, and the packet length.
-As on FDDI networks,
-packets are assumed to contain an LLC packet.
-Regardless of whether
-the '-e' option is specified or not, the source routing information is
-printed for source-routed packets.
-.LP
-On 802.11 networks, the '-e' option causes \fItcpdump\fP to print
-the `frame control' fields, all of the addresses in the 802.11 header,
-and the packet length.
-As on FDDI networks,
-packets are assumed to contain an LLC packet.
-.LP
-\fI(N.B.: The following description assumes familiarity with
-the SLIP compression algorithm described in RFC-1144.)\fP
-.LP
-On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
-packet type, and compression information are printed out.
-The packet type is printed first.
-The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
-No further link information is printed for \fIip\fR packets.
-For TCP packets, the connection identifier is printed following the type.
-If the packet is compressed, its encoded header is printed out.
-The special cases are printed out as
-\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
-the sequence number (or sequence number and ack) has changed.
-If it is not a special case,
-zero or more changes are printed.
-A change is indicated by U (urgent pointer), W (window), A (ack),
-S (sequence number), and I (packet ID), followed by a delta (+n or -n),
-or a new value (=n).
-Finally, the amount of data in the packet and compressed header length
-are printed.
-.LP
-For example, the following line shows an outbound compressed TCP packet,
-with an implicit connection identifier; the ack has changed by 6,
-the sequence number by 49, and the packet ID by 6; there are 3 bytes of
-data and 6 bytes of compressed header:
-.RS
-.nf
-\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
-.fi
-.RE
-.HD
-ARP/RARP Packets
-.LP
-Arp/rarp output shows the type of request and its arguments.
-The
-format is intended to be self explanatory.
-Here is a short sample taken from the start of an `rlogin' from
-host \fIrtsg\fP to host \fIcsam\fP:
-.RS
-.nf
-.sp .5
-\f(CWarp who-has csam tell rtsg
-arp reply csam is-at CSAM\fR
-.sp .5
-.fi
-.RE
-The first line says that rtsg sent an arp packet asking
-for the Ethernet address of internet host csam.
-Csam
-replies with its Ethernet address (in this example, Ethernet addresses
-are in caps and internet addresses in lower case).
-.LP
-This would look less redundant if we had done \fItcpdump \-n\fP:
-.RS
-.nf
-.sp .5
-\f(CWarp 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\fP
-.fi
-.RE
-.LP
-If we had done \fItcpdump \-e\fP, the fact that the first packet is
-broadcast and the second is point-to-point would be visible:
-.RS
-.nf
-.sp .5
-\f(CWRTSG Broadcast 0806  64: arp who-has csam tell rtsg
-CSAM RTSG 0806  64: arp reply csam is-at CSAM\fR
-.sp .5
-.fi
-.RE
-For the first packet this says the Ethernet source address is RTSG, the
-destination is the Ethernet broadcast address, the type field
-contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
-.HD
-TCP Packets
-.LP
-\fI(N.B.:The following description assumes familiarity with
-the TCP protocol described in RFC-793.
-If you are not familiar
-with the protocol, neither this description nor \fItcpdump\fP will
-be of much use to you.)\fP
-.LP
-The general format of a tcp protocol line is:
-.RS
-.nf
-.sp .5
-\fIsrc > dst: flags data-seqno ack window urgent options\fP
-.sp .5
-.fi
-.RE
-\fISrc\fP and \fIdst\fP are the source and destination IP
-addresses and ports.
-\fIFlags\fP are some combination of S (SYN),
-F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single
-`.' (no flags).
-\fIData-seqno\fP describes the portion of sequence space covered
-by the data in this packet (see example below).
-\fIAck\fP is sequence number of the next data expected the other
-direction on this connection.
-\fIWindow\fP is the number of bytes of receive buffer space available
-the other direction on this connection.
-\fIUrg\fP indicates there is `urgent' data in the packet.
-\fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
-.LP
-\fISrc, dst\fP and \fIflags\fP are always present.
-The other fields
-depend on the contents of the packet's tcp protocol header and
-are output only if appropriate.
-.LP
-Here is the opening portion of an rlogin from host \fIrtsg\fP to
-host \fIcsam\fP.
-.RS
-.nf
-.sp .5
-\s-2\f(CWrtsg.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\fR\s+2
-.sp .5
-.fi
-.RE
-The first line says that tcp port 1023 on rtsg sent a packet
-to port \fIlogin\fP
-on csam.
-The \fBS\fP indicates that the \fISYN\fP flag was set.
-The packet sequence number was 768512 and it contained no data.
-(The notation is `first:last(nbytes)' which means `sequence
-numbers \fIfirst\fP
-up to but not including \fIlast\fP which is \fInbytes\fP 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.
-.LP
-Csam replies with a similar packet except it includes a piggy-backed
-ack for rtsg's SYN.
-Rtsg then acks csam's SYN.
-The `.' 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 \fItcpdump\fP 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').
-`-S' will override this
-feature, causing the original sequence numbers to be output.
-.LP
-On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
-in the rtsg \(-> csam side of the conversation).
-The PUSH flag is set in the packet.
-On the 7th line, csam says it's received data sent by rtsg up to
-but not including byte 21.
-Most of this data is apparently sitting in the
-socket buffer since csam's receive window has gotten 19 bytes smaller.
-Csam also sends one byte of data to rtsg in this packet.
-On the 8th and 9th lines,
-csam sends two bytes of urgent, pushed data to rtsg.
-.LP
-If the snapshot was small enough that \fItcpdump\fP didn't capture
-the full TCP header, it interprets as much of the header as it can
-and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
-be interpreted.
-If the header contains a bogus option (one with a length
-that's either too small or beyond the end of the header), \fItcpdump\fP
-reports it as ``[\fIbad opt\fP]'' and does not interpret any further
-options (since it's impossible to tell where they start).
-If the header
-length indicates options are present but the IP datagram length is not
-long enough for the options to actually be there, \fItcpdump\fP reports
-it as ``[\fIbad hdr length\fP]''.
-.HD
-.B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
-.PP
-There are 8 bits in the control bits section of the TCP header:
-.IP
-.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
-.PP
-Let's assume that we want to watch packets used in establishing
-a TCP connection.
-Recall that TCP uses a 3-way handshake protocol
-when it initializes a new connection; the connection sequence with
-regard to the TCP control bits is
-.PP
-.RS
-1) Caller sends SYN
-.RE
-.RS
-2) Recipient responds with SYN, ACK
-.RE
-.RS
-3) Caller sends ACK
-.RE
-.PP
-Now we're interested in capturing packets that have only the
-SYN bit set (Step 1).
-Note that we don't want packets from step 2
-(SYN-ACK), just a plain initial SYN.
-What we need is a correct filter
-expression for \fItcpdump\fP.
-.PP
-Recall the structure of a TCP header without options:
-.PP
-.nf
- 0                            15                              31
------------------------------------------------------------------
-|          source port          |       destination port        |
------------------------------------------------------------------
-|                        sequence number                        |
------------------------------------------------------------------
-|                     acknowledgment number                     |
------------------------------------------------------------------
-|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
------------------------------------------------------------------
-|         TCP checksum          |       urgent pointer          |
------------------------------------------------------------------
-.fi
-.PP
-A TCP header usually holds 20 octets of data, unless options are
-present.
-The first line of the graph contains octets 0 - 3, the
-second line shows octets 4 - 7 etc.
-.PP
-Starting to count with 0, the relevant TCP control bits are contained
-in octet 13:
-.PP
-.nf
- 0             7|             15|             23|             31
-----------------|---------------|---------------|----------------
-|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
-----------------|---------------|---------------|----------------
-|               |  13th octet   |               |               |
-.fi
-.PP
-Let's have a closer look at octet no. 13:
-.PP
-.nf
-                |               |
-                |---------------|
-                |C|E|U|A|P|R|S|F|
-                |---------------|
-                |7   5   3     0|
-.fi
-.PP
-These are the TCP control bits we are interested
-in.
-We have numbered the bits in this octet from 0 to 7, right to
-left, so the PSH bit is bit number 3, while the URG bit is number 5.
-.PP
-Recall that we want to capture packets with only SYN set.
-Let's see what happens to octet 13 if a TCP datagram arrives
-with the SYN bit set in its header:
-.PP
-.nf
-                |C|E|U|A|P|R|S|F|
-                |---------------|
-                |0 0 0 0 0 0 1 0|
-                |---------------|
-                |7 6 5 4 3 2 1 0|
-.fi
-.PP
-Looking at the
-control bits section we see that only bit number 1 (SYN) is set.
-.PP
-Assuming that octet number 13 is an 8-bit unsigned integer in
-network byte order, the binary value of this octet is
-.IP
-00000010
-.PP
-and its decimal representation is
-.PP
-.nf
-   7     6     5     4     3     2     1     0
-0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2
-.fi
-.PP
-We're almost done, because now we know that if only SYN is set,
-the value of the 13th octet in the TCP header, when interpreted
-as a 8-bit unsigned integer in network byte order, must be exactly 2.
-.PP
-This relationship can be expressed as
-.RS
-.B
-tcp[13] == 2
-.RE
-.PP
-We can use this expression as the filter for \fItcpdump\fP in order
-to watch packets which have only SYN set:
-.RS
-.B
-tcpdump -i xl0 tcp[13] == 2
-.RE
-.PP
-The expression says "let the 13th octet of a TCP datagram have
-the decimal value 2", which is exactly what we want.
-.PP
-Now, let's assume that we need to capture SYN packets, but we
-don't care if ACK or any other TCP control bit is set at the
-same time.
-Let's see what happens to octet 13 when a TCP datagram
-with SYN-ACK set arrives:
-.PP
-.nf
-     |C|E|U|A|P|R|S|F|
-     |---------------|
-     |0 0 0 1 0 0 1 0|
-     |---------------|
-     |7 6 5 4 3 2 1 0|
-.fi
-.PP
-Now bits 1 and 4 are set in the 13th octet.
-The binary value of
-octet 13 is
-.IP
-     00010010
-.PP
-which translates to decimal
-.PP
-.nf
-   7     6     5     4     3     2     1     0
-0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18
-.fi
-.PP
-Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter
-expression, because that would select only those packets that have
-SYN-ACK set, but not those with only SYN set.
-Remember that we don't care
-if ACK or any other control bit is set as long as SYN is set.
-.PP
-In order to achieve our goal, we need to logically AND the
-binary value of octet 13 with some other value to preserve
-the SYN bit.
-We know that we want SYN to be set in any case,
-so we'll logically AND the value in the 13th octet with
-the binary value of a SYN:
-.PP
-.nf
-
-          00010010 SYN-ACK              00000010 SYN
-     AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
-          --------                      --------
-     =    00000010                 =    00000010
-.fi
-.PP
-We see that this AND operation delivers the same result
-regardless whether ACK or another TCP control bit is set.
-The decimal representation of the AND value as well as
-the result of this operation is 2 (binary 00000010),
-so we know that for packets with SYN set the following
-relation must hold true:
-.IP
-( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
-.PP
-This points us to the \fItcpdump\fP filter expression
-.RS
-.B
-     tcpdump -i xl0 'tcp[13] & 2 == 2'
-.RE
-.PP
-Note that you should use single quotes or a backslash
-in the expression to hide the AND ('&') special character
-from the shell.
-.HD
-.B
-UDP Packets
-.LP
-UDP format is illustrated by this rwho packet:
-.RS
-.nf
-.sp .5
-\f(CWactinide.who > broadcast.who: udp 84\fP
-.sp .5
-.fi
-.RE
-This says that port \fIwho\fP on host \fIactinide\fP sent a udp
-datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
-broadcast address.
-The packet contained 84 bytes of user data.
-.LP
-Some UDP services are recognized (from the source or destination
-port number) and the higher level protocol information printed.
-In particular, Domain Name service requests (RFC-1034/1035) and Sun
-RPC calls (RFC-1050) to NFS.
-.HD
-UDP Name Server Requests
-.LP
-\fI(N.B.:The following description assumes familiarity with
-the Domain Service protocol described in RFC-1035.
-If you are not familiar
-with the protocol, the following description will appear to be written
-in greek.)\fP
-.LP
-Name server requests are formatted as
-.RS
-.nf
-.sp .5
-\fIsrc > dst: id op? flags qtype qclass name (len)\fP
-.sp .5
-\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
-.sp .5
-.fi
-.RE
-Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
-address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
-The query id was `3'.
-The `+' indicates the \fIrecursion desired\fP flag
-was set.
-The query length was 37 bytes, not including the UDP and
-IP protocol headers.
-The query operation was the normal one, \fIQuery\fP,
-so the op field was omitted.
-If the op had been anything else, it would
-have been printed between the `3' and the `+'.
-Similarly, the qclass was the normal one,
-\fIC_IN\fP, and omitted.
-Any other qclass would have been printed
-immediately after the `A'.
-.LP
-A few anomalies are checked and may result in extra fields enclosed in
-square brackets:  If a query contains an answer, authority records or
-additional records section,
-.IR ancount ,
-.IR nscount ,
-or
-.I arcount
-are printed as `[\fIn\fPa]', `[\fIn\fPn]' or  `[\fIn\fPau]' where \fIn\fP
-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 two and three, `[b2&3=\fIx\fP]'
-is printed, where \fIx\fP is the hex value of header bytes two and three.
-.HD
-UDP Name Server Responses
-.LP
-Name server responses are formatted as
-.RS
-.nf
-.sp .5
-\fIsrc > dst:  id op rcode flags a/n/au type class data (len)\fP
-.sp .5
-\f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
-helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
-.sp .5
-.fi
-.RE
-In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
-with 3 answer records, 3 name server records and 7 additional 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 was 273 bytes,
-excluding UDP and IP headers.
-The op (Query) and response code
-(NoError) were omitted, as was the class (C_IN) of the A record.
-.LP
-In the second example, \fIhelios\fP responds to query 2 with a
-response code of non-existent domain (NXDomain) with no answers,
-one name server and no authority records.
-The `*' indicates that
-the \fIauthoritative answer\fP bit was set.
-Since there were no
-answers, no type, class or data were printed.
-.LP
-Other flag characters that might appear are `\-' (recursion available,
-RA, \fInot\fP set) and `|' (truncated message, TC, set).
-If the
-`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
-is printed.
-.LP
-Note that name server requests and responses tend to be large and the
-default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
-to print.
-Use the \fB\-s\fP flag to increase the snaplen if you
-need to seriously investigate name server traffic.
-`\fB\-s 128\fP'
-has worked well for me.
-
-.HD
-SMB/CIFS decoding
-.LP
-\fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
-on UDP/137, UDP/138 and TCP/139.
-Some primitive decoding of IPX and
-NetBEUI SMB data is also done.
-
-By default a fairly minimal decode is done, with a much more detailed
-decode done if -v is used.
-Be warned that with -v a single SMB packet
-may take up a page or more, so only use -v if you really want all the
-gory details.
-
-For information on SMB packet formats and what all te fields mean see
-www.cifs.org or the pub/samba/specs/ directory on your favorite
-samba.org mirror site.
-The SMB patches were written by Andrew Tridgell
-(tridge@samba.org).
-
-.HD
-NFS Requests and Replies
-.LP
-Sun NFS (Network File System) requests and replies are printed as:
-.RS
-.nf
-.sp .5
-\fIsrc.xid > dst.nfs: len op args\fP
-\fIsrc.nfs > dst.xid: reply stat len op results\fP
-.sp .5
-\f(CW
-sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
-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
-\fR
-.sp .5
-.fi
-.RE
-In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
-to \fIwrl\fP (note that the number following the src host is a
-transaction id, \fInot\fP the source port).
-The request was 112 bytes,
-excluding the UDP and IP headers.
-The operation was a \fIreadlink\fP
-(read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119.
-(If one is lucky, as in this case, the file handle can be interpreted
-as a major,minor device number pair, followed by the inode number and
-generation number.)
-\fIWrl\fP replies `ok' with the contents of the link.
-.LP
-In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
-`\fIxcolors\fP' 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 spec.
-.LP
-If the \-v (verbose) flag is given, additional information is printed.
-For example:
-.RS
-.nf
-.sp .5
-\f(CW
-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
-\fP
-.sp .5
-.fi
-.RE
-(\-v also prints the IP header TTL, ID, length, and fragmentation fields,
-which have been omitted from this example.)  In the first line,
-\fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
-at byte offset 24576.
-\fIWrl\fP replies `ok'; the packet shown on the
-second line is the first fragment of the reply, and hence is only 1472
-bytes long (the other bytes will follow in subsequent fragments, but
-these fragments do not have NFS or even UDP headers and so might not be
-printed, depending on the filter expression used).
-Because the \-v flag
-is given, some of the file attributes (which 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.
-.LP
-If the \-v flag is given more than once, even more details are printed.
-.LP
-Note that NFS requests are very large and much of the detail won't be printed
-unless \fIsnaplen\fP is increased.
-Try using `\fB\-s 192\fP' to watch
-NFS traffic.
-.LP
-NFS reply packets do not explicitly identify the RPC operation.
-Instead,
-\fItcpdump\fP 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.
-.HD
-AFS Requests and Replies
-.LP
-Transarc AFS (Andrew File System) requests and replies are printed
-as:
-.HD
-.RS
-.nf
-.sp .5
-\fIsrc.sport > dst.dport: rx packet-type\fP
-\fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
-\fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
-.sp .5
-\f(CW
-elvis.7001 > pike.afsfs:
-	rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
-	new fid 536876964/1/1 ".newsrc"
-pike.afsfs > elvis.7001: rx data fs reply rename
-\fR
-.sp .5
-.fi
-.RE
-In the first line, host elvis sends a RX packet to pike.
-This was
-a RX data packet to the fs (fileserver) service, and is the start of
-an RPC call.
-The RPC call was a rename, with the old directory file id
-of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory
-file id of 536876964/1/1 and a new filename of `.newsrc'.
-The host pike
-responds with a RPC reply to the rename call (which was successful, because
-it was a data packet and not an abort packet).
-.LP
-In general, all AFS RPCs are decoded at least by RPC call name.
-Most
-AFS RPCs have at least some of the arguments decoded (generally only
-the `interesting' arguments, for some definition of interesting).
-.LP
-The format is intended to be self-describing, but it will probably
-not be useful to people who are not familiar with the workings of
-AFS and RX.
-.LP
-If the -v (verbose) flag is given twice, acknowledgement packets and
-additional header information is printed, such as the the RX call ID,
-call number, sequence number, serial number, and the RX packet flags.
-.LP
-If the -v flag is given twice, additional information is printed,
-such as the the RX call ID, serial number, and the RX packet flags.
-The MTU negotiation information is also printed from RX ack packets.
-.LP
-If the -v flag is given three times, the security index and service id
-are printed.
-.LP
-Error codes are printed for abort packets, with the exception of Ubik
-beacon packets (because abort packets are used to signify a yes vote
-for the Ubik protocol).
-.LP
-Note that AFS requests are very large and many of the arguments won't
-be printed unless \fIsnaplen\fP is increased.
-Try using `\fB-s 256\fP'
-to watch AFS traffic.
-.LP
-AFS reply packets do not explicitly identify the RPC operation.
-Instead,
-\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
-replies using the call number and service ID.
-If a reply does not closely
-follow the
-corresponding request, it might not be parsable.
-
-.HD
-KIP AppleTalk (DDP in UDP)
-.LP
-AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
-and dumped as DDP packets (i.e., all the UDP header information is
-discarded).
-The file
-.I /etc/atalk.names
-is used to translate AppleTalk net and node numbers to names.
-Lines in this file have the form
-.RS
-.nf
-.sp .5
-\fInumber	name\fP
-
-\f(CW1.254		ether
-16.1		icsd-net
-1.254.110	ace\fR
-.sp .5
-.fi
-.RE
-The first two lines give the names of AppleTalk networks.
-The third
-line gives the name of a particular host (a host is distinguished
-from a net by the 3rd octet in the number \-
-a net number \fImust\fP have two octets and a host number \fImust\fP
-have three octets.)  The number and name should be separated by
-whitespace (blanks or tabs).
-The
-.I /etc/atalk.names
-file may contain blank lines or comment lines (lines starting with
-a `#').
-.LP
-AppleTalk addresses are printed in the form
-.RS
-.nf
-.sp .5
-\fInet.host.port\fP
-
-\f(CW144.1.209.2 > icsd-net.112.220
-office.2 > icsd-net.112.220
-jssmag.149.235 > icsd-net.2\fR
-.sp .5
-.fi
-.RE
-(If the
-.I /etc/atalk.names
-doesn't exist or doesn't contain an entry for some AppleTalk
-host/net number, addresses are printed in numeric form.)
-In the first example, NBP (DDP port 2) on net 144.1 node 209
-is sending to whatever is listening on port 220 of net icsd node 112.
-The second line is the same except the full name of the source node
-is known (`office').
-The third line is a send from port 235 on
-net jssmag node 149 to broadcast on the icsd-net NBP port (note that
-the broadcast address (255) is indicated by a net name with no host
-number \- for this reason it's a good idea to keep node names and
-net names distinct in /etc/atalk.names).
-.LP
-NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
-packets have their contents interpreted.
-Other protocols just dump
-the protocol name (or number if no name is registered for the
-protocol) and packet size.
-
-\fBNBP packets\fP are formatted like the following examples:
-.RS
-.nf
-.sp .5
-\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
-jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
-techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
-.sp .5
-.fi
-.RE
-The first line is a name lookup request for laserwriters sent by net icsd host
-112 and broadcast on net jssmag.
-The nbp id for the lookup is 190.
-The second line shows a reply for this request (note that it has the
-same id) from host jssmag.209 saying that it has a laserwriter
-resource named "RM1140" registered on port 250.
-The third line is
-another reply to the same request saying host techpit has laserwriter
-"techpit" registered on port 186.
-
-\fBATP packet\fP formatting is demonstrated by the following example:
-.RS
-.nf
-.sp .5
-\s-2\f(CWjssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
-helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
-jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
-helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
-helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
-jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
-jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
-.sp .5
-.fi
-.RE
-Jssmag.209 initiates transaction id 12266 with host helios by requesting
-up to 8 packets (the `<0-7>').
-The hex number at the end of the line
-is the value of the `userdata' field in the request.
-.LP
-Helios responds with 8 512-byte packets.
-The `:digit' following the
-transaction id gives the packet sequence number in the transaction
-and the number in parens is the amount of data in the packet,
-excluding the atp header.
-The `*' on packet 7 indicates that the
-EOM bit was set.
-.LP
-Jssmag.209 then requests that packets 3 & 5 be retransmitted.
-Helios
-resends them then jssmag.209 releases the transaction.
-Finally,
-jssmag.209 initiates the next request.
-The `*' on the request
-indicates that XO (`exactly once') was \fInot\fP set.
-
-.HD
-IP Fragmentation
-.LP
-Fragmented Internet datagrams are printed as
-.RS
-.nf
-.sp .5
-\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
-\fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
-.sp .5
-.fi
-.RE
-(The first form indicates there are more fragments.
-The second
-indicates this is the last fragment.)
-.LP
-\fIId\fP is the fragment id.
-\fISize\fP is the fragment
-size (in bytes) excluding the IP header.
-\fIOffset\fP is this
-fragment's offset (in bytes) in the original datagram.
-.LP
-The fragment information is output for each fragment.
-The first
-fragment contains the higher level protocol header and the frag
-info is printed after the protocol info.
-Fragments
-after the first contain no higher level protocol header and the
-frag info is printed after the source and destination addresses.
-For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
-over a CSNET connection that doesn't appear to handle 576 byte datagrams:
-.RS
-.nf
-.sp .5
-\s-2\f(CWarizona.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\fP\s+2
-.sp .5
-.fi
-.RE
-There are a couple of things to note here:  First, addresses in the
-2nd line don't include port numbers.
-This is because the TCP
-protocol information is all in the first fragment and we have no idea
-what the port or sequence numbers are when we print the later fragments.
-Second, the tcp sequence information in the first line is printed as if there
-were 308 bytes of user data when, in fact, there are 512 bytes (308 in
-the first frag and 204 in the second).
-If you are looking for holes
-in the sequence space or trying to match up acks
-with packets, this can fool you.
-.LP
-A packet with the IP \fIdon't fragment\fP flag is marked with a
-trailing \fB(DF)\fP.
-.HD
-Timestamps
-.LP
-By default, all output lines are preceded by a timestamp.
-The timestamp
-is the current clock time in the form
-.RS
-.nf
-\fIhh:mm:ss.frac\fP
-.fi
-.RE
-and 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 lag between when the
-Ethernet interface removed the packet from the wire and when the kernel
-serviced the `new packet' interrupt.
-.SH "SEE ALSO"
-stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
-.SH AUTHORS
-The original authors are:
-.LP
-Van Jacobson,
-Craig Leres and
-Steven McCanne, all of the
-Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
-.LP
-It is currently being maintained by tcpdump.org.
-.LP
-The current version is available via http:
-.LP
-.RS
-.I http://www.tcpdump.org/
-.RE
-.LP
-The original distribution is available via anonymous ftp:
-.LP
-.RS
-.I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
-.RE
-.LP
-IPv6/IPsec support is added by WIDE/KAME project.
-This program uses Eric Young's SSLeay library, under specific configuration.
-.SH BUGS
-Please send problems, bugs, questions, desirable enhancements, etc. to:
-.LP
-.RS
-tcpdump-workers@tcpdump.org
-.RE
-.LP
-Please send source code contributions, etc. to:
-.LP
-.RS
-patches@tcpdump.org
-.RE
-.LP
-NIT doesn't let you watch your own outbound traffic, BPF will.
-We recommend that you use the latter.
-.LP
-On Linux systems with 2.0[.x] kernels:
-.IP
-packets on the loopback device will be seen twice;
-.IP
-packet filtering cannot be done in the kernel, so that all packets must
-be copied from the kernel in order to be filtered in user mode;
-.IP
-all of a packet, not just the part that's within the snapshot length,
-will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
-asked to copy only part of a packet to userland, will not report the
-true length of the packet; this would cause most IP packets to get an
-error from
-.BR tcpdump );
-.IP
-capturing on some PPP devices won't work correctly.
-.LP
-We recommend that you upgrade to a 2.2 or later kernel.
-.LP
-Some attempt should be made to reassemble IP fragments or, at least
-to compute the right length for the higher level protocol.
-.LP
-Name server inverse queries are not dumped correctly: the (empty)
-question section is printed rather than real query in the answer
-section.
-Some believe that inverse queries are themselves a bug and
-prefer to fix the program generating them rather than \fItcpdump\fP.
-.LP
-A packet trace that crosses a daylight savings time change will give
-skewed time stamps (the time change is ignored).
-.LP
-Filter expressions on fields other than those in Token Ring headers will
-not correctly handle source-routed Token Ring packets.
-.LP
-Filter expressions on fields other than those in 802.11 headers will not
-correctly handle 802.11 data packets with both To DS and From DS set.
-.LP
-.BR "ip6 proto"
-should chase header chain, but at this moment it does not.
-.BR "ip6 protochain"
-is supplied for this behavior.
-.LP
-Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
-does not work against IPv6 packets.
-It only looks at IPv4 packets.