1TCPDUMP(8)                  System Manager's Manual                 TCPDUMP(8)
2
3
4

NAME

6       tcpdump - dump traffic on a network
7

SYNOPSIS

9       tcpdump [ -AbdDefhHIJKlLnNOpqStuUvxX# ] [ -B buffer_size ]
10               [ -c count ] [ --count ] [ -C file_size ]
11               [ -E spi@ipaddr algo:secret,...  ]
12               [ -F file ] [ -G rotate_seconds ] [ -i interface ]
13               [ --immediate-mode ] [ -j tstamp_type ] [ -m module ]
14               [ -M secret ] [ --number ] [ --print ] [ -Q in|out|inout ]
15               [ -r file ] [ -s snaplen ] [ -T type ] [ --version ]
16               [ -V file ] [ -w file ] [ -W filecount ] [ -y datalinktype ]
17               [ -z postrotate-command ] [ -Z user ]
18               [ --time-stamp-precision=tstamp_precision ]
19               [ --micro ] [ --nano ]
20               [ expression ]
21

DESCRIPTION

23       Tcpdump  prints  out a description of the contents of packets on a net‐
24       work interface that match the Boolean  expression  (see  pcap-filter(7)
25       for  the  expression  syntax);  the  description  is preceded by a time
26       stamp, printed, by default, as hours, minutes, seconds,  and  fractions
27       of a second since midnight.  It can also be run with the -w flag, which
28       causes it to save the packet data to a file for later analysis,  and/or
29       with  the  -r  flag,  which  causes it to read from a saved packet file
30       rather than to read packets from a network interface.  It can  also  be
31       run  with  the  -V flag, which causes it to read a list of saved packet
32       files. In all cases, only packets that match expression  will  be  pro‐
33       cessed by tcpdump.
34
35       Tcpdump  will,  if not run with the -c flag, continue capturing packets
36       until it is interrupted by a SIGINT signal (generated, for example,  by
37       typing your interrupt character, typically control-C) or a SIGTERM sig‐
38       nal (typically generated with the kill(1) command); if run with the  -c
39       flag,  it  will  capture packets until it is interrupted by a SIGINT or
40       SIGTERM signal or the specified number of packets have been processed.
41
42       When tcpdump finishes capturing packets, it will report counts of:
43
44              packets ``captured'' (this is the number of packets that tcpdump
45              has received and processed);
46
47              packets  ``received  by filter'' (the meaning of this depends on
48              the OS on which you're running tcpdump, and possibly on the  way
49              the OS was configured - if a filter was specified on the command
50              line, on some OSes it counts packets regardless of whether  they
51              were  matched  by  the  filter expression and, even if they were
52              matched by the filter expression, regardless of whether  tcpdump
53              has  read  and  processed them yet, on other OSes it counts only
54              packets that were matched by the filter expression regardless of
55              whether  tcpdump  has  read and processed them yet, and on other
56              OSes it counts only packets that were matched by the filter  ex‐
57              pression and were processed by tcpdump);
58
59              packets  ``dropped  by  kernel''  (this is the number of packets
60              that were dropped, due to a lack of buffer space, by the  packet
61              capture  mechanism in the OS on which tcpdump is running, if the
62              OS reports that information to applications; if not, it will  be
63              reported as 0).
64
65       On  platforms  that  support the SIGINFO signal, such as most BSDs (in‐
66       cluding macOS) and Digital/Tru64 UNIX, it will report those counts when
67       it  receives  a  SIGINFO signal (generated, for example, by typing your
68       ``status'' character, typically control-T, although on some  platforms,
69       such  as  macOS, the ``status'' character is not set by default, so you
70       must set it with stty(1) in order to use it) and will continue  captur‐
71       ing  packets.  On platforms that do not support the SIGINFO signal, the
72       same can be achieved by using the SIGUSR1 signal.
73
74       Using the SIGUSR2 signal along with the -w flag will forcibly flush the
75       packet buffer into the output file.
76
77       Reading packets from a network interface may require that you have spe‐
78       cial privileges; see the pcap(3PCAP) man page for details.   Reading  a
79       saved packet file doesn't require special privileges.
80

OPTIONS

82       -A     Print each packet (minus its link level header) in ASCII.  Handy
83              for capturing web pages.
84
85       -b     Print the AS number in BGP packets in ASDOT notation rather than
86              ASPLAIN notation.
87
88       -B buffer_size
89       --buffer-size=buffer_size
90              Set  the operating system capture buffer size to buffer_size, in
91              units of KiB (1024 bytes).
92
93       -c count
94              Exit after receiving count packets.
95
96       --count
97              Print only on stdout  the  packet  count  when  reading  capture
98              file(s)  instead of parsing/printing the packets. If a filter is
99              specified on the command line, tcpdump counts only packets  that
100              were matched by the filter expression.
101
102       -C file_size
103              Before  writing  a  raw  packet to a savefile, check whether the
104              file is currently larger than file_size and, if  so,  close  the
105              current  savefile and open a new one.  Savefiles after the first
106              savefile will have the name specified with the -w flag,  with  a
107              number after it, starting at 1 and continuing upward.  The units
108              of  file_size  are  millions  of  bytes  (1,000,000  bytes,  not
109              1,048,576 bytes).
110
111              Note  that when used with -Z option (enabled by default), privi‐
112              leges are dropped before opening the first savefile.
113
114       -d     Dump the compiled packet-matching code in a human readable  form
115              to standard output and stop.
116
117              Please  mind  that  although code compilation is always DLT-spe‐
118              cific, typically it is impossible (and unnecessary)  to  specify
119              which  DLT  to  use for the dump because tcpdump uses either the
120              DLT of the input pcap file specified with -r, or the default DLT
121              of  the  network  interface specified with -i, or the particular
122              DLT of the network interface specified with -y  and  -i  respec‐
123              tively.  In  these cases the dump shows the same exact code that
124              would filter the input file or the network interface without -d.
125
126              However, when neither -r nor -i is specified, specifying -d pre‐
127              vents  tcpdump  from  guessing a suitable network interface (see
128              -i).  In this case the DLT defaults to EN10MB and can be set  to
129              another valid value manually with -y.
130
131       -dd    Dump packet-matching code as a C program fragment.
132
133       -ddd   Dump  packet-matching  code  as decimal numbers (preceded with a
134              count).
135
136       -D
137       --list-interfaces
138              Print the list of the network interfaces available on the system
139              and  on which tcpdump can capture packets.  For each network in‐
140              terface, a number and an interface name, possibly followed by  a
141              text  description  of the interface, are printed.  The interface
142              name or the number can be supplied to the -i flag to specify  an
143              interface on which to capture.
144
145              This  can be useful on systems that don't have a command to list
146              them (e.g., Windows systems, or UNIX  systems  lacking  ifconfig
147              -a); the number can be useful on Windows 2000 and later systems,
148              where the interface name is a somewhat complex string.
149
150              The -D flag will not be supported if tcpdump was built  with  an
151              older  version of libpcap that lacks the pcap_findalldevs(3PCAP)
152              function.
153
154       -e     Print the link-level header on each  dump  line.   This  can  be
155              used,  for  example,  to print MAC layer addresses for protocols
156              such as Ethernet and IEEE 802.11.
157
158       -E     Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that
159              are addressed to addr and contain Security Parameter Index value
160              spi. This combination may be repeated with comma or newline sep‐
161              aration.
162
163              Note  that  setting the secret for IPv4 ESP packets is supported
164              at this time.
165
166              Algorithms may  be  des-cbc,  3des-cbc,  blowfish-cbc,  rc3-cbc,
167              cast128-cbc,  or  none.  The default is des-cbc.  The ability to
168              decrypt packets is only present if  tcpdump  was  compiled  with
169              cryptography enabled.
170
171              secret is the ASCII text for ESP secret key.  If preceded by 0x,
172              then a hex value will be read.
173
174              The option assumes RFC 2406 ESP, not RFC 1827 ESP.   The  option
175              is  only for debugging purposes, and the use of this option with
176              a true `secret' key is discouraged.  By presenting IPsec  secret
177              key  onto  command line you make it visible to others, via ps(1)
178              and other occasions.
179
180              In addition to the above syntax, the syntax  file  name  may  be
181              used  to  have  tcpdump  read  the provided file in. The file is
182              opened upon receiving the first ESP packet, so any special  per‐
183              missions  that  tcpdump  may have been given should already have
184              been given up.
185
186       -f     Print `foreign' IPv4 addresses numerically rather than  symboli‐
187              cally  (this option is intended to get around serious brain dam‐
188              age in Sun's NIS server — usually it hangs  forever  translating
189              non-local internet numbers).
190
191              The test for `foreign' IPv4 addresses is done using the IPv4 ad‐
192              dress and netmask of the interface  on  that  capture  is  being
193              done.   If that address or netmask are not available, either be‐
194              cause the interface on that capture is being done has no address
195              or netmask or because it is the "any" pseudo-interface, which is
196              available in Linux and in recent versions of macOS and  Solaris,
197              and  which  can  capture on more than one interface, this option
198              will not work correctly.
199
200       -F file
201              Use file as input for the filter expression.  An additional  ex‐
202              pression given on the command line is ignored.
203
204       -G rotate_seconds
205              If specified, rotates the dump file specified with the -w option
206              every rotate_seconds seconds.   Savefiles  will  have  the  name
207              specified by -w which should include a time format as defined by
208              strftime(3).  If no time format is specified, each new file will
209              overwrite  the  previous.   Whenever a generated filename is not
210              unique, tcpdump will overwrite the pre-existing data;  providing
211              a  time specification that is coarser than the capture period is
212              therefore not advised.
213
214              If used in conjunction with the -C option, filenames  will  take
215              the form of `file<count>'.
216
217              Note  that when used with -Z option (enabled by default), privi‐
218              leges are dropped before opening the first savefile.
219
220       -h
221       --help Print the tcpdump and libpcap version  strings,  print  a  usage
222              message, and exit.
223
224       --version
225              Print the tcpdump and libpcap version strings and exit.
226
227       -H     Attempt to detect 802.11s draft mesh headers.
228
229       -i interface
230       --interface=interface
231              Listen,  report the list of link-layer types, report the list of
232              time stamp types, or report the results of  compiling  a  filter
233              expression  on  interface.  If unspecified and if the -d flag is
234              not given, tcpdump searches the system interface  list  for  the
235              lowest  numbered,  configured up interface (excluding loopback),
236              which may turn out to be, for example, ``eth0''.
237
238              On Linux systems with 2.2 or later kernels and  on  recent  ver‐
239              sions of macOS and Solaris, an interface argument of ``any'' can
240              be used to capture packets from all interfaces.  Note that  cap‐
241              tures  on  the ``any'' pseudo-interface will not be done in pro‐
242              miscuous mode.
243
244              If the -D flag is supported, an interface number as  printed  by
245              that flag can be used as the interface argument, if no interface
246              on the system has that number as a name.
247
248       -I
249       --monitor-mode
250              Put the interface in "monitor mode"; this is supported  only  on
251              IEEE 802.11 Wi-Fi interfaces, and supported only on some operat‐
252              ing systems.
253
254              Note that in monitor mode the adapter  might  disassociate  from
255              the  network with which it's associated, so that you will not be
256              able to use any wireless networks with that adapter.  This could
257              prevent  accessing  files on a network server, or resolving host
258              names or network addresses, if you are capturing in monitor mode
259              and are not connected to another network with another adapter.
260
261              This  flag  will  affect the output of the -L flag.  If -I isn't
262              specified, only those link-layer types  available  when  not  in
263              monitor mode will be shown; if -I is specified, only those link-
264              layer types available when in monitor mode will be shown.
265
266       --immediate-mode
267              Capture in "immediate mode".  In this mode, packets  are  deliv‐
268              ered  to  tcpdump  as  soon  as  they  arrive, rather than being
269              buffered for efficiency.  This  is  the  default  when  printing
270              packets  rather  than  saving  packets  to a ``savefile'' if the
271              packets are being printed to a terminal rather than to a file or
272              pipe.
273
274       -j tstamp_type
275       --time-stamp-type=tstamp_type
276              Set  the  time  stamp  type for the capture to tstamp_type.  The
277              names  to  use  for  the  time  stamp   types   are   given   in
278              pcap-tstamp(7);  not all the types listed there will necessarily
279              be valid for any given interface.
280
281       -J
282       --list-time-stamp-types
283              List the supported time stamp types for the interface and  exit.
284              If  the time stamp type cannot be set for the interface, no time
285              stamp types are listed.
286
287       --time-stamp-precision=tstamp_precision
288              When capturing, set the time stamp precision for the capture  to
289              tstamp_precision.  Note that availability of high precision time
290              stamps (nanoseconds) and their actual accuracy is  platform  and
291              hardware  dependent.   Also note that when writing captures made
292              with nanosecond accuracy to a  savefile,  the  time  stamps  are
293              written with nanosecond resolution, and the file is written with
294              a different magic number, to indicate that the time  stamps  are
295              in  seconds  and  nanoseconds;  not  all programs that read pcap
296              savefiles will be able to read those captures.
297
298              When reading a savefile, convert time stamps  to  the  precision
299              specified  by  timestamp_precision,  and  display them with that
300              resolution.  If the precision specified is less than the  preci‐
301              sion of time stamps in the file, the conversion will lose preci‐
302              sion.
303
304              The supported values for timestamp_precision are micro  for  mi‐
305              crosecond  resolution  and  nano for nanosecond resolution.  The
306              default is microsecond resolution.
307
308       --micro
309       --nano Shorthands for --time-stamp-precision=micro or --time-stamp-pre‐
310              cision=nano,  adjusting  the  time  stamp precision accordingly.
311              When reading packets from a savefile,  using  --micro  truncates
312              time  stamps  if the savefile was created with nanosecond preci‐
313              sion.  In contrast, a savefile created with  microsecond  preci‐
314              sion  will  have  trailing  zeroes  added to the time stamp when
315              --nano is used.
316
317       -K
318       --dont-verify-checksums
319              Don't attempt to verify IP, TCP, or UDP checksums.  This is use‐
320              ful  for  interfaces  that perform some or all of those checksum
321              calculation in hardware; otherwise, all outgoing  TCP  checksums
322              will be flagged as bad.
323
324       -l     Make  stdout  line buffered.  Useful if you want to see the data
325              while capturing it.  E.g.,
326
327                     tcpdump -l | tee dat
328
329              or
330
331                     tcpdump -l > dat & tail -f dat
332
333              Note that on Windows,``line buffered'' means ``unbuffered'',  so
334              that  WinDump  will  write  each character individually if -l is
335              specified.
336
337              -U is similar to -l in its behavior, but it will cause output to
338              be  ``packet-buffered'', so that the output is written to stdout
339              at the end of each packet rather than at the end of  each  line;
340              this is buffered on all platforms, including Windows.
341
342       -L
343       --list-data-link-types
344              List  the known data link types for the interface, in the speci‐
345              fied mode, and exit.  The list of known data link types  may  be
346              dependent on the specified mode; for example, on some platforms,
347              a Wi-Fi interface might support one set of data link types  when
348              not  in  monitor  mode  (for example, it might support only fake
349              Ethernet headers, or might support 802.11 headers but  not  sup‐
350              port  802.11  headers with radio information) and another set of
351              data link types when in monitor mode (for example, it might sup‐
352              port  802.11  headers, or 802.11 headers with radio information,
353              only in monitor mode).
354
355       -m module
356              Load SMI MIB module definitions from file module.   This  option
357              can  be used several times to load several MIB modules into tcp‐
358              dump.
359
360       -M secret
361              Use secret as a shared secret for validating the  digests  found
362              in TCP segments with the TCP-MD5 option (RFC 2385), if present.
363
364       -n     Don't  convert  host  addresses  to  names.  This can be used to
365              avoid DNS lookups.
366
367       -nn    Don't convert protocol and port numbers etc. to names either.
368
369       -N     Don't print domain name qualification of host names.   E.g.,  if
370              you  give  this  flag then tcpdump will print ``nic'' instead of
371              ``nic.ddn.mil''.
372
373       -#
374       --number
375              Print an optional packet number at the beginning of the line.
376
377       -O
378       --no-optimize
379              Do not run the packet-matching code optimizer.  This  is  useful
380              only if you suspect a bug in the optimizer.
381
382       -p
383       --no-promiscuous-mode
384              Don't  put  the  interface into promiscuous mode.  Note that the
385              interface might be in promiscuous mode for  some  other  reason;
386              hence,  `-p'  cannot  be used as an abbreviation for `ether host
387              {local-hw-addr} or ether broadcast'.
388
389       --print
390              Print parsed packet output, even if the raw  packets  are  being
391              saved to a file with the -w flag.
392
393       -Q direction
394       --direction=direction
395              Choose send/receive direction direction for which packets should
396              be captured. Possible values are `in', `out'  and  `inout'.  Not
397              available on all platforms.
398
399       -q     Quick  (quiet?) output.  Print less protocol information so out‐
400              put lines are shorter.
401
402       -r file
403              Read packets from file (which was created with the -w option  or
404              by other tools that write pcap or pcapng files).  Standard input
405              is used if file is ``-''.
406
407       -S
408       --absolute-tcp-sequence-numbers
409              Print absolute, rather than relative, TCP sequence numbers.
410
411       -s snaplen
412       --snapshot-length=snaplen
413              Snarf snaplen bytes of data from each packet rather than the de‐
414              fault  of  262144 bytes.  Packets truncated because of a limited
415              snapshot are indicated in the output  with  ``[|proto]'',  where
416              proto  is the name of the protocol level at which the truncation
417              has occurred.
418
419              Note that taking larger snapshots both increases the  amount  of
420              time it takes to process packets and, effectively, decreases the
421              amount of packet buffering.  This may cause packets to be  lost.
422              Note  also  that taking smaller snapshots will discard data from
423              protocols above the transport  layer,  which  loses  information
424              that  may  be  important.  NFS and AFS requests and replies, for
425              example, are very large, and much of the detail won't be  avail‐
426              able if a too-short snapshot length is selected.
427
428              If  you  need to reduce the snapshot size below the default, you
429              should limit snaplen to the smallest number  that  will  capture
430              the  protocol information you're interested in.  Setting snaplen
431              to 0 sets it to the default of 262144, for backwards compatibil‐
432              ity with recent older versions of tcpdump.
433
434       -T type
435              Force  packets  selected  by  "expression" to be interpreted the
436              specified type.  Currently known types are aodv  (Ad-hoc  On-de‐
437              mand  Distance Vector protocol), carp (Common Address Redundancy
438              Protocol), cnfp (Cisco NetFlow protocol),  domain  (Domain  Name
439              System),  lmp (Link Management Protocol), pgm (Pragmatic General
440              Multicast), pgm_zmtp1 (ZMTP/1.0 inside PGM/EPGM), ptp (Precision
441              Time  Protocol), radius (RADIUS), resp (REdis Serialization Pro‐
442              tocol), rpc (Remote Procedure Call),  rtcp  (Real-Time  Applica‐
443              tions  control protocol), rtp (Real-Time Applications protocol),
444              snmp (Simple Network  Management  Protocol),  someip  (SOME/IP),
445              tftp  (Trivial File Transfer Protocol), vat (Visual Audio Tool),
446              vxlan (Virtual eXtensible Local Area Network),  wb  (distributed
447              White Board) and zmtp1 (ZeroMQ Message Transport Protocol 1.0).
448
449              Note  that  the  pgm type above affects UDP interpretation only,
450              the native PGM is always recognised as IP protocol  113  regard‐
451              less. UDP-encapsulated PGM is often called "EPGM" or "PGM/UDP".
452
453              Note  that  the  pgm_zmtp1  type above affects interpretation of
454              both native PGM and UDP at once. During the native PGM  decoding
455              the  application  data of an ODATA/RDATA packet would be decoded
456              as a ZeroMQ datagram with ZMTP/1.0 frames.  During the  UDP  de‐
457              coding in addition to that any UDP packet would be treated as an
458              encapsulated PGM packet.
459
460       -t     Don't print a timestamp on each dump line.
461
462       -tt    Print the timestamp, as seconds since January 1, 1970, 00:00:00,
463              UTC,  and  fractions  of  a second since that time, on each dump
464              line.
465
466       -ttt   Print a delta (microsecond or nanosecond resolution depending on
467              the  --time-stamp-precision option) between current and previous
468              line on each dump line.  The default is microsecond resolution.
469
470       -tttt  Print a timestamp, as hours, minutes, seconds, and fractions  of
471              a  second  since  midnight,  preceded  by the date, on each dump
472              line.
473
474       -ttttt Print a delta (microsecond or nanosecond resolution depending on
475              the  --time-stamp-precision  option)  between  current and first
476              line on each dump line.  The default is microsecond resolution.
477
478       -u     Print undecoded NFS handles.
479
480       -U
481       --packet-buffered
482              If the -w option is not specified, or if it is specified but the
483              --print  flag  is also specified, make the printed packet output
484              ``packet-buffered''; i.e., as the description of the contents of
485              each  packet is printed, it will be written to the standard out‐
486              put, rather than, when not writing to a terminal, being  written
487              only when the output buffer fills.
488
489              If  the -w option is specified, make the saved raw packet output
490              ``packet-buffered''; i.e., as each packet is saved, it  will  be
491              written  to the output file, rather than being written only when
492              the output buffer fills.
493
494              The -U flag will not be supported if tcpdump was built  with  an
495              older  version  of libpcap that lacks the pcap_dump_flush(3PCAP)
496              function.
497
498       -v     When parsing and printing, produce (slightly more) verbose  out‐
499              put.   For  example,  the  time  to  live, identification, total
500              length and options in an IP packet are  printed.   Also  enables
501              additional  packet integrity checks such as verifying the IP and
502              ICMP header checksum.
503
504              When writing to a file with the -w option and at the  same  time
505              not  reading  from  a file with the -r option, report to stderr,
506              once per second, the number of  packets  captured.  In  Solaris,
507              FreeBSD  and  possibly other operating systems this periodic up‐
508              date currently can cause loss of captured packets on  their  way
509              from the kernel to tcpdump.
510
511       -vv    Even  more  verbose  output.  For example, additional fields are
512              printed from NFS reply packets, and SMB packets  are  fully  de‐
513              coded.
514
515       -vvv   Even more verbose output.  For example, telnet SB ... SE options
516              are printed in full.  With -X Telnet options are printed in  hex
517              as well.
518
519       -V file
520              Read  a  list  of filenames from file. Standard input is used if
521              file is ``-''.
522
523       -w file
524              Write the raw packets to file rather than parsing  and  printing
525              them  out.  They can later be printed with the -r option.  Stan‐
526              dard output is used if file is ``-''.
527
528              This output will be buffered if written to a file or pipe, so  a
529              program reading from the file or pipe may not see packets for an
530              arbitrary amount of time after they are received.   Use  the  -U
531              flag  to  cause  packets  to  be written as soon as they are re‐
532              ceived.
533
534              The MIME type application/vnd.tcpdump.pcap has  been  registered
535              with  IANA  for pcap files. The filename extension .pcap appears
536              to be the most commonly used along with .cap and  .dmp.  Tcpdump
537              itself  doesn't  check  the extension when reading capture files
538              and doesn't add an extension when writing them  (it  uses  magic
539              numbers  in  the  file  header instead). However, many operating
540              systems and applications will use the extension if it is present
541              and adding one (e.g. .pcap) is recommended.
542
543              See pcap-savefile(5) for a description of the file format.
544
545       -W filecount
546              Used in conjunction with the -C option, this will limit the num‐
547              ber of files created to the specified number,  and  begin  over‐
548              writing  files  from  the  beginning, thus creating a 'rotating'
549              buffer.  In addition, it will name the files with enough leading
550              0s to support the maximum number of files, allowing them to sort
551              correctly.
552
553              Used in conjunction with the -G option, this will limit the num‐
554              ber  of rotated dump files that get created, exiting with status
555              0 when reaching the limit.
556
557              If used in conjunction with both -C and -G, the -W  option  will
558              currently be ignored, and will only affect the file name.
559
560       -x     When  parsing  and printing, in addition to printing the headers
561              of each packet, print the data of each packet  (minus  its  link
562              level  header)  in  hex.   The  smaller  of the entire packet or
563              snaplen bytes will be printed.  Note that  this  is  the  entire
564              link-layer  packet, so for link layers that pad (e.g. Ethernet),
565              the padding bytes will also be printed  when  the  higher  layer
566              packet is shorter than the required padding.  In the current im‐
567              plementation this flag may have the same effect as  -xx  if  the
568              packet is truncated.
569
570       -xx    When  parsing  and printing, in addition to printing the headers
571              of each packet, print the data of  each  packet,  including  its
572              link level header, in hex.
573
574       -X     When  parsing  and printing, in addition to printing the headers
575              of each packet, print the data of each packet  (minus  its  link
576              level  header)  in  hex  and  ASCII.   This  is  very  handy for
577              analysing new protocols.  In  the  current  implementation  this
578              flag may have the same effect as -XX if the packet is truncated.
579
580       -XX    When  parsing  and printing, in addition to printing the headers
581              of each packet, print the data of  each  packet,  including  its
582              link level header, in hex and ASCII.
583
584       -y datalinktype
585       --linktype=datalinktype
586              Set  the  data link type to use while capturing packets (see -L)
587              or just compiling and dumping packet-matching code (see  -d)  to
588              datalinktype.
589
590       -z postrotate-command
591              Used  in  conjunction  with the -C or -G options, this will make
592              tcpdump run " postrotate-command file " where file is the  save‐
593              file  being  closed after each rotation. For example, specifying
594              -z gzip or -z bzip2 will compress each savefile  using  gzip  or
595              bzip2.
596
597              Note  that  tcpdump will run the command in parallel to the cap‐
598              ture, using the lowest priority so that this doesn't disturb the
599              capture process.
600
601              And  in  case  you would like to use a command that itself takes
602              flags or different arguments,  you  can  always  write  a  shell
603              script  that  will  take the savefile name as the only argument,
604              make the flags & arguments arrangements and execute the  command
605              that you want.
606
607       -Z user
608       --relinquish-privileges=user
609              If  tcpdump is running as root, after opening the capture device
610              or input savefile, but before opening any savefiles for  output,
611              change the user ID to user and the group ID to the primary group
612              of user.
613
614              This behavior is enabled by default (-Z  tcpdump),  and  can  be
615              disabled by -Z root.
616
617
618        expression
619              selects  which  packets  will  be  dumped.   If no expression is
620              given, all packets on the net will be dumped.   Otherwise,  only
621              packets for which expression is `true' will be dumped.
622
623              For the expression syntax, see pcap-filter(7).
624
625              The  expression  argument  can  be passed to tcpdump as either a
626              single Shell argument, or as multiple Shell arguments, whichever
627              is more convenient.  Generally, if the expression contains Shell
628              metacharacters, such as  backslashes  used  to  escape  protocol
629              names,  it  is  easier  to  pass it as a single, quoted argument
630              rather than to escape the Shell metacharacters.  Multiple  argu‐
631              ments are concatenated with spaces before being parsed.
632

EXAMPLES

634       To print all packets arriving at or departing from sundown:
635              tcpdump host sundown
636
637       To print traffic between helios and either hot or ace:
638              tcpdump host helios and \( hot or ace \)
639
640       To print all IP packets between ace and any host except helios:
641              tcpdump ip host ace and not helios
642
643       To print all traffic between local hosts and hosts at Berkeley:
644              tcpdump net ucb-ether
645
646       To  print all ftp traffic through internet gateway snup: (note that the
647       expression is quoted to prevent the shell from  (mis-)interpreting  the
648       parentheses):
649              tcpdump 'gateway snup and (port ftp or ftp-data)'
650
651       To  print traffic neither sourced from nor destined for local hosts (if
652       you gateway to one other net, this stuff should never make it onto your
653       local net).
654              tcpdump ip and not net localnet
655
656       To  print  the  start and end packets (the SYN and FIN packets) of each
657       TCP conversation that involves a non-local host.
658              tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'
659
660       To print the TCP packets with flags RST and ACK both set.  (i.e. select
661       only  the  RST  and  ACK flags in the flags field, and if the result is
662       "RST and ACK both set", match)
663              tcpdump 'tcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)'
664
665       To print all IPv4 HTTP packets to and from port  80,  i.e.  print  only
666       packets  that  contain  data, not, for example, SYN and FIN packets and
667       ACK-only packets.  (IPv6 is left as an exercise for the reader.)
668              tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
669
670       To print IP packets longer than 576 bytes sent through gateway snup:
671              tcpdump 'gateway snup and ip[2:2] > 576'
672
673       To print IP broadcast or multicast packets that were not sent via  Eth‐
674       ernet broadcast or multicast:
675              tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
676
677       To print all ICMP packets that are not echo requests/replies (i.e., not
678       ping packets):
679              tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'
680

OUTPUT FORMAT

682       The output of tcpdump is protocol dependent.   The  following  gives  a
683       brief description and examples of most of the formats.
684
685       Timestamps
686
687       By  default,  all  output lines are preceded by a timestamp.  The time‐
688       stamp is the current clock time in the form
689              hh:mm:ss.frac
690       and is as accurate as the kernel's clock.  The timestamp  reflects  the
691       time the kernel applied a time stamp to the packet.  No attempt is made
692       to account for the time lag between when the network interface finished
693       receiving  the  packet  from  the network and when the kernel applied a
694       time stamp to the packet; that time lag could include a  delay  between
695       the  time  when  the network interface finished receiving a packet from
696       the network and the time when an interrupt was delivered to the  kernel
697       to get it to read the packet and a delay between the time when the ker‐
698       nel serviced the `new packet' interrupt and the time when it applied  a
699       time stamp to the packet.
700
701       Link Level Headers
702
703       If  the '-e' option is given, the link level header is printed out.  On
704       Ethernets, the source and destination addresses, protocol,  and  packet
705       length are printed.
706
707       On  FDDI  networks, the  '-e' option causes tcpdump to print the `frame
708       control' field,  the source and destination addresses, and  the  packet
709       length.   (The  `frame control' field governs the interpretation of the
710       rest of the packet.  Normal packets (such as those containing IP  data‐
711       grams)  are `async' packets, with a priority value between 0 and 7; for
712       example, `async4'.  Such packets are assumed to contain an 802.2  Logi‐
713       cal  Link  Control (LLC) packet; the LLC header is printed if it is not
714       an ISO datagram or a so-called SNAP packet.
715
716       On Token Ring networks, the '-e' option causes  tcpdump  to  print  the
717       `access control' and `frame control' fields, the source and destination
718       addresses, and the packet length.  As on FDDI networks, packets are as‐
719       sumed  to contain an LLC packet.  Regardless of whether the '-e' option
720       is specified or not, the source  routing  information  is  printed  for
721       source-routed packets.
722
723       On  802.11 networks, the '-e' option causes tcpdump to print the `frame
724       control' fields, all of the addresses in the  802.11  header,  and  the
725       packet  length.  As on FDDI networks, packets are assumed to contain an
726       LLC packet.
727
728       (N.B.: The following description assumes familiarity with the SLIP com‐
729       pression algorithm described in RFC 1144.)
730
731       On SLIP links, a direction indicator (``I'' for inbound, ``O'' for out‐
732       bound), packet type, and compression information are printed out.   The
733       packet  type is printed first.  The three types are ip, utcp, and ctcp.
734       No further link information is printed for ip packets.  For  TCP  pack‐
735       ets,  the  connection identifier is printed following the type.  If the
736       packet is compressed, its encoded header is printed out.   The  special
737       cases are printed out as *S+n and *SA+n, where n is the amount by which
738       the sequence number (or sequence number and ack) has changed.  If it is
739       not  a special case, zero or more changes are printed.  A change is in‐
740       dicated by U (urgent pointer), W (window), A (ack),  S  (sequence  num‐
741       ber), and I (packet ID), followed by a delta (+n or -n), or a new value
742       (=n).  Finally, the amount of data in the packet and compressed  header
743       length are printed.
744
745       For  example,  the  following  line  shows  an  outbound compressed TCP
746       packet, with an implicit connection identifier; the ack has changed  by
747       6, the sequence number by 49, and the packet ID by 6; there are 3 bytes
748       of data and 6 bytes of compressed header:
749              O ctcp * A+6 S+49 I+6 3 (6)
750
751       ARP/RARP Packets
752
753       ARP/RARP output shows the type of request and its arguments.  The  for‐
754       mat  is  intended to be self explanatory.  Here is a short sample taken
755       from the start of an `rlogin' from host rtsg to host csam:
756              arp who-has csam tell rtsg
757              arp reply csam is-at CSAM
758       The first line says that rtsg sent an ARP packet asking for the  Ether‐
759       net  address of internet host csam.  Csam replies with its Ethernet ad‐
760       dress (in this example, Ethernet addresses are in caps and internet ad‐
761       dresses in lower case).
762
763       This would look less redundant if we had done tcpdump -n:
764              arp who-has 128.3.254.6 tell 128.3.254.68
765              arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
766
767       If  we had done tcpdump -e, the fact that the first packet is broadcast
768       and the second is point-to-point would be visible:
769              RTSG Broadcast 0806  64: arp who-has csam tell rtsg
770              CSAM RTSG 0806  64: arp reply csam is-at CSAM
771       For the first packet this says the Ethernet source address is RTSG, the
772       destination is the Ethernet broadcast address, the type field contained
773       hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
774
775       IPv4 Packets
776
777       If the link-layer header is not being printed, for IPv4 packets, IP  is
778       printed after the time stamp.
779
780       If  the -v flag is specified, information from the IPv4 header is shown
781       in parentheses after the IP or the link-layer header.  The general for‐
782       mat of this information is:
783              tos tos, ttl ttl, id id, offset offset, flags [flags], proto proto, length length, options (options)
784       tos  is  the type of service field; if the ECN bits are non-zero, those
785       are reported as ECT(1), ECT(0), or CE.  ttl is the time-to-live; it  is
786       not reported if it is zero.  id is the IP identification field.  offset
787       is the fragment offset field; it is printed whether this is part  of  a
788       fragmented  datagram  or  not.  flags are the MF and DF flags; + is re‐
789       ported if MF is set, and DF is reported if F is set.   If  neither  are
790       set, . is reported.  proto is the protocol ID field.  length is the to‐
791       tal length field.  options are the IP options, if any.
792
793       Next, for TCP and UDP packets, the source and destination IP  addresses
794       and TCP or UDP ports, with a dot between each IP address and its corre‐
795       sponding port, will be printed, with a > separating the source and des‐
796       tination.  For other protocols, the addresses will be printed, with a >
797       separating the source and destination.  Higher level protocol  informa‐
798       tion, if any, will be printed after that.
799
800       For  fragmented  IP  datagrams,  the first fragment contains the higher
801       level protocol header; fragments after  the  first  contain  no  higher
802       level  protocol header.  Fragmentation information will be printed only
803       with the -v flag, in the IP header information, as described above.
804
805       TCP Packets
806
807       (N.B.:The following description assumes familiarity with the TCP proto‐
808       col  described  in RFC 793.  If you are not familiar with the protocol,
809       this description will not be of much use to you.)
810
811       The general format of a TCP protocol line is:
812              src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length len
813       Src and dst are the source and  destination  IP  addresses  and  ports.
814       Tcpflags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U
815       (URG), W (ECN CWR), E (ECN-Echo) or `.' (ACK), or `none'  if  no  flags
816       are set.  Data-seqno describes the portion of sequence space covered by
817       the data in this packet (see example below).  Ackno is sequence  number
818       of the next data expected the other direction on this connection.  Win‐
819       dow is the number of bytes of receive buffer space available the  other
820       direction  on this connection.  Urg indicates there is `urgent' data in
821       the packet.  Opts are TCP options (e.g., mss 1024).  Len is the  length
822       of payload data.
823
824       Iptype,  Src,  dst, and flags are always present.  The other fields de‐
825       pend on the contents of the packet's TCP protocol header and are output
826       only if appropriate.
827
828       Here is the opening portion of an rlogin from host rtsg to host csam.
829              IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]
830              IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
831              IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096
832              IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1
833              IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096
834              IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19
835              IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1
836              IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1
837              IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1
838       The  first  line  says that TCP port 1023 on rtsg sent a packet to port
839       login on csam.  The S indicates that the SYN flag was set.  The  packet
840       sequence  number was 768512 and it contained no data.  (The notation is
841       `first:last' which means `sequence numbers first up to but not  includ‐
842       ing  last'.)  There was no piggy-backed ACK, the available receive win‐
843       dow was 4096 bytes and there was a max-segment-size  option  requesting
844       an MSS of 1024 bytes.
845
846       Csam  replies  with  a similar packet except it includes a piggy-backed
847       ACK for rtsg's SYN.  Rtsg then ACKs csam's SYN.  The `.' means the  ACK
848       flag  was  set.   The  packet contained no data so there is no data se‐
849       quence number or length.  Note that the ACK sequence number is a  small
850       integer  (1).   The  first  time  tcpdump sees a TCP `conversation', it
851       prints the sequence number from the packet.  On subsequent  packets  of
852       the  conversation, the difference between the current packet's sequence
853       number and this initial sequence number is printed.   This  means  that
854       sequence  numbers  after  the first can be interpreted as relative byte
855       positions in the conversation's data stream (with the first  data  byte
856       each  direction  being  `1').  `-S' will override this feature, causing
857       the original sequence numbers to be output.
858
859       On the 6th line, rtsg sends csam 19 bytes of data (bytes 2  through  20
860       in  the rtsg → csam side of the conversation).  The PUSH flag is set in
861       the packet.  On the 7th line, csam says it's received data sent by rtsg
862       up  to but not including byte 21.  Most of this data is apparently sit‐
863       ting in the socket buffer since csam's receive  window  has  gotten  19
864       bytes  smaller.   Csam  also  sends  one  byte  of data to rtsg in this
865       packet.  On the 8th and 9th lines, csam  sends  two  bytes  of  urgent,
866       pushed data to rtsg.
867
868       If  the  snapshot was small enough that tcpdump didn't capture the full
869       TCP header, it interprets as much of the header as it can and then  re‐
870       ports  ``[|tcp]''  to  indicate the remainder could not be interpreted.
871       If the header contains a bogus option (one with a length that's  either
872       too  small  or  beyond  the  end  of the header), tcpdump reports it as
873       ``[bad opt]'' and does not interpret any further  options  (since  it's
874       impossible  to  tell where they start).  If the header length indicates
875       options are present but the IP datagram length is not long  enough  for
876       the  options  to  actually  be  there, tcpdump reports it as ``[bad hdr
877       length]''.
878
879       Capturing TCP packets with particular flag combinations (SYN-ACK,  URG-
880       ACK, etc.)
881
882       There are 8 bits in the control bits section of the TCP header:
883
884              CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
885
886       Let's  assume  that we want to watch packets used in establishing a TCP
887       connection.  Recall that TCP uses a 3-way handshake  protocol  when  it
888       initializes  a  new  connection; the connection sequence with regard to
889       the TCP control bits is
890
891              1) Caller sends SYN
892              2) Recipient responds with SYN, ACK
893              3) Caller sends ACK
894
895       Now we're interested in capturing packets that have only  the  SYN  bit
896       set  (Step  1).  Note that we don't want packets from step 2 (SYN-ACK),
897       just a plain initial SYN.  What we need is a correct filter  expression
898       for tcpdump.
899
900       Recall the structure of a TCP header without options:
901
902        0                            15                              31
903       -----------------------------------------------------------------
904       |          source port          |       destination port        |
905       -----------------------------------------------------------------
906       |                        sequence number                        |
907       -----------------------------------------------------------------
908       |                     acknowledgment number                     |
909       -----------------------------------------------------------------
910       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
911       -----------------------------------------------------------------
912       |         TCP checksum          |       urgent pointer          |
913       -----------------------------------------------------------------
914
915       A  TCP  header  usually  holds  20  octets  of data, unless options are
916       present.  The first line of the graph contains octets 0 - 3, the second
917       line shows octets 4 - 7 etc.
918
919       Starting  to  count with 0, the relevant TCP control bits are contained
920       in octet 13:
921
922        0             7|             15|             23|             31
923       ----------------|---------------|---------------|----------------
924       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
925       ----------------|---------------|---------------|----------------
926       |               |  13th octet   |               |               |
927
928       Let's have a closer look at octet no. 13:
929
930                       |               |
931                       |---------------|
932                       |C|E|U|A|P|R|S|F|
933                       |---------------|
934                       |7   5   3     0|
935
936       These are the TCP control bits we are interested in.  We have  numbered
937       the  bits  in  this octet from 0 to 7, right to left, so the PSH bit is
938       bit number 3, while the URG bit is number 5.
939
940       Recall that we want to capture packets with only SYN  set.   Let's  see
941       what happens to octet 13 if a TCP datagram arrives with the SYN bit set
942       in its header:
943
944                       |C|E|U|A|P|R|S|F|
945                       |---------------|
946                       |0 0 0 0 0 0 1 0|
947                       |---------------|
948                       |7 6 5 4 3 2 1 0|
949
950       Looking at the control bits section we see that only bit number 1 (SYN)
951       is set.
952
953       Assuming  that  octet number 13 is an 8-bit unsigned integer in network
954       byte order, the binary value of this octet is
955
956              00000010
957
958       and its decimal representation is
959
960          7     6     5     4     3     2     1     0
961       0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2
962
963       We're almost done, because now we know that if only  SYN  is  set,  the
964       value  of the 13th octet in the TCP header, when interpreted as a 8-bit
965       unsigned integer in network byte order, must be exactly 2.
966
967       This relationship can be expressed as
968              tcp[13] == 2
969
970       We can use this expression as the filter for tcpdump in order to  watch
971       packets which have only SYN set:
972              tcpdump -i xl0 tcp[13] == 2
973
974       The expression says "let the 13th octet of a TCP datagram have the dec‐
975       imal value 2", which is exactly what we want.
976
977       Now, let's assume that we need to capture SYN  packets,  but  we  don't
978       care  if  ACK  or  any  other  TCP control bit is set at the same time.
979       Let's see what happens to octet 13 when a TCP datagram with SYN-ACK set
980       arrives:
981
982            |C|E|U|A|P|R|S|F|
983            |---------------|
984            |0 0 0 1 0 0 1 0|
985            |---------------|
986            |7 6 5 4 3 2 1 0|
987
988       Now  bits 1 and 4 are set in the 13th octet.  The binary value of octet
989       13 is
990
991                   00010010
992
993       which translates to decimal
994
995          7     6     5     4     3     2     1     0
996       0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18
997
998       Now we can't just use 'tcp[13] == 18' in the tcpdump filter expression,
999       because that would select only those packets that have SYN-ACK set, but
1000       not those with only SYN set.  Remember that we don't care if ACK or any
1001       other control bit is set as long as SYN is set.
1002
1003       In order to achieve our goal, we need to logically AND the binary value
1004       of octet 13 with some other value to preserve the  SYN  bit.   We  know
1005       that  we  want  SYN  to  be set in any case, so we'll logically AND the
1006       value in the 13th octet with the binary value of a SYN:
1007
1008                 00010010 SYN-ACK              00000010 SYN
1009            AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
1010                 --------                      --------
1011            =    00000010                 =    00000010
1012
1013       We see that this AND operation  delivers  the  same  result  regardless
1014       whether ACK or another TCP control bit is set.  The decimal representa‐
1015       tion of the AND value as well as the result of this operation is 2 (bi‐
1016       nary  00000010), so we know that for packets with SYN set the following
1017       relation must hold true:
1018
1019              ( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
1020
1021       This points us to the tcpdump filter expression
1022                   tcpdump -i xl0 'tcp[13] & 2 == 2'
1023
1024       Some offsets and field values may be expressed as names rather than  as
1025       numeric values. For example tcp[13] may be replaced with tcp[tcpflags].
1026       The following TCP flag field values are also available:  tcp-fin,  tcp-
1027       syn, tcp-rst, tcp-push, tcp-ack, tcp-urg.
1028
1029       This can be demonstrated as:
1030                   tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'
1031
1032       Note that you should use single quotes or a backslash in the expression
1033       to hide the AND ('&') special character from the shell.
1034
1035       UDP Packets
1036
1037       UDP format is illustrated by this rwho packet:
1038              actinide.who > broadcast.who: udp 84
1039       This says that port who on host actinide sent a UDP  datagram  to  port
1040       who on host broadcast, the Internet broadcast address.  The packet con‐
1041       tained 84 bytes of user data.
1042
1043       Some UDP services are recognized (from the source or  destination  port
1044       number) and the higher level protocol information printed.  In particu‐
1045       lar, Domain Name service requests (RFC 1034/1035)  and  Sun  RPC  calls
1046       (RFC 1050) to NFS.
1047
1048       TCP or UDP Name Server Requests
1049
1050       (N.B.:The  following  description  assumes  familiarity with the Domain
1051       Service protocol described in RFC 1035.  If you are not  familiar  with
1052       the  protocol,  the  following description will appear to be written in
1053       Greek.)
1054
1055       Name server requests are formatted as
1056              src > dst: id op? flags qtype qclass name (len)
1057              h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
1058       Host h2opolo asked the domain server on helios for  an  address  record
1059       (qtype=A)  associated  with the name ucbvax.berkeley.edu.  The query id
1060       was `3'.  The `+' indicates the recursion desired flag  was  set.   The
1061       query  length  was  37  bytes, excluding the TCP or UDP and IP protocol
1062       headers.  The query operation was the normal  one,  Query,  so  the  op
1063       field  was  omitted.   If  the op had been anything else, it would have
1064       been printed between the `3' and the `+'.  Similarly,  the  qclass  was
1065       the  normal  one,  C_IN, and omitted.  Any other qclass would have been
1066       printed immediately after the `A'.
1067
1068       A few anomalies are checked and may result in extra fields enclosed  in
1069       square  brackets:   If a query contains an answer, authority records or
1070       additional records section, ancount, nscount, or arcount are printed as
1071       `[na]', `[nn]' or  `[nau]' where n is the appropriate count.  If any of
1072       the response bits are set (AA, RA or rcode) or  any  of  the  `must  be
1073       zero' bits are set in bytes two and three, `[b2&3=x]' is printed, where
1074       x is the hex value of header bytes two and three.
1075
1076       TCP or UDP Name Server Responses
1077
1078       Name server responses are formatted as
1079              src > dst:  id op rcode flags a/n/au type class data (len)
1080              helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
1081              helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)
1082       In the first example, helios responds to query id 3 from h2opolo with 3
1083       answer  records,  3  name server records and 7 additional records.  The
1084       first answer record is type A (address) and its data  is  internet  ad‐
1085       dress  128.32.137.3.  The total size of the response was 273 bytes, ex‐
1086       cluding TCP or UDP and IP headers.  The op (Query)  and  response  code
1087       (NoError) were omitted, as was the class (C_IN) of the A record.
1088
1089       In  the second example, helios responds to query 2 with a response code
1090       of non-existent domain (NXDomain) with no answers, one name server  and
1091       no  authority records.  The `*' indicates that the authoritative answer
1092       bit was set.  Since there were no answers, no type, class or data  were
1093       printed.
1094
1095       Other  flag  characters that might appear are `-' (recursion available,
1096       RA, not set) and `|' (truncated message, TC, set).  If  the  `question'
1097       section doesn't contain exactly one entry, `[nq]' is printed.
1098
1099       SMB/CIFS decoding
1100
1101       tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data on
1102       UDP/137, UDP/138 and TCP/139.  Some primitive decoding of IPX and  Net‐
1103       BEUI SMB data is also done.
1104
1105       By  default  a fairly minimal decode is done, with a much more detailed
1106       decode done if -v is used.  Be warned that with -v a single SMB  packet
1107       may  take  up a page or more, so only use -v if you really want all the
1108       gory details.
1109
1110       For information on SMB packet formats and what all the fields mean  see
1111       https://download.samba.org/pub/samba/specs/ and other online resources.
1112       The SMB patches were written by Andrew Tridgell (tridge@samba.org).
1113
1114       NFS Requests and Replies
1115
1116       Sun NFS (Network File System) requests and replies are printed as:
1117              src.sport > dst.nfs: NFS request xid xid len op args
1118              src.nfs > dst.dport: NFS reply xid xid reply stat len op results
1119              sushi.1023 > wrl.nfs: NFS request xid 26377
1120                   112 readlink fh 21,24/10.73165
1121              wrl.nfs > sushi.1023: NFS reply xid 26377
1122                   reply ok 40 readlink "../var"
1123              sushi.1022 > wrl.nfs: NFS request xid 8219
1124                   144 lookup fh 9,74/4096.6878 "xcolors"
1125              wrl.nfs > sushi.1022: NFS reply xid 8219
1126                   reply ok 128 lookup fh 9,74/4134.3150
1127       In the first line, host sushi sends a transaction with id 26377 to wrl.
1128       The request was 112 bytes, excluding the UDP and IP headers.  The oper‐
1129       ation  was  a  readlink  (read  symbolic  link)  on  file  handle  (fh)
1130       21,24/10.731657119.  (If one is lucky, as in this case, the file handle
1131       can be interpreted as a major,minor device number pair, followed by the
1132       inode  number  and  generation number.) In the second line, wrl replies
1133       `ok' with the same transaction id and the contents of the link.
1134
1135       In the third line, sushi asks (using  a  new  transaction  id)  wrl  to
1136       lookup  the  name  `xcolors'  in  directory file 9,74/4096.6878. In the
1137       fourth line, wrl sends a reply with the respective transaction id.
1138
1139       Note that the data printed depends on the operation type.   The  format
1140       is  intended  to be self explanatory if read in conjunction with an NFS
1141       protocol spec.  Also note that older versions of  tcpdump  printed  NFS
1142       packets  in a slightly different format: the transaction id (xid) would
1143       be printed instead of the non-NFS port number of the packet.
1144
1145       If the -v (verbose) flag is given, additional information  is  printed.
1146       For example:
1147              sushi.1023 > wrl.nfs: NFS request xid 79658
1148                   148 read fh 21,11/12.195 8192 bytes @ 24576
1149              wrl.nfs > sushi.1023: NFS reply xid 79658
1150                   reply ok 1472 read REG 100664 ids 417/0 sz 29388
1151       (-v  also  prints  the  IP  header  TTL,  ID, length, and fragmentation
1152       fields, which have been omitted from this example.)  In the first line,
1153       sushi  asks wrl to read 8192 bytes from file 21,11/12.195, at byte off‐
1154       set 24576.  Wrl replies `ok'; the packet shown on the  second  line  is
1155       the first fragment of the reply, and hence is only 1472 bytes long (the
1156       other bytes will follow in subsequent fragments, but these fragments do
1157       not have NFS or even UDP headers and so might not be printed, depending
1158       on the filter expression used).  Because the -v flag is given, some  of
1159       the  file  attributes (which are returned in addition to the file data)
1160       are printed: the file type (``REG'', for regular file), the  file  mode
1161       (in octal), the UID and GID, and the file size.
1162
1163       If the -v flag is given more than once, even more details are printed.
1164
1165       NFS  reply  packets  do not explicitly identify the RPC operation.  In‐
1166       stead, tcpdump keeps track of ``recent'' requests, and matches them  to
1167       the replies using the transaction ID.  If a reply does not closely fol‐
1168       low the corresponding request, it might not be parsable.
1169
1170       AFS Requests and Replies
1171
1172       Transarc AFS (Andrew File System) requests and replies are printed as:
1173
1174              src.sport > dst.dport: rx packet-type
1175              src.sport > dst.dport: rx packet-type service call call-name args
1176              src.sport > dst.dport: rx packet-type service reply call-name args
1177              elvis.7001 > pike.afsfs:
1178                   rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
1179                   new fid 536876964/1/1 ".newsrc"
1180              pike.afsfs > elvis.7001: rx data fs reply rename
1181       In the first line, host elvis sends a RX packet to pike.  This was a RX
1182       data  packet to the fs (fileserver) service, and is the start of an RPC
1183       call.  The RPC call was a rename, with the old  directory  file  id  of
1184       536876964/1/1 and an old filename of `.newsrc.new', and a new directory
1185       file id of 536876964/1/1 and a new filename  of  `.newsrc'.   The  host
1186       pike  responds  with a RPC reply to the rename call (which was success‐
1187       ful, because it was a data packet and not an abort packet).
1188
1189       In general, all AFS RPCs are decoded at least by RPC call  name.   Most
1190       AFS  RPCs  have  at least some of the arguments decoded (generally only
1191       the `interesting' arguments, for some definition of interesting).
1192
1193       The format is intended to be self-describing, but it will probably  not
1194       be  useful  to people who are not familiar with the workings of AFS and
1195       RX.
1196
1197       If the -v (verbose) flag is given twice,  acknowledgement  packets  and
1198       additional  header information is printed, such as the RX call ID, call
1199       number, sequence number, serial number, and the RX packet flags.
1200
1201       If the -v flag is given twice, additional information is printed,  such
1202       as the RX call ID, serial number, and the RX packet flags.  The MTU ne‐
1203       gotiation information is also printed from RX ack packets.
1204
1205       If the -v flag is given three times, the security index and service  id
1206       are printed.
1207
1208       Error  codes  are printed for abort packets, with the exception of Ubik
1209       beacon packets (because abort packets are used to signify  a  yes  vote
1210       for the Ubik protocol).
1211
1212       AFS  reply  packets  do not explicitly identify the RPC operation.  In‐
1213       stead, tcpdump keeps track of ``recent'' requests, and matches them  to
1214       the  replies using the call number and service ID.  If a reply does not
1215       closely follow the corresponding request, it might not be parsable.
1216
1217
1218       KIP AppleTalk (DDP in UDP)
1219
1220       AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated
1221       and dumped as DDP packets (i.e., all the UDP header information is dis‐
1222       carded).  The file /etc/atalk.names is used to translate AppleTalk  net
1223       and node numbers to names.  Lines in this file have the form
1224              number    name
1225
1226              1.254          ether
1227              16.1      icsd-net
1228              1.254.110 ace
1229       The  first  two  lines give the names of AppleTalk networks.  The third
1230       line gives the name of a particular host (a host is distinguished  from
1231       a  net  by  the  3rd  octet  in the number - a net number must have two
1232       octets and a host number must have three octets.)  The number and  name
1233       should   be   separated   by   whitespace   (blanks   or   tabs).   The
1234       /etc/atalk.names file may contain blank lines or comment  lines  (lines
1235       starting with a `#').
1236
1237       AppleTalk addresses are printed in the form
1238              net.host.port
1239
1240              144.1.209.2 > icsd-net.112.220
1241              office.2 > icsd-net.112.220
1242              jssmag.149.235 > icsd-net.2
1243       (If  the /etc/atalk.names doesn't exist or doesn't contain an entry for
1244       some AppleTalk host/net number, addresses are printed in numeric form.)
1245       In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending
1246       to whatever is listening on port 220 of net icsd node 112.  The  second
1247       line is the same except the full name of the source node is known (`of‐
1248       fice').  The third line is a send from port 235 on net jssmag node  149
1249       to  broadcast on the icsd-net NBP port (note that the broadcast address
1250       (255) is indicated by a net name with no host number - for this  reason
1251       it's  a  good  idea  to  keep  node  names  and  net  names distinct in
1252       /etc/atalk.names).
1253
1254       NBP (name binding protocol) and ATP  (AppleTalk  transaction  protocol)
1255       packets have their contents interpreted.  Other protocols just dump the
1256       protocol name (or number if no name is registered for the protocol) and
1257       packet size.
1258
1259       NBP packets are formatted like the following examples:
1260              icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
1261              jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
1262              techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
1263       The  first  line  is a name lookup request for laserwriters sent by net
1264       icsd host 112 and broadcast on net jssmag.  The nbp id for  the  lookup
1265       is  190.   The second line shows a reply for this request (note that it
1266       has the same id) from host jssmag.209 saying that it has a  laserwriter
1267       resource  named "RM1140" registered on port 250.  The third line is an‐
1268       other reply to the same request saying  host  techpit  has  laserwriter
1269       "techpit" registered on port 186.
1270
1271       ATP packet formatting is demonstrated by the following example:
1272              jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
1273              helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
1274              helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
1275              helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
1276              helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
1277              helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
1278              helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
1279              helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
1280              helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
1281              jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
1282              helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
1283              helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
1284              jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
1285              jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
1286       Jssmag.209  initiates transaction id 12266 with host helios by request‐
1287       ing up to 8 packets (the `<0-7>').  The hex number at the  end  of  the
1288       line is the value of the `userdata' field in the request.
1289
1290       Helios  responds  with  8 512-byte packets.  The `:digit' following the
1291       transaction id gives the packet sequence number in the transaction  and
1292       the number in parens is the amount of data in the packet, excluding the
1293       ATP header.  The `*' on packet 7 indicates that the EOM bit was set.
1294
1295       Jssmag.209 then requests that packets 3 & 5 be  retransmitted.   Helios
1296       resends  them  then jssmag.209 releases the transaction.  Finally, jss‐
1297       mag.209 initiates the next request.  The `*' on the  request  indicates
1298       that XO (`exactly once') was not set.
1299
1300

SEE ALSO

1302       stty(1),     pcap(3PCAP),     bpf(4),     nit(4P),    pcap-savefile(5),
1303       pcap-filter(7), pcap-tstamp(7)
1304
1305              https://www.iana.org/assignments/media-types/applica
1306              tion/vnd.tcpdump.pcap
1307

AUTHORS

1309       The original authors are:
1310
1311       Van  Jacobson,  Craig  Leres  and  Steven  McCanne, all of the Lawrence
1312       Berkeley National Laboratory, University of California, Berkeley, CA.
1313
1314       It is currently maintained by The Tcpdump Group.
1315
1316       The current version is available via HTTPS:
1317
1318              https://www.tcpdump.org/
1319
1320       The original distribution is available via anonymous ftp:
1321
1322              ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z
1323
1324       IPv6/IPsec support is added by WIDE/KAME project.   This  program  uses
1325       OpenSSL/LibreSSL, under specific configurations.
1326

BUGS

1328       To    report    a   security   issue   please   send   an   e-mail   to
1329       security@tcpdump.org.
1330
1331       To report bugs and other problems, contribute patches, request  a  fea‐
1332       ture, provide generic feedback etc. please see the file CONTRIBUTING.md
1333       in the tcpdump source tree root.
1334
1335       NIT doesn't let you watch your own outbound traffic, BPF will.  We rec‐
1336       ommend that you use the latter.
1337
1338       On Linux systems with 2.0[.x] kernels:
1339
1340              packets on the loopback device will be seen twice;
1341
1342              packet filtering cannot be done in the kernel, so that all pack‐
1343              ets must be copied from the kernel in order to  be  filtered  in
1344              user mode;
1345
1346              all  of  a  packet, not just the part that's within the snapshot
1347              length, will be copied from the kernel (the 2.0[.x] packet  cap‐
1348              ture  mechanism,  if  asked  to  copy  only  part of a packet to
1349              userspace, will not report the true length of the  packet;  this
1350              would cause most IP packets to get an error from tcpdump);
1351
1352              capturing on some PPP devices won't work correctly.
1353
1354       We recommend that you upgrade to a 2.2 or later kernel.
1355
1356       Some  attempt should be made to reassemble IP fragments or, at least to
1357       compute the right length for the higher level protocol.
1358
1359       Name server inverse queries are not dumped correctly: the (empty) ques‐
1360       tion  section  is printed rather than real query in the answer section.
1361       Some believe that inverse queries are themselves a bug  and  prefer  to
1362       fix the program generating them rather than tcpdump.
1363
1364       A  packet  trace  that crosses a daylight savings time change will give
1365       skewed time stamps (the time change is ignored).
1366
1367       Filter expressions on fields other than those  in  Token  Ring  headers
1368       will not correctly handle source-routed Token Ring packets.
1369
1370       Filter  expressions  on  fields other than those in 802.11 headers will
1371       not correctly handle 802.11 data packets with both To DS  and  From  DS
1372       set.
1373
1374       ip6  proto  should  chase header chain, but at this moment it does not.
1375       ip6 protochain is supplied for this behavior.
1376
1377       Arithmetic expression against transport  layer  headers,  like  tcp[0],
1378       does not work against IPv6 packets.  It only looks at IPv4 packets.
1379
1380
1381
1382                                 30 July 2022                       TCPDUMP(8)
Impressum