Linux "tcpdump" Command Line Options and Examples
dump traffic on a network

Tcpdump prints out a description of the contents of packets on a network interface that match the boolean expression; the description is preceded by a time stamp, printed, by default, as hours, minutes, seconds, and fractions of a second since midnight.


Usage:

tcpdump [ -AbdDefhHIJKlLnNOpqStuUvxX# ] [ -B buffer_size ]
[ -c count ]
[ -C file_size ] [ -G rotate_seconds ] [ -F file ]
[ -i interface ] [ -j tstamp_type ] [ -m module ] [ -M secret ]
[ --number ] [ -Q in|out|inout ]
[ -r file ] [ -V file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ]
[ -E spi@ipaddr algo:secret,... ]
[ -y datalinktype ] [ -z postrotate-command ] [ -Z user ]
[ --time-stamp-precision=tstamp_precision ]
[ --immediate-mode ] [ --version ]
[ expression ]






Command Line Options:

-A
Print each packet (minus its link level header) in ASCII. Handy for capturing web pages.
tcpdump -A ...
-b
Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN notation.
tcpdump -b ...
--buffer-size
Set the operating system capture buffer size to buffer_size, in units of KiB (1024 bytes).
tcpdump --buffer-size ...
-c
Exit after receiving count packets.
tcpdump -c ...
-C
Before writing a raw packet to a savefile, check whether the file is currently larger than file_sizeand, if so, close the current savefile and open a new one. Savefiles after the first savefile willhave the name specified with the -w flag, with a number after it, starting at 1 and continuing upward.The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576 bytes).
tcpdump -C ...
-d
Dump the compiled packet-matching code in a human readable form to standard output and stop.
tcpdump -d ...
-dd
Dump packet-matching code as a C program fragment.
tcpdump -dd ...
-ddd
Dump packet-matching code as decimal numbers (preceded with a count).
tcpdump -ddd ...
--list-interfaces
Print the list of the network interfaces available on the system and on which tcpdump can capture pack‐ets. For each network interface, a number and an interface name, possibly followed by a text descrip‐tion of the interface, is printed. The interface name or the number can be supplied to the -i flag tospecify an interface on which to capture.This can be useful on systems that don't have a command to list them (e.g., Windows systems, or UNIXsystems lacking ifconfig -a); the number can be useful on Windows 2000 and later systems, where theinterface name is a somewhat complex string.The -D flag will not be supported if tcpdump was built with an older version of libpcap that lacks thepcap_findalldevs() function.
tcpdump --list-interfaces ...
-F
Use file as input for the filter expression. An additional expression given on the command line isignored.
tcpdump -F ...
-G
If specified, rotates the dump file specified with the -w option every rotate_seconds seconds. Save‐files will have the name specified by -w which should include a time format as defined by strftime(3).If no time format is specified, each new file will overwrite the previous.If used in conjunction with the -C option, filenames will take the form of `file<count>'.
tcpdump -G ...
--help
Print the tcpdump and libpcap version strings, print a usage message, and exit.
tcpdump --help ...
--version
Print the tcpdump and libpcap version strings and exit.
tcpdump --version ...
-H
Attempt to detect 802.11s draft mesh headers.
tcpdump -H ...
--interface
Listen on interface. If unspecified, tcpdump searches the system interface list for the lowest num‐bered, configured up interface (excluding loopback), which may turn out to be, for example, ``eth0''.On Linux systems with 2.2 or later kernels, an interface argument of ``any'' can be used to capturepackets from all interfaces. Note that captures on the ``any'' device will not be done in promiscuousmode.If the -D flag is supported, an interface number as printed by that flag can be used as the interfaceargument, if no interface on the system has that number as a name.
tcpdump --interface ...
--monitor-mode
Put the interface in "monitor mode"; this is supported only on IEEE 802.11 Wi-Fi interfaces, and sup‐ported only on some operating systems.Note that in monitor mode the adapter might disassociate from the network with which it's associated,so that you will not be able to use any wireless networks with that adapter. This could preventaccessing files on a network server, or resolving host names or network addresses, if you are capturingin monitor mode and are not connected to another network with another adapter.This flag will affect the output of the -L flag. If -I isn't specified, only those link-layer typesavailable when not in monitor mode will be shown; if -I is specified, only those link-layer typesavailable when in monitor mode will be shown.
tcpdump --monitor-mode ...
--immediate-mode
Capture in "immediate mode". In this mode, packets are delivered to tcpdump as soon as they arrive,rather than being buffered for efficiency. This is the default when printing packets rather than sav‐ing packets to a ``savefile'' if the packets are being printed to a terminal rather than to a file orpipe.
tcpdump --immediate-mode ...
--time-stamp-type
Set the time stamp type for the capture to tstamp_type. The names to use for the time stamp types aregiven in pcap-tstamp(7); not all the types listed there will necessarily be valid for any given inter‐face.
tcpdump --time-stamp-type ...
--list-time-stamp-types
List the supported time stamp types for the interface and exit. If the time stamp type cannot be setfor the interface, no time stamp types are listed.
tcpdump --list-time-stamp-types ...
--time-stamp-precision
When capturing, set the time stamp precision for the capture to tstamp_precision. Note that availabil‐ity of high precision time stamps (nanoseconds) and their actual accuracy is platform and hardwaredependent. Also note that when writing captures made with nanosecond accuracy to a savefile, the timestamps are written with nanosecond resolution, and the file is written with a different magic number,to indicate that the time stamps are in seconds and nanoseconds; not all programs that read pcap save‐files will be able to read those captures.When reading a savefile, convert time stamps to the precision specified by timestamp_precision, and displaythem with that resolution. If the precision specified is less than the precision of time stamps in the file,the conversion will lose precision.The supported values for timestamp_precision are micro for microsecond resolution and nano for nanosecond res‐olution. The default is microsecond resolution.
tcpdump --time-stamp-precision ...
--dont-verify-checksums
Don't attempt to verify IP, TCP, or UDP checksums. This is useful for interfaces that perform some orall of those checksum calculation in hardware; otherwise, all outgoing TCP checksums will be flagged asbad.
tcpdump --dont-verify-checksums ...
-l
tcpdump -l | tee datortcpdump -l > dat & tail -f datNote that on Windows,``line buffered'' means ``unbuffered'', so that WinDump will write each characterindividually if -l is specified.
tcpdump -l ...
--list-data-link-types
List the known data link types for the interface, in the specified mode, and exit. The list of knowndata link types may be dependent on the specified mode; for example, on some platforms, a Wi-Fi inter‐face might support one set of data link types when not in monitor mode (for example, it might supportonly fake Ethernet headers, or might support 802.11 headers but not support 802.11 headers with radioinformation) and another set of data link types when in monitor mode (for example, it might support802.11 headers, or 802.11 headers with radio information, only in monitor mode).
tcpdump --list-data-link-types ...
-m
Load SMI MIB module definitions from file module. This option can be used several times to load sev‐eral MIB modules into tcpdump.
tcpdump -m ...
-M
Use secret as a shared secret for validating the digests found in TCP segments with the TCP-MD5 option(RFC 2385), if present.
tcpdump -M ...
-n
Don't convert addresses (i.e., host addresses, port numbers, etc.) to names
tcpdump -n ...
--number
Print an optional packet number at the beginning of the line.
tcpdump --number ...
--no-optimize
Do not run the packet-matching code optimizer. This is useful only if you suspect a bug in the opti‐mizer.
tcpdump --no-optimize ...
--no-promiscuous-mode
Don't put the interface into promiscuous mode. Note that the interface might be in promiscuous modefor some other reason; hence, `-p' cannot be used as an abbreviation for `ether host {local-hw-addr} orether broadcast'.
tcpdump --no-promiscuous-mode ...
--direction
Choose send/receive direction direction for which packets should be captured. Possible values are `in',`out' and `inout'. Not available on all platforms.
tcpdump --direction ...
-q
Quick (quiet?) output. Print less protocol information so output lines are shorter.
tcpdump -q ...
-r
Read packets from file (which was created with the -w option or by other tools that write pcap or pcap-ng files). Standard input is used if file is ``-''.
tcpdump -r ...
--absolute-tcp-sequence-numbers
Print absolute, rather than relative, TCP sequence numbers.
tcpdump --absolute-tcp-sequence-numbers ...
--snapshot-length
Snarf snaplen bytes of data from each packet rather than the default of 262144 bytes. Packets trun‐cated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is thename of the protocol level at which the truncation has occurred. Note that taking larger snapshotsboth increases the amount of time it takes to process packets and, effectively, decreases the amount ofpacket buffering. This may cause packets to be lost. You should limit snaplen to the smallest numberthat will capture the protocol information you're interested in. Setting snaplen to 0 sets it to thedefault of 262144, for backwards compatibility with recent older versions of tcpdump.
tcpdump --snapshot-length ...
-T
Force packets selected by "expression" to be interpreted the specified type. Currently known types areaodv (Ad-hoc On-demand Distance Vector protocol), carp (Common Address Redundancy Protocol), cnfp(Cisco NetFlow protocol), lmp (Link Management Protocol), pgm (Pragmatic General Multicast), pgm_zmtp1(ZMTP/1.0 inside PGM/EPGM), resp (REdis Serialization Protocol), radius (RADIUS), rpc (Remote ProcedureCall), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), snmp(Simple Network Management Protocol), tftp (Trivial File Transfer Protocol), vat (Visual Audio Tool),wb (distributed White Board), zmtp1 (ZeroMQ Message Transport Protocol 1.0) and vxlan (Virtual eXtensi‐ble Local Area Network).Note that the pgm type above affects UDP interpretation only, the native PGM is always recognised as IPprotocol 113 regardless. UDP-encapsulated PGM is often called "EPGM" or "PGM/UDP".Note that the pgm_zmtp1 type above affects interpretation of both native PGM and UDP at once. Duringthe native PGM decoding the application data of an ODATA/RDATA packet would be decoded as a ZeroMQdatagram with ZMTP/1.0 frames. During the UDP decoding in addition to that any UDP packet would betreated as an encapsulated PGM packet.
tcpdump -T ...
-t
Don't print a timestamp on each dump line.
tcpdump -t ...
-ttt
Print a delta (micro-second resolution) between current and previous line on each dump line.
tcpdump -ttt ...
-ttttt
Print a delta (micro-second resolution) between current and first line on each dump line.
tcpdump -ttttt ...
-u
Print undecoded NFS handles.
tcpdump -u ...
--packet-buffered
If the -w option is not specified, make the printed packet output ``packet-buffered''; i.e., as thedescription of the contents of each packet is printed, it will be written to the standard output,rather than, when not writing to a terminal, being written only when the output buffer fills.If the -w option is specified, make the saved raw packet output ``packet-buffered''; i.e., as eachpacket is saved, it will be written to the output file, rather than being written only when the outputbuffer fills.The -U flag will not be supported if tcpdump was built with an older version of libpcap that lacks thepcap_dump_flush() function.
tcpdump --packet-buffered ...
-V
Read a list of filenames from file. Standard input is used if file is ``-''.
tcpdump -V ...
-w
Write the raw packets to file rather than parsing and printing them out. They can later be printedwith the -r option. Standard output is used if file is ``-''.This output will be buffered if written to a file or pipe, so a program reading from the file or pipemay not see packets for an arbitrary amount of time after they are received. Use the -U flag to causepackets to be written as soon as they are received.The MIME type application/vnd.tcpdump.pcap has been registered with IANA for pcap files. The filenameextension .pcap appears to be the most commonly used along with .cap and .dmp. Tcpdump itself doesn'tcheck the extension when reading capture files and doesn't add an extension when writing them (it usesmagic numbers in the file header instead). However, many operating systems and applications will usethe extension if it is present and adding one (e.g. .pcap) is recommended.See pcap-savefile(5) for a description of the file format.
tcpdump -w ...
--linktype
Set the data link type to use while capturing packets to datalinktype.
tcpdump --linktype ...
-z
Used in conjunction with the -C or -G options, this will make tcpdump run " postrotate-command file "where file is the savefile being closed after each rotation. For example, specifying -z gzip or -zbzip2 will compress each savefile using gzip or bzip2.Note that tcpdump will run the command in parallel to the capture, using the lowest priority so thatthis doesn't disturb the capture process.And in case you would like to use a command that itself takes flags or different arguments, you canalways write a shell script that will take the savefile name as the only argument, make the flags &arguments arrangements and execute the command that you want.
tcpdump -z ...
--relinquish-privileges
If tcpdump is running as root, after opening the capture device or input savefile, but before openingany savefiles for output, change the user ID to user and the group ID to the primary group of user.This behavior can also be enabled by default at compile time.expressionselects which packets will be dumped. If no expression is given, all packets on the net will bedumped. Otherwise, only packets for which expression is `true' will be dumped.For the expression syntax, see pcap-filter(7).The expression argument can be passed to tcpdump as either a single Shell argument, or as multipleShell arguments, whichever is more convenient. Generally, if the expression contains Shell metacharac‐ters, such as backslashes used to escape protocol names, it is easier to pass it as a single, quotedargument rather than to escape the Shell metacharacters. Multiple arguments are concatenated with spa‐ces before being parsed.EXAMPLESTo print all packets arriving at or departing from sundown:tcpdump host sundownTo print traffic between helios and either hot or ace:tcpdump host helios and \( hot or ace \)To print all IP packets between ace and any host except helios:tcpdump ip host ace and not heliosTo print all traffic between local hosts and hosts at Berkeley:tcpdump net ucb-etherTo print all ftp traffic through internet gateway snup: (note that the expression is quoted to prevent theshell from (mis-)interpreting the parentheses):tcpdump 'gateway snup and (port ftp or ftp-data)'To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, thisstuff should never make it onto your local net).tcpdump ip and not net localnetTo print the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host.tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'To print all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not, for exam‐ple, SYN and FIN packets and ACK-only packets. (IPv6 is left as an exercise for the reader.)tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'To print IP packets longer than 576 bytes sent through gateway snup:tcpdump 'gateway snup and ip[2:2] > 576'To print IP broadcast or multicast packets that were not sent via Ethernet broadcast or multicast:tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'To print all ICMP packets that are not echo requests/replies (i.e., not ping packets):tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'OUTPUT FORMATThe output of tcpdump is protocol dependent. The following gives a brief description and examples of most ofthe formats.TimestampsBy default, all output lines are preceded by a timestamp. The timestamp is the current clock time in the formhh:mm:ss.fracand is as accurate as the kernel's clock. The timestamp reflects the time the kernel applied a time stamp tothe packet. No attempt is made to account for the time lag between when the network interface finishedreceiving the packet from the network and when the kernel applied a time stamp to the packet; that time lagcould include a delay between the time when the network interface finished receiving a packet from the networkand the time when an interrupt was delivered to the kernel to get it to read the packet and a delay betweenthe time when the kernel serviced the `new packet' interrupt and the time when it applied a time stamp to thepacket.Link Level HeadersIf the '-e' option is given, the link level header is printed out. On Ethernets, the source and destinationaddresses, protocol, and packet length are printed.On FDDI networks, the '-e' option causes tcpdump to print the `frame control' field, the source and destina‐tion addresses, and the packet length. (The `frame control' field governs the interpretation of the rest ofthe packet. Normal packets (such as those containing IP datagrams) are `async' packets, with a priority valuebetween 0 and 7; for example, `async4'. Such packets are assumed to contain an 802.2 Logical Link Control(LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-called SNAP packet.On Token Ring networks, the '-e' option causes tcpdump to print the `access control' and `frame control'fields, the source and destination addresses, and the packet length. As on FDDI networks, packets are assumedto contain an LLC packet. Regardless of whether the '-e' option is specified or not, the source routinginformation is printed for source-routed packets.On 802.11 networks, the '-e' option causes tcpdump to print the `frame control' fields, all of the addressesin the 802.11 header, and the packet length. As on FDDI networks, packets are assumed to contain an LLCpacket.(N.B.: The following description assumes familiarity with the SLIP compression algorithm described inRFC-1144.)On SLIP links, a direction indicator (``I'' for inbound, ``O'' for outbound), packet type, and compressioninformation are printed out. The packet type is printed first. The three types are ip, utcp, and ctcp. Nofurther link information is printed for ip packets. For TCP packets, the connection identifier is printedfollowing the type. If the packet is compressed, its encoded header is printed out. The special cases areprinted out as *S+n and *SA+n, where n is the amount by which the sequence number (or sequence number and ack)has changed. If it is not a special case, zero or more changes are printed. A change is indicated by U(urgent pointer), W (window), A (ack), S (sequence number), and I (packet ID), followed by a delta (+n or -n),or a new value (=n). Finally, the amount of data in the packet and compressed header length are printed.For example, the following line shows an outbound compressed TCP packet, with an implicit connection identi‐fier; the ack has changed by 6, the sequence number by 49, and the packet ID by 6; there are 3 bytes of dataand 6 bytes of compressed header:O ctcp * A+6 S+49 I+6 3 (6)ARP/RARP PacketsArp/rarp output shows the type of request and its arguments. The format is intended to be self explanatory.Here is a short sample taken from the start of an `rlogin' from host rtsg to host csam:arp who-has csam tell rtsgarp reply csam is-at CSAMThe first line says that rtsg sent an arp packet asking for the Ethernet address of internet host csam. Csamreplies with its Ethernet address (in this example, Ethernet addresses are in caps and internet addresses inlower case).This would look less redundant if we had done tcpdump -n:arp who-has 128.3.254.6 tell 128.3.254.68arp reply 128.3.254.6 is-at 02:07:01:00:01:c4If we had done tcpdump -e, the fact that the first packet is broadcast and the second is point-to-point wouldbe visible:RTSG Broadcast 0806 64: arp who-has csam tell rtsgCSAM RTSG 0806 64: arp reply csam is-at CSAMFor the first packet this says the Ethernet source address is RTSG, the destination is the Ethernet broadcastaddress, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.IPv4 PacketsIf the link-layer header is not being printed, for IPv4 packets, IP is printed after the time stamp.If the -v flag is specified, information from the IPv4 header is shown in parentheses after the IP or thelink-layer header. The general format of this information is:tos tos, ttl ttl, id id, offset offset, flags [flags], proto proto, length length, options (options)tos is the type of service field; if the ECN bits are non-zero, those are reported as ECT(1), ECT(0), or CE.ttl is the time-to-live; it is not reported if it is zero. id is the IP identification field. offset is thefragment offset field; it is printed whether this is part of a fragmented datagram or not. flags are the MFand DF flags; + is reported if MF is set, and DFP is reported if F is set. If neither are set, . is reported.proto is the protocol ID field. length is the total length field. options are the IP options, if any.Next, for TCP and UDP packets, the source and destination IP addresses and TCP or UDP ports, with a dotbetween each IP address and its corresponding port, will be printed, with a > separating the source and desti‐nation. For other protocols, the addresses will be printed, with a > separating the source and destination.Higher level protocol information, if any, will be printed after that.For fragmented IP datagrams, the first fragment contains the higher level protocol header; fragments after thefirst contain no higher level protocol header. Fragmentation information will be printed only with the -vflag, in the IP header information, as described above.TCP Packets(N.B.:The following description assumes familiarity with the TCP protocol described in RFC-793. If you arenot familiar with the protocol, this description will not be of much use to you.)The general format of a TCP protocol line is:src > dst: Flags [tcpflags], seq data-seqno, ack ackno, win window, urg urgent, options [opts], length lenSrc and dst are the source and destination IP addresses and ports. Tcpflags are some combination of S (SYN),F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or `.' (ACK), or `none' if no flags are set.Data-seqno describes the portion of sequence space covered by the data in this packet (see example below).Ackno is sequence number of the next data expected the other direction on this connection. Window is the num‐ber of bytes of receive buffer space available the other direction on this connection. Urg indicates there is`urgent' data in the packet. Opts are TCP options (e.g., mss 1024). Len is the length of payload data.Iptype, Src, dst, and flags are always present. The other fields depend on the contents of the packet's TCPprotocol header and are output only if appropriate.Here is the opening portion of an rlogin from host rtsg to host csam.IP rtsg.1023 > csam.login: Flags [S], seq 768512:768512, win 4096, opts [mss 1024]IP csam.login > rtsg.1023: Flags [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]IP rtsg.1023 > csam.login: Flags [.], ack 1, win 4096IP rtsg.1023 > csam.login: Flags [P.], seq 1:2, ack 1, win 4096, length 1IP csam.login > rtsg.1023: Flags [.], ack 2, win 4096IP rtsg.1023 > csam.login: Flags [P.], seq 2:21, ack 1, win 4096, length 19IP csam.login > rtsg.1023: Flags [P.], seq 1:2, ack 21, win 4077, length 1IP csam.login > rtsg.1023: Flags [P.], seq 2:3, ack 21, win 4077, urg 1, length 1IP csam.login > rtsg.1023: Flags [P.], seq 3:4, ack 21, win 4077, urg 1, length 1The first line says that TCP port 1023 on rtsg sent a packet to port login on csam. The S indicates that theSYN flag was set. The packet sequence number was 768512 and it contained no data. (The notation is`first:last' which means `sequence numbers first up to but not including last.) There was no piggy-backedack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of1024 bytes.Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then ackscsam's SYN. The `.' means the ACK flag was set. The packet contained no data so there is no data sequencenumber or length. Note that the ack sequence number is a small integer (1). The first time tcpdump sees aTCP `conversation', it prints the sequence number from the packet. On subsequent packets of the conversation,the difference between the current packet's sequence number and this initial sequence number is printed. Thismeans that sequence numbers after the first can be interpreted as relative byte positions in the conversa‐tion's data stream (with the first data byte each direction being `1'). `-S' will override this feature,causing the original sequence numbers to be output.On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg → csam side of the conversa‐tion). The PUSH flag is set in the packet. On the 7th line, csam says it's received data sent by rtsg up tobut not including byte 21. Most of this data is apparently sitting in the socket buffer since csam's receivewindow has gotten 19 bytes smaller. Csam also sends one byte of data to rtsg in this packet. On the 8th and9th lines, csam sends two bytes of urgent, pushed data to rtsg.If the snapshot was small enough that tcpdump didn't capture the full TCP header, it interprets as much of theheader as it can and then reports ``[|tcp]'' to indicate the remainder could not be interpreted. If theheader contains a bogus option (one with a length that's either too small or beyond the end of the header),tcpdump reports it as ``[bad opt]'' and does not interpret any further options (since it's impossible to tellwhere they start). If the header length indicates options are present but the IP datagram length is not longenough for the options to actually be there, tcpdump reports it as ``[bad hdr length]''.Capturing TCP packets with particular flag combinations (SYN-ACK, URG-ACK, etc.)There are 8 bits in the control bits section of the TCP header:CWR | ECE | URG | ACK | PSH | RST | SYN | FINLet's assume that we want to watch packets used in establishing a TCP connection. Recall that TCP uses a
tcpdump --relinquish-privileges ...