tcpdump.1

<B>Digital的Unix操作系统VAX 4.2源码</B>

\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
.fi
.in -.5i
\fIProto\fR is one of \fBether, ip, arp, rarp, tcp, \fRor \fBudp\fR, and
indicates the protocol layer for the index operation.
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
.B len ,
gives the length of the packet.
.IP
For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
The expression `\fBip[0] & 0xf != 5\fP'
catches all IP packets with options. The expression
`\fBip[2:2] & 0x1fff = 0\fP'
catches only unfragmented datagrams and frag zero of fragmented 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.
.PP
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 (`\fBand\fP').
.IP
Alternation (`\fBor\fP').
.PP
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.
.PP
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
.PP
Expression arguments can be passed to 
.PN tcpdump 
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 Restrictions
The 
.PN tcpdump
command for ULTRIX requires ULTRIX version 4.0 or later; the kernel
has to have been built with the 
.PN packetfilter
pseudo-device driver (see
.MS packetfilter 4 ).
.PP
ULTRIX V4.0 and ULTRIX V4.1 do not let you
watch either your own outbound or inbound traffic.
.PP
Some attempt should be made to reassemble IP fragments or, at least
to compute the right length for the higher level protocol.
.PP
A packet trace that crosses a daylight savings time change will give
skewed time stamps (the time change is ignored).
.PP
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 
.PN tcpdump .
.PP
Apple Ethertalk DDP packets could be dumped as easily as KIP DDP
packets but are not.
.SH Examples
To print all packets arriving at or departing from the host
named 
.PN sundown 
type the following command:
.RS
.nf
\fBtcpdump host sundown\fP
.fi
.RE
.PP
To print traffic between 
.PN helios
and either 
.PN hot
or 
.PN ace :
.RS
.nf
\fBtcpdump host helios and \\( hot or ace \\)\fP
.fi
.RE
.PP
To print all IP packets between 
.PN ace 
and any host except 
.PN helios :
.RS
.nf
\fBtcpdump ip host ace and not helios\fP
.fi
.RE
.PP
To print all traffic between local hosts and hosts at Berkeley:
.RS
.nf
.B "tcpdump net ucb-ether"
.fi
.RE
.PP
To print all ftp traffic through internet gateway 
.PN snup :
.RS
.nf
.B "tcpdump 'gateway snup and (port ftp or ftp-data)' "
.fi
.RE
(Note that the expression is quoted to prevent the shell from
interpreting, or misinterpreting, the parentheses):
.PP
To print traffic neither sourced from nor destined for local hosts
(if you gateway to one other net, these packets should never make it
onto your local net).
.RS
.nf
.B "tcpdump ip and not net \fIlocalnet\fP"
.fi
.RE
.PP
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[13] & 3 != 0 and not src and dst net \fIlocalnet\fP' "
.fi
.RE
.PP
To print IP packets longer than 576 bytes sent through gateway 
.PN snup :
.RS
.nf
.B "tcpdump 'gateway snup and ip[2:2] > 576' "
.fi
.RE
.PP
To print IP broadcast or multicast packets that were
not sent via ethernet broadcast or multicast:
.RS
.nf
.B "tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224' "
.fi
.RE
.SH Output Format
The output of 
.PN tcpdump
is protocol dependent.  The following
gives a brief description and examples of most of the formats.
.sp
.sp
.B "Link Level Headers"
.PP
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.
.PP
.NT
The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.
.NE
.PP
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.
.PP
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
.sp
.sp
.B "ARP/RARP Packets"
.PP
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 
.PN rtsg 
to host 
.PN csam :
.RS
.nf
.sp .5
\f(CWarp who-has csam tell rtsg
arp reply csam is-at CSAM\fP
.sp .5
.fi
.RE
The first line says that 
.PN rtsg 
sent an arp packet asking
for the ethernet address of internet host 
.PN csam .  
.PN Csam
replies with its ethernet address (in this example, ethernet addresses
are in caps and internet addresses in lower case).
.PP
This would look less redundant if we had done 
.PN "tcpdump \-n" :
.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
.PP
If we had done 
.PN "tcpdump \-e" , 
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\fP
.sp .5
.fi
.RE
For the first packet this says the ethernet source address is RTSG, the
destination is the broadcast address, the type field
contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
.sp
.sp 
.B "TCP Packets"
.PP
.NT
The following description assumes familiarity with
the TCP protocol described in RFC-793.
.NE
.PP
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) or R (RST) 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 the sequence number of the next data expected in the other
direction on this connection.
\fIWindow\fP is the number of bytes of receive buffer space available in
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 (for example, 
<mss 1024>).
.PP
\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.
.PP
Here is the opening portion of an rlogin from host 
.PN rtsg
to host 
.PN csam .
.EX
\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\fP\s+2
.EE
The first line says that tcp port 1023 on 
.PN rtsg 
sent a packet to port \fIlogin\fP
on 
.PN 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.
.PP
The host
.PN csam 
replies with a similar packet except it includes a piggy-backed
ack for 
.PN rtsg 's 
SYN.  
The host
.PN rtsg 
then acks 
.PN 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 
.PN tcpdump 
sees a tcp `conversation', it prints the sequence number from the packet.
On subsequent packets of the conversation, the difference between
the current packet's sequence number and this initial sequence number
is printed.  This means that sequence numbers after the
first can be interpreted
as relative byte positions in the conversation's data stream (with the
first data byte each direction being `1').  `-S' will override this
feature, causing the original sequence numbers to be output.
.PP
On the 6th line, 
.PN rtsg 
sends 
.PN csam