Move tcpdump-3.9/ to tcpdump/. No need for a versioned dir.
[dragonfly.git] / contrib / tcpdump / tcpdump.1
66170f0a 1.\" @(#) $Header: /tcpdump/master/tcpdump/tcpdump.1,v 2007/06/15 20:13:49 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.
25.TH TCPDUMP 1 "18 April 2005"
27tcpdump \- dump traffic on a network
30.B tcpdump
32.B \-AdDeflLnNOpqRStuUvxX
33] [
34.B \-c
35.I count
38.ti +8
40.B \-C
41.I file_size
42] [
43.B \-F
44.I file
47.ti +8
49.B \-i
50.I interface
53.B \-m
54.I module
57.B \-M
58.I secret
61.ti +8
63.B \-r
64.I file
67.B \-s
68.I snaplen
71.B \-T
72.I type
75.B \-w
76.I file
79.ti +8
81.B \-W
82.I filecount
85.ti +8
87.B \-E
88.I spi@ipaddr algo:secret,...
91.ti +8
93.B \-y
94.I datalinktype
97.B \-Z
98.I user
100.ti +8
102.I expression
108\fITcpdump\fP prints out a description of the contents of packets on a
109network interface that match the boolean \fIexpression\fP. It can also
110be run with the
111.B \-w
112flag, which causes it to save the packet data to a file for later
113analysis, and/or with the
114.B \-r
115flag, which causes it to read from a saved packet file rather than to
116read packets from a network interface. In all cases, only packets that
118.I expression
119will be processed by
120.IR tcpdump .
122.I Tcpdump
123will, if not run with the
124.B \-c
125flag, continue capturing packets until it is interrupted by a SIGINT
126signal (generated, for example, by typing your interrupt character,
127typically control-C) or a SIGTERM signal (typically generated with the
128.BR kill (1)
129command); if run with the
130.B \-c
131flag, it will capture packets until it is interrupted by a SIGINT or
132SIGTERM signal or the specified number of packets have been processed.
135.I tcpdump
136finishes capturing packets, it will report counts of:
138packets ``captured'' (this is the number of packets that
139.I tcpdump
140has received and processed);
142packets ``received by filter'' (the meaning of this depends on the OS on
143which you're running
144.IR tcpdump ,
145and possibly on the way the OS was configured - if a filter was
146specified on the command line, on some OSes it counts packets regardless
147of whether they were matched by the filter expression and, even if they
148were matched by the filter expression, regardless of whether
149.I tcpdump
150has read and processed them yet, on other OSes it counts only packets that were
151matched by the filter expression regardless of whether
152.I tcpdump
153has read and processed them yet, and on other OSes it counts only
154packets that were matched by the filter expression and were processed by
155.IR tcpdump );
157packets ``dropped by kernel'' (this is the number of packets that were
158dropped, due to a lack of buffer space, by the packet capture mechanism
159in the OS on which
160.I tcpdump
161is running, if the OS reports that information to applications; if not,
162it will be reported as 0).
164On platforms that support the SIGINFO signal, such as most BSDs
165(including Mac OS X) and Digital/Tru64 UNIX, it will report those counts
166when it receives a SIGINFO signal (generated, for example, by typing
167your ``status'' character, typically control-T, although on some
168platforms, such as Mac OS X, the ``status'' character is not set by
169default, so you must set it with
170.BR stty (1)
171in order to use it) and will continue capturing packets.
173Reading packets from a network interface may require that you have
174special privileges:
176.B Under SunOS 3.x or 4.x with NIT or BPF:
177You must have read access to
178.I /dev/nit
180.IR /dev/bpf* .
182.B Under Solaris with DLPI:
183You must have read/write access to the network pseudo device, e.g.
184.IR /dev/le .
185On at least some versions of Solaris, however, this is not sufficient to
187.I tcpdump
188to capture in promiscuous mode; on those versions of Solaris, you must
189be root, or
190.I tcpdump
191must be installed setuid to root, in order to capture in promiscuous
192mode. Note that, on many (perhaps all) interfaces, if you don't capture
193in promiscuous mode, you will not see any outgoing packets, so a capture
194not done in promiscuous mode may not be very useful.
196.B Under HP-UX with DLPI:
197You must be root or
198.I tcpdump
199must be installed setuid to root.
201.B Under IRIX with snoop:
202You must be root or
203.I tcpdump
204must be installed setuid to root.
206.B Under Linux:
207You must be root or
208.I tcpdump
209must be installed setuid to root (unless your distribution has a kernel
210that supports capability bits such as CAP_NET_RAW and code to allow
211those capability bits to be given to particular accounts and to cause
212those bits to be set on a user's initial processes when they log in, in
213which case you must have CAP_NET_RAW in order to capture and
214CAP_NET_ADMIN to enumerate network devices with, for example, the
215.B \-D
218.B Under ULTRIX and Digital UNIX/Tru64 UNIX:
219Any user may capture network traffic with
220.IR tcpdump .
221However, no user (not even the super-user) can capture in promiscuous
222mode on an interface unless the super-user has enabled promiscuous-mode
223operation on that interface using
224.IR pfconfig (8),
225and no user (not even the super-user) can capture unicast traffic
226received by or sent by the machine on an interface unless the super-user
227has enabled copy-all-mode operation on that interface using
228.IR pfconfig ,
230.I useful
231packet capture on an interface probably requires that either
232promiscuous-mode or copy-all-mode operation, or both modes of
233operation, be enabled on that interface.
235.B Under BSD (this includes Mac OS X):
236You must have read access to
237.I /dev/bpf*
238on systems that don't have a cloning BPF device, or to
239.I /dev/bpf
240on systems that do.
241On BSDs with a devfs (this includes Mac OS X), this might involve more
242than just having somebody with super-user access setting the ownership
243or permissions on the BPF devices - it might involve configuring devfs
244to set the ownership or permissions every time the system is booted,
245if the system even supports that; if it doesn't support that, you might
246have to find some other way to make that happen at boot time.
248Reading a saved packet file doesn't require special privileges.
251.B \-A
252Print each packet (minus its link level header) in ASCII. Handy for
253capturing web pages.
255.B \-c
256Exit after receiving \fIcount\fP packets.
258.B \-C
259Before writing a raw packet to a savefile, check whether the file is
260currently larger than \fIfile_size\fP and, if so, close the current
261savefile and open a new one. Savefiles after the first savefile will
262have the name specified with the
263.B \-w
264flag, with a number after it, starting at 1 and continuing upward.
265The units of \fIfile_size\fP are millions of bytes (1,000,000 bytes,
266not 1,048,576 bytes).
268.B \-d
269Dump the compiled packet-matching code in a human readable form to
270standard output and stop.
272.B \-dd
273Dump packet-matching code as a
274.B C
275program fragment.
277.B \-ddd
278Dump packet-matching code as decimal numbers (preceded with a count).
280.B \-D
281Print the list of the network interfaces available on the system and on
283.I tcpdump
284can capture packets. For each network interface, a number and an
285interface name, possibly followed by a text description of the
286interface, is printed. The interface name or the number can be supplied
287to the
288.B \-i
289flag to specify an interface on which to capture.
291This 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" );
294the number can be useful on Windows 2000 and later systems, where the
295interface name is a somewhat complex string.
298.B \-D
299flag will not be supported if
300.I tcpdump
301was built with an older version of
302.I libpcap
303that lacks the
304.B pcap_findalldevs()
307.B \-e
308Print the link-level header on each dump line.
310.B \-E
311Use \fIspi@ipaddr algo:secret\fP for decrypting IPsec ESP packets that
312are addressed to \fIaddr\fP and contain Security Parameter Index value
313\fIspi\fP. This combination may be repeated with comma or newline seperation.
315Note that setting the secret for IPv4 ESP packets is supported at this time.
317Algorithms may be
322\fBcast128-cbc\fP, or
324The default is \fBdes-cbc\fP.
325The ability to decrypt packets is only present if \fItcpdump\fP was compiled
326with cryptography enabled.
328\fIsecret\fP is the ASCII text for ESP secret key.
329If preceeded by 0x, then a hex value will be read.
331The option assumes RFC2406 ESP, not RFC1827 ESP.
332The option is only for debugging purposes, and
333the use of this option with a true `secret' key is discouraged.
334By presenting IPsec secret key onto command line
335you make it visible to others, via
336.IR ps (1)
337and other occasions.
339In addition to the above syntax, the syntax \fIfile name\fP may be used
340to have tcpdump read the provided file in. The file is opened upon
341receiving the first ESP packet, so any special permissions that tcpdump
342may have been given should already have been given up.
344.B \-f
345Print `foreign' IPv4 addresses numerically rather than symbolically
346(this option is intended to get around serious brain damage in
347Sun's NIS server \(em usually it hangs forever translating non-local
348internet numbers).
350The test for `foreign' IPv4 addresses is done using the IPv4 address and
351netmask of the interface on which capture is being done. If that
352address or netmask are not available, available, either because the
353interface on which capture is being done has no address or netmask or
354because the capture is being done on the Linux "any" interface, which
355can capture on more than one interface, this option will not work
358.B \-F
359Use \fIfile\fP as input for the filter expression.
360An additional expression given on the command line is ignored.
362.B \-i
363Listen on \fIinterface\fP.
364If unspecified, \fItcpdump\fP searches the system interface list for the
365lowest numbered, configured up interface (excluding loopback).
366Ties are broken by choosing the earliest match.
368On Linux systems with 2.2 or later kernels, an
369.I interface
370argument of ``any'' can be used to capture packets from all interfaces.
371Note that captures on the ``any'' device will not be done in promiscuous
374If the
375.B \-D
376flag is supported, an interface number as printed by that flag can be
377used as the
378.I interface
381.B \-l
382Make stdout line buffered.
383Useful if you want to see the data
384while capturing it.
387``tcpdump\ \ \-l\ \ |\ \ tee dat'' or
388``tcpdump\ \ \-l \ \ > dat\ \ &\ \ tail\ \ \-f\ \ dat''.
390.B \-L
391List the known data link types for the interface and exit.
393.B \-m
394Load SMI MIB module definitions from file \fImodule\fR.
395This option
396can be used several times to load several MIB modules into \fItcpdump\fP.
398.B \-M
399Use \fIsecret\fP as a shared secret for validating the digests found in
400TCP segments with the TCP-MD5 option (RFC 2385), if present.
402.B \-n
403Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
405.B \-N
406Don't print domain name qualification of host names.
408if you give this flag then \fItcpdump\fP will print ``nic''
409instead of ``''.
411.B \-O
412Do not run the packet-matching code optimizer.
413This is useful only
414if you suspect a bug in the optimizer.
416.B \-p
417\fIDon't\fP put the interface
418into promiscuous mode.
419Note that the interface might be in promiscuous
420mode for some other reason; hence, `-p' cannot be used as an abbreviation for
421`ether host {local-hw-addr} or ether broadcast'.
423.B \-q
424Quick (quiet?) output.
425Print less protocol information so output
426lines are shorter.
428.B \-R
429Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829).
430If specified, \fItcpdump\fP will not print replay prevention field.
431Since there is no protocol version field in ESP/AH specification,
432\fItcpdump\fP cannot deduce the version of ESP/AH protocol.
434.B \-r
435Read packets from \fIfile\fR (which was created with the
436.B \-w
438Standard input is used if \fIfile\fR is ``-''.
440.B \-S
441Print absolute, rather than relative, TCP sequence numbers.
443.B \-s
444Snarf \fIsnaplen\fP bytes of data from each packet rather than the
445default of 68 (with SunOS's NIT, the minimum is actually 96).
44668 bytes is adequate for IP, ICMP, TCP
447and UDP but may truncate protocol information from name server and NFS
448packets (see below).
449Packets truncated because of a limited snapshot
450are indicated in the output with ``[|\fIproto\fP]'', where \fIproto\fP
451is the name of the protocol level at which the truncation has occurred.
452Note that taking larger snapshots both increases
453the amount of time it takes to process packets and, effectively,
454decreases the amount of packet buffering.
455This may cause packets to be
457You should limit \fIsnaplen\fP to the smallest number that will
458capture the protocol information you're interested in.
460\fIsnaplen\fP to 0 means use the required length to catch whole packets.
462.B \-T
463Force packets selected by "\fIexpression\fP" to be interpreted the
464specified \fItype\fR.
465Currently 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),
475\fBwb\fR (distributed White Board).
477.B \-t
478\fIDon't\fP print a timestamp on each dump line.
480.B \-tt
481Print an unformatted timestamp on each dump line.
483.B \-ttt
484Print a delta (in micro-seconds) between current and previous line
485on each dump line.
487.B \-tttt
488Print a timestamp in default format proceeded by date on each dump line.
490.B \-u
491Print undecoded NFS handles.
493.B \-U
494Make output saved via the
495.B \-w
496option ``packet-buffered''; i.e., as each packet is saved, it will be
497written to the output file, rather than being written only when the
498output buffer fills.
501.B \-U
502flag will not be supported if
503.I tcpdump
504was built with an older version of
505.I libpcap
506that lacks the
507.B pcap_dump_flush()
510.B \-v
511When parsing and printing, produce (slightly more) verbose output.
512For example, the time to live,
513identification, total length and options in an IP packet are printed.
514Also enables additional packet integrity checks such as verifying the
515IP and ICMP header checksum.
517When writing to a file with the
518.B \-w
519option, report, every 10 seconds, the number of packets captured.
521.B \-vv
522Even more verbose output.
523For example, additional fields are
524printed from NFS reply packets, and SMB packets are fully decoded.
526.B \-vvv
527Even more verbose output.
528For example,
529telnet \fBSB\fP ... \fBSE\fP options
530are printed in full.
532.B \-X
533Telnet options are printed in hex as well.
535.B \-w
536Write the raw packets to \fIfile\fR rather than parsing and printing
537them out.
538They can later be printed with the \-r option.
539Standard output is used if \fIfile\fR is ``-''.
541.B \-W
542Used in conjunction with the
543.B \-C
544option, this will limit the number
545of files created to the specified number, and begin overwriting files
546from the beginning, thus creating a 'rotating' buffer.
547In addition, it will name
548the files with enough leading 0s to support the maximum number of
549files, allowing them to sort correctly.
551.B \-x
552When parsing and printing,
553in addition to printing the headers of each packet, print the data of
554each packet (minus its link level header) in hex.
555The smaller of the entire packet or
556.I snaplen
557bytes will be printed. Note that this is the entire link-layer
558packet, so for link layers that pad (e.g. Ethernet), the padding bytes
559will also be printed when the higher layer packet is shorter than the
560required padding.
562.B \-xx
563When parsing and printing,
564in addition to printing the headers of each packet, print the data of
565each packet,
566.I including
567its link level header, in hex.
569.B \-X
570When parsing and printing,
571in addition to printing the headers of each packet, print the data of
572each packet (minus its link level header) in hex and ASCII.
573This is very handy for analysing new protocols.
575.B \-XX
576When parsing and printing,
577in addition to printing the headers of each packet, print the data of
578each packet,
579.I including
580its link level header, in hex and ASCII.
582.B \-y
583Set the data link type to use while capturing packets to \fIdatalinktype\fP.
585.B \-Z
586Drops privileges (if root) and changes user ID to
587.I user
588and the group ID to the primary group of
589.IR user .
591This behavior can also be enabled by default at compile time.
592.IP "\fI expression\fP"
594selects which packets will be dumped.
595If no \fIexpression\fP
596is given, all packets on the net will be dumped.
598only packets for which \fIexpression\fP is `true' will be dumped.
600The \fIexpression\fP consists of one or more
601.I primitives.
602Primitives usually consist of an
603.I id
604(name or number) preceded by one or more qualifiers.
605There are three
606different kinds of qualifier:
607.IP \fItype\fP
608qualifiers say what kind of thing the id name or number refers to.
609Possible types are
610.BR host ,
611.B net ,
612.B port
614.BR portrange .
615E.g., `host foo', `net 128.3', `port 20', `portrange 6000-6008'.
616If there is no type
618.B host
619is assumed.
620.IP \fIdir\fP
621qualifiers specify a particular transfer direction to and/or from
622.IR id .
623Possible directions are
624.BR src ,
625.BR dst ,
626.B "src or dst"
628.B "src and"
629.BR dst .
630E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.
632there is no dir qualifier,
633.B "src or dst"
634is assumed.
635For some link layers, such as SLIP and the ``cooked'' Linux capture mode
636used for the ``any'' device and for some other device types, the
637.B inbound
639.B outbound
640qualifiers can be used to specify a desired direction.
641.IP \fIproto\fP
642qualifiers restrict the match to a particular protocol.
644protos 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
656.BR udp .
657E.g., `ether src foo', `arp net 128.3', `tcp port 21', `udp portrange
659If there is
660no proto qualifier, all protocols consistent with the type are
662E.g., `src foo' means `(ip or arp or rarp) src foo'
663(except the latter is not legal syntax), `net bar' means `(ip or
664arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.
666[`fddi' is actually an alias for `ether'; the parser treats them
667identically as meaning ``the data link level used on the specified
668network interface.'' FDDI headers contain Ethernet-like source
669and destination addresses, and often contain Ethernet-like packet
670types, so you can filter on these FDDI fields just as with the
671analogous Ethernet fields.
672FDDI headers also contain other fields,
673but you cannot name them explicitly in a filter expression.
675Similarly, `tr' and `wlan' are aliases for `ether'; the previous
676paragraph's statements about FDDI headers also apply to Token Ring
677and 802.11 wireless LAN headers. For 802.11 headers, the destination
678address is the DA field and the source address is the SA field; the
679BSSID, RA, and TA fields aren't tested.]
681In addition to the above, there are some special `primitive' keywords
682that don't follow the pattern:
683.BR gateway ,
684.BR broadcast ,
685.BR less ,
686.B greater
687and arithmetic expressions.
688All of these are described below.
690More complex filter expressions are built up by using the words
691.BR and ,
692.B or
694.B not
695to combine primitives.
696E.g., `host foo and not port ftp and not port ftp-data'.
697To save typing, identical qualifier lists can be omitted.
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'.
702Allowable primitives are:
703.IP "\fBdst host \fIhost\fR"
704True if the IPv4/v6 destination field of the packet is \fIhost\fP,
705which may be either an address or a name.
706.IP "\fBsrc host \fIhost\fR"
707True if the IPv4/v6 source field of the packet is \fIhost\fP.
708.IP "\fBhost \fIhost\fP
709True if either the IPv4/v6 source or destination of the packet is \fIhost\fP.
711Any of the above host expressions can be prepended with the keywords,
712\fBip\fP, \fBarp\fP, \fBrarp\fP, or \fBip6\fP as in: +.5i
715\fBip host \fIhost\fR -.5i
718which is equivalent to: +.5i
721\fBether proto \fI\\ip\fB and host \fIhost\fR -.5i
724If \fIhost\fR is a name with multiple IP addresses, each address will
725be checked for a match.
726.IP "\fBether dst \fIehost\fP
727True if the Ethernet destination address is \fIehost\fP.
729may be either a name from /etc/ethers or a number (see
730.IR ethers (3N)
731for numeric format).
732.IP "\fBether src \fIehost\fP
733True if the Ethernet source address is \fIehost\fP.
734.IP "\fBether host \fIehost\fP
735True if either the Ethernet source or destination address is \fIehost\fP.
736.IP "\fBgateway\fP \fIhost\fP
737True if the packet used \fIhost\fP as a gateway.
738I.e., the Ethernet
739source or destination address was \fIhost\fP but neither the IP source
740nor the IP destination was \fIhost\fP.
741\fIHost\fP must be a name and
742must be found both by the machine's host-name-to-IP-address resolution
743mechanisms (host name file, DNS, NIS, etc.) and by the machine's
744host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.).
745(An equivalent expression is +.5i
748\fBether host \fIehost \fBand not host \fIhost\fR -.5i
751which can be used with either names or numbers for \fIhost / ehost\fP.)
752This syntax does not work in IPv6-enabled configuration at this moment.
753.IP "\fBdst net \fInet\fR"
754True if the IPv4/v6 destination address of the packet has a network
755number of \fInet\fP.
756\fINet\fP may be either a name from the networks database
757(/etc/networks, etc.) or a network number.
758An IPv4 network number can be written as a dotted quad (e.g.,,
759dotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or single
760number (e.g., 10); the netmask is for a dotted quad
761(which means that it's really a host match), for a dotted
762triple, for a dotted pair, or for a single number.
763An IPv6 network number must be written out fully; the netmask is
764ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 "network" matches are really always
765host matches, and a network match requires a netmask length.
766.IP "\fBsrc net \fInet\fR"
767True if the IPv4/v6 source address of the packet has a network
768number of \fInet\fP.
769.IP "\fBnet \fInet\fR"
770True if either the IPv4/v6 source or destination address of the packet has a network
771number of \fInet\fP.
772.IP "\fBnet \fInet\fR \fBmask \fInetmask\fR"
773True if the IPv4 address matches \fInet\fR with the specific \fInetmask\fR.
774May be qualified with \fBsrc\fR or \fBdst\fR.
775Note that this syntax is not valid for IPv6 \fInet\fR.
776.IP "\fBnet \fInet\fR/\fIlen\fR"
777True if the IPv4/v6 address matches \fInet\fR with a netmask \fIlen\fR
778bits wide.
779May be qualified with \fBsrc\fR or \fBdst\fR.
780.IP "\fBdst port \fIport\fR"
781True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
782destination port value of \fIport\fP.
783The \fIport\fP can be a number or a name used in /etc/services (see
784.IR tcp (4P)
786.IR udp (4P)).
787If a name is used, both the port
788number and protocol are checked.
789If a number or ambiguous name is used,
790only the port number is checked (e.g., \fBdst port 513\fR will print both
791tcp/login traffic and udp/who traffic, and \fBport domain\fR will print
792both tcp/domain and udp/domain traffic).
793.IP "\fBsrc port \fIport\fR"
794True if the packet has a source port value of \fIport\fP.
795.IP "\fBport \fIport\fR"
796True if either the source or destination port of the packet is \fIport\fP.
797.IP "\fBdst portrange \fIport1\fB-\fIport2\fR"
798True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a
799destination port value between \fIport1\fP and \fIport2\fP.
800.I port1
802.I port2
803are interpreted in the same fashion as the
804.I port
805parameter for
806.BR port .
807.IP "\fBsrc portrange \fIport1\fB-\fIport2\fR"
808True if the packet has a source port value between \fIport1\fP and
810.IP "\fBportrange \fIport1\fB-\fIport2\fR"
811True if either the source or destination port of the packet is between
812\fIport1\fP and \fIport2\fP.
814Any of the above port or port range expressions can be prepended with
815the keywords, \fBtcp\fP or \fBudp\fP, as in: +.5i
818\fBtcp src port \fIport\fR -.5i
821which matches only tcp packets whose source port is \fIport\fP.
822.IP "\fBless \fIlength\fR"
823True if the packet has a length less than or equal to \fIlength\fP.
824This is equivalent to: +.5i
827\fBlen <= \fIlength\fP. -.5i
830.IP "\fBgreater \fIlength\fR"
831True if the packet has a length greater than or equal to \fIlength\fP.
832This is equivalent to: +.5i
835\fBlen >= \fIlength\fP. -.5i
838.IP "\fBip proto \fIprotocol\fR"
839True if the packet is an IPv4 packet (see
840.IR ip (4P))
841of 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.
845Note that the identifiers \fBtcp\fP, \fBudp\fP, and \fBicmp\fP are also
846keywords and must be escaped via backslash (\\), which is \\\\ in the C-shell.
847Note that this primitive does not chase the protocol header chain.
848.IP "\fBip6 proto \fIprotocol\fR"
849True if the packet is an IPv6 packet of protocol type \fIprotocol\fP.
850Note that this primitive does not chase the protocol header chain.
851.IP "\fBip6 protochain \fIprotocol\fR"
852True if the packet is IPv6 packet,
853and contains protocol header with type \fIprotocol\fR
854in its protocol header chain.
855For example, +.5i
858\fBip6 protochain 6\fR -.5i
861matches any IPv6 packet with TCP protocol header in the protocol header chain.
862The packet may contain, for example,
863authentication header, routing header, or hop-by-hop option header,
864between IPv6 header and TCP header.
865The BPF code emitted by this primitive is complex and
866cannot be optimized by BPF optimizer code in \fItcpdump\fP,
867so this can be somewhat slow.
868.IP "\fBip protochain \fIprotocol\fR"
869Equivalent to \fBip6 protochain \fIprotocol\fR, but this is for IPv4.
870.IP "\fBether broadcast\fR"
871True if the packet is an Ethernet broadcast packet.
872The \fIether\fP
873keyword is optional.
874.IP "\fBip broadcast\fR"
875True if the packet is an IPv4 broadcast packet.
876It checks for both the all-zeroes and all-ones broadcast conventions,
877and looks up the subnet mask on the interface on which the capture is
878being done.
880If the subnet mask of the interface on which the capture is being done
881is not available, either because the interface on which capture is being
882done 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
884check will not work correctly.
885.IP "\fBether multicast\fR"
886True if the packet is an Ethernet multicast packet.
887The \fBether\fP
888keyword is optional.
889This is shorthand for `\fBether[0] & 1 != 0\fP'.
890.IP "\fBip multicast\fR"
891True if the packet is an IPv4 multicast packet.
892.IP "\fBip6 multicast\fR"
893True if the packet is an IPv6 multicast packet.
894.IP "\fBether proto \fIprotocol\fR"
895True 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.
900Note these identifiers are also keywords
901and must be escaped via backslash (\\).
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
906protocol identification comes from the 802.2 Logical Link Control (LLC)
907header, which is usually layered on top of the FDDI, Token Ring, or
908802.11 header.
910When filtering for most protocol identifiers on FDDI, Token Ring, or
911802.11, \fItcpdump\fR checks only the protocol ID field of an LLC header
912in so-called SNAP format with an Organizational Unit Identifier (OUI) of
9130x000000, for encapsulated Ethernet; it doesn't check whether the packet
914is in SNAP format with an OUI of 0x000000.
915The exceptions are:
919\fItcpdump\fR checks the DSAP (Destination Service Access Point) and
920SSAP (Source Service Access Point) fields of the LLC header;
922\fBstp\fP and \fBnetbeui\fP
923\fItcpdump\fR checks the DSAP of the LLC header;
926\fItcpdump\fR checks for a SNAP-format packet with an OUI of 0x080007
927and the AppleTalk etype.
930In the case of Ethernet, \fItcpdump\fR checks the Ethernet type field
931for most of those protocols. The exceptions are:
934\fBiso\fP, \fBstp\fP, and \fBnetbeui\fP
935\fItcpdump\fR checks for an 802.3 frame and then checks the LLC header as
936it does for FDDI, Token Ring, and 802.11;
939\fItcpdump\fR checks both for the AppleTalk etype in an Ethernet frame and
940for a SNAP-format packet as it does for FDDI, Token Ring, and 802.11;
943\fItcpdump\fR checks for the AppleTalk ARP etype in either an Ethernet
944frame or an 802.2 SNAP frame with an OUI of 0x000000;
947\fItcpdump\fR checks for the IPX etype in an Ethernet frame, the IPX
948DSAP in the LLC header, the 802.3-with-no-LLC-header encapsulation of
949IPX, and the IPX etype in a SNAP frame.
951.IP "\fBdecnet src \fIhost\fR"
952True if the DECNET source address is
953.IR host ,
954which may be an address of the form ``10.123'', or a DECNET host
956[DECNET host name support is only available on ULTRIX systems
957that are configured to run DECNET.]
958.IP "\fBdecnet dst \fIhost\fR"
959True if the DECNET destination address is
960.IR host .
961.IP "\fBdecnet host \fIhost\fR"
962True if either the DECNET source or destination address is
963.IR host .
964.IP "\fBifname \fIinterface\fR"
965True if the packet was logged as coming from the specified interface (applies
966only to packets logged by OpenBSD's
967.BR pf (4)).
968.IP "\fBon \fIinterface\fR"
969Synonymous with the
970.B ifname
972.IP "\fBrnr \fInum\fR"
973True 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"
977Synonomous with the
978.B rnr
980.IP "\fBreason \fIcode\fR"
981True if the packet was logged with the specified PF reason code. The known
982codes are:
983.BR match ,
984.BR bad-offset ,
985.BR fragment ,
986.BR short ,
987.BR normalize ,
989.B memory
990(applies only to packets logged by OpenBSD's
991.BR pf (4)).
992.IP "\fBrset \fIname\fR"
993True if the packet was logged as matching the specified PF ruleset
994name of an anchored ruleset (applies only to packets logged by
995.BR pf (4)).
996.IP "\fBruleset \fIname\fR"
997Synonomous with the
998.B rset
1000.IP "\fBsrnr \fInum\fR"
1001True if the packet was logged as matching the specified PF rule number
1002of an anchored ruleset (applies only to packets logged by
1003.BR pf (4)).
1004.IP "\fBsubrulenum \fInum\fR"
1005Synonomous with the
1006.B srnr
1008.IP "\fBaction \fIact\fR"
1009True if PF took the specified action when the packet was logged. Known actions
1011.B pass
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"
1017Abbreviations for: +.5i
1020\fBether proto \fIp\fR -.5i
1023where \fIp\fR is one of the above protocols.
1024.IP "\fBlat\fR, \fBmoprc\fR, \fBmopdl\fR"
1025Abbreviations for: +.5i
1028\fBether proto \fIp\fR -.5i
1031where \fIp\fR is one of the above protocols.
1032Note that
1033\fItcpdump\fP does not currently know how to parse these protocols.
1034.IP "\fBvlan \fI[vlan_id]\fR"
1035True if the packet is an IEEE 802.1Q VLAN packet.
1036If \fI[vlan_id]\fR is specified, only true if the packet has the specified
1038Note that the first \fBvlan\fR keyword encountered in \fIexpression\fR
1039changes the decoding offsets for the remainder of \fIexpression\fR on
1040the 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
1042hierarchies. Each use of that expression increments the filter offsets
1043by 4.
1045For example: +.5i
1048\fBvlan 100 && vlan 200\fR -.5i
1051filters on VLAN 200 encapsulated within VLAN 100, and +.5i
1054\fBvlan && vlan 300 && ip\fR -.5i
1057filters IPv4 protocols encapsulated in VLAN 300 encapsulated within any
1058higher order VLAN.
1059.IP "\fBmpls \fI[label_num]\fR"
1060True if the packet is an MPLS packet.
1061If \fI[label_num]\fR is specified, only true is the packet has the specified
1063Note that the first \fBmpls\fR keyword encountered in \fIexpression\fR
1064changes the decoding offsets for the remainder of \fIexpression\fR on
1065the 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
1067filter on MPLS hierarchies. Each use of that expression increments the
1068filter offsets by 4.
1070For example: +.5i
1073\fBmpls 100000 && mpls 1024\fR -.5i
1076filters packets with an outer label of 100000 and an inner label of
10771024, and +.5i
1080\fBmpls && mpls 1024 && host\fR -.5i
1083filters packets to or from with an inner label of 1024 and
1084any outer label.
1085.IP \fBpppoed\fP
1086True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet
1087type 0x8863).
1088.IP \fBpppoes\fP
1089True if the packet is a PPP-over-Ethernet Session packet (Ethernet
1090type 0x8864).
1091Note that the first \fBpppoes\fR keyword encountered in \fIexpression\fR
1092changes the decoding offsets for the remainder of \fIexpression\fR on
1093the assumption that the packet is a PPPoE session packet.
1095For example: +.5i
1098\fBpppoes && ip\fR -.5i
1101filters IPv4 protocols encapsulated in PPPoE.
1102.IP "\fBtcp\fR, \fBudp\fR, \fBicmp\fR"
1103Abbreviations for: +.5i
1106\fBip proto \fIp\fR\fB or ip6 proto \fIp\fR -.5i
1109where \fIp\fR is one of the above protocols.
1110.IP "\fBiso proto \fIprotocol\fR"
1111True 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"
1115Abbreviations for: +.5i
1118\fBiso proto \fIp\fR -.5i
1121where \fIp\fR is one of the above protocols.
1122.IP "\fBl1\fR, \fBl2\fR, \fBiih\fR, \fBlsp\fR, \fBsnp\fR, \fBcsnp\fR, \fBpsnp\fR"
1123Abbreviations for IS-IS PDU types.
1124.IP "\fBvpi\fP \fIn\fR
1125True if the packet is an ATM packet, for SunATM on Solaris, with a
1126virtual path identifier of
1127.IR n .
1128.IP "\fBvci\fP \fIn\fR
1129True if the packet is an ATM packet, for SunATM on Solaris, with a
1130virtual channel identifier of
1131.IR n .
1132.IP \fBlane\fP
1133True if the packet is an ATM packet, for SunATM on Solaris, and is
1134an ATM LANE packet.
1135Note that the first \fBlane\fR keyword encountered in \fIexpression\fR
1136changes the tests done in the remainder of \fIexpression\fR
1137on the assumption that the packet is either a LANE emulated Ethernet
1138packet or a LANE LE Control packet. If \fBlane\fR isn't specified, the
1139tests are done under the assumption that the packet is an
1140LLC-encapsulated packet.
1141.IP \fBllc\fP
1142True if the packet is an ATM packet, for SunATM on Solaris, and is
1143an LLC-encapsulated packet.
1144.IP \fBoamf4s\fP
1145True if the packet is an ATM packet, for SunATM on Solaris, and is
1146a segment OAM F4 flow cell (VPI=0 & VCI=3).
1147.IP \fBoamf4e\fP
1148True if the packet is an ATM packet, for SunATM on Solaris, and is
1149an end-to-end OAM F4 flow cell (VPI=0 & VCI=4).
1150.IP \fBoamf4\fP
1151True if the packet is an ATM packet, for SunATM on Solaris, and is
1152a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
1153.IP \fBoam\fP
1154True if the packet is an ATM packet, for SunATM on Solaris, and is
1155a segment or end-to-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).
1156.IP \fBmetac\fP
1157True if the packet is an ATM packet, for SunATM on Solaris, and is
1158on a meta signaling circuit (VPI=0 & VCI=1).
1159.IP \fBbcc\fP
1160True if the packet is an ATM packet, for SunATM on Solaris, and is
1161on a broadcast signaling circuit (VPI=0 & VCI=2).
1162.IP \fBsc\fP
1163True if the packet is an ATM packet, for SunATM on Solaris, and is
1164on a signaling circuit (VPI=0 & VCI=5).
1165.IP \fBilmic\fP
1166True if the packet is an ATM packet, for SunATM on Solaris, and is
1167on an ILMI circuit (VPI=0 & VCI=16).
1168.IP \fBconnectmsg\fP
1169True if the packet is an ATM packet, for SunATM on Solaris, and is
1170on a signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1171Connect Ack, Release, or Release Done message.
1172.IP \fBmetaconnect\fP
1173True if the packet is an ATM packet, for SunATM on Solaris, and is
1174on a meta signaling circuit and is a Q.2931 Setup, Call Proceeding, Connect,
1175Release, or Release Done message.
1176.IP "\fIexpr relop expr\fR"
1177True if the relation holds, where \fIrelop\fR is one of >, <, >=, <=, =,
1178!=, and \fIexpr\fR is an arithmetic expression composed of integer
1179constants (expressed in standard C syntax), the normal binary operators
1180[+, -, *, /, &, |, <<, >>], a length operator, and special packet data
1181accessors. Note that all comparisons are unsigned, so that, for example,
11820x80000000 and 0xffffffff are > 0.
1183To access
1184data inside the packet, use the following syntax: +.5i
1187\fIproto\fB [ \fIexpr\fB : \fIsize\fB ]\fR -.5i
1190\fIProto\fR is one of \fBether, fddi, tr, wlan, ppp, slip, link,
1191ip, arp, rarp, tcp, udp, icmp, ip6\fR or \fBradio\fR, and
1192indicates the protocol layer for the index operation.
1193(\fBether, fddi, wlan, tr, ppp, slip\fR and \fBlink\fR all refer to the
1194link layer. \fBradio\fR refers to the "radio header" added to some
1195802.11 captures.)
1196Note that \fItcp, udp\fR and other upper-layer protocol types only
1197apply to IPv4, not IPv6 (this will be fixed in the future).
1198The byte offset, relative to the indicated protocol layer, is
1199given by \fIexpr\fR.
1200\fISize\fR is optional and indicates the number of bytes in the
1201field of interest; it can be either one, two, or four, and defaults to one.
1202The length operator, indicated by the keyword \fBlen\fP, gives the
1203length of the packet.
1205For example, `\fBether[0] & 1 != 0\fP' catches all multicast traffic.
1206The expression `\fBip[0] & 0xf != 5\fP'
1207catches all IPv4 packets with options.
1208The expression
1209`\fBip[6:2] & 0x1fff = 0\fP'
1210catches only unfragmented IPv4 datagrams and frag zero of fragmented
1211IPv4 datagrams.
1212This check is implicitly applied to the \fBtcp\fP and \fBudp\fP
1213index operations.
1214For instance, \fBtcp[0]\fP always means the first
1215byte of the TCP \fIheader\fP, and never means the first byte of an
1216intervening fragment.
1218Some offsets and field values may be expressed as names rather than
1219as numeric values.
1220The following protocol header field offsets are
1221available: \fBicmptype\fP (ICMP type field), \fBicmpcode\fP (ICMP
1222code field), and \fBtcpflags\fP (TCP flags field).
1224The 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.
1231The 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.
1235Primitives may be combined using:
1237A parenthesized group of primitives and operators
1238(parentheses are special to the Shell and must be escaped).
1240Negation (`\fB!\fP' or `\fBnot\fP').
1242Concatenation (`\fB&&\fP' or `\fBand\fP').
1244Alternation (`\fB||\fP' or `\fBor\fP').
1246Negation has highest precedence.
1247Alternation and concatenation have equal precedence and associate
1248left to right.
1249Note that explicit \fBand\fR tokens, not juxtaposition,
1250are now required for concatenation.
1252If an identifier is given without a keyword, the most recent keyword
1253is assumed.
1254For example, +.5i
1257\fBnot host vs and ace\fR -.5i
1260is short for +.5i
1263\fBnot host vs and host ace\fR -.5i
1266which should not be confused with +.5i
1269\fBnot ( host vs or ace )\fR -.5i
1273Expression arguments can be passed to \fItcpdump\fP as either a single
1274argument or as multiple arguments, whichever is more convenient.
1275Generally, if the expression contains Shell metacharacters, it is
1276easier to pass it as a single, quoted argument.
1277Multiple arguments are concatenated with spaces before being parsed.
1280To print all packets arriving at or departing from \fIsundown\fP:
1283\fBtcpdump host sundown\fP
1287To print traffic between \fIhelios\fR and either \fIhot\fR or \fIace\fR:
1290\fBtcpdump host helios and \\( hot or ace \\)\fP
1294To print all IP packets between \fIace\fR and any host except \fIhelios\fR:
1297\fBtcpdump ip host ace and not helios\fP
1301To print all traffic between local hosts and hosts at Berkeley:
1305tcpdump net ucb-ether
1309To 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):
1315tcpdump 'gateway snup and (port ftp or ftp-data)'
1319To print traffic neither sourced from nor destined for local hosts
1320(if you gateway to one other net, this stuff should never make it
1321onto your local net).
1325tcpdump ip and not net \fIlocalnet\fP
1329To print the start and end packets (the SYN and FIN packets) of each
1330TCP conversation that involves a non-local host.
1334tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net \fIlocalnet\fP'
1338To print all IPv4 HTTP packets to and from port 80, i.e. print only
1339packets that contain data, not, for example, SYN and FIN packets and
1340ACK-only packets. (IPv6 is left as an exercise for the reader.)
1344tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
1348To print IP packets longer than 576 bytes sent through gateway \fIsnup\fP:
1352tcpdump 'gateway snup and ip[2:2] > 576'
1356To print IP broadcast or multicast packets that were
1357.I not
1358sent via Ethernet broadcast or multicast:
1362tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
1366To print all ICMP packets that are not echo requests/replies (i.e., not
1367ping packets):
1371tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
1376The output of \fItcpdump\fP is protocol dependent.
1377The following
1378gives a brief description and examples of most of the formats. HD
1380.sp 1.5
1384Link Level Headers
1386If the '-e' option is given, the link level header is printed out.
1387On Ethernets, the source and destination addresses, protocol,
1388and packet length are printed.
1390On FDDI networks, the '-e' option causes \fItcpdump\fP to print
1391the `frame control' field, the source and destination addresses,
1392and the packet length.
1393(The `frame control' field governs the
1394interpretation of the rest of the packet.
1395Normal packets (such
1396as those containing IP datagrams) are `async' packets, with a priority
1397value between 0 and 7; for example, `\fBasync4\fR'.
1398Such packets
1399are assumed to contain an 802.2 Logical Link Control (LLC) packet;
1400the LLC header is printed if it is \fInot\fR an ISO datagram or a
1401so-called SNAP packet.
1403On Token Ring networks, the '-e' option causes \fItcpdump\fP to print
1404the `access control' and `frame control' fields, the source and
1405destination addresses, and the packet length.
1406As on FDDI networks,
1407packets are assumed to contain an LLC packet.
1408Regardless of whether
1409the '-e' option is specified or not, the source routing information is
1410printed for source-routed packets.
1412On 802.11 networks, the '-e' option causes \fItcpdump\fP to print
1413the `frame control' fields, all of the addresses in the 802.11 header,
1414and the packet length.
1415As on FDDI networks,
1416packets are assumed to contain an LLC packet.
1418\fI(N.B.: The following description assumes familiarity with
1419the SLIP compression algorithm described in RFC-1144.)\fP
1421On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound),
1422packet type, and compression information are printed out.
1423The packet type is printed first.
1424The three types are \fIip\fP, \fIutcp\fP, and \fIctcp\fP.
1425No further link information is printed for \fIip\fR packets.
1426For TCP packets, the connection identifier is printed following the type.
1427If the packet is compressed, its encoded header is printed out.
1428The special cases are printed out as
1429\fB*S+\fIn\fR and \fB*SA+\fIn\fR, where \fIn\fR is the amount by which
1430the sequence number (or sequence number and ack) has changed.
1431If it is not a special case,
1432zero or more changes are printed.
1433A change is indicated by U (urgent pointer), W (window), A (ack),
1434S (sequence number), and I (packet ID), followed by a delta (+n or -n),
1435or a new value (=n).
1436Finally, the amount of data in the packet and compressed header length
1437are printed.
1439For example, the following line shows an outbound compressed TCP packet,
1440with an implicit connection identifier; the ack has changed by 6,
1441the sequence number by 49, and the packet ID by 6; there are 3 bytes of
1442data and 6 bytes of compressed header:
1445\fBO ctcp * A+6 S+49 I+6 3 (6)\fP
1449ARP/RARP Packets
1451Arp/rarp output shows the type of request and its arguments.
1453format is intended to be self explanatory.
1454Here is a short sample taken from the start of an `rlogin' from
1455host \fIrtsg\fP to host \fIcsam\fP:
1458.sp .5
1459\f(CWarp who-has csam tell rtsg
1460arp reply csam is-at CSAM\fR
1461.sp .5
1464The first line says that rtsg sent an arp packet asking
1465for the Ethernet address of internet host csam.
1467replies with its Ethernet address (in this example, Ethernet addresses
1468are in caps and internet addresses in lower case).
1470This would look less redundant if we had done \fItcpdump \-n\fP:
1473.sp .5
1474\f(CWarp who-has tell
1475arp reply is-at 02:07:01:00:01:c4\fP
1479If we had done \fItcpdump \-e\fP, the fact that the first packet is
1480broadcast and the second is point-to-point would be visible:
1483.sp .5
1484\f(CWRTSG Broadcast 0806 64: arp who-has csam tell rtsg
1485CSAM RTSG 0806 64: arp reply csam is-at CSAM\fR
1486.sp .5
1489For the first packet this says the Ethernet source address is RTSG, the
1490destination is the Ethernet broadcast address, the type field
1491contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
1493TCP Packets
1495\fI(N.B.:The following description assumes familiarity with
1496the TCP protocol described in RFC-793.
1497If you are not familiar
1498with the protocol, neither this description nor \fItcpdump\fP will
1499be of much use to you.)\fP
1501The general format of a tcp protocol line is:
1504.sp .5
1505\fIsrc > dst: flags data-seqno ack window urgent options\fP
1506.sp .5
1509\fISrc\fP and \fIdst\fP are the source and destination IP
1510addresses and ports.
1511\fIFlags\fP are some combination of S (SYN),
1512F (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
1515by the data in this packet (see example below).
1516\fIAck\fP is sequence number of the next data expected the other
1517direction on this connection.
1518\fIWindow\fP is the number of bytes of receive buffer space available
1519the 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>).
1523\fISrc, dst\fP and \fIflags\fP are always present.
1524The other fields
1525depend on the contents of the packet's tcp protocol header and
1526are output only if appropriate.
1528Here is the opening portion of an rlogin from host \fIrtsg\fP to
1529host \fIcsam\fP.
1532.sp .5
1533\s-2\f(CWrtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
1534csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
1535rtsg.1023 > csam.login: . ack 1 win 4096
1536rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
1537csam.login > rtsg.1023: . ack 2 win 4096
1538rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
1539csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
1540csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
1541csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1\fR\s+2
1542.sp .5
1545The first line says that tcp port 1023 on rtsg sent a packet
1546to port \fIlogin\fP
1547on csam.
1548The \fBS\fP indicates that the \fISYN\fP flag was set.
1549The packet sequence number was 768512 and it contained no data.
1550(The notation is `first:last(nbytes)' which means `sequence
1551numbers \fIfirst\fP
1552up to but not including \fIlast\fP which is \fInbytes\fP bytes of user data'.)
1553There was no piggy-backed ack, the available receive window was 4096
1554bytes and there was a max-segment-size option requesting an mss of
15551024 bytes.
1557Csam replies with a similar packet except it includes a piggy-backed
1558ack for rtsg's SYN.
1559Rtsg then acks csam's SYN.
1560The `.' means no
1561flags were set.
1562The packet contained no data so there is no data sequence number.
1563Note that the ack sequence
1564number is a small integer (1).
1565The first time \fItcpdump\fP sees a
1566tcp `conversation', it prints the sequence number from the packet.
1567On subsequent packets of the conversation, the difference between
1568the current packet's sequence number and this initial sequence number
1569is printed.
1570This means that sequence numbers after the
1571first can be interpreted
1572as relative byte positions in the conversation's data stream (with the
1573first data byte each direction being `1').
1574`-S' will override this
1575feature, causing the original sequence numbers to be output.
1577On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20
1578in the rtsg \(-> csam side of the conversation).
1579The PUSH flag is set in the packet.
1580On the 7th line, csam says it's received data sent by rtsg up to
1581but not including byte 21.
1582Most of this data is apparently sitting in the
1583socket buffer since csam's receive window has gotten 19 bytes smaller.
1584Csam also sends one byte of data to rtsg in this packet.
1585On the 8th and 9th lines,
1586csam sends two bytes of urgent, pushed data to rtsg.
1588If the snapshot was small enough that \fItcpdump\fP didn't capture
1589the full TCP header, it interprets as much of the header as it can
1590and then reports ``[|\fItcp\fP]'' to indicate the remainder could not
1591be interpreted.
1592If the header contains a bogus option (one with a length
1593that's either too small or beyond the end of the header), \fItcpdump\fP
1594reports it as ``[\fIbad opt\fP]'' and does not interpret any further
1595options (since it's impossible to tell where they start).
1596If the header
1597length indicates options are present but the IP datagram length is not
1598long enough for the options to actually be there, \fItcpdump\fP reports
1599it as ``[\fIbad hdr length\fP]''.
1601.B Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)
1603There are 8 bits in the control bits section of the TCP header:
1605.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
1607Let's assume that we want to watch packets used in establishing
1608a TCP connection.
1609Recall that TCP uses a 3-way handshake protocol
1610when it initializes a new connection; the connection sequence with
1611regard to the TCP control bits is
16141) Caller sends SYN
16172) Recipient responds with SYN, ACK
16203) Caller sends ACK
1623Now we're interested in capturing packets that have only the
1624SYN bit set (Step 1).
1625Note that we don't want packets from step 2
1626(SYN-ACK), just a plain initial SYN.
1627What we need is a correct filter
1628expression for \fItcpdump\fP.
1630Recall the structure of a TCP header without options:
1633 0 15 31
1635| source port | destination port |
1637| sequence number |
1639| acknowledgment number |
1641| HL | rsvd |C|E|U|A|P|R|S|F| window size |
1643| TCP checksum | urgent pointer |
1647A TCP header usually holds 20 octets of data, unless options are
1649The first line of the graph contains octets 0 - 3, the
1650second line shows octets 4 - 7 etc.
1652Starting to count with 0, the relevant TCP control bits are contained
1653in octet 13:
1656 0 7| 15| 23| 31
1658| HL | rsvd |C|E|U|A|P|R|S|F| window size |
1660| | 13th octet | | |
1663Let's have a closer look at octet no. 13:
1666 | |
1667 |---------------|
1668 |C|E|U|A|P|R|S|F|
1669 |---------------|
1670 |7 5 3 0|
1673These are the TCP control bits we are interested
1675We have numbered the bits in this octet from 0 to 7, right to
1676left, so the PSH bit is bit number 3, while the URG bit is number 5.
1678Recall that we want to capture packets with only SYN set.
1679Let's see what happens to octet 13 if a TCP datagram arrives
1680with the SYN bit set in its header:
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|
1690Looking at the
1691control bits section we see that only bit number 1 (SYN) is set.
1693Assuming that octet number 13 is an 8-bit unsigned integer in
1694network byte order, the binary value of this octet is
1698and its decimal representation is
1701 7 6 5 4 3 2 1 0
17020*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2 = 2
1705We're almost done, because now we know that if only SYN is set,
1706the value of the 13th octet in the TCP header, when interpreted
1707as a 8-bit unsigned integer in network byte order, must be exactly 2.
1709This relationship can be expressed as
1712tcp[13] == 2
1715We can use this expression as the filter for \fItcpdump\fP in order
1716to watch packets which have only SYN set:
1719tcpdump -i xl0 tcp[13] == 2
1722The expression says "let the 13th octet of a TCP datagram have
1723the decimal value 2", which is exactly what we want.
1725Now, let's assume that we need to capture SYN packets, but we
1726don't care if ACK or any other TCP control bit is set at the
1727same time.
1728Let's see what happens to octet 13 when a TCP datagram
1729with SYN-ACK set arrives:
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|
1739Now bits 1 and 4 are set in the 13th octet.
1740The binary value of
1741octet 13 is
1743 00010010
1745which translates to decimal
1748 7 6 5 4 3 2 1 0
17490*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2 = 18
1752Now we can't just use 'tcp[13] == 18' in the \fItcpdump\fP filter
1753expression, because that would select only those packets that have
1754SYN-ACK set, but not those with only SYN set.
1755Remember that we don't care
1756if ACK or any other control bit is set as long as SYN is set.
1758In order to achieve our goal, we need to logically AND the
1759binary value of octet 13 with some other value to preserve
1760the SYN bit.
1761We know that we want SYN to be set in any case,
1762so we'll logically AND the value in the 13th octet with
1763the binary value of a SYN:
1767 00010010 SYN-ACK 00000010 SYN
1768 AND 00000010 (we want SYN) AND 00000010 (we want SYN)
1769 -------- --------
1770 = 00000010 = 00000010
1773We see that this AND operation delivers the same result
1774regardless whether ACK or another TCP control bit is set.
1775The decimal representation of the AND value as well as
1776the result of this operation is 2 (binary 00000010),
1777so we know that for packets with SYN set the following
1778relation must hold true:
1780( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
1782This points us to the \fItcpdump\fP filter expression
1785 tcpdump -i xl0 'tcp[13] & 2 == 2'
1788Note that you should use single quotes or a backslash
1789in the expression to hide the AND ('&') special character
1790from the shell.
1793UDP Packets
1795UDP format is illustrated by this rwho packet:
1798.sp .5
1799\f(CWactinide.who > broadcast.who: udp 84\fP
1800.sp .5
1803This says that port \fIwho\fP on host \fIactinide\fP sent a udp
1804datagram to port \fIwho\fP on host \fIbroadcast\fP, the Internet
1805broadcast address.
1806The packet contained 84 bytes of user data.
1808Some UDP services are recognized (from the source or destination
1809port number) and the higher level protocol information printed.
1810In particular, Domain Name service requests (RFC-1034/1035) and Sun
1811RPC calls (RFC-1050) to NFS.
1813UDP Name Server Requests
1815\fI(N.B.:The following description assumes familiarity with
1816the Domain Service protocol described in RFC-1035.
1817If you are not familiar
1818with the protocol, the following description will appear to be written
1819in greek.)\fP
1821Name server requests are formatted as
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? (37)\fR
1828.sp .5
1831Host \fIh2opolo\fP asked the domain server on \fIhelios\fP for an
1832address record (qtype=A) associated with the name \\fP
1833The query id was `3'.
1834The `+' indicates the \fIrecursion desired\fP flag
1835was set.
1836The query length was 37 bytes, not including the UDP and
1837IP protocol headers.
1838The query operation was the normal one, \fIQuery\fP,
1839so the op field was omitted.
1840If the op had been anything else, it would
1841have been printed between the `3' and the `+'.
1842Similarly, the qclass was the normal one,
1843\fIC_IN\fP, and omitted.
1844Any other qclass would have been printed
1845immediately after the `A'.
1847A few anomalies are checked and may result in extra fields enclosed in
1848square brackets: If a query contains an answer, authority records or
1849additional records section,
1850.IR ancount ,
1851.IR nscount ,
1853.I arcount
1854are printed as `[\fIn\fPa]', `[\fIn\fPn]' or `[\fIn\fPau]' where \fIn\fP
1855is the appropriate count.
1856If 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]'
1858is printed, where \fIx\fP is the hex value of header bytes two and three.
1860UDP Name Server Responses
1862Name server responses are formatted as
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 (273)
1869helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)\fR
1870.sp .5
1873In the first example, \fIhelios\fP responds to query id 3 from \fIh2opolo\fP
1874with 3 answer records, 3 name server records and 7 additional records.
1875The first answer record is type A (address) and its data is internet
1877The total size of the response was 273 bytes,
1878excluding UDP and IP headers.
1879The op (Query) and response code
1880(NoError) were omitted, as was the class (C_IN) of the A record.
1882In the second example, \fIhelios\fP responds to query 2 with a
1883response code of non-existent domain (NXDomain) with no answers,
1884one name server and no authority records.
1885The `*' indicates that
1886the \fIauthoritative answer\fP bit was set.
1887Since there were no
1888answers, no type, class or data were printed.
1890Other flag characters that might appear are `\-' (recursion available,
1891RA, \fInot\fP set) and `|' (truncated message, TC, set).
1892If the
1893`question' section doesn't contain exactly one entry, `[\fIn\fPq]'
1894is printed.
1896Note that name server requests and responses tend to be large and the
1897default \fIsnaplen\fP of 68 bytes may not capture enough of the packet
1898to print.
1899Use the \fB\-s\fP flag to increase the snaplen if you
1900need to seriously investigate name server traffic.
1901`\fB\-s 128\fP'
1902has worked well for me.
1905SMB/CIFS decoding
1907\fItcpdump\fP now includes fairly extensive SMB/CIFS/NBT decoding for data
1908on UDP/137, UDP/138 and TCP/139.
1909Some primitive decoding of IPX and
1910NetBEUI SMB data is also done.
1912By default a fairly minimal decode is done, with a much more detailed
1913decode done if -v is used.
1914Be warned that with -v a single SMB packet
1915may take up a page or more, so only use -v if you really want all the
1916gory details.
1918For information on SMB packet formats and what all te fields mean see or the pub/samba/specs/ directory on your favorite mirror site.
1921The SMB patches were written by Andrew Tridgell
1925NFS Requests and Replies
1927Sun NFS (Network File System) requests and replies are printed as:
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
1935sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
1936wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
1937sushi.201b > wrl.nfs:
1938 144 lookup fh 9,74/4096.6878 "xcolors"
1939wrl.nfs > sushi.201b:
1940 reply ok 128 lookup fh 9,74/4134.3150
1942.sp .5
1945In the first line, host \fIsushi\fP sends a transaction with id \fI6709\fP
1946to \fIwrl\fP (note that the number following the src host is a
1947transaction id, \fInot\fP the source port).
1948The request was 112 bytes,
1949excluding the UDP and IP headers.
1950The 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
1953as a major,minor device number pair, followed by the inode number and
1954generation number.)
1955\fIWrl\fP replies `ok' with the contents of the link.
1957In the third line, \fIsushi\fP asks \fIwrl\fP to lookup the name
1958`\fIxcolors\fP' in directory file 9,74/4096.6878.
1959Note that the data printed
1960depends on the operation type.
1961The format is intended to be self
1962explanatory if read in conjunction with
1963an NFS protocol spec.
1965If the \-v (verbose) flag is given, additional information is printed.
1966For example:
1969.sp .5
1971sushi.1372a > wrl.nfs:
1972 148 read fh 21,11/12.195 8192 bytes @ 24576
1973wrl.nfs > sushi.1372a:
1974 reply ok 1472 read REG 100664 ids 417/0 sz 29388
1976.sp .5
1979(\-v also prints the IP header TTL, ID, length, and fragmentation fields,
1980which 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,
1982at byte offset 24576.
1983\fIWrl\fP replies `ok'; the packet shown on the
1984second line is the first fragment of the reply, and hence is only 1472
1985bytes long (the other bytes will follow in subsequent fragments, but
1986these fragments do not have NFS or even UDP headers and so might not be
1987printed, depending on the filter expression used).
1988Because the \-v flag
1989is given, some of the file attributes (which are returned in addition
1990to the file data) are printed: the file type (``REG'', for regular file),
1991the file mode (in octal), the uid and gid, and the file size.
1993If the \-v flag is given more than once, even more details are printed.
1995Note that NFS requests are very large and much of the detail won't be printed
1996unless \fIsnaplen\fP is increased.
1997Try using `\fB\-s 192\fP' to watch
1998NFS traffic.
2000NFS reply packets do not explicitly identify the RPC operation.
2002\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2003replies using the transaction ID.
2004If a reply does not closely follow the
2005corresponding request, it might not be parsable.
2007AFS Requests and Replies
2009Transarc AFS (Andrew File System) requests and replies are printed
2014.sp .5
2015\ > dst.dport: rx packet-type\fP
2016\ > dst.dport: rx packet-type service call call-name args\fP
2017\ > dst.dport: rx packet-type service reply call-name args\fP
2018.sp .5
2020elvis.7001 > pike.afsfs:
2021 rx data fs call rename old fid 536876964/1/1 ""
2022 new fid 536876964/1/1 ".newsrc"
2023pike.afsfs > elvis.7001: rx data fs reply rename
2025.sp .5
2028In the first line, host elvis sends a RX packet to pike.
2029This was
2030a RX data packet to the fs (fileserver) service, and is the start of
2031an RPC call.
2032The RPC call was a rename, with the old directory file id
2033of 536876964/1/1 and an old filename of `', and a new directory
2034file id of 536876964/1/1 and a new filename of `.newsrc'.
2035The host pike
2036responds with a RPC reply to the rename call (which was successful, because
2037it was a data packet and not an abort packet).
2039In general, all AFS RPCs are decoded at least by RPC call name.
2041AFS RPCs have at least some of the arguments decoded (generally only
2042the `interesting' arguments, for some definition of interesting).
2044The format is intended to be self-describing, but it will probably
2045not be useful to people who are not familiar with the workings of
2046AFS and RX.
2048If the -v (verbose) flag is given twice, acknowledgement packets and
2049additional header information is printed, such as the the RX call ID,
2050call number, sequence number, serial number, and the RX packet flags.
2052If the -v flag is given twice, additional information is printed,
2053such as the the RX call ID, serial number, and the RX packet flags.
2054The MTU negotiation information is also printed from RX ack packets.
2056If the -v flag is given three times, the security index and service id
2057are printed.
2059Error codes are printed for abort packets, with the exception of Ubik
2060beacon packets (because abort packets are used to signify a yes vote
2061for the Ubik protocol).
2063Note that AFS requests are very large and many of the arguments won't
2064be printed unless \fIsnaplen\fP is increased.
2065Try using `\fB-s 256\fP'
2066to watch AFS traffic.
2068AFS reply packets do not explicitly identify the RPC operation.
2070\fItcpdump\fP keeps track of ``recent'' requests, and matches them to the
2071replies using the call number and service ID.
2072If a reply does not closely
2073follow the
2074corresponding request, it might not be parsable.
2077KIP AppleTalk (DDP in UDP)
2079AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
2080and dumped as DDP packets (i.e., all the UDP header information is
2082The file
2083.I /etc/atalk.names
2084is used to translate AppleTalk net and node numbers to names.
2085Lines in this file have the form
2088.sp .5
2089\fInumber name\fP
2091\f(CW1.254 ether
209216.1 icsd-net
20931.254.110 ace\fR
2094.sp .5
2097The first two lines give the names of AppleTalk networks.
2098The third
2099line gives the name of a particular host (a host is distinguished
2100from a net by the 3rd octet in the number \-
2101a net number \fImust\fP have two octets and a host number \fImust\fP
2102have three octets.) The number and name should be separated by
2103whitespace (blanks or tabs).
2105.I /etc/atalk.names
2106file may contain blank lines or comment lines (lines starting with
2107a `#').
2109AppleTalk addresses are printed in the form
2112.sp .5
2115\f(CW144.1.209.2 > icsd-net.112.220
2116office.2 > icsd-net.112.220
2117jssmag.149.235 > icsd-net.2\fR
2118.sp .5
2121(If the
2122.I /etc/atalk.names
2123doesn't exist or doesn't contain an entry for some AppleTalk
2124host/net number, addresses are printed in numeric form.)
2125In the first example, NBP (DDP port 2) on net 144.1 node 209
2126is sending to whatever is listening on port 220 of net icsd node 112.
2127The second line is the same except the full name of the source node
2128is known (`office').
2129The third line is a send from port 235 on
2130net jssmag node 149 to broadcast on the icsd-net NBP port (note that
2131the broadcast address (255) is indicated by a net name with no host
2132number \- for this reason it's a good idea to keep node names and
2133net names distinct in /etc/atalk.names).
2135NBP (name binding protocol) and ATP (AppleTalk transaction protocol)
2136packets have their contents interpreted.
2137Other protocols just dump
2138the protocol name (or number if no name is registered for the
2139protocol) and packet size.
2141\fBNBP packets\fP are formatted like the following examples:
2144.sp .5
2145\s-2\f(CWicsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
2146jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
2147techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186\fR\s+2
2148.sp .5
2151The first line is a name lookup request for laserwriters sent by net icsd host
2152112 and broadcast on net jssmag.
2153The nbp id for the lookup is 190.
2154The second line shows a reply for this request (note that it has the
2155same id) from host jssmag.209 saying that it has a laserwriter
2156resource named "RM1140" registered on port 250.
2157The third line is
2158another reply to the same request saying host techpit has laserwriter
2159"techpit" registered on port 186.
2161\fBATP packet\fP formatting is demonstrated by the following example:
2164.sp .5
2165\s-2\f(CWjssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
2166helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
2167helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
2168helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
2169helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2170helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
2171helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2172helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
2173helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
2174jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
2175helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
2176helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
2177jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
2178jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002\fR\s+2
2179.sp .5
2182Jssmag.209 initiates transaction id 12266 with host helios by requesting
2183up to 8 packets (the `<0-7>').
2184The hex number at the end of the line
2185is the value of the `userdata' field in the request.
2187Helios responds with 8 512-byte packets.
2188The `:digit' following the
2189transaction id gives the packet sequence number in the transaction
2190and the number in parens is the amount of data in the packet,
2191excluding the atp header.
2192The `*' on packet 7 indicates that the
2193EOM bit was set.
2195Jssmag.209 then requests that packets 3 & 5 be retransmitted.
2197resends them then jssmag.209 releases the transaction.
2199jssmag.209 initiates the next request.
2200The `*' on the request
2201indicates that XO (`exactly once') was \fInot\fP set.
2204IP Fragmentation
2206Fragmented Internet datagrams are printed as
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
2215(The first form indicates there are more fragments.
2216The second
2217indicates this is the last fragment.)
2219\fIId\fP is the fragment id.
2220\fISize\fP is the fragment
2221size (in bytes) excluding the IP header.
2222\fIOffset\fP is this
2223fragment's offset (in bytes) in the original datagram.
2225The fragment information is output for each fragment.
2226The first
2227fragment contains the higher level protocol header and the frag
2228info is printed after the protocol info.
2230after the first contain no higher level protocol header and the
2231frag info is printed after the source and destination addresses.
2232For example, here is part of an ftp from to
2233over a CSNET connection that doesn't appear to handle 576 byte datagrams:
2236.sp .5
2237\s-2\f(CWarizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
2238arizona > rtsg: (frag 595a:204@328)
2239rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560\fP\s+2
2240.sp .5
2243There are a couple of things to note here: First, addresses in the
22442nd line don't include port numbers.
2245This is because the TCP
2246protocol information is all in the first fragment and we have no idea
2247what the port or sequence numbers are when we print the later fragments.
2248Second, the tcp sequence information in the first line is printed as if there
2249were 308 bytes of user data when, in fact, there are 512 bytes (308 in
2250the first frag and 204 in the second).
2251If you are looking for holes
2252in the sequence space or trying to match up acks
2253with packets, this can fool you.
2255A packet with the IP \fIdon't fragment\fP flag is marked with a
2256trailing \fB(DF)\fP.
2260By default, all output lines are preceded by a timestamp.
2261The timestamp
2262is the current clock time in the form
2268and is as accurate as the kernel's clock.
2269The timestamp reflects the time the kernel first saw the packet.
2270No attempt
2271is made to account for the time lag between when the
2272Ethernet interface removed the packet from the wire and when the kernel
2273serviced the `new packet' interrupt.
2274.SH "SEE ALSO"
2275stty(1), pcap(3), bpf(4), nit(4P), pfconfig(8)
2277The original authors are:
2279Van Jacobson,
2280Craig Leres and
2281Steven McCanne, all of the
2282Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
2284It is currently being maintained by
2286The current version is available via http:
2292The original distribution is available via anonymous ftp:
2298IPv6/IPsec support is added by WIDE/KAME project.
2299This program uses Eric Young's SSLeay library, under specific configuration.
2300.SH BUGS
2301Please send problems, bugs, questions, desirable enhancements, etc. to:
2307Please send source code contributions, etc. to:
2313NIT doesn't let you watch your own outbound traffic, BPF will.
2314We recommend that you use the latter.
2316On Linux systems with 2.0[.x] kernels:
2318packets on the loopback device will be seen twice;
2320packet filtering cannot be done in the kernel, so that all packets must
2321be copied from the kernel in order to be filtered in user mode;
2323all of a packet, not just the part that's within the snapshot length,
2324will be copied from the kernel (the 2.0[.x] packet capture mechanism, if
2325asked to copy only part of a packet to userland, will not report the
2326true length of the packet; this would cause most IP packets to get an
2327error from
2328.BR tcpdump );
2330capturing on some PPP devices won't work correctly.
2332We recommend that you upgrade to a 2.2 or later kernel.
2334Some attempt should be made to reassemble IP fragments or, at least
2335to compute the right length for the higher level protocol.
2337Name server inverse queries are not dumped correctly: the (empty)
2338question section is printed rather than real query in the answer
2340Some believe that inverse queries are themselves a bug and
2341prefer to fix the program generating them rather than \fItcpdump\fP.
2343A packet trace that crosses a daylight savings time change will give
2344skewed time stamps (the time change is ignored).
2346Filter expressions on fields other than those in Token Ring headers will
2347not correctly handle source-routed Token Ring packets.
2349Filter expressions on fields other than those in 802.11 headers will not
2350correctly handle 802.11 data packets with both To DS and From DS set.
2352.BR "ip6 proto"
2353should chase header chain, but at this moment it does not.
2354.BR "ip6 protochain"
2355is supplied for this behavior.
2357Arithmetic expression against transport layer headers, like \fBtcp[0]\fP,
2358does not work against IPv6 packets.
2359It only looks at IPv4 packets.