tcpdump - Unix, Linux Command

Tcpdump prints out the headers of packets on a network interface
that match the boolean expression.  It can also be run with the
-w flag, which causes it to save the packet data to a file for later
analysis, and/or with the
-r flag, which causes it to read from a saved packet file rather than to
read packets from a network interface.  In all cases, only packets that
match
expression will be processed by
tcpdump. 

Tcpdump will, if not run with the
-c flag, continue capturing packets until it is interrupted by a SIGINT
signal (generated, for example, by typing your interrupt character,
typically control-C) or a SIGTERM signal (typically generated with the
kill(1)
command); if run with the
-c flag, it will capture packets until it is interrupted by a SIGINT or
SIGTERM signal or the specified number of packets have been processed.


When
tcpdump finishes capturing packets, it will report counts of:


Note that when used with -Z option (enabled by default), privileges
are dropped before opening first savefile.




The expression consists of one or more
primitives. Primitives usually consist of an
id (name or number) preceded by one or more qualifiers.
There are three
different kinds of qualifier:

ip host host

ether proto \ip and host host

ether host ehost and not host host

tcp src port port

len <= length.

len >= length.

ip6 protochain 6

ether proto p

ether proto p

vlan 100 && vlan 200

vlan && vlan 300 && ip

mpls 100000 && mpls 1024

mpls && mpls 1024 && host 192.9.200.1

pppoes && ip

ip proto p or ip6 proto p

iso proto p

proto [ expr : size ]


For example, ‘ether[0] & 1 != 0’ catches all multicast traffic.
The expression ‘ip[0] & 0xf != 5’
catches all IPv4 packets with options.
The expression
‘ip[6:2] & 0x1fff = 0’
catches only unfragmented IPv4 datagrams and frag zero of fragmented
IPv4 datagrams.
This check is implicitly applied to the tcp and udp
index operations.
For instance, tcp[0] always means the first
byte of the TCP header, and never means the first byte of an
intervening fragment.


Some offsets and field values may be expressed as names rather than
as numeric values.
The following protocol header field offsets are
available: icmptype (ICMP type field), icmpcode (ICMP
code field), and tcpflags (TCP flags field).


The following ICMP type field values are available: icmp-echoreply,
icmp-unreach, icmp-sourcequench, icmp-redirect,
icmp-echo, icmp-routeradvert, icmp-routersolicit,
icmp-timxceed, icmp-paramprob, icmp-tstamp,
icmp-tstampreply, icmp-ireq, icmp-ireqreply,
icmp-maskreq, icmp-maskreply.


The following TCP flags field values are available: tcp-fin,
tcp-syn, tcp-rst, tcp-push,
tcp-ack, tcp-urg.


If an identifier is given without a keyword, the most recent keyword
is assumed.
For example,


not host vs and ace

not host vs and host ace

not ( host vs or ace )


Expression arguments can be passed to tcpdump as either a single
argument or as multiple arguments, whichever is more convenient.
Generally, if the expression contains Shell metacharacters, it is
easier to pass it as a single, quoted argument.
Multiple arguments are concatenated with spaces before being parsed.


To print all packets arriving at or departing from sundown:

tcpdump host sundown


To 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 helios


To print all traffic between local hosts and hosts at Berkeley:

 
tcpdump net ucb-ether


To print all ftp traffic through internet gateway snup:
(note that the expression is quoted to prevent the shell 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, this stuff should never make it
onto your local net).

 
tcpdump ip and not net localnet


To 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 example, 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’


The output of tcpdump is protocol dependent.
The following
gives a brief description and examples of most of the formats.


 Link Level Headers


If the ’-e’ option is given, the link level header is printed out.
On Ethernets, the source and destination addresses, protocol,
and packet length are printed.


On FDDI networks, the  ’-e’ option causes tcpdump to print
the ‘frame control’ field,  the source and destination addresses,
and the packet length.
(The ‘frame control’ field governs the
interpretation of the rest of the packet.
Normal packets (such
as those containing IP datagrams) are ‘async’ packets, with a priority
value between 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 assumed to contain an LLC packet.
Regardless of whether
the ’-e’ option is specified or not, the source routing information is
printed for source-routed packets.


On 802.11 networks, the ’-e’ option causes tcpdump to print
the ‘frame control’ fields, all of the addresses in the 802.11 header,
and the packet length.
As on FDDI networks,
packets are assumed to contain an LLC packet.


(N.B.: The following description assumes familiarity with
the SLIP compression algorithm described in RFC-1144.)


On SLIP links, a direction indicator (‘‘I’’ for inbound, ‘‘O’’ for outbound),
packet type, and compression information are printed out.
The packet type is printed first.
The three types are ip, utcp, and ctcp.
No further link information is printed for ip packets.
For TCP packets, the connection identifier is printed following the type.
If the packet is compressed, its encoded header is printed out.
The special cases are printed 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 identifier; the ack has changed by 6,
the sequence number by 49, and the packet ID by 6; there are 3 bytes of
data and 6 bytes of compressed header:

O ctcp * A+6 S+49 I+6 3 (6)


 ARP/RARP Packets


Arp/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 rtsg
arp reply csam is-at CSAM



arp who-has csam tell rtsg
arp reply csam is-at CSAM




This would look less redundant if we had done tcpdump -n:


arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4


arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4


If we had done tcpdump -e, the fact that the first packet is
broadcast and the second is point-to-point would be visible:


RTSG Broadcast 0806  64: arp who-has csam tell rtsg
CSAM RTSG 0806  64: arp reply csam is-at CSAM



RTSG Broadcast 0806  64: arp who-has csam tell rtsg
CSAM RTSG 0806  64: arp reply csam is-at CSAM




 TCP Packets


(N.B.:The following description assumes familiarity with
the TCP protocol described in RFC-793.
If you are not familiar
with the protocol, neither this description nor tcpdump will
be of much use to you.)


The general format of a tcp protocol line is:


src > dst: flags data-seqno ack window urgent options



src > dst: flags data-seqno ack window urgent options




Src, dst and flags are always present.
The other fields
depend on the contents of the packet’s tcp protocol header and
are output only if appropriate.


Here is the opening portion of an rlogin from host rtsg to
host csam.


rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1



rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1




Csam replies with a similar packet except it includes a piggy-backed
ack for rtsg’s SYN.
Rtsg then acks csam’s SYN.
The ‘.’ means no
flags were set.
The packet contained no data so there is no data sequence number.
Note that the ack sequence
number is a small integer (1).
The first time tcpdump sees a
tcp ‘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.
This means that sequence numbers after the
first can be interpreted
as relative byte positions in the conversation’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 conversation).
The PUSH flag is set in the packet.
On the 7th line, csam says it’s received data sent by rtsg up to
but not including byte 21.
Most of this data is apparently sitting in the
socket buffer since csam’s receive window has gotten 19 bytes smaller.
Csam also sends one byte of data to rtsg in this packet.
On the 8th and 9th 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 the header as it can
and then reports ‘‘[|tcp]’’ to indicate the remainder could not
be interpreted.
If the header 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 tell where they start).
If the header
length indicates options are present but the IP datagram length is not
long enough 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:



 0                            15                              31
-----------------------------------------------------------------
|          source port          |       destination port        |
-----------------------------------------------------------------
|                        sequence number                        |
-----------------------------------------------------------------
|                     acknowledgment number                     |
-----------------------------------------------------------------
|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
-----------------------------------------------------------------
|         TCP checksum          |       urgent pointer          |
-----------------------------------------------------------------

 0             7|             15|             23|             31
----------------|---------------|---------------|----------------
|  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
----------------|---------------|---------------|----------------
|               |  13th octet   |               |               |

                |               |
                |---------------|
                |C|E|U|A|P|R|S|F|
                |---------------|
                |7   5   3     0|

                |C|E|U|A|P|R|S|F|
                |---------------|
                |0 0 0 0 0 0 1 0|
                |---------------|
                |7 6 5 4 3 2 1 0|

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2

     |C|E|U|A|P|R|S|F|
     |---------------|
     |0 0 0 1 0 0 1 0|
     |---------------|
     |7 6 5 4 3 2 1 0|

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18


          00010010 SYN-ACK              00000010 SYN
     AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
          --------                      --------
     =    00000010                 =    00000010


          00010010 SYN-ACK              00000010 SYN
     AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
          --------                      --------
     =    00000010                 =    00000010


  UDP Packets


actinide.who > broadcast.who: udp 84



actinide.who > broadcast.who: udp 84




 UDP Name Server Requests


src > dst: id op? flags qtype qclass name (len)

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)



src > dst: id op? flags qtype qclass name (len)


h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)




 UDP Name Server Responses


src > dst:  id op rcode flags a/n/au type class data (len)

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)



src > dst:  id op rcode flags a/n/au type class data (len)


helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)






 SMB/CIFS decoding


By default a fairly minimal decode is done, with a much more detailed
decode done if -v is used.
Be warned that with -v a single SMB packet
may take up a page or more, so only use -v if you really want all the
gory details.


For information on SMB packet formats and what all te fields mean see
www.cifs.org or the pub/samba/specs/ directory on your favorite
samba.org mirror site.
The SMB patches were written by Andrew Tridgell
(tridge@samba.org).




 NFS Requests and Replies


src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results


sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
        144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
        reply ok 128 lookup fh 9,74/4134.3150




src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results



sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
        144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
        reply ok 128 lookup fh 9,74/4134.3150






sushi.1372a > wrl.nfs:
        148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
        reply ok 1472 read REG 100664 ids 417/0 sz 29388





sushi.1372a > wrl.nfs:
        148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
        reply ok 1472 read REG 100664 ids 417/0 sz 29388





 AFS Requests and Replies


 

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args


elvis.7001 > pike.afsfs:
        rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
        new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename




src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args



elvis.7001 > pike.afsfs:
        rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
        new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename







 KIP AppleTalk (DDP in UDP)


number  name

1.254           ether
16.1            icsd-net
1.254.110       ace



number  name


1.254           ether
16.1            icsd-net
1.254.110       ace




net.host.port

144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2



net.host.port


144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2




NBP packets are formatted like the following examples:


icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186



icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186




ATP packet formatting is demonstrated by the following example:


jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002



jssmag.209.165 > helios.132: atp-req  12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req  12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel  12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002






 IP Fragmentation


(frag id:size@offset+)
(frag id:size@offset)



(frag id:size@offset+)
(frag id:size@offset)




arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560



arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560




 Timestamps

hh:mm:ss.frac


Van Jacobson,
Craig Leres and
Steven McCanne, all of the
Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.


It is currently being maintained by tcpdump.org.


The current version is available via http:


http://www.tcpdump.org/ 

The original distribution is available via anonymous ftp:


ftp://ftp.ee.lbl.gov/tcpdump.tar.Z 

IPv6/IPsec support is added by WIDE/KAME project.
This program uses Eric Young’s SSLeay library, under specific configuration.


tcpdump-workers@tcpdump.org


Please send source code contributions, etc. to:


patches@tcpdump.org


NIT doesn’t let you watch your own outbound traffic, BPF will.
We recommend that you use the latter.


On Linux systems with 2.0[.x] kernels:


Some attempt should be made to reassemble IP fragments or, at least
to compute the right length for the higher level protocol.


Name server inverse queries are not dumped correctly: the (empty)
question section is printed rather than real query in the answer
section.
Some believe that inverse queries are themselves a bug and
prefer to fix the program generating them rather than tcpdump.


A packet trace that crosses a daylight savings time change will give
skewed time stamps (the time change is ignored).


Filter expressions on fields other than those in Token Ring headers will
not correctly handle source-routed Token Ring packets.


Filter expressions on fields other than those in 802.11 headers will not
correctly handle 802.11 data packets with both To DS and From DS set.


ip6 proto should chase header chain, but at this moment it does not.
ip6 protochain is supplied for this behavior.


Arithmetic expression against transport layer headers, like tcp[0],
does not work against IPv6 packets.
It only looks at IPv4 packets.











Advertisements


    129 Lectures 
     23 hours 

 Eduonix Learning Solutions

    5 Lectures 
     4.5 hours 

 Frahaan Hussain

    35 Lectures 
     2 hours 

 Pradeep D

    41 Lectures 
     2.5 hours 

 Musab Zayadneh

    46 Lectures 
     4 hours 

 GUHARAJANM

    6 Lectures 
     4 hours 

 Uplatz
 Print
 Add Notes
 Bookmark this page