-.\" @(#) $Header: /tcpdump/master/tcpdump/Attic/tcpdump.1,v 1.67.1.1 1999-10-07 23:47:13 mcr Exp $ (LBL)
+.\" @(#) $Header: /tcpdump/master/tcpdump/Attic/tcpdump.1,v 1.92.2.1 2001-01-17 18:54:07 guy Exp $ (LBL)
.\"
.\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
.\" The Regents of the University of California. All rights reserved.
.\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
-.TH TCPDUMP 1 "30 June 1997"
+.TH TCPDUMP 1 "3 January 2001"
.SH NAME
tcpdump \- dump traffic on a network
.SH SYNOPSIS
.na
.B tcpdump
[
-.B \-adeflnNOpqStvx
+.B \-adeflnNOpqRStvxX
] [
.B \-c
.I count
[
.B \-i
.I interface
-] [
+]
+[
+.B \-m
+.I module
+]
+[
.B \-r
.I file
]
+.br
+.ti +8
[
.B \-s
.I snaplen
]
-.br
-.ti +8
[
.B \-T
.I type
.B \-w
.I file
]
+.br
+.ti +8
+[
+.B \-E
+.I algo:secret
+]
[
.I expression
]
or
.IR /dev/bpf* .
.B Under Solaris with dlpi:
-You must have read access to the network pseudo device, e.g.
+You must have read/write access to the network pseudo device, e.g.
.IR /dev/le .
.B Under HP-UX with dlpi:
You must be root or it must be installed setuid to root.
.B \-e
Print the link-level header on each dump line.
.TP
+.B \-E
+Use \fIalgo:secret\fP for decrypting IPsec ESP packets. 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.
+\fIsecret\fP the ascii text for ESP secret key.
+We cannot take arbitrary binary value at this moment.
+The option assumes RFC2406 ESP, not RFC1827 ESP.
+The option is only for debugging purposes, and
+the use of this option with truly `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.
+.TP
.B \-f
Print `foreign' internet addresses numerically rather than symbolically
(this option is intended to get around serious brain damage in
if you give this flag then \fItcpdump\fP will print ``nic''
instead of ``nic.ddn.mil''.
.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 \-O
Do not run the packet-matching code optimizer. This is useful only
if you suspect a bug in the optimizer.
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.
+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
+\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),
\fBvat\fR (Visual Audio Tool),
and
\fBwb\fR (distributed White Board).
.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 \-S
Print absolute, rather than relative, TCP sequence numbers.
.TP
Print an unformatted timestamp on each dump line.
.TP
.B \-v
-(Slightly more) verbose output. For example, the time to live
-and type of service information in an IP packet is printed.
+(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.
.TP
.B \-vv
Even more verbose output. For example, additional fields are
printed from NFS reply packets.
.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.
The smaller of the entire packet or
.I snaplen
bytes will be printed.
+.TP
+.B \-X
+When printing hex, print ascii too. Thus if
+.B \-x
+is also set, the packet is printed in hex/ascii.
+This is very handy for analysing new protocols.
+Even if
+.B \-x
+is not also set, some parts of some packets may be printed
+in hex/ascii.
.IP "\fI expression\fP"
.RS
selects which packets will be dumped. If no \fIexpression\fP
is assumed.
.IP \fIdir\fP
qualifiers specify a particular transfer direction to and/or from
-.I id.
+.IR id .
Possible directions are
.BR src ,
.BR dst ,
protos are:
.BR ether ,
.BR fddi ,
+.BR tr ,
.BR ip ,
+.BR ip6 ,
.BR arp ,
.BR rarp ,
.BR decnet ,
-.BR lat ,
-.BR sca ,
-.BR moprc ,
-.BR mopdl ,
.B tcp
and
.BR udp .
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.]
+but you cannot name them explicitly in a filter expression.
+.LP
+Similarly, `tr' is an alias for `ether'; the previous paragraph's
+statements about FDDI headers also apply to Token Ring headers.]
.LP
In addition to the above, there are some special `primitive' keywords
that don't follow the pattern:
.LP
Allowable primitives are:
.IP "\fBdst host \fIhost\fR"
-True if the IP destination field of the packet is \fIhost\fP,
+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 IP source field of the packet is \fIhost\fP.
+True if the IPv4/v6 source field of the packet is \fIhost\fP.
.IP "\fBhost \fIhost\fP
-True if either the IP source or destination of the packet is \fIhost\fP.
+True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
Any of the above host expressions can be prepended with the keywords,
-\fBip\fP, \fBarp\fP, or \fBrarp\fP as in:
+\fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in:
.in +.5i
.nf
\fBip 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 IP destination address of the packet has a network
+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 /etc/networks
or a network number (see \fInetworks(4)\fP for details).
.IP "\fBsrc net \fInet\fR"
-True if the IP source address of the packet has a network
+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 IP source or destination address of the packet has a network
+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 \fImask\fR"
True if the IP address matches \fInet\fR with the specific netmask.
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 IP address matches \fInet\fR a netmask \fIlen\fR bits wide.
+True if the IPv4/v6 address matches \fInet\fR 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 or ip/udp and has a
+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)
.fi
.in -.5i
.IP "\fBip proto \fIprotocol\fR"
-True if the packet is an ip packet (see
+True if the packet is an IP packet (see
.IR ip (4P))
of protocol type \fIprotocol\fP.
\fIProtocol\fP can be a number or one of the names
-\fIicmp\fP, \fIigrp\fP, \fIudp\fP, \fInd\fP, or \fItcp\fP.
+\fIicmp\fP, \fIicmp6\fP, \fIigmp\fP, \fIigrp\fP, \fIpim\fP, \fIah\fP,
+\fIesp\fP, \fIudp\fP, or \fItcp\fP.
Note that the identifiers \fItcp\fP, \fIudp\fP, and \fIicmp\fP are also
keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
+Note that this primitive does not chase 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 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.
This is shorthand for `\fBether[0] & 1 != 0\fP'.
.IP "\fBip multicast\fR"
True if the packet is an IP 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 a name like
-\fIip\fP, \fIarp\fP, or \fIrarp\fP.
+\fIProtocol\fP can be a number or one of the names
+\fIip\fP, \fIip6\fP, \fIarp\fP, \fIrarp\fP, \fIatalk\fP, \fIaarp\fP,
+\fIdecnet\fP, \fIsca\fP, \fIlat\fP, \fImopdl\fP, \fImoprc\fP, or
+\fIiso\fP.
Note these identifiers are also keywords
and must be escaped via backslash (\\).
[In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), the
(LLC) header, which is usually layered on top of the FDDI header.
\fITcpdump\fP assumes, when filtering on the protocol identifier,
that all FDDI packets include an LLC header, and that the LLC header
-is in so-called SNAP format.]
+is in so-called SNAP format. The same applies to Token Ring.]
.IP "\fBdecnet src \fIhost\fR"
True if the DECNET source address is
.IR host ,
.IP "\fBdecnet host \fIhost\fR"
True if either the DECNET source or destination address is
.IR host .
-.IP "\fBip\fR, \fBarp\fR, \fBrarp\fR, \fBdecnet\fR"
+.IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR"
Abbreviations for:
.in +.5i
.nf
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 is 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.
.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
Abbreviations for:
.in +.5i
.nf
-\fBip proto \fIp\fR
+\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
+\fIclnp\fP, \fIesis\fP, or \fIisis\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.
+Note that \fItcpdump\fR does an incomplete job of parsing these protocols.
.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
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
-\fIProto\fR is one of \fBether, fddi,
-ip, arp, rarp, tcp, udp, \fRor \fBicmp\fR, and
+\fIProto\fR is one of \fBether, fddi, tr,
+ip, arp, rarp, tcp, udp, icmp\fR or \fBip6\fR, and
indicates the protocol layer for the index operation.
+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
.fi
.in -.5i
.LP
-Expression arguments can be passed to tcpdump as either a single argument
-or as multiple arguments, whichever is more convenient.
+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.
.RS
.nf
.B
-tcpdump 'icmp[0] != 8 and icmp[0] != 0"
+tcpdump 'icmp[0] != 8 and icmp[0] != 0'
.fi
.RE
.SH OUTPUT FORMAT
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
\fI(N.B.: The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.)\fP
.LP
.nf
.sp .5
\f(CWarp who-has csam tell rtsg
-arp reply csam is-at CSAM\fP
+arp reply csam is-at CSAM\fR
.sp .5
.fi
.RE
.nf
.sp .5
\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
-CSAM RTSG 0806 64: arp reply csam is-at CSAM\fP
+CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
.sp .5
.fi
.RE
.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 tcpdump will
+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:
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\fP\s+2
+csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
.sp .5
.fi
.RE
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 \fBtcpdump\fP sees a
+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
On the 8th and 9th lines,
csam sends two bytes of urgent, pushed data to rtsg.
.LP
-If the snapshot was small enough that \fBtcpdump\fP didn't capture
+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), tcpdump 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, tcpdump reports it as ``[\fIbad hdr length\fP]''.
+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 6 bits in the control bits section of the TCP header:
+.IP
+.I 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 | reserved |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 fist 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 | reserved |U|A|P|R|S|F| window size |
+----------------|---------------|---------------|----------------
+| | 13th octet | | |
+.fi
+.PP
+Let's have a closer look at octet no. 13:
+.PP
+.nf
+ | |
+ |---------------|
+ | |U|A|P|R|S|F|
+ |---------------|
+ |7 5 3 0|
+.fi
+.PP
+We see that this octet contains 2 bytes from the reserved field.
+According to RFC 793 this field is reserved for future use and must
+be 0. The remaining 6 bits 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
+ | |U|A|P|R|S|F|
+ |---------------|
+ |0 0 0 0 0 0 1 0|
+ |---------------|
+ |7 6 5 4 3 2 1 0|
+.fi
+.PP
+We already mentioned that bits number 7 and 6 belong to the
+reserved field, so they must must be 0. 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
+ | |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
.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)\fP
+\f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
.sp .5
.fi
.RE
\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)\fP
+helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
.sp .5
.fi
.RE
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.
+
+If you are decoding SMB sessions containing unicode strings then you
+may wish to set the environment variable USE_UNICODE to 1. A patch to
+auto-detect unicode srings would be welcome.
+
+For information on SMB packet formats and what all te fields mean see
+www.cifs.org or the pub/samba/specs/ directory on your favourite
+samba.org mirror site. The SMB patches were written by Andrew Tridgell
+
.HD
NFS Requests and Replies
.LP
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150
-\fP
+\fR
.sp .5
.fi
.RE
.sp .5
.fi
.RE
-(\-v also prints the IP header TTL, ID, and fragmentation fields,
+(\-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
\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
\f(CW1.254 ether
16.1 icsd-net
-1.254.110 ace\fP
+1.254.110 ace\fR
.sp .5
.fi
.RE
\f(CW144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
-jssmag.149.235 > icsd-net.2\fP
+jssmag.149.235 > icsd-net.2\fR
.sp .5
.fi
.RE
.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\fP\s+2
+techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
.sp .5
.fi
.RE
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\fP\s+2
+jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
.sp .5
.fi
.RE
.SH "SEE ALSO"
traffic(1C), nit(4P), bpf(4), pcap(3)
.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
-The current version is available via anonymous ftp:
+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
+.RE
+.LP
+Please send source code contributions, etc. to:
+.LP
+.RS
+.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 ).
+.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)
+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 tcpdump.
-.LP
-Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
-packets but aren't.
-Even if we were inclined to do anything to promote the use of
-Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its
-networks so we'd would have no way of testing this code.
+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
-Filters expressions that manipulate FDDI headers assume that all FDDI
-packets are encapsulated Ethernet packets. This is true for IP, ARP,
-and DECNET Phase IV, but is not true for protocols such as ISO CLNS.
-Therefore, the filter may inadvertently accept certain packets that
-do not properly match the filter expression.
+Filter expressions that manipulate FDDI or Token Ring headers assume
+that all FDDI and Token Ring packets are SNAP-encapsulated Ethernet
+packets. This is true for IP, ARP, and DECNET Phase IV, but is not true
+for protocols such as ISO CLNS. Therefore, the filter may inadvertently
+accept certain packets that do not properly match the filter expression.
+.LP
+Filter expressions on fields other than those that manipulate Token Ring
+headers will not correctly handle source-routed Token Ring packets.
+.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.
projects / tcpdump / commitdiff
