d13b4de6f9823e80fa24310801050d3a533a359b
[dragonfly.git] / contrib / tcpdump-3.9 / tcpdump.1
1 .\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.167.2.11 2007/06/15 20:13:49 guy Exp $ (LBL)
2 .\"
3 .\"     $NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $
4 .\"
5 .\" Copyright (c) 1987, 1988, 1989, 1990, 1991, 1992, 1994, 1995, 1996, 1997
6 .\"     The Regents of the University of California.  All rights reserved.
7 .\" All rights reserved.
8 .\"
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that: (1) source code distributions
11 .\" retain the above copyright notice and this paragraph in its entirety, (2)
12 .\" distributions including binary code include the above copyright notice and
13 .\" this paragraph in its entirety in the documentation or other materials
14 .\" provided with the distribution, and (3) all advertising materials mentioning
15 .\" features or use of this software display the following acknowledgement:
16 .\" ``This product includes software developed by the University of California,
17 .\" Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
18 .\" the University nor the names of its contributors may be used to endorse
19 .\" or promote products derived from this software without specific prior
20 .\" written permission.
21 .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
22 .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
23 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
24 .\"
25 .TH TCPDUMP 1  "18 April 2005"
26 .SH NAME
27 tcpdump \- dump traffic on a network
28 .SH SYNOPSIS
29 .na
30 .B tcpdump
31 [
32 .B \-AdDeflLnNOpqRStuUvxX
33 ] [
34 .B \-c
35 .I count
36 ]
37 .br
38 .ti +8
39 [
40 .B \-C
41 .I file_size
42 ] [
43 .B \-F
44 .I file
45 ]
46 .br
47 .ti +8
48 [
49 .B \-i
50 .I interface
51 ]
52 [
53 .B \-m
54 .I module
55 ]
56 [
57 .B \-M
58 .I secret
59 ]
60 .br
61 .ti +8
62 [
63 .B \-r
64 .I file
65 ]
66 [
67 .B \-s
68 .I snaplen
69 ]
70 [
71 .B \-T
72 .I type
73 ]
74 [
75 .B \-w
76 .I file
77 ]
78 .br
79 .ti +8
80 [
81 .B \-W
82 .I filecount
83 ]
84 .br
85 .ti +8
86 [
87 .B \-E
88 .I spi@ipaddr algo:secret,...
89 ]
90 .br
91 .ti +8
92 [
93 .B \-y
94 .I datalinktype
95 ]
96 [
97 .B \-Z
98 .I user
99 ]
100 .ti +8
101 [
102 .I expression
103 ]
104 .br
105 .ad
106 .SH DESCRIPTION
107 .LP
108 \fITcpdump\fP prints out a description of the contents of packets on a
109 network interface that match the boolean \fIexpression\fP.  It can also
110 be run with the
111 .B \-w
112 flag, which causes it to save the packet data to a file for later
113 analysis, and/or with the
114 .B \-r
115 flag, which causes it to read from a saved packet file rather than to
116 read packets from a network interface.  In all cases, only packets that
117 match
118 .I expression
119 will be processed by
120 .IR tcpdump .
121 .LP
122 .I Tcpdump
123 will, if not run with the
124 .B \-c
125 flag, continue capturing packets until it is interrupted by a SIGINT
126 signal (generated, for example, by typing your interrupt character,
127 typically control-C) or a SIGTERM signal (typically generated with the
128 .BR kill (1)
129 command); if run with the
130 .B \-c
131 flag, it will capture packets until it is interrupted by a SIGINT or
132 SIGTERM signal or the specified number of packets have been processed.
133 .LP
134 When
135 .I tcpdump
136 finishes capturing packets, it will report counts of:
137 .IP
138 packets ``captured'' (this is the number of packets that
139 .I tcpdump
140 has received and processed);
141 .IP
142 packets ``received by filter'' (the meaning of this depends on the OS on
143 which you're running
144 .IR tcpdump ,
145 and possibly on the way the OS was configured - if a filter was
146 specified on the command line, on some OSes it counts packets regardless
147 of whether they were matched by the filter expression and, even if they
148 were matched by the filter expression, regardless of whether
149 .I tcpdump
150 has read and processed them yet, on other OSes it counts only packets that were
151 matched by the filter expression regardless of whether
152 .I tcpdump
153 has read and processed them yet, and on other OSes it counts only
154 packets that were matched by the filter expression and were processed by
155 .IR tcpdump );
156 .IP
157 packets ``dropped by kernel'' (this is the number of packets that were
158 dropped, due to a lack of buffer space, by the packet capture mechanism
159 in the OS on which
160 .I tcpdump
161 is running, if the OS reports that information to applications; if not,
162 it will be reported as 0).
163 .LP
164 On platforms that support the SIGINFO signal, such as most BSDs
165 (including Mac OS X) and Digital/Tru64 UNIX, it will report those counts
166 when it receives a SIGINFO signal (generated, for example, by typing
167 your ``status'' character, typically control-T, although on some
168 platforms, such as Mac OS X, the ``status'' character is not set by
169 default, so you must set it with
170 .BR stty (1)
171 in order to use it) and will continue capturing packets.
172 .LP
173 Reading packets from a network interface may require that you have
174 special privileges:
175 .TP
176 .B Under SunOS 3.x or 4.x with NIT or BPF:
177 You must have read access to
178 .I /dev/nit
179 or
180 .IR /dev/bpf* .
181 .TP
182 .B Under Solaris with DLPI:
183 You must have read/write access to the network pseudo device, e.g.
184 .IR /dev/le .
185 On at least some versions of Solaris, however, this is not sufficient to
186 allow
187 .I tcpdump
188 to capture in promiscuous mode; on those versions of Solaris, you must
189 be root, or
190 .I tcpdump
191 must be installed setuid to root, in order to capture in promiscuous
192 mode.  Note that, on many (perhaps all) interfaces, if you don't capture
193 in promiscuous mode, you will not see any outgoing packets, so a capture
194 not done in promiscuous mode may not be very useful.
195 .TP
196 .B Under HP-UX with DLPI:
197 You must be root or
198 .I tcpdump
199 must be installed setuid to root.
200 .TP
201 .B Under IRIX with snoop:
202 You must be root or
203 .I tcpdump
204 must be installed setuid to root.
205 .TP
206 .B Under Linux:
207 You must be root or
208 .I tcpdump
209 must be installed setuid to root (unless your distribution has a kernel
210 that supports capability bits such as CAP_NET_RAW and code to allow
211 those capability bits to be given to particular accounts and to cause
212 those bits to be set on a user's initial processes when they log in, in
213 which case you  must have CAP_NET_RAW in order to capture and
214 CAP_NET_ADMIN to enumerate network devices with, for example, the
215 .B \-D
216 flag).
217 .TP
218 .B Under ULTRIX and Digital UNIX/Tru64 UNIX:
219 Any user may capture network traffic with
220 .IR tcpdump .
221 However, no user (not even the super-user) can capture in promiscuous
222 mode on an interface unless the super-user has enabled promiscuous-mode
223 operation on that interface using
224 .IR pfconfig (8),
225 and no user (not even the super-user) can capture unicast traffic
226 received by or sent by the machine on an interface unless the super-user
227 has enabled copy-all-mode operation on that interface using
228 .IR pfconfig ,
229 so
230 .I useful
231 packet capture on an interface probably requires that either
232 promiscuous-mode or copy-all-mode operation, or both modes of
233 operation, be enabled on that interface.
234 .TP
235 .B Under BSD (this includes Mac OS X):
236 You must have read access to
237 .I /dev/bpf*
238 on systems that don't have a cloning BPF device, or to
239 .I /dev/bpf
240 on systems that do.
241 On BSDs with a devfs (this includes Mac OS X), this might involve more
242 than just having somebody with super-user access setting the ownership
243 or permissions on the BPF devices - it might involve configuring devfs
244 to set the ownership or permissions every time the system is booted,
245 if the system even supports that; if it doesn't support that, you might
246 have to find some other way to make that happen at boot time.
247 .LP
248 Reading a saved packet file doesn't require special privileges.
249 .SH OPTIONS
250 .TP
251 .B \-A
252 Print each packet (minus its link level header) in ASCII.  Handy for
253 capturing web pages.
254 .TP
255 .B \-c
256 Exit after receiving \fIcount\fP packets.
257 .TP
258 .B \-C
259 Before writing a raw packet to a savefile, check whether the file is
260 currently larger than \fIfile_size\fP and, if so, close the current
261 savefile and open a new one.  Savefiles after the first savefile will
262 have the name specified with the
263 .B \-w
264 flag, with a number after it, starting at 1 and continuing upward.
265 The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
266 not 1,048,576 bytes).
267 .TP
268 .B \-d
269 Dump the compiled packet-matching code in a human readable form to
270 standard output and stop.
271 .TP
272 .B \-dd
273 Dump packet-matching code as a
274 .B C
275 program fragment.
276 .TP
277 .B \-ddd
278 Dump packet-matching code as decimal numbers (preceded with a count).
279 .TP
280 .B \-D
281 Print the list of the network interfaces available on the system and on
282 which
283 .I tcpdump
284 can capture packets.  For each network interface, a number and an
285 interface name, possibly followed by a text description of the
286 interface, is printed.  The interface name or the number can be supplied
287 to the
288 .B \-i
289 flag to specify an interface on which to capture.
290 .IP
291 This can be useful on systems that don't have a command to list them
292 (e.g., Windows systems, or UNIX systems lacking
293 .BR "ifconfig \-a" );
294 the number can be useful on Windows 2000 and later systems, where the
295 interface name is a somewhat complex string.
296 .IP
297 The
298 .B \-D
299 flag will not be supported if
300 .I tcpdump
301 was built with an older version of
302 .I libpcap
303 that lacks the
304 .B pcap_findalldevs()
305 function.
306 .TP
307 .B \-e
308 Print the link-level header on each dump line.
309 .TP
310 .B \-E
311 Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that
312 are addressed to \fIaddr\fP and contain Security Parameter Index value
313 \fIspi\fP. This combination may be repeated with comma or newline seperation.
314 .IP
315 Note that setting the secret for IPv4 ESP packets is supported at this time.
316 .IP
317 Algorithms may be
318 \fBdes-cbc\fP,
319 \fB3des-cbc\fP,
320 \fBblowfish-cbc\fP,
321 \fBrc3-cbc\fP,
322 \fBcast128-cbc\fP, or
323 \fBnone\fP.
324 The default is \fBdes-cbc\fP.
325 The ability to decrypt packets is only present if \fItcpdump\fP was compiled
326 with cryptography enabled.
327 .IP
328 \fIsecret\fP is the ASCII text for ESP secret key. 
329 If preceeded by 0x, then a hex value will be read.
330 .IP
331 The option assumes RFC2406 ESP, not RFC1827 ESP.
332 The option is only for debugging purposes, and
333 the use of this option with a true `secret' key is discouraged.
334 By presenting IPsec secret key onto command line
335 you make it visible to others, via
336 .IR ps (1)
337 and other occasions.
338 .IP
339 In addition to the above syntax, the syntax \fIfile name\fP may be used
340 to have tcpdump read the provided file in. The file is opened upon 
341 receiving the first ESP packet, so any special permissions that tcpdump
342 may have been given should already have been given up.
343 .TP
344 .B \-f
345 Print `foreign' IPv4 addresses numerically rather than symbolically
346 (this option is intended to get around serious brain damage in
347 Sun's NIS server \(em usually it hangs forever translating non-local
348 internet numbers).
349 .IP
350 The test for `foreign' IPv4 addresses is done using the IPv4 address and
351 netmask of the interface on which capture is being done.  If that
352 address or netmask are not available, available, either because the
353 interface on which capture is being done has no address or netmask or
354 because the capture is being done on the Linux "any" interface, which
355 can capture on more than one interface, this option will not work
356 correctly.
357 .TP
358 .B \-F
359 Use \fIfile\fP as input for the filter expression.
360 An additional expression given on the command line is ignored.
361 .TP
362 .B \-i
363 Listen on \fIinterface\fP.
364 If unspecified, \fItcpdump\fP searches the system interface list for the
365 lowest numbered, configured up interface (excluding loopback).
366 Ties are broken by choosing the earliest match.
367 .IP
368 On Linux systems with 2.2 or later kernels, an
369 .I interface
370 argument of ``any'' can be used to capture packets from all interfaces.
371 Note that captures on the ``any'' device will not be done in promiscuous
372 mode.
373 .IP
374 If the
375 .B \-D
376 flag is supported, an interface number as printed by that flag can be
377 used as the
378 .I interface
379 argument.
380 .TP
381 .B \-l
382 Make stdout line buffered.
383 Useful if you want to see the data
384 while capturing it.
385 E.g.,
386 .br
387 ``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
388 ``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
389 .TP
390 .B \-L
391 List the known data link types for the interface and exit.
392 .TP
393 .B \-m
394 Load SMI MIB module definitions from file \fImodule\fR.
395 This option
396 can be used several times to load several MIB modules into \fItcpdump\fP.
397 .TP
398 .B \-M
399 Use \fIsecret\fP as a shared secret for validating the digests found in
400 TCP segments with the TCP-MD5 option (RFC 2385), if present.
401 .TP
402 .B \-n
403 Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
404 .TP
405 .B \-N
406 Don't print domain name qualification of host names.
407 E.g.,
408 if you give this flag then \fItcpdump\fP will print ``nic''
409 instead of ``nic.ddn.mil''.
410 .TP
411 .B \-O
412 Do not run the packet-matching code optimizer.
413 This is useful only
414 if you suspect a bug in the optimizer.
415 .TP
416 .B \-p
417 \fIDon't\fP put the interface
418 into promiscuous mode.
419 Note that the interface might be in promiscuous
420 mode for some other reason; hence, `-p' cannot be used as an abbreviation for
421 `ether host {local-hw-addr} or ether broadcast'.
422 .TP
423 .B \-q
424 Quick (quiet?) output.
425 Print less protocol information so output
426 lines are shorter.
427 .TP
428 .B \-R
429 Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
430 If specified, \fItcpdump\fP will not print replay prevention field.
431 Since there is no protocol version field in ESP/AH specification,
432 \fItcpdump\fP cannot deduce the version of ESP/AH protocol.
433 .TP
434 .B \-r
435 Read packets from \fIfile\fR (which was created with the
436 .B \-w
437 option).
438 Standard input is used if \fIfile\fR is ``-''.
439 .TP
440 .B \-S
441 Print absolute, rather than relative, TCP sequence numbers.
442 .TP
443 .B \-s
444 Snarf \fIsnaplen\fP bytes of data from each packet rather than the
445 default of 68 (with SunOS's NIT, the minimum is actually 96).
446 68 bytes is adequate for IP, ICMP, TCP
447 and UDP but may truncate protocol information from name server and NFS
448 packets (see below).
449 Packets truncated because of a limited snapshot
450 are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
451 is the name of the protocol level at which the truncation has occurred.
452 Note that taking larger snapshots both increases
453 the amount of time it takes to process packets and, effectively,
454 decreases the amount of packet buffering.
455 This may cause packets to be
456 lost.
457 You should limit \fIsnaplen\fP to the smallest number that will
458 capture the protocol information you're interested in.
459 Setting
460 \fIsnaplen\fP to 0 means use the required length to catch whole packets.
461 .TP
462 .B \-T
463 Force packets selected by "\fIexpression\fP" to be interpreted the
464 specified \fItype\fR.
465 Currently known types are
466 \fBaodv\fR (Ad-hoc On-demand Distance Vector protocol),
467 \fBcnfp\fR (Cisco NetFlow protocol),
468 \fBrpc\fR (Remote Procedure Call),
469 \fBrtp\fR (Real-Time Applications protocol),
470 \fBrtcp\fR (Real-Time Applications control protocol),
471 \fBsnmp\fR (Simple Network Management Protocol),
472 \fBtftp\fR (Trivial File Transfer Protocol),
473 \fBvat\fR (Visual Audio Tool),
474 and
475 \fBwb\fR (distributed White Board).
476 .TP
477 .B \-t
478 \fIDon't\fP print a timestamp on each dump line.
479 .TP
480 .B \-tt
481 Print an unformatted timestamp on each dump line.
482 .TP
483 .B \-ttt
484 Print a delta (in micro-seconds) between current and previous line
485 on each dump line.
486 .TP
487 .B \-tttt
488 Print a timestamp in default format proceeded by date on each dump line.
489 .TP
490 .B \-u
491 Print undecoded NFS handles.
492 .TP
493 .B \-U
494 Make output saved via the
495 .B \-w
496 option ``packet-buffered''; i.e., as each packet is saved, it will be
497 written to the output file, rather than being written only when the
498 output buffer fills.
499 .IP
500 The
501 .B \-U
502 flag will not be supported if
503 .I tcpdump
504 was built with an older version of
505 .I libpcap
506 that lacks the
507 .B pcap_dump_flush()
508 function.
509 .TP
510 .B \-v
511 When parsing and printing, produce (slightly more) verbose output.
512 For example, the time to live,
513 identification, total length and options in an IP packet are printed.
514 Also enables additional packet integrity checks such as verifying the
515 IP and ICMP header checksum.
516 .IP
517 When writing to a file with the
518 .B \-w
519 option, report, every 10 seconds, the number of packets captured.
520 .TP
521 .B \-vv
522 Even more verbose output.
523 For example, additional fields are
524 printed from NFS reply packets, and SMB packets are fully decoded.
525 .TP
526 .B \-vvv
527 Even more verbose output.
528 For example,
529 telnet \fBSB\fP ... \fBSE\fP options
530 are printed in full.
531 With
532 .B \-X
533 Telnet options are printed in hex as well.
534 .TP
535 .B \-w
536 Write the raw packets to \fIfile\fR rather than parsing and printing
537 them out.
538 They can later be printed with the \-r option.
539 Standard output is used if \fIfile\fR is ``-''.
540 .TP
541 .B \-W
542 Used in conjunction with the 
543 .B \-C 
544 option, this will limit the number
545 of files created to the specified number, and begin overwriting files
546 from the beginning, thus creating a 'rotating' buffer. 
547 In addition, it will name
548 the files with enough leading 0s to support the maximum number of
549 files, allowing them to sort correctly.
550 .TP
551 .B \-x
552 When parsing and printing,
553 in addition to printing the headers of each packet, print the data of
554 each packet (minus its link level header) in hex. 
555 The smaller of the entire packet or
556 .I snaplen
557 bytes will be printed.  Note that this is the entire link-layer
558 packet, so for link layers that pad (e.g. Ethernet), the padding bytes
559 will also be printed when the higher layer packet is shorter than the
560 required padding.
561 .TP
562 .B \-xx
563 When parsing and printing,
564 in addition to printing the headers of each packet, print the data of
565 each packet,
566 .I including
567 its link level header, in hex.
568 .TP
569 .B \-X
570 When parsing and printing,
571 in addition to printing the headers of each packet, print the data of
572 each packet (minus its link level header) in hex and ASCII.
573 This is very handy for analysing new protocols.
574 .TP
575 .B \-XX
576 When parsing and printing,
577 in addition to printing the headers of each packet, print the data of
578 each packet,
579 .I including
580 its link level header, in hex and ASCII.
581 .TP
582 .B \-y
583 Set the data link type to use while capturing packets to \fIdatalinktype\fP.
584 .TP
585 .B \-Z
586 Drops privileges (if root) and changes user ID to
587 .I user
588 and the group ID to the primary group of
589 .IR user .
590 .IP
591 This behavior can also be enabled by default at compile time.
592 .IP "\fI expression\fP"
593 .RS
594 selects which packets will be dumped.
595 If no \fIexpression\fP
596 is given, all packets on the net will be dumped.
597 Otherwise,
598 only packets for which \fIexpression\fP is `true' will be dumped.
599 .LP
600 The \fIexpression\fP consists of one or more
601 .I primitives.
602 Primitives usually consist of an
603 .I id
604 (name or number) preceded by one or more qualifiers.
605 There are three
606 different kinds of qualifier:
607 .IP \fItype\fP
608 qualifiers say what kind of thing the id name or number refers to.
609 Possible types are
610 .BR host ,
611 .B net ,
612 .B port
613 and
614 .BR portrange .
615 E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'.
616 If there is no type
617 qualifier,
618 .B host
619 is assumed.
620 .IP \fIdir\fP
621 qualifiers specify a particular transfer direction to and/or from
622 .IR id .
623 Possible directions are
624 .BR src ,
625 .BR dst ,
626 .B "src or dst"
627 and
628 .B "src and"
629 .BR dst .
630 E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.
631 If
632 there is no dir qualifier,
633 .B "src or dst"
634 is assumed.
635 For some link layers, such as SLIP and the ``cooked'' Linux capture mode
636 used for the ``any'' device and for some other device types, the
637 .B inbound
638 and
639 .B outbound
640 qualifiers can be used to specify a desired direction.
641 .IP \fIproto\fP
642 qualifiers restrict the match to a particular protocol.
643 Possible
644 protos are:
645 .BR ether ,
646 .BR fddi ,
647 .BR tr ,
648 .BR wlan ,
649 .BR ip ,
650 .BR ip6 ,
651 .BR arp ,
652 .BR rarp ,
653 .BR decnet ,
654 .B tcp
655 and
656 .BR udp .
657 E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange
658 7000-7009'.
659 If there is
660 no proto qualifier, all protocols consistent with the type are
661 assumed.
662 E.g., `src foo' means `(ip or arp or rarp) src foo'
663 (except the latter is not legal syntax), `net bar' means `(ip or
664 arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
665 .LP
666 [`fddi' is actually an alias for `ether'; the parser treats them
667 identically as meaning ``the data link level used on the specified
668 network interface.''  FDDI headers contain Ethernet-like source
669 and destination addresses, and often contain Ethernet-like packet
670 types, so you can filter on these FDDI fields just as with the
671 analogous Ethernet fields.
672 FDDI headers also contain other fields,
673 but you cannot name them explicitly in a filter expression.
674 .LP
675 Similarly, `tr' and `wlan' are aliases for `ether'; the previous
676 paragraph's statements about FDDI headers also apply to Token Ring
677 and 802.11 wireless LAN headers.  For 802.11 headers, the destination
678 address is the DA field and the source address is the SA field; the
679 BSSID, RA, and TA fields aren't tested.]
680 .LP
681 In addition to the above, there are some special `primitive' keywords
682 that don't follow the pattern:
683 .BR gateway ,
684 .BR broadcast ,
685 .BR less ,
686 .B greater
687 and arithmetic expressions.
688 All of these are described below.
689 .LP
690 More complex filter expressions are built up by using the words
691 .BR and ,
692 .B or
693 and
694 .B not
695 to combine primitives.
696 E.g., `host foo and not port ftp and not port ftp-data'.
697 To save typing, identical qualifier lists can be omitted.
698 E.g.,
699 `tcp dst port ftp or ftp-data or domain' is exactly the same as
700 `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
701 .LP
702 Allowable primitives are:
703 .IP "\fBdst host \fIhost\fR"
704 True if the IPv4/v6 destination field of the packet is \fIhost\fP,
705 which may be either an address or a name.
706 .IP "\fBsrc host \fIhost\fR"
707 True if the IPv4/v6 source field of the packet is \fIhost\fP.
708 .IP "\fBhost \fIhost\fP
709 True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
710 .IP
711 Any of the above host expressions can be prepended with the keywords,
712 \fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in:
713 .in +.5i
714 .nf
715 \fBip host \fIhost\fR
716 .fi
717 .in -.5i
718 which is equivalent to:
719 .in +.5i
720 .nf
721 \fBether proto \fI\\ip\fB and host \fIhost\fR
722 .fi
723 .in -.5i
724 If \fIhost\fR is a name with multiple IP addresses, each address will
725 be checked for a match.
726 .IP "\fBether dst \fIehost\fP
727 True if the Ethernet destination address is \fIehost\fP.
728 \fIEhost\fP
729 may be either a name from /etc/ethers or a number (see
730 .IR ethers (3N)
731 for numeric format).
732 .IP "\fBether src \fIehost\fP
733 True if the Ethernet source address is \fIehost\fP.
734 .IP "\fBether host \fIehost\fP
735 True if either the Ethernet source or destination address is \fIehost\fP.
736 .IP "\fBgateway\fP \fIhost\fP
737 True if the packet used \fIhost\fP as a gateway.
738 I.e., the Ethernet
739 source or destination address was \fIhost\fP but neither the IP source
740 nor the IP destination was \fIhost\fP.
741 \fIHost\fP must be a name and
742 must be found both by the machine's host-name-to-IP-address resolution
743 mechanisms (host name file, DNS, NIS, etc.) and by the machine's
744 host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.).
745 (An equivalent expression is
746 .in +.5i
747 .nf
748 \fBether host \fIehost \fBand not host \fIhost\fR
749 .fi
750 .in -.5i
751 which can be used with either names or numbers for \fIhost / ehost\fP.)
752 This syntax does not work in IPv6-enabled configuration at this moment.
753 .IP "\fBdst net \fInet\fR"
754 True if the IPv4/v6 destination address of the packet has a network
755 number of \fInet\fP.
756 \fINet\fP may be either a name from the networks database
757 (/etc/networks, etc.) or a network number.
758 An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0),
759 dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single
760 number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad
761 (which means that it's really a host match), 255.255.255.0 for a dotted
762 triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number.
763 An IPv6 network number must be written out fully; the netmask is
764 ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always
765 host matches, and a network match requires a netmask length.
766 .IP "\fBsrc net \fInet\fR"
767 True if the IPv4/v6 source address of the packet has a network
768 number of \fInet\fP.
769 .IP "\fBnet \fInet\fR"
770 True if either the IPv4/v6 source or destination address of the packet has a network
771 number of \fInet\fP.
772 .IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
773 True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR.
774 May be qualified with \fBsrc\fR or \fBdst\fR.
775 Note that this syntax is not valid for IPv6 \fInet\fR.
776 .IP "\fBnet \fInet\fR/\fIlen\fR"
777 True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR
778 bits wide.
779 May be qualified with \fBsrc\fR or \fBdst\fR.
780 .IP "\fBdst port \fIport\fR"
781 True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
782 destination port value of \fIport\fP.
783 The \fIport\fP can be a number or a name used in /etc/services (see
784 .IR tcp (4P)
785 and
786 .IR udp (4P)).
787 If a name is used, both the port
788 number and protocol are checked.
789 If a number or ambiguous name is used,
790 only the port number is checked (e.g., \fBdst port 513\fR will print both
791 tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
792 both tcp/domain and udp/domain traffic).
793 .IP "\fBsrc port \fIport\fR"
794 True if the packet has a source port value of \fIport\fP.
795 .IP "\fBport \fIport\fR"
796 True if either the source or destination port of the packet is \fIport\fP.
797 .IP "\fBdst portrange \fIport1\fB-\fIport2\fR"
798 True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
799 destination port value between \fIport1\fP and \fIport2\fP.
800 .I port1
801 and
802 .I port2
803 are interpreted in the same fashion as the
804 .I port
805 parameter for
806 .BR port .
807 .IP "\fBsrc portrange \fIport1\fB-\fIport2\fR"
808 True if the packet has a source port value between \fIport1\fP and
809 \fIport2\fP.
810 .IP "\fBportrange \fIport1\fB-\fIport2\fR"
811 True if either the source or destination port of the packet is between
812 \fIport1\fP and \fIport2\fP.
813 .IP
814 Any of the above port or port range expressions can be prepended with
815 the keywords, \fBtcp\fP or \fBudp\fP, as in:
816 .in +.5i
817 .nf
818 \fBtcp src port \fIport\fR
819 .fi
820 .in -.5i
821 which matches only tcp packets whose source port is \fIport\fP.
822 .IP "\fBless \fIlength\fR"
823 True if the packet has a length less than or equal to \fIlength\fP.
824 This is equivalent to:
825 .in +.5i
826 .nf
827 \fBlen <= \fIlength\fP.
828 .fi
829 .in -.5i
830 .IP "\fBgreater \fIlength\fR"
831 True if the packet has a length greater than or equal to \fIlength\fP.
832 This is equivalent to:
833 .in +.5i
834 .nf
835 \fBlen >= \fIlength\fP.
836 .fi
837 .in -.5i
838 .IP "\fBip proto \fIprotocol\fR"
839 True if the packet is an IPv4 packet (see
840 .IR ip (4P))
841 of protocol type \fIprotocol\fP.
842 \fIProtocol\fP can be a number or one of the names
843 \fBicmp\fP, \fBicmp6\fP, \fBigmp\fP, \fBigrp\fP, \fBpim\fP, \fBah\fP,
844 \fBesp\fP, \fBvrrp\fP, \fBudp\fP, or \fBtcp\fP.
845 Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also
846 keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
847 Note that this primitive does not chase the protocol header chain.
848 .IP "\fBip6 proto \fIprotocol\fR"
849 True if the packet is an IPv6 packet of protocol type \fIprotocol\fP.
850 Note that this primitive does not chase the protocol header chain.
851 .IP "\fBip6 protochain \fIprotocol\fR"
852 True if the packet is IPv6 packet,
853 and contains protocol header with type \fIprotocol\fR
854 in its protocol header chain.
855 For example,
856 .in +.5i
857 .nf
858 \fBip6 protochain 6\fR
859 .fi
860 .in -.5i
861 matches any IPv6 packet with TCP protocol header in the protocol header chain.
862 The packet may contain, for example,
863 authentication header, routing header, or hop-by-hop option header,
864 between IPv6 header and TCP header.
865 The BPF code emitted by this primitive is complex and
866 cannot be optimized by BPF optimizer code in \fItcpdump\fP,
867 so this can be somewhat slow.
868 .IP "\fBip protochain \fIprotocol\fR"
869 Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
870 .IP "\fBether broadcast\fR"
871 True if the packet is an Ethernet broadcast packet.
872 The \fIether\fP
873 keyword is optional.
874 .IP "\fBip broadcast\fR"
875 True if the packet is an IPv4 broadcast packet.
876 It checks for both the all-zeroes and all-ones broadcast conventions,
877 and looks up the subnet mask on the interface on which the capture is
878 being done.
879 .IP
880 If the subnet mask of the interface on which the capture is being done
881 is not available, either because the interface on which capture is being
882 done has no netmask or because the capture is being done on the Linux
883 "any" interface, which can capture on more than one interface, this
884 check will not work correctly.
885 .IP "\fBether multicast\fR"
886 True if the packet is an Ethernet multicast packet.
887 The \fBether\fP
888 keyword is optional.
889 This is shorthand for `\fBether[0] & 1 != 0\fP'.
890 .IP "\fBip multicast\fR"
891 True if the packet is an IPv4 multicast packet.
892 .IP "\fBip6 multicast\fR"
893 True if the packet is an IPv6 multicast packet.
894 .IP  "\fBether proto \fIprotocol\fR"
895 True if the packet is of ether type \fIprotocol\fR.
896 \fIProtocol\fP can be a number or one of the names
897 \fBip\fP, \fBip6\fP, \fBarp\fP, \fBrarp\fP, \fBatalk\fP, \fBaarp\fP,
898 \fBdecnet\fP, \fBsca\fP, \fBlat\fP, \fBmopdl\fP, \fBmoprc\fP,
899 \fBiso\fP, \fBstp\fP, \fBipx\fP, or \fBnetbeui\fP.
900 Note these identifiers are also keywords
901 and must be escaped via backslash (\\).
902 .IP
903 [In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), Token Ring
904 (e.g., `\fBtr protocol arp\fR'), and IEEE 802.11 wireless LANS (e.g.,
905 `\fBwlan protocol arp\fR'), for most of those protocols, the
906 protocol identification comes from the 802.2 Logical Link Control (LLC)
907 header, which is usually layered on top of the FDDI, Token Ring, or
908 802.11 header.
909 .IP
910 When filtering for most protocol identifiers on FDDI, Token Ring, or
911 802.11, \fItcpdump\fR checks only the protocol ID field of an LLC header
912 in so-called SNAP format with an Organizational Unit Identifier (OUI) of
913 0x000000, for encapsulated Ethernet; it doesn't check whether the packet
914 is in SNAP format with an OUI of 0x000000.
915 The exceptions are:
916 .RS
917 .TP
918 \fBiso\fP
919 \fItcpdump\fR checks the DSAP (Destination Service Access Point) and
920 SSAP (Source Service Access Point) fields of the LLC header;
921 .TP
922 \fBstp\fP and \fBnetbeui\fP
923 \fItcpdump\fR checks the DSAP of the LLC header;
924 .TP
925 \fBatalk\fP
926 \fItcpdump\fR checks for a SNAP-format packet with an OUI of 0x080007
927 and the AppleTalk etype.
928 .RE
929 .IP
930 In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field
931 for most of those protocols.  The exceptions are:
932 .RS
933 .TP
934 \fBiso\fP, \fBstp\fP, and \fBnetbeui\fP
935 \fItcpdump\fR checks for an 802.3 frame and then checks the LLC header as
936 it does for FDDI, Token Ring, and 802.11;
937 .TP
938 \fBatalk\fP
939 \fItcpdump\fR checks both for the AppleTalk etype in an Ethernet frame and
940 for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11;
941 .TP
942 \fBaarp\fP
943 \fItcpdump\fR checks for the AppleTalk ARP etype in either an Ethernet
944 frame or an 802.2 SNAP frame with an OUI of 0x000000;
945 .TP
946 \fBipx\fP
947 \fItcpdump\fR checks for the IPX etype in an Ethernet frame, the IPX
948 DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of
949 IPX, and the IPX etype in a SNAP frame.
950 .RE
951 .IP "\fBdecnet src \fIhost\fR"
952 True if the DECNET source address is
953 .IR host ,
954 which may be an address of the form ``10.123'', or a DECNET host
955 name.
956 [DECNET host name support is only available on ULTRIX systems
957 that are configured to run DECNET.]
958 .IP "\fBdecnet dst \fIhost\fR"
959 True if the DECNET destination address is
960 .IR host .
961 .IP "\fBdecnet host \fIhost\fR"
962 True if either the DECNET source or destination address is
963 .IR host .
964 .IP "\fBifname \fIinterface\fR"
965 True if the packet was logged as coming from the specified interface (applies
966 only to packets logged by OpenBSD's
967 .BR pf (4)).
968 .IP "\fBon \fIinterface\fR"
969 Synonymous with the
970 .B ifname
971 modifier.
972 .IP "\fBrnr \fInum\fR"
973 True if the packet was logged as matching the specified PF rule number
974 (applies only to packets logged by OpenBSD's
975 .BR pf (4)).
976 .IP "\fBrulenum \fInum\fR"
977 Synonomous with the
978 .B rnr
979 modifier.
980 .IP "\fBreason \fIcode\fR"
981 True if the packet was logged with the specified PF reason code.  The known
982 codes are:
983 .BR match ,
984 .BR bad-offset ,
985 .BR fragment ,
986 .BR short ,
987 .BR normalize ,
988 and
989 .B memory
990 (applies only to packets logged by OpenBSD's
991 .BR pf (4)).
992 .IP "\fBrset \fIname\fR"
993 True if the packet was logged as matching the specified PF ruleset
994 name of an anchored ruleset (applies only to packets logged by
995 .BR pf (4)).
996 .IP "\fBruleset \fIname\fR"
997 Synonomous with the
998 .B rset
999 modifier.
1000 .IP "\fBsrnr \fInum\fR"
1001 True if the packet was logged as matching the specified PF rule number
1002 of an anchored ruleset (applies only to packets logged by
1003 .BR pf (4)).
1004 .IP "\fBsubrulenum \fInum\fR"
1005 Synonomous with the
1006 .B srnr
1007 modifier.
1008 .IP "\fBaction \fIact\fR"
1009 True if PF took the specified action when the packet was logged.  Known actions
1010 are:
1011 .B pass
1012 and
1013 .B block
1014 (applies only to packets logged by OpenBSD's
1015 .BR pf (4)).
1016 .IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
1017 Abbreviations for:
1018 .in +.5i
1019 .nf
1020 \fBether proto \fIp\fR
1021 .fi
1022 .in -.5i
1023 where \fIp\fR is one of the above protocols.
1024 .IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
1025 Abbreviations for:
1026 .in +.5i
1027 .nf
1028 \fBether proto \fIp\fR
1029 .fi
1030 .in -.5i
1031 where \fIp\fR is one of the above protocols.
1032 Note that
1033 \fItcpdump\fP does not currently know how to parse these protocols.
1034 .IP "\fBvlan \fI[vlan_id]\fR"
1035 True if the packet is an IEEE 802.1Q VLAN packet.
1036 If \fI[vlan_id]\fR is specified, only true if the packet has the specified
1037 \fIvlan_id\fR.
1038 Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR
1039 changes the decoding offsets for the remainder of \fIexpression\fR on
1040 the assumption that the packet is a VLAN packet.  The \fBvlan
1041 \fI[vlan_id]\fR expression may be used more than once, to filter on VLAN
1042 hierarchies.  Each use of that expression increments the filter offsets
1043 by 4.
1044 .IP
1045 For example:
1046 .in +.5i
1047 .nf
1048 \fBvlan 100 && vlan 200\fR
1049 .fi
1050 .in -.5i
1051 filters on VLAN 200 encapsulated within VLAN 100, and
1052 .in +.5i
1053 .nf
1054 \fBvlan && vlan 300 && ip\fR
1055 .fi
1056 .in -.5i
1057 filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any
1058 higher order VLAN.
1059 .IP "\fBmpls \fI[label_num]\fR"
1060 True if the packet is an MPLS packet.
1061 If \fI[label_num]\fR is specified, only true is the packet has the specified
1062 \fIlabel_num\fR.
1063 Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR
1064 changes the decoding offsets for the remainder of \fIexpression\fR on
1065 the assumption that the packet is a MPLS-encapsulated IP packet.  The
1066 \fBmpls \fI[label_num]\fR expression may be used more than once, to
1067 filter on MPLS hierarchies.  Each use of that expression increments the
1068 filter offsets by 4. 
1069 .IP
1070 For example:
1071 .in +.5i
1072 .nf
1073 \fBmpls 100000 && mpls 1024\fR
1074 .fi
1075 .in -.5i
1076 filters packets with an outer label of 100000 and an inner label of
1077 1024, and
1078 .in +.5i
1079 .nf
1080 \fBmpls && mpls 1024 && host 192.9.200.1\fR
1081 .fi
1082 .in -.5i
1083 filters packets to or from 192.9.200.1 with an inner label of 1024 and
1084 any outer label.
1085 .IP \fBpppoed\fP
1086 True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet
1087 type 0x8863).
1088 .IP \fBpppoes\fP
1089 True if the packet is a PPP-over-Ethernet Session packet (Ethernet
1090 type 0x8864).
1091 Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR
1092 changes the decoding offsets for the remainder of \fIexpression\fR on
1093 the assumption that the packet is a PPPoE session packet.
1094 .IP
1095 For example:
1096 .in +.5i
1097 .nf
1098 \fBpppoes && ip\fR
1099 .fi
1100 .in -.5i
1101 filters IPv4 protocols encapsulated in PPPoE.
1102 .IP  "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
1103 Abbreviations for:
1104 .in +.5i
1105 .nf
1106 \fBip proto \fIp\fR\fB or ip6 proto \fIp\fR
1107 .fi
1108 .in -.5i
1109 where \fIp\fR is one of the above protocols.
1110 .IP "\fBiso proto \fIprotocol\fR"
1111 True if the packet is an OSI packet of protocol type \fIprotocol\fP.
1112 \fIProtocol\fP can be a number or one of the names
1113 \fBclnp\fP, \fBesis\fP, or \fBisis\fP.
1114 .IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR"
1115 Abbreviations for:
1116 .in +.5i
1117 .nf
1118 \fBiso proto \fIp\fR
1119 .fi
1120 .in -.5i
1121 where \fIp\fR is one of the above protocols.
1122 .IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR"
1123 Abbreviations for IS-IS PDU types.
1124 .IP "\fBvpi\fP \fIn\fR
1125 True if the packet is an ATM packet, for SunATM on Solaris, with a
1126 virtual path identifier of
1127 .IR n .
1128 .IP "\fBvci\fP \fIn\fR
1129 True if the packet is an ATM packet, for SunATM on Solaris, with a
1130 virtual channel identifier of
1131 .IR n .
1132 .IP \fBlane\fP
1133 True if the packet is an ATM packet, for SunATM on Solaris, and is
1134 an ATM LANE packet.
1135 Note that the first \fBlane\fR keyword encountered in \fIexpression\fR
1136 changes the tests done in the remainder of \fIexpression\fR
1137 on the assumption that the packet is either a LANE emulated Ethernet
1138 packet or a LANE LE Control packet.  If \fBlane\fR isn't specified, the
1139 tests are done under the assumption that the packet is an
1140 LLC-encapsulated packet.
1141 .IP \fBllc\fP
1142 True if the packet is an ATM packet, for SunATM on Solaris, and is
1143 an LLC-encapsulated packet.
1144 .IP \fBoamf4s\fP
1145 True if the packet is an ATM packet, for SunATM on Solaris, and is
1146 a segment OAM F4 flow cell (VPI=0 & VCI=3).
1147 .IP \fBoamf4e\fP
1148 True if the packet is an ATM packet, for SunATM on Solaris, and is
1149 an end-to-end OAM F4 flow cell (VPI=0 & VCI=4).
1150 .IP \fBoamf4\fP
1151 True if the packet is an ATM packet, for SunATM on Solaris, and is
1152 a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
1153 .IP \fBoam\fP
1154 True if the packet is an ATM packet, for SunATM on Solaris, and is
1155 a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
1156 .IP \fBmetac\fP
1157 True if the packet is an ATM packet, for SunATM on Solaris, and is
1158 on a meta signaling circuit (VPI=0 & VCI=1).
1159 .IP \fBbcc\fP
1160 True if the packet is an ATM packet, for SunATM on Solaris, and is
1161 on a broadcast signaling circuit (VPI=0 & VCI=2).
1162 .IP \fBsc\fP
1163 True if the packet is an ATM packet, for SunATM on Solaris, and is
1164 on a signaling circuit (VPI=0 & VCI=5).
1165 .IP \fBilmic\fP
1166 True if the packet is an ATM packet, for SunATM on Solaris, and is
1167 on an ILMI circuit (VPI=0 & VCI=16).
1168 .IP \fBconnectmsg\fP
1169 True if the packet is an ATM packet, for SunATM on Solaris, and is
1170 on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1171 Connect Ack, Release, or Release Done message.
1172 .IP \fBmetaconnect\fP
1173 True if the packet is an ATM packet, for SunATM on Solaris, and is
1174 on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1175 Release, or Release Done message.
1176 .IP  "\fIexpr relop expr\fR"
1177 True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =,
1178 !=, and \fIexpr\fR is an arithmetic expression composed of integer
1179 constants (expressed in standard C syntax), the normal binary operators
1180 [+, -, *, /, &, |, <<, >>], a length operator, and special packet data
1181 accessors.  Note that all comparisons are unsigned, so that, for example,
1182 0x80000000 and 0xffffffff are > 0.
1183 To access
1184 data inside the packet, use the following syntax:
1185 .in +.5i
1186 .nf
1187 \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
1188 .fi
1189 .in -.5i
1190 \fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link,
1191 ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and
1192 indicates the protocol layer for the index operation.
1193 (\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the
1194 link layer. \fBradio\fR refers to the "radio header" added to some
1195 802.11 captures.)
1196 Note that \fItcp, udp\fR and other upper-layer protocol types only
1197 apply to IPv4, not IPv6 (this will be fixed in the future).
1198 The byte offset, relative to the indicated protocol layer, is
1199 given by \fIexpr\fR.
1200 \fISize\fR is optional and indicates the number of bytes in the
1201 field of interest; it can be either one, two, or four, and defaults to one.
1202 The length operator, indicated by the keyword \fBlen\fP, gives the
1203 length of the packet.
1204
1205 For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
1206 The expression `\fBip[0] & 0xf != 5\fP'
1207 catches all IPv4 packets with options.
1208 The expression
1209 `\fBip[6:2] & 0x1fff = 0\fP'
1210 catches only unfragmented IPv4 datagrams and frag zero of fragmented
1211 IPv4 datagrams.
1212 This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
1213 index operations.
1214 For instance, \fBtcp[0]\fP always means the first
1215 byte of the TCP \fIheader\fP, and never means the first byte of an
1216 intervening fragment.
1217
1218 Some offsets and field values may be expressed as names rather than
1219 as numeric values.
1220 The following protocol header field offsets are
1221 available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP
1222 code field), and \fBtcpflags\fP (TCP flags field).
1223
1224 The following ICMP type field values are available: \fBicmp-echoreply\fP,
1225 \fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
1226 \fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
1227 \fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
1228 \fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
1229 \fBicmp-maskreq\fP, \fBicmp-maskreply\fP.
1230
1231 The following TCP flags field values are available: \fBtcp-fin\fP,
1232 \fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
1233 \fBtcp-ack\fP, \fBtcp-urg\fP.
1234 .LP
1235 Primitives may be combined using:
1236 .IP
1237 A parenthesized group of primitives and operators
1238 (parentheses are special to the Shell and must be escaped).
1239 .IP
1240 Negation (`\fB!\fP' or `\fBnot\fP').
1241 .IP
1242 Concatenation (`\fB&&\fP' or `\fBand\fP').
1243 .IP
1244 Alternation (`\fB||\fP' or `\fBor\fP').
1245 .LP
1246 Negation has highest precedence.
1247 Alternation and concatenation have equal precedence and associate
1248 left to right.
1249 Note that explicit \fBand\fR tokens, not juxtaposition,
1250 are now required for concatenation.
1251 .LP
1252 If an identifier is given without a keyword, the most recent keyword
1253 is assumed.
1254 For example,
1255 .in +.5i
1256 .nf
1257 \fBnot host vs and ace\fR
1258 .fi
1259 .in -.5i
1260 is short for
1261 .in +.5i
1262 .nf
1263 \fBnot host vs and host ace\fR
1264 .fi
1265 .in -.5i
1266 which should not be confused with
1267 .in +.5i
1268 .nf
1269 \fBnot ( host vs or ace )\fR
1270 .fi
1271 .in -.5i
1272 .LP
1273 Expression arguments can be passed to \fItcpdump\fP as either a single
1274 argument or as multiple arguments, whichever is more convenient.
1275 Generally, if the expression contains Shell metacharacters, it is
1276 easier to pass it as a single, quoted argument.
1277 Multiple arguments are concatenated with spaces before being parsed.
1278 .SH EXAMPLES
1279 .LP
1280 To print all packets arriving at or departing from \fIsundown\fP:
1281 .RS
1282 .nf
1283 \fBtcpdump host sundown\fP
1284 .fi
1285 .RE
1286 .LP
1287 To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
1288 .RS
1289 .nf
1290 \fBtcpdump host helios and \\( hot or ace \\)\fP
1291 .fi
1292 .RE
1293 .LP
1294 To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
1295 .RS
1296 .nf
1297 \fBtcpdump ip host ace and not helios\fP
1298 .fi
1299 .RE
1300 .LP
1301 To print all traffic between local hosts and hosts at Berkeley:
1302 .RS
1303 .nf
1304 .B
1305 tcpdump net ucb-ether
1306 .fi
1307 .RE
1308 .LP
1309 To print all ftp traffic through internet gateway \fIsnup\fP:
1310 (note that the expression is quoted to prevent the shell from
1311 (mis-)interpreting the parentheses):
1312 .RS
1313 .nf
1314 .B
1315 tcpdump 'gateway snup and (port ftp or ftp-data)'
1316 .fi
1317 .RE
1318 .LP
1319 To print traffic neither sourced from nor destined for local hosts
1320 (if you gateway to one other net, this stuff should never make it
1321 onto your local net).
1322 .RS
1323 .nf
1324 .B
1325 tcpdump ip and not net \fIlocalnet\fP
1326 .fi
1327 .RE
1328 .LP
1329 To print the start and end packets (the SYN and FIN packets) of each
1330 TCP conversation that involves a non-local host.
1331 .RS
1332 .nf
1333 .B
1334 tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
1335 .fi
1336 .RE
1337 .LP
1338 To print all IPv4 HTTP packets to and from port 80, i.e. print only
1339 packets that contain data, not, for example, SYN and FIN packets and
1340 ACK-only packets.  (IPv6 is left as an exercise for the reader.)
1341 .RS
1342 .nf
1343 .B
1344 tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
1345 .fi
1346 .RE
1347 .LP
1348 To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
1349 .RS
1350 .nf
1351 .B
1352 tcpdump 'gateway snup and ip[2:2] > 576'
1353 .fi
1354 .RE
1355 .LP
1356 To print IP broadcast or multicast packets that were
1357 .I not
1358 sent via Ethernet broadcast or multicast:
1359 .RS
1360 .nf
1361 .B
1362 tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
1363 .fi
1364 .RE
1365 .LP
1366 To print all ICMP packets that are not echo requests/replies (i.e., not
1367 ping packets):
1368 .RS
1369 .nf
1370 .B
1371 tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
1372 .fi
1373 .RE
1374 .SH OUTPUT FORMAT
1375 .LP
1376 The output of \fItcpdump\fP is protocol dependent.
1377 The following
1378 gives a brief description and examples of most of the formats.
1379 .de HD
1380 .sp 1.5
1381 .B
1382 ..
1383 .HD
1384 Link Level Headers
1385 .LP
1386 If the '-e' option is given, the link level header is printed out.
1387 On Ethernets, the source and destination addresses, protocol,
1388 and packet length are printed.
1389 .LP
1390 On FDDI networks, the  '-e' option causes \fItcpdump\fP to print
1391 the `frame control' field,  the source and destination addresses,
1392 and the packet length.
1393 (The `frame control' field governs the
1394 interpretation of the rest of the packet.
1395 Normal packets (such
1396 as those containing IP datagrams) are `async' packets, with a priority
1397 value between 0 and 7; for example, `\fBasync4\fR'.
1398 Such packets
1399 are assumed to contain an 802.2 Logical Link Control (LLC) packet;
1400 the LLC header is printed if it is \fInot\fR an ISO datagram or a
1401 so-called SNAP packet.
1402 .LP
1403 On Token Ring networks, the '-e' option causes \fItcpdump\fP to print
1404 the `access control' and `frame control' fields, the source and
1405 destination addresses, and the packet length.
1406 As on FDDI networks,
1407 packets are assumed to contain an LLC packet.
1408 Regardless of whether
1409 the '-e' option is specified or not, the source routing information is
1410 printed for source-routed packets.
1411 .LP
1412 On 802.11 networks, the '-e' option causes \fItcpdump\fP to print
1413 the `frame control' fields, all of the addresses in the 802.11 header,
1414 and the packet length.
1415 As on FDDI networks,
1416 packets are assumed to contain an LLC packet.
1417 .LP
1418 \fI(N.B.: The following description assumes familiarity with
1419 the SLIP compression algorithm described in RFC-1144.)\fP
1420 .LP
1421 On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
1422 packet type, and compression information are printed out.
1423 The packet type is printed first.
1424 The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
1425 No further link information is printed for \fIip\fR packets.
1426 For TCP packets, the connection identifier is printed following the type.
1427 If the packet is compressed, its encoded header is printed out.
1428 The special cases are printed out as
1429 \fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
1430 the sequence number (or sequence number and ack) has changed.
1431 If it is not a special case,
1432 zero or more changes are printed.
1433 A change is indicated by U (urgent pointer), W (window), A (ack),
1434 S (sequence number), and I (packet ID), followed by a delta (+n or -n),
1435 or a new value (=n).
1436 Finally, the amount of data in the packet and compressed header length
1437 are printed.
1438 .LP
1439 For example, the following line shows an outbound compressed TCP packet,
1440 with an implicit connection identifier; the ack has changed by 6,
1441 the sequence number by 49, and the packet ID by 6; there are 3 bytes of
1442 data and 6 bytes of compressed header:
1443 .RS
1444 .nf
1445 \fBO ctcp * A+6 S+49 I+6 3 (6)\fP
1446 .fi
1447 .RE
1448 .HD
1449 ARP/RARP Packets
1450 .LP
1451 Arp/rarp output shows the type of request and its arguments.
1452 The
1453 format is intended to be self explanatory.
1454 Here is a short sample taken from the start of an `rlogin' from
1455 host \fIrtsg\fP to host \fIcsam\fP:
1456 .RS
1457 .nf
1458 .sp .5
1459 \f(CWarp who-has csam tell rtsg
1460 arp reply csam is-at CSAM\fR
1461 .sp .5
1462 .fi
1463 .RE
1464 The first line says that rtsg sent an arp packet asking
1465 for the Ethernet address of internet host csam.
1466 Csam
1467 replies with its Ethernet address (in this example, Ethernet addresses
1468 are in caps and internet addresses in lower case).
1469 .LP
1470 This would look less redundant if we had done \fItcpdump \-n\fP:
1471 .RS
1472 .nf
1473 .sp .5
1474 \f(CWarp who-has 128.3.254.6 tell 128.3.254.68
1475 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
1476 .fi
1477 .RE
1478 .LP
1479 If we had done \fItcpdump \-e\fP, the fact that the first packet is
1480 broadcast and the second is point-to-point would be visible:
1481 .RS
1482 .nf
1483 .sp .5
1484 \f(CWRTSG Broadcast 0806  64: arp who-has csam tell rtsg
1485 CSAM RTSG 0806  64: arp reply csam is-at CSAM\fR
1486 .sp .5
1487 .fi
1488 .RE
1489 For the first packet this says the Ethernet source address is RTSG, the
1490 destination is the Ethernet broadcast address, the type field
1491 contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
1492 .HD
1493 TCP Packets
1494 .LP
1495 \fI(N.B.:The following description assumes familiarity with
1496 the TCP protocol described in RFC-793.
1497 If you are not familiar
1498 with the protocol, neither this description nor \fItcpdump\fP will
1499 be of much use to you.)\fP
1500 .LP
1501 The general format of a tcp protocol line is:
1502 .RS
1503 .nf
1504 .sp .5
1505 \fIsrc > dst: flags data-seqno ack window urgent options\fP
1506 .sp .5
1507 .fi
1508 .RE
1509 \fISrc\fP and \fIdst\fP are the source and destination IP
1510 addresses and ports.
1511 \fIFlags\fP are some combination of S (SYN),
1512 F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single
1513 `.' (no flags).
1514 \fIData-seqno\fP describes the portion of sequence space covered
1515 by the data in this packet (see example below).
1516 \fIAck\fP is sequence number of the next data expected the other
1517 direction on this connection.
1518 \fIWindow\fP is the number of bytes of receive buffer space available
1519 the other direction on this connection.
1520 \fIUrg\fP indicates there is `urgent' data in the packet.
1521 \fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
1522 .LP
1523 \fISrc, dst\fP and \fIflags\fP are always present.
1524 The other fields
1525 depend on the contents of the packet's tcp protocol header and
1526 are output only if appropriate.
1527 .LP
1528 Here is the opening portion of an rlogin from host \fIrtsg\fP to
1529 host \fIcsam\fP.
1530 .RS
1531 .nf
1532 .sp .5
1533 \s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
1534 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
1535 rtsg.1023 > csam.login: . ack 1 win 4096
1536 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
1537 csam.login > rtsg.1023: . ack 2 win 4096
1538 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
1539 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
1540 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
1541 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
1542 .sp .5
1543 .fi
1544 .RE
1545 The first line says that tcp port 1023 on rtsg sent a packet
1546 to port \fIlogin\fP
1547 on csam.
1548 The \fBS\fP indicates that the \fISYN\fP flag was set.
1549 The packet sequence number was 768512 and it contained no data.
1550 (The notation is `first:last(nbytes)' which means `sequence
1551 numbers \fIfirst\fP
1552 up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
1553 There was no piggy-backed ack, the available receive window was 4096
1554 bytes and there was a max-segment-size option requesting an mss of
1555 1024 bytes.
1556 .LP
1557 Csam replies with a similar packet except it includes a piggy-backed
1558 ack for rtsg's SYN.
1559 Rtsg then acks csam's SYN.
1560 The `.' means no
1561 flags were set.
1562 The packet contained no data so there is no data sequence number.
1563 Note that the ack sequence
1564 number is a small integer (1).
1565 The first time \fItcpdump\fP sees a
1566 tcp `conversation', it prints the sequence number from the packet.
1567 On subsequent packets of the conversation, the difference between
1568 the current packet's sequence number and this initial sequence number
1569 is printed.
1570 This means that sequence numbers after the
1571 first can be interpreted
1572 as relative byte positions in the conversation's data stream (with the
1573 first data byte each direction being `1').
1574 `-S' will override this
1575 feature, causing the original sequence numbers to be output.
1576 .LP
1577 On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
1578 in the rtsg \(-> csam side of the conversation).
1579 The PUSH flag is set in the packet.
1580 On the 7th line, csam says it's received data sent by rtsg up to
1581 but not including byte 21.
1582 Most of this data is apparently sitting in the
1583 socket buffer since csam's receive window has gotten 19 bytes smaller.
1584 Csam also sends one byte of data to rtsg in this packet.
1585 On the 8th and 9th lines,
1586 csam sends two bytes of urgent, pushed data to rtsg.
1587 .LP
1588 If the snapshot was small enough that \fItcpdump\fP didn't capture
1589 the full TCP header, it interprets as much of the header as it can
1590 and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
1591 be interpreted.
1592 If the header contains a bogus option (one with a length
1593 that's either too small or beyond the end of the header), \fItcpdump\fP
1594 reports it as ``[\fIbad opt\fP]'' and does not interpret any further
1595 options (since it's impossible to tell where they start).
1596 If the header
1597 length indicates options are present but the IP datagram length is not
1598 long enough for the options to actually be there, \fItcpdump\fP reports
1599 it as ``[\fIbad hdr length\fP]''.
1600 .HD
1601 .B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
1602 .PP
1603 There are 8 bits in the control bits section of the TCP header:
1604 .IP
1605 .I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
1606 .PP
1607 Let's assume that we want to watch packets used in establishing
1608 a TCP connection.
1609 Recall that TCP uses a 3-way handshake protocol
1610 when it initializes a new connection; the connection sequence with
1611 regard to the TCP control bits is
1612 .PP
1613 .RS
1614 1) Caller sends SYN
1615 .RE
1616 .RS
1617 2) Recipient responds with SYN, ACK
1618 .RE
1619 .RS
1620 3) Caller sends ACK
1621 .RE
1622 .PP
1623 Now we're interested in capturing packets that have only the
1624 SYN bit set (Step 1).
1625 Note that we don't want packets from step 2
1626 (SYN-ACK), just a plain initial SYN.
1627 What we need is a correct filter
1628 expression for \fItcpdump\fP.
1629 .PP
1630 Recall the structure of a TCP header without options:
1631 .PP
1632 .nf
1633  0                            15                              31
1634 -----------------------------------------------------------------
1635 |          source port          |       destination port        |
1636 -----------------------------------------------------------------
1637 |                        sequence number                        |
1638 -----------------------------------------------------------------
1639 |                     acknowledgment number                     |
1640 -----------------------------------------------------------------
1641 |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
1642 -----------------------------------------------------------------
1643 |         TCP checksum          |       urgent pointer          |
1644 -----------------------------------------------------------------
1645 .fi
1646 .PP
1647 A TCP header usually holds 20 octets of data, unless options are
1648 present.
1649 The first line of the graph contains octets 0 - 3, the
1650 second line shows octets 4 - 7 etc.
1651 .PP
1652 Starting to count with 0, the relevant TCP control bits are contained
1653 in octet 13:
1654 .PP
1655 .nf
1656  0             7|             15|             23|             31
1657 ----------------|---------------|---------------|----------------
1658 |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
1659 ----------------|---------------|---------------|----------------
1660 |               |  13th octet   |               |               |
1661 .fi
1662 .PP
1663 Let's have a closer look at octet no. 13:
1664 .PP
1665 .nf
1666                 |               |
1667                 |---------------|
1668                 |C|E|U|A|P|R|S|F|
1669                 |---------------|
1670                 |7   5   3     0|
1671 .fi
1672 .PP
1673 These are the TCP control bits we are interested
1674 in.
1675 We have numbered the bits in this octet from 0 to 7, right to
1676 left, so the PSH bit is bit number 3, while the URG bit is number 5.
1677 .PP
1678 Recall that we want to capture packets with only SYN set.
1679 Let's see what happens to octet 13 if a TCP datagram arrives
1680 with the SYN bit set in its header:
1681 .PP
1682 .nf
1683                 |C|E|U|A|P|R|S|F|
1684                 |---------------|
1685                 |0 0 0 0 0 0 1 0|
1686                 |---------------|
1687                 |7 6 5 4 3 2 1 0|
1688 .fi
1689 .PP
1690 Looking at the
1691 control bits section we see that only bit number 1 (SYN) is set.
1692 .PP
1693 Assuming that octet number 13 is an 8-bit unsigned integer in
1694 network byte order, the binary value of this octet is
1695 .IP
1696 00000010
1697 .PP
1698 and its decimal representation is
1699 .PP
1700 .nf
1701    7     6     5     4     3     2     1     0
1702 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2
1703 .fi
1704 .PP
1705 We're almost done, because now we know that if only SYN is set,
1706 the value of the 13th octet in the TCP header, when interpreted
1707 as a 8-bit unsigned integer in network byte order, must be exactly 2.
1708 .PP
1709 This relationship can be expressed as
1710 .RS
1711 .B
1712 tcp[13] == 2
1713 .RE
1714 .PP
1715 We can use this expression as the filter for \fItcpdump\fP in order
1716 to watch packets which have only SYN set:
1717 .RS
1718 .B
1719 tcpdump -i xl0 tcp[13] == 2
1720 .RE
1721 .PP
1722 The expression says "let the 13th octet of a TCP datagram have
1723 the decimal value 2", which is exactly what we want.
1724 .PP
1725 Now, let's assume that we need to capture SYN packets, but we
1726 don't care if ACK or any other TCP control bit is set at the
1727 same time.
1728 Let's see what happens to octet 13 when a TCP datagram
1729 with SYN-ACK set arrives:
1730 .PP
1731 .nf
1732      |C|E|U|A|P|R|S|F|
1733      |---------------|
1734      |0 0 0 1 0 0 1 0|
1735      |---------------|
1736      |7 6 5 4 3 2 1 0|
1737 .fi
1738 .PP
1739 Now bits 1 and 4 are set in the 13th octet.
1740 The binary value of
1741 octet 13 is
1742 .IP
1743      00010010
1744 .PP
1745 which translates to decimal
1746 .PP
1747 .nf
1748    7     6     5     4     3     2     1     0
1749 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18
1750 .fi
1751 .PP
1752 Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter
1753 expression, because that would select only those packets that have
1754 SYN-ACK set, but not those with only SYN set.
1755 Remember that we don't care
1756 if ACK or any other control bit is set as long as SYN is set.
1757 .PP
1758 In order to achieve our goal, we need to logically AND the
1759 binary value of octet 13 with some other value to preserve
1760 the SYN bit.
1761 We know that we want SYN to be set in any case,
1762 so we'll logically AND the value in the 13th octet with
1763 the binary value of a SYN:
1764 .PP
1765 .nf
1766
1767           00010010 SYN-ACK              00000010 SYN
1768      AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
1769           --------                      --------
1770      =    00000010                 =    00000010
1771 .fi
1772 .PP
1773 We see that this AND operation delivers the same result
1774 regardless whether ACK or another TCP control bit is set.
1775 The decimal representation of the AND value as well as
1776 the result of this operation is 2 (binary 00000010),
1777 so we know that for packets with SYN set the following
1778 relation must hold true:
1779 .IP
1780 ( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
1781 .PP
1782 This points us to the \fItcpdump\fP filter expression
1783 .RS
1784 .B
1785      tcpdump -i xl0 'tcp[13] & 2 == 2'
1786 .RE
1787 .PP
1788 Note that you should use single quotes or a backslash
1789 in the expression to hide the AND ('&') special character
1790 from the shell.
1791 .HD
1792 .B
1793 UDP Packets
1794 .LP
1795 UDP format is illustrated by this rwho packet:
1796 .RS
1797 .nf
1798 .sp .5
1799 \f(CWactinide.who > broadcast.who: udp 84\fP
1800 .sp .5
1801 .fi
1802 .RE
1803 This says that port \fIwho\fP on host \fIactinide\fP sent a udp
1804 datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
1805 broadcast address.
1806 The packet contained 84 bytes of user data.
1807 .LP
1808 Some UDP services are recognized (from the source or destination
1809 port number) and the higher level protocol information printed.
1810 In particular, Domain Name service requests (RFC-1034/1035) and Sun
1811 RPC calls (RFC-1050) to NFS.
1812 .HD
1813 UDP Name Server Requests
1814 .LP
1815 \fI(N.B.:The following description assumes familiarity with
1816 the Domain Service protocol described in RFC-1035.
1817 If you are not familiar
1818 with the protocol, the following description will appear to be written
1819 in greek.)\fP
1820 .LP
1821 Name server requests are formatted as
1822 .RS
1823 .nf
1824 .sp .5
1825 \fIsrc > dst: id op? flags qtype qclass name (len)\fP
1826 .sp .5
1827 \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
1828 .sp .5
1829 .fi
1830 .RE
1831 Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
1832 address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
1833 The query id was `3'.
1834 The `+' indicates the \fIrecursion desired\fP flag
1835 was set.
1836 The query length was 37 bytes, not including the UDP and
1837 IP protocol headers.
1838 The query operation was the normal one, \fIQuery\fP,
1839 so the op field was omitted.
1840 If the op had been anything else, it would
1841 have been printed between the `3' and the `+'.
1842 Similarly, the qclass was the normal one,
1843 \fIC_IN\fP, and omitted.
1844 Any other qclass would have been printed
1845 immediately after the `A'.
1846 .LP
1847 A few anomalies are checked and may result in extra fields enclosed in
1848 square brackets:  If a query contains an answer, authority records or
1849 additional records section,
1850 .IR ancount ,
1851 .IR nscount ,
1852 or
1853 .I arcount
1854 are printed as `[\fIn\fPa]', `[\fIn\fPn]' or  `[\fIn\fPau]' where \fIn\fP
1855 is the appropriate count.
1856 If any of the response bits are set (AA, RA or rcode) or any of the
1857 `must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
1858 is printed, where \fIx\fP is the hex value of header bytes two and three.
1859 .HD
1860 UDP Name Server Responses
1861 .LP
1862 Name server responses are formatted as
1863 .RS
1864 .nf
1865 .sp .5
1866 \fIsrc > dst:  id op rcode flags a/n/au type class data (len)\fP
1867 .sp .5
1868 \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
1869 helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
1870 .sp .5
1871 .fi
1872 .RE
1873 In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
1874 with 3 answer records, 3 name server records and 7 additional records.
1875 The first answer record is type A (address) and its data is internet
1876 address 128.32.137.3.
1877 The total size of the response was 273 bytes,
1878 excluding UDP and IP headers.
1879 The op (Query) and response code
1880 (NoError) were omitted, as was the class (C_IN) of the A record.
1881 .LP
1882 In the second example, \fIhelios\fP responds to query 2 with a
1883 response code of non-existent domain (NXDomain) with no answers,
1884 one name server and no authority records.
1885 The `*' indicates that
1886 the \fIauthoritative answer\fP bit was set.
1887 Since there were no
1888 answers, no type, class or data were printed.
1889 .LP
1890 Other flag characters that might appear are `\-' (recursion available,
1891 RA, \fInot\fP set) and `|' (truncated message, TC, set).
1892 If the
1893 `question' section doesn't contain exactly one entry, `[\fIn\fPq]'
1894 is printed.
1895 .LP
1896 Note that name server requests and responses tend to be large and the
1897 default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
1898 to print.
1899 Use the \fB\-s\fP flag to increase the snaplen if you
1900 need to seriously investigate name server traffic.
1901 `\fB\-s 128\fP'
1902 has worked well for me.
1903
1904 .HD
1905 SMB/CIFS decoding
1906 .LP
1907 \fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
1908 on UDP/137, UDP/138 and TCP/139.
1909 Some primitive decoding of IPX and
1910 NetBEUI SMB data is also done.
1911
1912 By default a fairly minimal decode is done, with a much more detailed
1913 decode done if -v is used.
1914 Be warned that with -v a single SMB packet
1915 may take up a page or more, so only use -v if you really want all the
1916 gory details.
1917
1918 For information on SMB packet formats and what all te fields mean see
1919 www.cifs.org or the pub/samba/specs/ directory on your favorite
1920 samba.org mirror site.
1921 The SMB patches were written by Andrew Tridgell
1922 (tridge@samba.org).
1923
1924 .HD
1925 NFS Requests and Replies
1926 .LP
1927 Sun NFS (Network File System) requests and replies are printed as:
1928 .RS
1929 .nf
1930 .sp .5
1931 \fIsrc.xid > dst.nfs: len op args\fP
1932 \fIsrc.nfs > dst.xid: reply stat len op results\fP
1933 .sp .5
1934 \f(CW
1935 sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
1936 wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
1937 sushi.201b > wrl.nfs:
1938         144 lookup fh 9,74/4096.6878 "xcolors"
1939 wrl.nfs > sushi.201b:
1940         reply ok 128 lookup fh 9,74/4134.3150
1941 \fR
1942 .sp .5
1943 .fi
1944 .RE
1945 In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
1946 to \fIwrl\fP (note that the number following the src host is a
1947 transaction id, \fInot\fP the source port).
1948 The request was 112 bytes,
1949 excluding the UDP and IP headers.
1950 The operation was a \fIreadlink\fP
1951 (read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119.
1952 (If one is lucky, as in this case, the file handle can be interpreted
1953 as a major,minor device number pair, followed by the inode number and
1954 generation number.)
1955 \fIWrl\fP replies `ok' with the contents of the link.
1956 .LP
1957 In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
1958 `\fIxcolors\fP' in directory file 9,74/4096.6878.
1959 Note that the data printed
1960 depends on the operation type.
1961 The format is intended to be self
1962 explanatory if read in conjunction with
1963 an NFS protocol spec.
1964 .LP
1965 If the \-v (verbose) flag is given, additional information is printed.
1966 For example:
1967 .RS
1968 .nf
1969 .sp .5
1970 \f(CW
1971 sushi.1372a > wrl.nfs:
1972         148 read fh 21,11/12.195 8192 bytes @ 24576
1973 wrl.nfs > sushi.1372a:
1974         reply ok 1472 read REG 100664 ids 417/0 sz 29388
1975 \fP
1976 .sp .5
1977 .fi
1978 .RE
1979 (\-v also prints the IP header TTL, ID, length, and fragmentation fields,
1980 which have been omitted from this example.)  In the first line,
1981 \fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
1982 at byte offset 24576.
1983 \fIWrl\fP replies `ok'; the packet shown on the
1984 second line is the first fragment of the reply, and hence is only 1472
1985 bytes long (the other bytes will follow in subsequent fragments, but
1986 these fragments do not have NFS or even UDP headers and so might not be
1987 printed, depending on the filter expression used).
1988 Because the \-v flag
1989 is given, some of the file attributes (which are returned in addition
1990 to the file data) are printed: the file type (``REG'', for regular file),
1991 the file mode (in octal), the uid and gid, and the file size.
1992 .LP
1993 If the \-v flag is given more than once, even more details are printed.
1994 .LP
1995 Note that NFS requests are very large and much of the detail won't be printed
1996 unless \fIsnaplen\fP is increased.
1997 Try using `\fB\-s 192\fP' to watch
1998 NFS traffic.
1999 .LP
2000 NFS reply packets do not explicitly identify the RPC operation.
2001 Instead,
2002 \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2003 replies using the transaction ID.
2004 If a reply does not closely follow the
2005 corresponding request, it might not be parsable.
2006 .HD
2007 AFS Requests and Replies
2008 .LP
2009 Transarc AFS (Andrew File System) requests and replies are printed
2010 as:
2011 .HD
2012 .RS
2013 .nf
2014 .sp .5
2015 \fIsrc.sport > dst.dport: rx packet-type\fP
2016 \fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
2017 \fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
2018 .sp .5
2019 \f(CW
2020 elvis.7001 > pike.afsfs:
2021         rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
2022         new fid 536876964/1/1 ".newsrc"
2023 pike.afsfs > elvis.7001: rx data fs reply rename
2024 \fR
2025 .sp .5
2026 .fi
2027 .RE
2028 In the first line, host elvis sends a RX packet to pike.
2029 This was
2030 a RX data packet to the fs (fileserver) service, and is the start of
2031 an RPC call.
2032 The RPC call was a rename, with the old directory file id
2033 of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory
2034 file id of 536876964/1/1 and a new filename of `.newsrc'.
2035 The host pike
2036 responds with a RPC reply to the rename call (which was successful, because
2037 it was a data packet and not an abort packet).
2038 .LP
2039 In general, all AFS RPCs are decoded at least by RPC call name.
2040 Most
2041 AFS RPCs have at least some of the arguments decoded (generally only
2042 the `interesting' arguments, for some definition of interesting).
2043 .LP
2044 The format is intended to be self-describing, but it will probably
2045 not be useful to people who are not familiar with the workings of
2046 AFS and RX.
2047 .LP
2048 If the -v (verbose) flag is given twice, acknowledgement packets and
2049 additional header information is printed, such as the the RX call ID,
2050 call number, sequence number, serial number, and the RX packet flags.
2051 .LP
2052 If the -v flag is given twice, additional information is printed,
2053 such as the the RX call ID, serial number, and the RX packet flags.
2054 The MTU negotiation information is also printed from RX ack packets.
2055 .LP
2056 If the -v flag is given three times, the security index and service id
2057 are printed.
2058 .LP
2059 Error codes are printed for abort packets, with the exception of Ubik
2060 beacon packets (because abort packets are used to signify a yes vote
2061 for the Ubik protocol).
2062 .LP
2063 Note that AFS requests are very large and many of the arguments won't
2064 be printed unless \fIsnaplen\fP is increased.
2065 Try using `\fB-s 256\fP'
2066 to watch AFS traffic.
2067 .LP
2068 AFS reply packets do not explicitly identify the RPC operation.
2069 Instead,
2070 \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2071 replies using the call number and service ID.
2072 If a reply does not closely
2073 follow the
2074 corresponding request, it might not be parsable.
2075
2076 .HD
2077 KIP AppleTalk (DDP in UDP)
2078 .LP
2079 AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
2080 and dumped as DDP packets (i.e., all the UDP header information is
2081 discarded).
2082 The file
2083 .I /etc/atalk.names
2084 is used to translate AppleTalk net and node numbers to names.
2085 Lines in this file have the form
2086 .RS
2087 .nf
2088 .sp .5
2089 \fInumber       name\fP
2090
2091 \f(CW1.254              ether
2092 16.1            icsd-net
2093 1.254.110       ace\fR
2094 .sp .5
2095 .fi
2096 .RE
2097 The first two lines give the names of AppleTalk networks.
2098 The third
2099 line gives the name of a particular host (a host is distinguished
2100 from a net by the 3rd octet in the number \-
2101 a net number \fImust\fP have two octets and a host number \fImust\fP
2102 have three octets.)  The number and name should be separated by
2103 whitespace (blanks or tabs).
2104 The
2105 .I /etc/atalk.names
2106 file may contain blank lines or comment lines (lines starting with
2107 a `#').
2108 .LP
2109 AppleTalk addresses are printed in the form
2110 .RS
2111 .nf
2112 .sp .5
2113 \fInet.host.port\fP
2114
2115 \f(CW144.1.209.2 > icsd-net.112.220
2116 office.2 > icsd-net.112.220
2117 jssmag.149.235 > icsd-net.2\fR
2118 .sp .5
2119 .fi
2120 .RE
2121 (If the
2122 .I /etc/atalk.names
2123 doesn't exist or doesn't contain an entry for some AppleTalk
2124 host/net number, addresses are printed in numeric form.)
2125 In the first example, NBP (DDP port 2) on net 144.1 node 209
2126 is sending to whatever is listening on port 220 of net icsd node 112.
2127 The second line is the same except the full name of the source node
2128 is known (`office').
2129 The third line is a send from port 235 on
2130 net jssmag node 149 to broadcast on the icsd-net NBP port (note that
2131 the broadcast address (255) is indicated by a net name with no host
2132 number \- for this reason it's a good idea to keep node names and
2133 net names distinct in /etc/atalk.names).
2134 .LP
2135 NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
2136 packets have their contents interpreted.
2137 Other protocols just dump
2138 the protocol name (or number if no name is registered for the
2139 protocol) and packet size.
2140
2141 \fBNBP packets\fP are formatted like the following examples:
2142 .RS
2143 .nf
2144 .sp .5
2145 \s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
2146 jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
2147 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
2148 .sp .5
2149 .fi
2150 .RE
2151 The first line is a name lookup request for laserwriters sent by net icsd host
2152 112 and broadcast on net jssmag.
2153 The nbp id for the lookup is 190.
2154 The second line shows a reply for this request (note that it has the
2155 same id) from host jssmag.209 saying that it has a laserwriter
2156 resource named "RM1140" registered on port 250.
2157 The third line is
2158 another reply to the same request saying host techpit has laserwriter
2159 "techpit" registered on port 186.
2160
2161 \fBATP packet\fP formatting is demonstrated by the following example:
2162 .RS
2163 .nf
2164 .sp .5
2165 \s-2\f(CWjssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
2166 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
2167 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
2168 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
2169 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2170 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
2171 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2172 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
2173 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
2174 jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
2175 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2176 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2177 jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
2178 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
2179 .sp .5
2180 .fi
2181 .RE
2182 Jssmag.209 initiates transaction id 12266 with host helios by requesting
2183 up to 8 packets (the `<0-7>').
2184 The hex number at the end of the line
2185 is the value of the `userdata' field in the request.
2186 .LP
2187 Helios responds with 8 512-byte packets.
2188 The `:digit' following the
2189 transaction id gives the packet sequence number in the transaction
2190 and the number in parens is the amount of data in the packet,
2191 excluding the atp header.
2192 The `*' on packet 7 indicates that the
2193 EOM bit was set.
2194 .LP
2195 Jssmag.209 then requests that packets 3 & 5 be retransmitted.
2196 Helios
2197 resends them then jssmag.209 releases the transaction.
2198 Finally,
2199 jssmag.209 initiates the next request.
2200 The `*' on the request
2201 indicates that XO (`exactly once') was \fInot\fP set.
2202
2203 .HD
2204 IP Fragmentation
2205 .LP
2206 Fragmented Internet datagrams are printed as
2207 .RS
2208 .nf
2209 .sp .5
2210 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
2211 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
2212 .sp .5
2213 .fi
2214 .RE
2215 (The first form indicates there are more fragments.
2216 The second
2217 indicates this is the last fragment.)
2218 .LP
2219 \fIId\fP is the fragment id.
2220 \fISize\fP is the fragment
2221 size (in bytes) excluding the IP header.
2222 \fIOffset\fP is this
2223 fragment's offset (in bytes) in the original datagram.
2224 .LP
2225 The fragment information is output for each fragment.
2226 The first
2227 fragment contains the higher level protocol header and the frag
2228 info is printed after the protocol info.
2229 Fragments
2230 after the first contain no higher level protocol header and the
2231 frag info is printed after the source and destination addresses.
2232 For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
2233 over a CSNET connection that doesn't appear to handle 576 byte datagrams:
2234 .RS
2235 .nf
2236 .sp .5
2237 \s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
2238 arizona > rtsg: (frag 595a:204@328)
2239 rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
2240 .sp .5
2241 .fi
2242 .RE
2243 There are a couple of things to note here:  First, addresses in the
2244 2nd line don't include port numbers.
2245 This is because the TCP
2246 protocol information is all in the first fragment and we have no idea
2247 what the port or sequence numbers are when we print the later fragments.
2248 Second, the tcp sequence information in the first line is printed as if there
2249 were 308 bytes of user data when, in fact, there are 512 bytes (308 in
2250 the first frag and 204 in the second).
2251 If you are looking for holes
2252 in the sequence space or trying to match up acks
2253 with packets, this can fool you.
2254 .LP
2255 A packet with the IP \fIdon't fragment\fP flag is marked with a
2256 trailing \fB(DF)\fP.
2257 .HD
2258 Timestamps
2259 .LP
2260 By default, all output lines are preceded by a timestamp.
2261 The timestamp
2262 is the current clock time in the form
2263 .RS
2264 .nf
2265 \fIhh:mm:ss.frac\fP
2266 .fi
2267 .RE
2268 and is as accurate as the kernel's clock.
2269 The timestamp reflects the time the kernel first saw the packet.
2270 No attempt
2271 is made to account for the time lag between when the
2272 Ethernet interface removed the packet from the wire and when the kernel
2273 serviced the `new packet' interrupt.
2274 .SH "SEE ALSO"
2275 stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
2276 .SH AUTHORS
2277 The original authors are:
2278 .LP
2279 Van Jacobson,
2280 Craig Leres and
2281 Steven McCanne, all of the
2282 Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
2283 .LP
2284 It is currently being maintained by tcpdump.org.
2285 .LP
2286 The current version is available via http:
2287 .LP
2288 .RS
2289 .I http://www.tcpdump.org/
2290 .RE
2291 .LP
2292 The original distribution is available via anonymous ftp:
2293 .LP
2294 .RS
2295 .I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
2296 .RE
2297 .LP
2298 IPv6/IPsec support is added by WIDE/KAME project.
2299 This program uses Eric Young's SSLeay library, under specific configuration.
2300 .SH BUGS
2301 Please send problems, bugs, questions, desirable enhancements, etc. to:
2302 .LP
2303 .RS
2304 tcpdump-workers@tcpdump.org
2305 .RE
2306 .LP
2307 Please send source code contributions, etc. to:
2308 .LP
2309 .RS
2310 patches@tcpdump.org
2311 .RE
2312 .LP
2313 NIT doesn't let you watch your own outbound traffic, BPF will.
2314 We recommend that you use the latter.
2315 .LP
2316 On Linux systems with 2.0[.x] kernels:
2317 .IP
2318 packets on the loopback device will be seen twice;
2319 .IP
2320 packet filtering cannot be done in the kernel, so that all packets must
2321 be copied from the kernel in order to be filtered in user mode;
2322 .IP
2323 all of a packet, not just the part that's within the snapshot length,
2324 will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
2325 asked to copy only part of a packet to userland, will not report the
2326 true length of the packet; this would cause most IP packets to get an
2327 error from
2328 .BR tcpdump );
2329 .IP
2330 capturing on some PPP devices won't work correctly.
2331 .LP
2332 We recommend that you upgrade to a 2.2 or later kernel.
2333 .LP
2334 Some attempt should be made to reassemble IP fragments or, at least
2335 to compute the right length for the higher level protocol.
2336 .LP
2337 Name server inverse queries are not dumped correctly: the (empty)
2338 question section is printed rather than real query in the answer
2339 section.
2340 Some believe that inverse queries are themselves a bug and
2341 prefer to fix the program generating them rather than \fItcpdump\fP.
2342 .LP
2343 A packet trace that crosses a daylight savings time change will give
2344 skewed time stamps (the time change is ignored).
2345 .LP
2346 Filter expressions on fields other than those in Token Ring headers will
2347 not correctly handle source-routed Token Ring packets.
2348 .LP
2349 Filter expressions on fields other than those in 802.11 headers will not
2350 correctly handle 802.11 data packets with both To DS and From DS set.
2351 .LP
2352 .BR "ip6 proto"
2353 should chase header chain, but at this moment it does not.
2354 .BR "ip6 protochain"
2355 is supplied for this behavior.
2356 .LP
2357 Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
2358 does not work against IPv6 packets.
2359 It only looks at IPv4 packets.