summaryrefslogtreecommitdiffstats
path: root/contrib/tcpdump/tcpdump.1
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/tcpdump/tcpdump.1')
-rw-r--r--contrib/tcpdump/tcpdump.1425
1 files changed, 355 insertions, 70 deletions
diff --git a/contrib/tcpdump/tcpdump.1 b/contrib/tcpdump/tcpdump.1
index 5e949d4..e639407 100644
--- a/contrib/tcpdump/tcpdump.1
+++ b/contrib/tcpdump/tcpdump.1
@@ -1,4 +1,4 @@
-.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.72.2.2 2000/01/29 16:42:03 itojun Exp $ (LBL)
+.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.92.2.2 2001/01/18 04:38:31 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.
@@ -20,7 +20,7 @@
.\" 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
@@ -66,6 +66,10 @@ tcpdump \- dump traffic on a network
.br
.ti +8
[
+.B \-E
+.I algo:secret
+]
+[
.I expression
]
.br
@@ -83,7 +87,7 @@ you must have read access to
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.
@@ -122,6 +126,27 @@ Dump packet-matching code as decimal numbers (preceded with a count).
.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
@@ -137,6 +162,12 @@ 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.
.TP
.B \-l
Make stdout line buffered. Useful if you want to see the data
@@ -155,7 +186,7 @@ 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 tcpdump.
+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
@@ -187,11 +218,13 @@ 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.
+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),
@@ -216,8 +249,10 @@ Print absolute, rather than relative, TCP sequence numbers.
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
@@ -275,7 +310,7 @@ qualifier,
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 ,
@@ -297,17 +332,12 @@ qualifiers restrict the match to a particular protocol. Possible
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 ,
-.BR icmp ,
-.BR icmp6 ,
.B tcp
and
.BR udp .
@@ -323,7 +353,10 @@ 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.]
+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:
@@ -446,11 +479,12 @@ This is equivalent to:
.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.
@@ -493,8 +527,10 @@ True if the packet is an IP multicast packet.
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, \fIip6\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
@@ -502,7 +538,7 @@ protocol identification comes from the 802.2 Logical Link Control
(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 ,
@@ -515,7 +551,7 @@ True if the DECNET destination address is
.IP "\fBdecnet host \fIhost\fR"
True if either the DECNET source or destination address is
.IR host .
-.IP "\fBip\fR, \fBip6\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
@@ -533,6 +569,13 @@ Abbreviations for:
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
@@ -541,6 +584,19 @@ Abbreviations for:
.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
@@ -553,7 +609,7 @@ data inside the packet, use the following syntax:
\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
-\fIProto\fR is one of \fBether, fddi,
+\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
@@ -613,8 +669,8 @@ which should not be confused with
.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.
@@ -701,7 +757,7 @@ ping packets):
.RS
.nf
.B
-tcpdump 'icmp[0] != 8 and icmp[0] != 0"
+tcpdump 'icmp[0] != 8 and icmp[0] != 0'
.fi
.RE
.SH OUTPUT FORMAT
@@ -729,6 +785,13 @@ 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
\fI(N.B.: The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.)\fP
.LP
@@ -770,7 +833,7 @@ host \fIrtsg\fP to host \fIcsam\fP:
.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
@@ -794,7 +857,7 @@ broadcast and the second is point-to-point would be visible:
.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
@@ -806,7 +869,7 @@ 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 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:
@@ -846,7 +909,7 @@ 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\fP\s+2
+csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
.sp .5
.fi
.RE
@@ -866,7 +929,7 @@ 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 \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
@@ -886,15 +949,201 @@ 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 \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
@@ -929,7 +1178,7 @@ Name server requests are formatted as
.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
@@ -966,7 +1215,7 @@ Name server responses are formatted as
\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
@@ -997,7 +1246,7 @@ has worked well for me.
.HD
SMB/CIFS decoding
.LP
-tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data
+\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.
@@ -1032,7 +1281,7 @@ 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
-\fP
+\fR
.sp .5
.fi
.RE
@@ -1066,7 +1315,7 @@ wrl.nfs > sushi.1372a:
.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
@@ -1089,7 +1338,7 @@ NFS reply packets do not explicitly identify the RPC operation. Instead,
replies using the transaction ID. If a reply does not closely follow the
corresponding request, it might not be parsable.
.HD
-AFS Request and Replies
+AFS Requests and Replies
.LP
Transarc AFS (Andrew File System) requests and replies are printed
as:
@@ -1106,7 +1355,7 @@ 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
-\fP
+\fR
.sp .5
.fi
.RE
@@ -1126,11 +1375,16 @@ 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, additional information is printed,
-such as the the RX call ID, call number, sequence number, serial number,
-and the RX packet flags.
+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 again, the security index and service id are printed.
+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
@@ -1162,7 +1416,7 @@ Lines in this file have the form
\f(CW1.254 ether
16.1 icsd-net
-1.254.110 ace\fP
+1.254.110 ace\fR
.sp .5
.fi
.RE
@@ -1185,7 +1439,7 @@ Appletalk addresses are printed in the form
\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
@@ -1213,7 +1467,7 @@ protocol) and packet size.
.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
@@ -1242,7 +1496,7 @@ 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\fP\s+2
+jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
.sp .5
.fi
.RE
@@ -1326,12 +1580,22 @@ serviced the `new packet' interrupt.
.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
@@ -1340,40 +1604,61 @@ The current version is available via anonymous ftp:
IPv6/IPsec support is added by WIDE/KAME project.
This program uses Eric Young's SSLeay library, under specific configuration.
.SH BUGS
-Please send bug reports to tcpdump@ee.lbl.gov.
+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 ).
+.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 tcp
-or
-.BR udp
-should chase header chain too.
+.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.
OpenPOWER on IntegriCloud