1 .\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 1.167.2.10 2005/12/05 20:11:19 guy Exp $ (LBL)
3 .\" $NetBSD: tcpdump.8,v 1.9 2003/03/31 00:18:17 perry Exp $
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.
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.
25 .TH TCPDUMP 1 "18 April 2005"
27 tcpdump \- dump traffic on a network
32 .B \-AdDeflLnNOpqRStuUvxX
88 .I spi@ipaddr algo:secret,...
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
112 flag, which causes it to save the packet data to a file for later
113 analysis, and/or with the
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
123 will, if not run with the
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
129 command); if run with the
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.
136 finishes capturing packets, it will report counts of:
138 packets ``captured'' (this is the number of packets that
140 has received and processed);
142 packets ``received by filter'' (the meaning of this depends on the OS on
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
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
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
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
161 is running, if the OS reports that information to applications; if not,
162 it will be reported as 0).
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
171 in order to use it) and will continue capturing packets.
173 Reading packets from a network interface may require that you have
176 .B Under SunOS 3.x or 4.x with NIT or BPF:
177 You must have read access to
182 .B Under Solaris with DLPI:
183 You must have read/write access to the network pseudo device, e.g.
185 On at least some versions of Solaris, however, this is not sufficient to
188 to capture in promiscuous mode; on those versions of Solaris, you must
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.
196 .B Under HP-UX with DLPI:
199 must be installed setuid to root.
201 .B Under IRIX with snoop:
204 must be installed setuid to root.
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
218 .B Under ULTRIX and Digital UNIX/Tru64 UNIX:
219 Any user may capture network traffic with
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
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
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.
235 .B Under BSD (this includes Mac OS X):
236 You must have read access to
238 On BSDs with a devfs (this includes Mac OS X), this might involve more
239 than just having somebody with super-user access setting the ownership
240 or permissions on the BPF devices - it might involve configuring devfs
241 to set the ownership or permissions every time the system is booted,
242 if the system even supports that; if it doesn't support that, you might
243 have to find some other way to make that happen at boot time.
245 Reading a saved packet file doesn't require special privileges.
249 Print each packet (minus its link level header) in ASCII. Handy for
253 Exit after receiving \fIcount\fP packets.
256 Before writing a raw packet to a savefile, check whether the file is
257 currently larger than \fIfile_size\fP and, if so, close the current
258 savefile and open a new one. Savefiles after the first savefile will
259 have the name specified with the
261 flag, with a number after it, starting at 1 and continuing upward.
262 The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
263 not 1,048,576 bytes).
266 Dump the compiled packet-matching code in a human readable form to
267 standard output and stop.
270 Dump packet-matching code as a
275 Dump packet-matching code as decimal numbers (preceded with a count).
278 Print the list of the network interfaces available on the system and on
281 can capture packets. For each network interface, a number and an
282 interface name, possibly followed by a text description of the
283 interface, is printed. The interface name or the number can be supplied
286 flag to specify an interface on which to capture.
288 This can be useful on systems that don't have a command to list them
289 (e.g., Windows systems, or UNIX systems lacking
290 .BR "ifconfig \-a" );
291 the number can be useful on Windows 2000 and later systems, where the
292 interface name is a somewhat complex string.
296 flag will not be supported if
298 was built with an older version of
301 .B pcap_findalldevs()
305 Print the link-level header on each dump line.
308 Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that
309 are addressed to \fIaddr\fP and contain Security Parameter Index value
310 \fIspi\fP. This combination may be repeated with comma or newline seperation.
312 Note that setting the secret for IPv4 ESP packets is supported at this time.
319 \fBcast128-cbc\fP, or
321 The default is \fBdes-cbc\fP.
322 The ability to decrypt packets is only present if \fItcpdump\fP was compiled
323 with cryptography enabled.
325 \fIsecret\fP is the ASCII text for ESP secret key.
326 If preceeded by 0x, then a hex value will be read.
328 The option assumes RFC2406 ESP, not RFC1827 ESP.
329 The option is only for debugging purposes, and
330 the use of this option with a true `secret' key is discouraged.
331 By presenting IPsec secret key onto command line
332 you make it visible to others, via
336 In addition to the above syntax, the syntax \fIfile name\fP may be used
337 to have tcpdump read the provided file in. The file is opened upon
338 receiving the first ESP packet, so any special permissions that tcpdump
339 may have been given should already have been given up.
342 Print `foreign' IPv4 addresses numerically rather than symbolically
343 (this option is intended to get around serious brain damage in
344 Sun's NIS server \(em usually it hangs forever translating non-local
347 The test for `foreign' IPv4 addresses is done using the IPv4 address and
348 netmask of the interface on which capture is being done. If that
349 address or netmask are not available, available, either because the
350 interface on which capture is being done has no address or netmask or
351 because the capture is being done on the Linux "any" interface, which
352 can capture on more than one interface, this option will not work
356 Use \fIfile\fP as input for the filter expression.
357 An additional expression given on the command line is ignored.
360 Listen on \fIinterface\fP.
361 If unspecified, \fItcpdump\fP searches the system interface list for the
362 lowest numbered, configured up interface (excluding loopback).
363 Ties are broken by choosing the earliest match.
365 On Linux systems with 2.2 or later kernels, an
367 argument of ``any'' can be used to capture packets from all interfaces.
368 Note that captures on the ``any'' device will not be done in promiscuous
373 flag is supported, an interface number as printed by that flag can be
379 Make stdout line buffered.
380 Useful if you want to see the data
384 ``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
385 ``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
388 List the known data link types for the interface and exit.
391 Load SMI MIB module definitions from file \fImodule\fR.
393 can be used several times to load several MIB modules into \fItcpdump\fP.
396 Use \fIsecret\fP as a shared secret for validating the digests found in
397 TCP segments with the TCP-MD5 option (RFC 2385), if present.
400 Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
403 Don't print domain name qualification of host names.
405 if you give this flag then \fItcpdump\fP will print ``nic''
406 instead of ``nic.ddn.mil''.
409 Do not run the packet-matching code optimizer.
411 if you suspect a bug in the optimizer.
414 \fIDon't\fP put the interface
415 into promiscuous mode.
416 Note that the interface might be in promiscuous
417 mode for some other reason; hence, `-p' cannot be used as an abbreviation for
418 `ether host {local-hw-addr} or ether broadcast'.
421 Quick (quiet?) output.
422 Print less protocol information so output
426 Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
427 If specified, \fItcpdump\fP will not print replay prevention field.
428 Since there is no protocol version field in ESP/AH specification,
429 \fItcpdump\fP cannot deduce the version of ESP/AH protocol.
432 Read packets from \fIfile\fR (which was created with the
435 Standard input is used if \fIfile\fR is ``-''.
438 Print absolute, rather than relative, TCP sequence numbers.
441 Snarf \fIsnaplen\fP bytes of data from each packet rather than the
442 default of 68 (with SunOS's NIT, the minimum is actually 96).
443 68 bytes is adequate for IP, ICMP, TCP
444 and UDP but may truncate protocol information from name server and NFS
446 Packets truncated because of a limited snapshot
447 are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
448 is the name of the protocol level at which the truncation has occurred.
449 Note that taking larger snapshots both increases
450 the amount of time it takes to process packets and, effectively,
451 decreases the amount of packet buffering.
452 This may cause packets to be
454 You should limit \fIsnaplen\fP to the smallest number that will
455 capture the protocol information you're interested in.
457 \fIsnaplen\fP to 0 means use the required length to catch whole packets.
460 Force packets selected by "\fIexpression\fP" to be interpreted the
461 specified \fItype\fR.
462 Currently known types are
463 \fBaodv\fR (Ad-hoc On-demand Distance Vector protocol),
464 \fBcnfp\fR (Cisco NetFlow protocol),
465 \fBrpc\fR (Remote Procedure Call),
466 \fBrtp\fR (Real-Time Applications protocol),
467 \fBrtcp\fR (Real-Time Applications control protocol),
468 \fBsnmp\fR (Simple Network Management Protocol),
469 \fBtftp\fR (Trivial File Transfer Protocol),
470 \fBvat\fR (Visual Audio Tool),
472 \fBwb\fR (distributed White Board).
475 \fIDon't\fP print a timestamp on each dump line.
478 Print an unformatted timestamp on each dump line.
481 Print a delta (in micro-seconds) between current and previous line
485 Print a timestamp in default format proceeded by date on each dump line.
488 Print undecoded NFS handles.
491 Make output saved via the
493 option ``packet-buffered''; i.e., as each packet is saved, it will be
494 written to the output file, rather than being written only when the
499 flag will not be supported if
501 was built with an older version of
508 When parsing and printing, produce (slightly more) verbose output.
509 For example, the time to live,
510 identification, total length and options in an IP packet are printed.
511 Also enables additional packet integrity checks such as verifying the
512 IP and ICMP header checksum.
514 When writing to a file with the
516 option, report, every 10 seconds, the number of packets captured.
519 Even more verbose output.
520 For example, additional fields are
521 printed from NFS reply packets, and SMB packets are fully decoded.
524 Even more verbose output.
526 telnet \fBSB\fP ... \fBSE\fP options
530 Telnet options are printed in hex as well.
533 Write the raw packets to \fIfile\fR rather than parsing and printing
535 They can later be printed with the \-r option.
536 Standard output is used if \fIfile\fR is ``-''.
539 Used in conjunction with the
541 option, this will limit the number
542 of files created to the specified number, and begin overwriting files
543 from the beginning, thus creating a 'rotating' buffer.
544 In addition, it will name
545 the files with enough leading 0s to support the maximum number of
546 files, allowing them to sort correctly.
549 When parsing and printing,
550 in addition to printing the headers of each packet, print the data of
551 each packet (minus its link level header) in hex.
552 The smaller of the entire packet or
554 bytes will be printed. Note that this is the entire link-layer
555 packet, so for link layers that pad (e.g. Ethernet), the padding bytes
556 will also be printed when the higher layer packet is shorter than the
560 When parsing and printing,
561 in addition to printing the headers of each packet, print the data of
564 its link level header, in hex.
567 When parsing and printing,
568 in addition to printing the headers of each packet, print the data of
569 each packet (minus its link level header) in hex and ASCII.
570 This is very handy for analysing new protocols.
573 When parsing and printing,
574 in addition to printing the headers of each packet, print the data of
577 its link level header, in hex and ASCII.
580 Set the data link type to use while capturing packets to \fIdatalinktype\fP.
583 Drops privileges (if root) and changes user ID to
585 and the group ID to the primary group of
588 This behavior can also be enabled by default at compile time.
589 .IP "\fI expression\fP"
591 selects which packets will be dumped.
592 If no \fIexpression\fP
593 is given, all packets on the net will be dumped.
595 only packets for which \fIexpression\fP is `true' will be dumped.
597 The \fIexpression\fP consists of one or more
599 Primitives usually consist of an
601 (name or number) preceded by one or more qualifiers.
603 different kinds of qualifier:
605 qualifiers say what kind of thing the id name or number refers to.
612 E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'.
618 qualifiers specify a particular transfer direction to and/or from
620 Possible directions are
627 E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.
629 there is no dir qualifier,
632 For some link layers, such as SLIP and the ``cooked'' Linux capture mode
633 used for the ``any'' device and for some other device types, the
637 qualifiers can be used to specify a desired direction.
639 qualifiers restrict the match to a particular protocol.
654 E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange
657 no proto qualifier, all protocols consistent with the type are
659 E.g., `src foo' means `(ip or arp or rarp) src foo'
660 (except the latter is not legal syntax), `net bar' means `(ip or
661 arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
663 [`fddi' is actually an alias for `ether'; the parser treats them
664 identically as meaning ``the data link level used on the specified
665 network interface.'' FDDI headers contain Ethernet-like source
666 and destination addresses, and often contain Ethernet-like packet
667 types, so you can filter on these FDDI fields just as with the
668 analogous Ethernet fields.
669 FDDI headers also contain other fields,
670 but you cannot name them explicitly in a filter expression.
672 Similarly, `tr' and `wlan' are aliases for `ether'; the previous
673 paragraph's statements about FDDI headers also apply to Token Ring
674 and 802.11 wireless LAN headers. For 802.11 headers, the destination
675 address is the DA field and the source address is the SA field; the
676 BSSID, RA, and TA fields aren't tested.]
678 In addition to the above, there are some special `primitive' keywords
679 that don't follow the pattern:
684 and arithmetic expressions.
685 All of these are described below.
687 More complex filter expressions are built up by using the words
692 to combine primitives.
693 E.g., `host foo and not port ftp and not port ftp-data'.
694 To save typing, identical qualifier lists can be omitted.
696 `tcp dst port ftp or ftp-data or domain' is exactly the same as
697 `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.
699 Allowable primitives are:
700 .IP "\fBdst host \fIhost\fR"
701 True if the IPv4/v6 destination field of the packet is \fIhost\fP,
702 which may be either an address or a name.
703 .IP "\fBsrc host \fIhost\fR"
704 True if the IPv4/v6 source field of the packet is \fIhost\fP.
705 .IP "\fBhost \fIhost\fP
706 True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
708 Any of the above host expressions can be prepended with the keywords,
709 \fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in:
712 \fBip host \fIhost\fR
715 which is equivalent to:
718 \fBether proto \fI\\ip\fB and host \fIhost\fR
721 If \fIhost\fR is a name with multiple IP addresses, each address will
722 be checked for a match.
723 .IP "\fBether dst \fIehost\fP
724 True if the Ethernet destination address is \fIehost\fP.
726 may be either a name from /etc/ethers or a number (see
729 .IP "\fBether src \fIehost\fP
730 True if the Ethernet source address is \fIehost\fP.
731 .IP "\fBether host \fIehost\fP
732 True if either the Ethernet source or destination address is \fIehost\fP.
733 .IP "\fBgateway\fP \fIhost\fP
734 True if the packet used \fIhost\fP as a gateway.
736 source or destination address was \fIhost\fP but neither the IP source
737 nor the IP destination was \fIhost\fP.
738 \fIHost\fP must be a name and
739 must be found both by the machine's host-name-to-IP-address resolution
740 mechanisms (host name file, DNS, NIS, etc.) and by the machine's
741 host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.).
742 (An equivalent expression is
745 \fBether host \fIehost \fBand not host \fIhost\fR
748 which can be used with either names or numbers for \fIhost / ehost\fP.)
749 This syntax does not work in IPv6-enabled configuration at this moment.
750 .IP "\fBdst net \fInet\fR"
751 True if the IPv4/v6 destination address of the packet has a network
753 \fINet\fP may be either a name from the networks database
754 (/etc/networks, etc.) or a network number.
755 An IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0),
756 dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single
757 number (e.g., 10); the netmask is 255.255.255.255 for a dotted quad
758 (which means that it's really a host match), 255.255.255.0 for a dotted
759 triple, 255.255.0.0 for a dotted pair, or 255.0.0.0 for a single number.
760 An IPv6 network number must be written out fully; the netmask is
761 ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always
762 host matches, and a network match requires a netmask length.
763 .IP "\fBsrc net \fInet\fR"
764 True if the IPv4/v6 source address of the packet has a network
766 .IP "\fBnet \fInet\fR"
767 True if either the IPv4/v6 source or destination address of the packet has a network
769 .IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
770 True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR.
771 May be qualified with \fBsrc\fR or \fBdst\fR.
772 Note that this syntax is not valid for IPv6 \fInet\fR.
773 .IP "\fBnet \fInet\fR/\fIlen\fR"
774 True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR
776 May be qualified with \fBsrc\fR or \fBdst\fR.
777 .IP "\fBdst port \fIport\fR"
778 True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
779 destination port value of \fIport\fP.
780 The \fIport\fP can be a number or a name used in /etc/services (see
784 If a name is used, both the port
785 number and protocol are checked.
786 If a number or ambiguous name is used,
787 only the port number is checked (e.g., \fBdst port 513\fR will print both
788 tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
789 both tcp/domain and udp/domain traffic).
790 .IP "\fBsrc port \fIport\fR"
791 True if the packet has a source port value of \fIport\fP.
792 .IP "\fBport \fIport\fR"
793 True if either the source or destination port of the packet is \fIport\fP.
794 .IP "\fBdst portrange \fIport1\fB-\fIport2\fR"
795 True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
796 destination port value between \fIport1\fP and \fIport2\fP.
800 are interpreted in the same fashion as the
804 .IP "\fBsrc portrange \fIport1\fB-\fIport2\fR"
805 True if the packet has a source port value between \fIport1\fP and
807 .IP "\fBportrange \fIport1\fB-\fIport2\fR"
808 True if either the source or destination port of the packet is between
809 \fIport1\fP and \fIport2\fP.
811 Any of the above port or port range expressions can be prepended with
812 the keywords, \fBtcp\fP or \fBudp\fP, as in:
815 \fBtcp src port \fIport\fR
818 which matches only tcp packets whose source port is \fIport\fP.
819 .IP "\fBless \fIlength\fR"
820 True if the packet has a length less than or equal to \fIlength\fP.
821 This is equivalent to:
824 \fBlen <= \fIlength\fP.
827 .IP "\fBgreater \fIlength\fR"
828 True if the packet has a length greater than or equal to \fIlength\fP.
829 This is equivalent to:
832 \fBlen >= \fIlength\fP.
835 .IP "\fBip proto \fIprotocol\fR"
836 True if the packet is an IPv4 packet (see
838 of protocol type \fIprotocol\fP.
839 \fIProtocol\fP can be a number or one of the names
840 \fBicmp\fP, \fBicmp6\fP, \fBigmp\fP, \fBigrp\fP, \fBpim\fP, \fBah\fP,
841 \fBesp\fP, \fBvrrp\fP, \fBudp\fP, or \fBtcp\fP.
842 Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also
843 keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
844 Note that this primitive does not chase the protocol header chain.
845 .IP "\fBip6 proto \fIprotocol\fR"
846 True if the packet is an IPv6 packet of protocol type \fIprotocol\fP.
847 Note that this primitive does not chase the protocol header chain.
848 .IP "\fBip6 protochain \fIprotocol\fR"
849 True if the packet is IPv6 packet,
850 and contains protocol header with type \fIprotocol\fR
851 in its protocol header chain.
855 \fBip6 protochain 6\fR
858 matches any IPv6 packet with TCP protocol header in the protocol header chain.
859 The packet may contain, for example,
860 authentication header, routing header, or hop-by-hop option header,
861 between IPv6 header and TCP header.
862 The BPF code emitted by this primitive is complex and
863 cannot be optimized by BPF optimizer code in \fItcpdump\fP,
864 so this can be somewhat slow.
865 .IP "\fBip protochain \fIprotocol\fR"
866 Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
867 .IP "\fBether broadcast\fR"
868 True if the packet is an Ethernet broadcast packet.
871 .IP "\fBip broadcast\fR"
872 True if the packet is an IPv4 broadcast packet.
873 It checks for both the all-zeroes and all-ones broadcast conventions,
874 and looks up the subnet mask on the interface on which the capture is
877 If the subnet mask of the interface on which the capture is being done
878 is not available, either because the interface on which capture is being
879 done has no netmask or because the capture is being done on the Linux
880 "any" interface, which can capture on more than one interface, this
881 check will not work correctly.
882 .IP "\fBether multicast\fR"
883 True if the packet is an Ethernet multicast packet.
886 This is shorthand for `\fBether[0] & 1 != 0\fP'.
887 .IP "\fBip multicast\fR"
888 True if the packet is an IPv4 multicast packet.
889 .IP "\fBip6 multicast\fR"
890 True if the packet is an IPv6 multicast packet.
891 .IP "\fBether proto \fIprotocol\fR"
892 True if the packet is of ether type \fIprotocol\fR.
893 \fIProtocol\fP can be a number or one of the names
894 \fBip\fP, \fBip6\fP, \fBarp\fP, \fBrarp\fP, \fBatalk\fP, \fBaarp\fP,
895 \fBdecnet\fP, \fBsca\fP, \fBlat\fP, \fBmopdl\fP, \fBmoprc\fP,
896 \fBiso\fP, \fBstp\fP, \fBipx\fP, or \fBnetbeui\fP.
897 Note these identifiers are also keywords
898 and must be escaped via backslash (\\).
900 [In the case of FDDI (e.g., `\fBfddi protocol arp\fR'), Token Ring
901 (e.g., `\fBtr protocol arp\fR'), and IEEE 802.11 wireless LANS (e.g.,
902 `\fBwlan protocol arp\fR'), for most of those protocols, the
903 protocol identification comes from the 802.2 Logical Link Control (LLC)
904 header, which is usually layered on top of the FDDI, Token Ring, or
907 When filtering for most protocol identifiers on FDDI, Token Ring, or
908 802.11, \fItcpdump\fR checks only the protocol ID field of an LLC header
909 in so-called SNAP format with an Organizational Unit Identifier (OUI) of
910 0x000000, for encapsulated Ethernet; it doesn't check whether the packet
911 is in SNAP format with an OUI of 0x000000.
916 \fItcpdump\fR checks the DSAP (Destination Service Access Point) and
917 SSAP (Source Service Access Point) fields of the LLC header;
919 \fBstp\fP and \fBnetbeui\fP
920 \fItcpdump\fR checks the DSAP of the LLC header;
923 \fItcpdump\fR checks for a SNAP-format packet with an OUI of 0x080007
924 and the AppleTalk etype.
927 In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field
928 for most of those protocols. The exceptions are:
931 \fBiso\fP, \fBstp\fP, and \fBnetbeui\fP
932 \fItcpdump\fR checks for an 802.3 frame and then checks the LLC header as
933 it does for FDDI, Token Ring, and 802.11;
936 \fItcpdump\fR checks both for the AppleTalk etype in an Ethernet frame and
937 for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11;
940 \fItcpdump\fR checks for the AppleTalk ARP etype in either an Ethernet
941 frame or an 802.2 SNAP frame with an OUI of 0x000000;
944 \fItcpdump\fR checks for the IPX etype in an Ethernet frame, the IPX
945 DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of
946 IPX, and the IPX etype in a SNAP frame.
948 .IP "\fBdecnet src \fIhost\fR"
949 True if the DECNET source address is
951 which may be an address of the form ``10.123'', or a DECNET host
953 [DECNET host name support is only available on ULTRIX systems
954 that are configured to run DECNET.]
955 .IP "\fBdecnet dst \fIhost\fR"
956 True if the DECNET destination address is
958 .IP "\fBdecnet host \fIhost\fR"
959 True if either the DECNET source or destination address is
961 .IP "\fBifname \fIinterface\fR"
962 True if the packet was logged as coming from the specified interface (applies
963 only to packets logged by OpenBSD's
965 .IP "\fBon \fIinterface\fR"
969 .IP "\fBrnr \fInum\fR"
970 True if the packet was logged as matching the specified PF rule number
971 (applies only to packets logged by OpenBSD's
973 .IP "\fBrulenum \fInum\fR"
977 .IP "\fBreason \fIcode\fR"
978 True if the packet was logged with the specified PF reason code. The known
987 (applies only to packets logged by OpenBSD's
989 .IP "\fBrset \fIname\fR"
990 True if the packet was logged as matching the specified PF ruleset
991 name of an anchored ruleset (applies only to packets logged by
993 .IP "\fBruleset \fIname\fR"
997 .IP "\fBsrnr \fInum\fR"
998 True if the packet was logged as matching the specified PF rule number
999 of an anchored ruleset (applies only to packets logged by
1001 .IP "\fBsubrulenum \fInum\fR"
1005 .IP "\fBaction \fIact\fR"
1006 True if PF took the specified action when the packet was logged. Known actions
1011 (applies only to packets logged by OpenBSD's
1013 .IP "\fBip\fR, \fBip6\fR, \fBarp\fR, \fBrarp\fR, \fBatalk\fR, \fBaarp\fR, \fBdecnet\fR, \fBiso\fR, \fBstp\fR, \fBipx\fR, \fInetbeui\fP"
1017 \fBether proto \fIp\fR
1020 where \fIp\fR is one of the above protocols.
1021 .IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
1025 \fBether proto \fIp\fR
1028 where \fIp\fR is one of the above protocols.
1030 \fItcpdump\fP does not currently know how to parse these protocols.
1031 .IP "\fBvlan \fI[vlan_id]\fR"
1032 True if the packet is an IEEE 802.1Q VLAN packet.
1033 If \fI[vlan_id]\fR is specified, only true if the packet has the specified
1035 Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR
1036 changes the decoding offsets for the remainder of \fIexpression\fR on
1037 the assumption that the packet is a VLAN packet. The \fBvlan
1038 \fI[vlan_id]\fR expression may be used more than once, to filter on VLAN
1039 hierarchies. Each use of that expression increments the filter offsets
1045 \fBvlan 100 && vlan 200\fR
1048 filters on VLAN 200 encapsulated within VLAN 100, and
1051 \fBvlan && vlan 300 && ip\fR
1054 filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any
1056 .IP "\fBmpls \fI[label_num]\fR"
1057 True if the packet is an MPLS packet.
1058 If \fI[label_num]\fR is specified, only true is the packet has the specified
1060 Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR
1061 changes the decoding offsets for the remainder of \fIexpression\fR on
1062 the assumption that the packet is a MPLS-encapsulated IP packet. The
1063 \fBmpls \fI[label_num]\fR expression may be used more than once, to
1064 filter on MPLS hierarchies. Each use of that expression increments the
1065 filter offsets by 4.
1070 \fBmpls 100000 && mpls 1024\fR
1073 filters packets with an outer label of 100000 and an inner label of
1077 \fBmpls && mpls 1024 && host 192.9.200.1\fR
1080 filters packets to or from 192.9.200.1 with an inner label of 1024 and
1083 True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet
1086 True if the packet is a PPP-over-Ethernet Session packet (Ethernet
1088 Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR
1089 changes the decoding offsets for the remainder of \fIexpression\fR on
1090 the assumption that the packet is a PPPoE session packet.
1098 filters IPv4 protocols encapsulated in PPPoE.
1099 .IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
1103 \fBip proto \fIp\fR\fB or ip6 proto \fIp\fR
1106 where \fIp\fR is one of the above protocols.
1107 .IP "\fBiso proto \fIprotocol\fR"
1108 True if the packet is an OSI packet of protocol type \fIprotocol\fP.
1109 \fIProtocol\fP can be a number or one of the names
1110 \fBclnp\fP, \fBesis\fP, or \fBisis\fP.
1111 .IP "\fBclnp\fR, \fBesis\fR, \fBisis\fR"
1115 \fBiso proto \fIp\fR
1118 where \fIp\fR is one of the above protocols.
1119 .IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR"
1120 Abbreviations for IS-IS PDU types.
1121 .IP "\fBvpi\fP \fIn\fR
1122 True if the packet is an ATM packet, for SunATM on Solaris, with a
1123 virtual path identifier of
1125 .IP "\fBvci\fP \fIn\fR
1126 True if the packet is an ATM packet, for SunATM on Solaris, with a
1127 virtual channel identifier of
1130 True if the packet is an ATM packet, for SunATM on Solaris, and is
1132 Note that the first \fBlane\fR keyword encountered in \fIexpression\fR
1133 changes the tests done in the remainder of \fIexpression\fR
1134 on the assumption that the packet is either a LANE emulated Ethernet
1135 packet or a LANE LE Control packet. If \fBlane\fR isn't specified, the
1136 tests are done under the assumption that the packet is an
1137 LLC-encapsulated packet.
1139 True if the packet is an ATM packet, for SunATM on Solaris, and is
1140 an LLC-encapsulated packet.
1142 True if the packet is an ATM packet, for SunATM on Solaris, and is
1143 a segment OAM F4 flow cell (VPI=0 & VCI=3).
1145 True if the packet is an ATM packet, for SunATM on Solaris, and is
1146 an end-to-end OAM F4 flow cell (VPI=0 & VCI=4).
1148 True if the packet is an ATM packet, for SunATM on Solaris, and is
1149 a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
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)).
1154 True if the packet is an ATM packet, for SunATM on Solaris, and is
1155 on a meta signaling circuit (VPI=0 & VCI=1).
1157 True if the packet is an ATM packet, for SunATM on Solaris, and is
1158 on a broadcast signaling circuit (VPI=0 & VCI=2).
1160 True if the packet is an ATM packet, for SunATM on Solaris, and is
1161 on a signaling circuit (VPI=0 & VCI=5).
1163 True if the packet is an ATM packet, for SunATM on Solaris, and is
1164 on an ILMI circuit (VPI=0 & VCI=16).
1165 .IP \fBconnectmsg\fP
1166 True if the packet is an ATM packet, for SunATM on Solaris, and is
1167 on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1168 Connect Ack, Release, or Release Done message.
1169 .IP \fBmetaconnect\fP
1170 True if the packet is an ATM packet, for SunATM on Solaris, and is
1171 on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1172 Release, or Release Done message.
1173 .IP "\fIexpr relop expr\fR"
1174 True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =,
1175 !=, and \fIexpr\fR is an arithmetic expression composed of integer
1176 constants (expressed in standard C syntax), the normal binary operators
1177 [+, -, *, /, &, |, <<, >>], a length operator, and special packet data
1178 accessors. Note that all comparisons are unsigned, so that, for example,
1179 0x80000000 and 0xffffffff are > 0.
1181 data inside the packet, use the following syntax:
1184 \fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR
1187 \fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link,
1188 ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and
1189 indicates the protocol layer for the index operation.
1190 (\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the
1191 link layer. \fBradio\fR refers to the "radio header" added to some
1193 Note that \fItcp, udp\fR and other upper-layer protocol types only
1194 apply to IPv4, not IPv6 (this will be fixed in the future).
1195 The byte offset, relative to the indicated protocol layer, is
1196 given by \fIexpr\fR.
1197 \fISize\fR is optional and indicates the number of bytes in the
1198 field of interest; it can be either one, two, or four, and defaults to one.
1199 The length operator, indicated by the keyword \fBlen\fP, gives the
1200 length of the packet.
1202 For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
1203 The expression `\fBip[0] & 0xf != 5\fP'
1204 catches all IPv4 packets with options.
1206 `\fBip[6:2] & 0x1fff = 0\fP'
1207 catches only unfragmented IPv4 datagrams and frag zero of fragmented
1209 This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
1211 For instance, \fBtcp[0]\fP always means the first
1212 byte of the TCP \fIheader\fP, and never means the first byte of an
1213 intervening fragment.
1215 Some offsets and field values may be expressed as names rather than
1217 The following protocol header field offsets are
1218 available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP
1219 code field), and \fBtcpflags\fP (TCP flags field).
1221 The following ICMP type field values are available: \fBicmp-echoreply\fP,
1222 \fBicmp-unreach\fP, \fBicmp-sourcequench\fP, \fBicmp-redirect\fP,
1223 \fBicmp-echo\fP, \fBicmp-routeradvert\fP, \fBicmp-routersolicit\fP,
1224 \fBicmp-timxceed\fP, \fBicmp-paramprob\fP, \fBicmp-tstamp\fP,
1225 \fBicmp-tstampreply\fP, \fBicmp-ireq\fP, \fBicmp-ireqreply\fP,
1226 \fBicmp-maskreq\fP, \fBicmp-maskreply\fP.
1228 The following TCP flags field values are available: \fBtcp-fin\fP,
1229 \fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
1230 \fBtcp-ack\fP, \fBtcp-urg\fP.
1232 Primitives may be combined using:
1234 A parenthesized group of primitives and operators
1235 (parentheses are special to the Shell and must be escaped).
1237 Negation (`\fB!\fP' or `\fBnot\fP').
1239 Concatenation (`\fB&&\fP' or `\fBand\fP').
1241 Alternation (`\fB||\fP' or `\fBor\fP').
1243 Negation has highest precedence.
1244 Alternation and concatenation have equal precedence and associate
1246 Note that explicit \fBand\fR tokens, not juxtaposition,
1247 are now required for concatenation.
1249 If an identifier is given without a keyword, the most recent keyword
1254 \fBnot host vs and ace\fR
1260 \fBnot host vs and host ace\fR
1263 which should not be confused with
1266 \fBnot ( host vs or ace )\fR
1270 Expression arguments can be passed to \fItcpdump\fP as either a single
1271 argument or as multiple arguments, whichever is more convenient.
1272 Generally, if the expression contains Shell metacharacters, it is
1273 easier to pass it as a single, quoted argument.
1274 Multiple arguments are concatenated with spaces before being parsed.
1277 To print all packets arriving at or departing from \fIsundown\fP:
1280 \fBtcpdump host sundown\fP
1284 To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
1287 \fBtcpdump host helios and \\( hot or ace \\)\fP
1291 To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
1294 \fBtcpdump ip host ace and not helios\fP
1298 To print all traffic between local hosts and hosts at Berkeley:
1302 tcpdump net ucb-ether
1306 To print all ftp traffic through internet gateway \fIsnup\fP:
1307 (note that the expression is quoted to prevent the shell from
1308 (mis-)interpreting the parentheses):
1312 tcpdump 'gateway snup and (port ftp or ftp-data)'
1316 To print traffic neither sourced from nor destined for local hosts
1317 (if you gateway to one other net, this stuff should never make it
1318 onto your local net).
1322 tcpdump ip and not net \fIlocalnet\fP
1326 To print the start and end packets (the SYN and FIN packets) of each
1327 TCP conversation that involves a non-local host.
1331 tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
1335 To print all IPv4 HTTP packets to and from port 80, i.e. print only
1336 packets that contain data, not, for example, SYN and FIN packets and
1337 ACK-only packets. (IPv6 is left as an exercise for the reader.)
1341 tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
1345 To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
1349 tcpdump 'gateway snup and ip[2:2] > 576'
1353 To print IP broadcast or multicast packets that were
1355 sent via Ethernet broadcast or multicast:
1359 tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
1363 To print all ICMP packets that are not echo requests/replies (i.e., not
1368 tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
1373 The output of \fItcpdump\fP is protocol dependent.
1375 gives a brief description and examples of most of the formats.
1383 If the '-e' option is given, the link level header is printed out.
1384 On Ethernets, the source and destination addresses, protocol,
1385 and packet length are printed.
1387 On FDDI networks, the '-e' option causes \fItcpdump\fP to print
1388 the `frame control' field, the source and destination addresses,
1389 and the packet length.
1390 (The `frame control' field governs the
1391 interpretation of the rest of the packet.
1392 Normal packets (such
1393 as those containing IP datagrams) are `async' packets, with a priority
1394 value between 0 and 7; for example, `\fBasync4\fR'.
1396 are assumed to contain an 802.2 Logical Link Control (LLC) packet;
1397 the LLC header is printed if it is \fInot\fR an ISO datagram or a
1398 so-called SNAP packet.
1400 On Token Ring networks, the '-e' option causes \fItcpdump\fP to print
1401 the `access control' and `frame control' fields, the source and
1402 destination addresses, and the packet length.
1403 As on FDDI networks,
1404 packets are assumed to contain an LLC packet.
1405 Regardless of whether
1406 the '-e' option is specified or not, the source routing information is
1407 printed for source-routed packets.
1409 On 802.11 networks, the '-e' option causes \fItcpdump\fP to print
1410 the `frame control' fields, all of the addresses in the 802.11 header,
1411 and the packet length.
1412 As on FDDI networks,
1413 packets are assumed to contain an LLC packet.
1415 \fI(N.B.: The following description assumes familiarity with
1416 the SLIP compression algorithm described in RFC-1144.)\fP
1418 On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
1419 packet type, and compression information are printed out.
1420 The packet type is printed first.
1421 The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
1422 No further link information is printed for \fIip\fR packets.
1423 For TCP packets, the connection identifier is printed following the type.
1424 If the packet is compressed, its encoded header is printed out.
1425 The special cases are printed out as
1426 \fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
1427 the sequence number (or sequence number and ack) has changed.
1428 If it is not a special case,
1429 zero or more changes are printed.
1430 A change is indicated by U (urgent pointer), W (window), A (ack),
1431 S (sequence number), and I (packet ID), followed by a delta (+n or -n),
1432 or a new value (=n).
1433 Finally, the amount of data in the packet and compressed header length
1436 For example, the following line shows an outbound compressed TCP packet,
1437 with an implicit connection identifier; the ack has changed by 6,
1438 the sequence number by 49, and the packet ID by 6; there are 3 bytes of
1439 data and 6 bytes of compressed header:
1442 \fBO ctcp * A+6 S+49 I+6 3 (6)\fP
1448 Arp/rarp output shows the type of request and its arguments.
1450 format is intended to be self explanatory.
1451 Here is a short sample taken from the start of an `rlogin' from
1452 host \fIrtsg\fP to host \fIcsam\fP:
1456 \f(CWarp who-has csam tell rtsg
1457 arp reply csam is-at CSAM\fR
1461 The first line says that rtsg sent an arp packet asking
1462 for the Ethernet address of internet host csam.
1464 replies with its Ethernet address (in this example, Ethernet addresses
1465 are in caps and internet addresses in lower case).
1467 This would look less redundant if we had done \fItcpdump \-n\fP:
1471 \f(CWarp who-has 128.3.254.6 tell 128.3.254.68
1472 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4\fP
1476 If we had done \fItcpdump \-e\fP, the fact that the first packet is
1477 broadcast and the second is point-to-point would be visible:
1481 \f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
1482 CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
1486 For the first packet this says the Ethernet source address is RTSG, the
1487 destination is the Ethernet broadcast address, the type field
1488 contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
1492 \fI(N.B.:The following description assumes familiarity with
1493 the TCP protocol described in RFC-793.
1494 If you are not familiar
1495 with the protocol, neither this description nor \fItcpdump\fP will
1496 be of much use to you.)\fP
1498 The general format of a tcp protocol line is:
1502 \fIsrc > dst: flags data-seqno ack window urgent options\fP
1506 \fISrc\fP and \fIdst\fP are the source and destination IP
1507 addresses and ports.
1508 \fIFlags\fP are some combination of S (SYN),
1509 F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single
1511 \fIData-seqno\fP describes the portion of sequence space covered
1512 by the data in this packet (see example below).
1513 \fIAck\fP is sequence number of the next data expected the other
1514 direction on this connection.
1515 \fIWindow\fP is the number of bytes of receive buffer space available
1516 the other direction on this connection.
1517 \fIUrg\fP indicates there is `urgent' data in the packet.
1518 \fIOptions\fP are tcp options enclosed in angle brackets (e.g., <mss 1024>).
1520 \fISrc, dst\fP and \fIflags\fP are always present.
1522 depend on the contents of the packet's tcp protocol header and
1523 are output only if appropriate.
1525 Here is the opening portion of an rlogin from host \fIrtsg\fP to
1530 \s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
1531 csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
1532 rtsg.1023 > csam.login: . ack 1 win 4096
1533 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
1534 csam.login > rtsg.1023: . ack 2 win 4096
1535 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
1536 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
1537 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
1538 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
1542 The first line says that tcp port 1023 on rtsg sent a packet
1545 The \fBS\fP indicates that the \fISYN\fP flag was set.
1546 The packet sequence number was 768512 and it contained no data.
1547 (The notation is `first:last(nbytes)' which means `sequence
1549 up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
1550 There was no piggy-backed ack, the available receive window was 4096
1551 bytes and there was a max-segment-size option requesting an mss of
1554 Csam replies with a similar packet except it includes a piggy-backed
1556 Rtsg then acks csam's SYN.
1559 The packet contained no data so there is no data sequence number.
1560 Note that the ack sequence
1561 number is a small integer (1).
1562 The first time \fItcpdump\fP sees a
1563 tcp `conversation', it prints the sequence number from the packet.
1564 On subsequent packets of the conversation, the difference between
1565 the current packet's sequence number and this initial sequence number
1567 This means that sequence numbers after the
1568 first can be interpreted
1569 as relative byte positions in the conversation's data stream (with the
1570 first data byte each direction being `1').
1571 `-S' will override this
1572 feature, causing the original sequence numbers to be output.
1574 On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
1575 in the rtsg \(-> csam side of the conversation).
1576 The PUSH flag is set in the packet.
1577 On the 7th line, csam says it's received data sent by rtsg up to
1578 but not including byte 21.
1579 Most of this data is apparently sitting in the
1580 socket buffer since csam's receive window has gotten 19 bytes smaller.
1581 Csam also sends one byte of data to rtsg in this packet.
1582 On the 8th and 9th lines,
1583 csam sends two bytes of urgent, pushed data to rtsg.
1585 If the snapshot was small enough that \fItcpdump\fP didn't capture
1586 the full TCP header, it interprets as much of the header as it can
1587 and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
1589 If the header contains a bogus option (one with a length
1590 that's either too small or beyond the end of the header), \fItcpdump\fP
1591 reports it as ``[\fIbad opt\fP]'' and does not interpret any further
1592 options (since it's impossible to tell where they start).
1594 length indicates options are present but the IP datagram length is not
1595 long enough for the options to actually be there, \fItcpdump\fP reports
1596 it as ``[\fIbad hdr length\fP]''.
1598 .B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
1600 There are 8 bits in the control bits section of the TCP header:
1602 .I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
1604 Let's assume that we want to watch packets used in establishing
1606 Recall that TCP uses a 3-way handshake protocol
1607 when it initializes a new connection; the connection sequence with
1608 regard to the TCP control bits is
1614 2) Recipient responds with SYN, ACK
1620 Now we're interested in capturing packets that have only the
1621 SYN bit set (Step 1).
1622 Note that we don't want packets from step 2
1623 (SYN-ACK), just a plain initial SYN.
1624 What we need is a correct filter
1625 expression for \fItcpdump\fP.
1627 Recall the structure of a TCP header without options:
1631 -----------------------------------------------------------------
1632 | source port | destination port |
1633 -----------------------------------------------------------------
1635 -----------------------------------------------------------------
1636 | acknowledgment number |
1637 -----------------------------------------------------------------
1638 | HL | rsvd |C|E|U|A|P|R|S|F| window size |
1639 -----------------------------------------------------------------
1640 | TCP checksum | urgent pointer |
1641 -----------------------------------------------------------------
1644 A TCP header usually holds 20 octets of data, unless options are
1646 The first line of the graph contains octets 0 - 3, the
1647 second line shows octets 4 - 7 etc.
1649 Starting to count with 0, the relevant TCP control bits are contained
1654 ----------------|---------------|---------------|----------------
1655 | HL | rsvd |C|E|U|A|P|R|S|F| window size |
1656 ----------------|---------------|---------------|----------------
1657 | | 13th octet | | |
1660 Let's have a closer look at octet no. 13:
1670 These are the TCP control bits we are interested
1672 We have numbered the bits in this octet from 0 to 7, right to
1673 left, so the PSH bit is bit number 3, while the URG bit is number 5.
1675 Recall that we want to capture packets with only SYN set.
1676 Let's see what happens to octet 13 if a TCP datagram arrives
1677 with the SYN bit set in its header:
1688 control bits section we see that only bit number 1 (SYN) is set.
1690 Assuming that octet number 13 is an 8-bit unsigned integer in
1691 network byte order, the binary value of this octet is
1695 and its decimal representation is
1699 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
1702 We're almost done, because now we know that if only SYN is set,
1703 the value of the 13th octet in the TCP header, when interpreted
1704 as a 8-bit unsigned integer in network byte order, must be exactly 2.
1706 This relationship can be expressed as
1712 We can use this expression as the filter for \fItcpdump\fP in order
1713 to watch packets which have only SYN set:
1716 tcpdump -i xl0 tcp[13] == 2
1719 The expression says "let the 13th octet of a TCP datagram have
1720 the decimal value 2", which is exactly what we want.
1722 Now, let's assume that we need to capture SYN packets, but we
1723 don't care if ACK or any other TCP control bit is set at the
1725 Let's see what happens to octet 13 when a TCP datagram
1726 with SYN-ACK set arrives:
1736 Now bits 1 and 4 are set in the 13th octet.
1742 which translates to decimal
1746 0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
1749 Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter
1750 expression, because that would select only those packets that have
1751 SYN-ACK set, but not those with only SYN set.
1752 Remember that we don't care
1753 if ACK or any other control bit is set as long as SYN is set.
1755 In order to achieve our goal, we need to logically AND the
1756 binary value of octet 13 with some other value to preserve
1758 We know that we want SYN to be set in any case,
1759 so we'll logically AND the value in the 13th octet with
1760 the binary value of a SYN:
1764 00010010 SYN-ACK 00000010 SYN
1765 AND 00000010 (we want SYN) AND 00000010 (we want SYN)
1767 = 00000010 = 00000010
1770 We see that this AND operation delivers the same result
1771 regardless whether ACK or another TCP control bit is set.
1772 The decimal representation of the AND value as well as
1773 the result of this operation is 2 (binary 00000010),
1774 so we know that for packets with SYN set the following
1775 relation must hold true:
1777 ( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
1779 This points us to the \fItcpdump\fP filter expression
1782 tcpdump -i xl0 'tcp[13] & 2 == 2'
1785 Note that you should use single quotes or a backslash
1786 in the expression to hide the AND ('&') special character
1792 UDP format is illustrated by this rwho packet:
1796 \f(CWactinide.who > broadcast.who: udp 84\fP
1800 This says that port \fIwho\fP on host \fIactinide\fP sent a udp
1801 datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
1803 The packet contained 84 bytes of user data.
1805 Some UDP services are recognized (from the source or destination
1806 port number) and the higher level protocol information printed.
1807 In particular, Domain Name service requests (RFC-1034/1035) and Sun
1808 RPC calls (RFC-1050) to NFS.
1810 UDP Name Server Requests
1812 \fI(N.B.:The following description assumes familiarity with
1813 the Domain Service protocol described in RFC-1035.
1814 If you are not familiar
1815 with the protocol, the following description will appear to be written
1818 Name server requests are formatted as
1822 \fIsrc > dst: id op? flags qtype qclass name (len)\fP
1824 \f(CWh2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)\fR
1828 Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
1829 address record (qtype=A) associated with the name \fIucbvax.berkeley.edu.\fP
1830 The query id was `3'.
1831 The `+' indicates the \fIrecursion desired\fP flag
1833 The query length was 37 bytes, not including the UDP and
1834 IP protocol headers.
1835 The query operation was the normal one, \fIQuery\fP,
1836 so the op field was omitted.
1837 If the op had been anything else, it would
1838 have been printed between the `3' and the `+'.
1839 Similarly, the qclass was the normal one,
1840 \fIC_IN\fP, and omitted.
1841 Any other qclass would have been printed
1842 immediately after the `A'.
1844 A few anomalies are checked and may result in extra fields enclosed in
1845 square brackets: If a query contains an answer, authority records or
1846 additional records section,
1851 are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
1852 is the appropriate count.
1853 If any of the response bits are set (AA, RA or rcode) or any of the
1854 `must be zero' bits are set in bytes two and three, `[b2&3=\fIx\fP]'
1855 is printed, where \fIx\fP is the hex value of header bytes two and three.
1857 UDP Name Server Responses
1859 Name server responses are formatted as
1863 \fIsrc > dst: id op rcode flags a/n/au type class data (len)\fP
1865 \f(CWhelios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
1866 helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
1870 In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
1871 with 3 answer records, 3 name server records and 7 additional records.
1872 The first answer record is type A (address) and its data is internet
1873 address 128.32.137.3.
1874 The total size of the response was 273 bytes,
1875 excluding UDP and IP headers.
1876 The op (Query) and response code
1877 (NoError) were omitted, as was the class (C_IN) of the A record.
1879 In the second example, \fIhelios\fP responds to query 2 with a
1880 response code of non-existent domain (NXDomain) with no answers,
1881 one name server and no authority records.
1882 The `*' indicates that
1883 the \fIauthoritative answer\fP bit was set.
1885 answers, no type, class or data were printed.
1887 Other flag characters that might appear are `\-' (recursion available,
1888 RA, \fInot\fP set) and `|' (truncated message, TC, set).
1890 `question' section doesn't contain exactly one entry, `[\fIn\fPq]'
1893 Note that name server requests and responses tend to be large and the
1894 default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
1896 Use the \fB\-s\fP flag to increase the snaplen if you
1897 need to seriously investigate name server traffic.
1899 has worked well for me.
1904 \fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
1905 on UDP/137, UDP/138 and TCP/139.
1906 Some primitive decoding of IPX and
1907 NetBEUI SMB data is also done.
1909 By default a fairly minimal decode is done, with a much more detailed
1910 decode done if -v is used.
1911 Be warned that with -v a single SMB packet
1912 may take up a page or more, so only use -v if you really want all the
1915 For information on SMB packet formats and what all te fields mean see
1916 www.cifs.org or the pub/samba/specs/ directory on your favorite
1917 samba.org mirror site.
1918 The SMB patches were written by Andrew Tridgell
1922 NFS Requests and Replies
1924 Sun NFS (Network File System) requests and replies are printed as:
1928 \fIsrc.xid > dst.nfs: len op args\fP
1929 \fIsrc.nfs > dst.xid: reply stat len op results\fP
1932 sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
1933 wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
1934 sushi.201b > wrl.nfs:
1935 144 lookup fh 9,74/4096.6878 "xcolors"
1936 wrl.nfs > sushi.201b:
1937 reply ok 128 lookup fh 9,74/4134.3150
1942 In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
1943 to \fIwrl\fP (note that the number following the src host is a
1944 transaction id, \fInot\fP the source port).
1945 The request was 112 bytes,
1946 excluding the UDP and IP headers.
1947 The operation was a \fIreadlink\fP
1948 (read symbolic link) on file handle (\fIfh\fP) 21,24/10.731657119.
1949 (If one is lucky, as in this case, the file handle can be interpreted
1950 as a major,minor device number pair, followed by the inode number and
1952 \fIWrl\fP replies `ok' with the contents of the link.
1954 In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
1955 `\fIxcolors\fP' in directory file 9,74/4096.6878.
1956 Note that the data printed
1957 depends on the operation type.
1958 The format is intended to be self
1959 explanatory if read in conjunction with
1960 an NFS protocol spec.
1962 If the \-v (verbose) flag is given, additional information is printed.
1968 sushi.1372a > wrl.nfs:
1969 148 read fh 21,11/12.195 8192 bytes @ 24576
1970 wrl.nfs > sushi.1372a:
1971 reply ok 1472 read REG 100664 ids 417/0 sz 29388
1976 (\-v also prints the IP header TTL, ID, length, and fragmentation fields,
1977 which have been omitted from this example.) In the first line,
1978 \fIsushi\fP asks \fIwrl\fP to read 8192 bytes from file 21,11/12.195,
1979 at byte offset 24576.
1980 \fIWrl\fP replies `ok'; the packet shown on the
1981 second line is the first fragment of the reply, and hence is only 1472
1982 bytes long (the other bytes will follow in subsequent fragments, but
1983 these fragments do not have NFS or even UDP headers and so might not be
1984 printed, depending on the filter expression used).
1985 Because the \-v flag
1986 is given, some of the file attributes (which are returned in addition
1987 to the file data) are printed: the file type (``REG'', for regular file),
1988 the file mode (in octal), the uid and gid, and the file size.
1990 If the \-v flag is given more than once, even more details are printed.
1992 Note that NFS requests are very large and much of the detail won't be printed
1993 unless \fIsnaplen\fP is increased.
1994 Try using `\fB\-s 192\fP' to watch
1997 NFS reply packets do not explicitly identify the RPC operation.
1999 \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2000 replies using the transaction ID.
2001 If a reply does not closely follow the
2002 corresponding request, it might not be parsable.
2004 AFS Requests and Replies
2006 Transarc AFS (Andrew File System) requests and replies are printed
2012 \fIsrc.sport > dst.dport: rx packet-type\fP
2013 \fIsrc.sport > dst.dport: rx packet-type service call call-name args\fP
2014 \fIsrc.sport > dst.dport: rx packet-type service reply call-name args\fP
2017 elvis.7001 > pike.afsfs:
2018 rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
2019 new fid 536876964/1/1 ".newsrc"
2020 pike.afsfs > elvis.7001: rx data fs reply rename
2025 In the first line, host elvis sends a RX packet to pike.
2027 a RX data packet to the fs (fileserver) service, and is the start of
2029 The RPC call was a rename, with the old directory file id
2030 of 536876964/1/1 and an old filename of `.newsrc.new', and a new directory
2031 file id of 536876964/1/1 and a new filename of `.newsrc'.
2033 responds with a RPC reply to the rename call (which was successful, because
2034 it was a data packet and not an abort packet).
2036 In general, all AFS RPCs are decoded at least by RPC call name.
2038 AFS RPCs have at least some of the arguments decoded (generally only
2039 the `interesting' arguments, for some definition of interesting).
2041 The format is intended to be self-describing, but it will probably
2042 not be useful to people who are not familiar with the workings of
2045 If the -v (verbose) flag is given twice, acknowledgement packets and
2046 additional header information is printed, such as the the RX call ID,
2047 call number, sequence number, serial number, and the RX packet flags.
2049 If the -v flag is given twice, additional information is printed,
2050 such as the the RX call ID, serial number, and the RX packet flags.
2051 The MTU negotiation information is also printed from RX ack packets.
2053 If the -v flag is given three times, the security index and service id
2056 Error codes are printed for abort packets, with the exception of Ubik
2057 beacon packets (because abort packets are used to signify a yes vote
2058 for the Ubik protocol).
2060 Note that AFS requests are very large and many of the arguments won't
2061 be printed unless \fIsnaplen\fP is increased.
2062 Try using `\fB-s 256\fP'
2063 to watch AFS traffic.
2065 AFS reply packets do not explicitly identify the RPC operation.
2067 \fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2068 replies using the call number and service ID.
2069 If a reply does not closely
2071 corresponding request, it might not be parsable.
2074 KIP AppleTalk (DDP in UDP)
2076 AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
2077 and dumped as DDP packets (i.e., all the UDP header information is
2081 is used to translate AppleTalk net and node numbers to names.
2082 Lines in this file have the form
2094 The first two lines give the names of AppleTalk networks.
2096 line gives the name of a particular host (a host is distinguished
2097 from a net by the 3rd octet in the number \-
2098 a net number \fImust\fP have two octets and a host number \fImust\fP
2099 have three octets.) The number and name should be separated by
2100 whitespace (blanks or tabs).
2103 file may contain blank lines or comment lines (lines starting with
2106 AppleTalk addresses are printed in the form
2112 \f(CW144.1.209.2 > icsd-net.112.220
2113 office.2 > icsd-net.112.220
2114 jssmag.149.235 > icsd-net.2\fR
2120 doesn't exist or doesn't contain an entry for some AppleTalk
2121 host/net number, addresses are printed in numeric form.)
2122 In the first example, NBP (DDP port 2) on net 144.1 node 209
2123 is sending to whatever is listening on port 220 of net icsd node 112.
2124 The second line is the same except the full name of the source node
2125 is known (`office').
2126 The third line is a send from port 235 on
2127 net jssmag node 149 to broadcast on the icsd-net NBP port (note that
2128 the broadcast address (255) is indicated by a net name with no host
2129 number \- for this reason it's a good idea to keep node names and
2130 net names distinct in /etc/atalk.names).
2132 NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
2133 packets have their contents interpreted.
2134 Other protocols just dump
2135 the protocol name (or number if no name is registered for the
2136 protocol) and packet size.
2138 \fBNBP packets\fP are formatted like the following examples:
2142 \s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
2143 jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
2144 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
2148 The first line is a name lookup request for laserwriters sent by net icsd host
2149 112 and broadcast on net jssmag.
2150 The nbp id for the lookup is 190.
2151 The second line shows a reply for this request (note that it has the
2152 same id) from host jssmag.209 saying that it has a laserwriter
2153 resource named "RM1140" registered on port 250.
2155 another reply to the same request saying host techpit has laserwriter
2156 "techpit" registered on port 186.
2158 \fBATP packet\fP formatting is demonstrated by the following example:
2162 \s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
2163 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
2164 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
2165 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
2166 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2167 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
2168 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2169 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
2170 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
2171 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
2172 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2173 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2174 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
2175 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
2179 Jssmag.209 initiates transaction id 12266 with host helios by requesting
2180 up to 8 packets (the `<0-7>').
2181 The hex number at the end of the line
2182 is the value of the `userdata' field in the request.
2184 Helios responds with 8 512-byte packets.
2185 The `:digit' following the
2186 transaction id gives the packet sequence number in the transaction
2187 and the number in parens is the amount of data in the packet,
2188 excluding the atp header.
2189 The `*' on packet 7 indicates that the
2192 Jssmag.209 then requests that packets 3 & 5 be retransmitted.
2194 resends them then jssmag.209 releases the transaction.
2196 jssmag.209 initiates the next request.
2197 The `*' on the request
2198 indicates that XO (`exactly once') was \fInot\fP set.
2203 Fragmented Internet datagrams are printed as
2207 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB+)\fR
2208 \fB(frag \fIid\fB:\fIsize\fB@\fIoffset\fB)\fR
2212 (The first form indicates there are more fragments.
2214 indicates this is the last fragment.)
2216 \fIId\fP is the fragment id.
2217 \fISize\fP is the fragment
2218 size (in bytes) excluding the IP header.
2219 \fIOffset\fP is this
2220 fragment's offset (in bytes) in the original datagram.
2222 The fragment information is output for each fragment.
2224 fragment contains the higher level protocol header and the frag
2225 info is printed after the protocol info.
2227 after the first contain no higher level protocol header and the
2228 frag info is printed after the source and destination addresses.
2229 For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa
2230 over a CSNET connection that doesn't appear to handle 576 byte datagrams:
2234 \s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
2235 arizona > rtsg: (frag 595a:204@328)
2236 rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
2240 There are a couple of things to note here: First, addresses in the
2241 2nd line don't include port numbers.
2242 This is because the TCP
2243 protocol information is all in the first fragment and we have no idea
2244 what the port or sequence numbers are when we print the later fragments.
2245 Second, the tcp sequence information in the first line is printed as if there
2246 were 308 bytes of user data when, in fact, there are 512 bytes (308 in
2247 the first frag and 204 in the second).
2248 If you are looking for holes
2249 in the sequence space or trying to match up acks
2250 with packets, this can fool you.
2252 A packet with the IP \fIdon't fragment\fP flag is marked with a
2253 trailing \fB(DF)\fP.
2257 By default, all output lines are preceded by a timestamp.
2259 is the current clock time in the form
2265 and is as accurate as the kernel's clock.
2266 The timestamp reflects the time the kernel first saw the packet.
2268 is made to account for the time lag between when the
2269 Ethernet interface removed the packet from the wire and when the kernel
2270 serviced the `new packet' interrupt.
2272 stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
2274 The original authors are:
2278 Steven McCanne, all of the
2279 Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
2281 It is currently being maintained by tcpdump.org.
2283 The current version is available via http:
2286 .I http://www.tcpdump.org/
2289 The original distribution is available via anonymous ftp:
2292 .I ftp://ftp.ee.lbl.gov/tcpdump.tar.Z
2295 IPv6/IPsec support is added by WIDE/KAME project.
2296 This program uses Eric Young's SSLeay library, under specific configuration.
2298 Please send problems, bugs, questions, desirable enhancements, etc. to:
2301 tcpdump-workers@tcpdump.org
2304 Please send source code contributions, etc. to:
2310 NIT doesn't let you watch your own outbound traffic, BPF will.
2311 We recommend that you use the latter.
2313 On Linux systems with 2.0[.x] kernels:
2315 packets on the loopback device will be seen twice;
2317 packet filtering cannot be done in the kernel, so that all packets must
2318 be copied from the kernel in order to be filtered in user mode;
2320 all of a packet, not just the part that's within the snapshot length,
2321 will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
2322 asked to copy only part of a packet to userland, will not report the
2323 true length of the packet; this would cause most IP packets to get an
2327 capturing on some PPP devices won't work correctly.
2329 We recommend that you upgrade to a 2.2 or later kernel.
2331 Some attempt should be made to reassemble IP fragments or, at least
2332 to compute the right length for the higher level protocol.
2334 Name server inverse queries are not dumped correctly: the (empty)
2335 question section is printed rather than real query in the answer
2337 Some believe that inverse queries are themselves a bug and
2338 prefer to fix the program generating them rather than \fItcpdump\fP.
2340 A packet trace that crosses a daylight savings time change will give
2341 skewed time stamps (the time change is ignored).
2343 Filter expressions on fields other than those in Token Ring headers will
2344 not correctly handle source-routed Token Ring packets.
2346 Filter expressions on fields other than those in 802.11 headers will not
2347 correctly handle 802.11 data packets with both To DS and From DS set.
2350 should chase header chain, but at this moment it does not.
2351 .BR "ip6 protochain"
2352 is supplied for this behavior.
2354 Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
2355 does not work against IPv6 packets.
2356 It only looks at IPv4 packets.
projects / dragonfly.git / blob