man tcpdump
Excerpts related to ethereal Capture Filters
Reading packets from a network
interface may require that you have spe-
cial privileges:
Under Linux:
You must be root or tcpdump must be installed
setuid to root.
Under BSD (this includes Mac OS X):
You must have read access to /dev/bpf*. On BSDs with
a devfs
(this includes Mac OS X).
[ OS X - To install UNIX applications, install the Apple Xcode developer
programs, including X windows), then install and use "Darwin Ports"
(http://darwinports.opendarwin.org/) to install "ethereal".
You must enable "su root" by using the Apple "Netinfo Manager" utility.
Under
the "Security" menu, do "Authenticate" and then "Enable Root
User". Next,
start X windows and, in the Xterm window, type "su root" and at the
next
prompt "ethereal".]
Reading a saved packet file
doesn't require special privileges.
Capture Filters (expressions)
Set the data link type to use while
capturing packets to
datalinktype.
expression
selects which packets will be
dumped. If no expression is
given, all packets on the net will be dumped.
Otherwise, only
packets for which expression is `true' will be dumped.
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:
type qualifiers say what kind of thing the id
name or number
refers to. Possible types are host, net and port. E.g.,
`host foo', `net 128.3', `port 20'. If there is no type
qualifier, host is assumed.
dir qualifiers specify a particular
transfer direction to
and/or from id. Possible directions are src, dst, src or
dst and src and dst. E.g., `src foo', `dst net 128.3',
`src or dst port ftp-data'. If there is no dir
quali-
fier, src or dst is assumed. For some link layers, such
as SLIP and the ``cooked'' Linux capture mode used for
the ``any'' device and for some other device types, the
inbound and outbound qualifiers can be used to specify a
desired direction.
proto qualifiers restrict the match to a particular
protocol.
Possible protos are: ether, fddi, tr, wlan, ip, ip6, arp,
rarp, decnet, tcp and udp. E.g., `ether src foo', `arp
net 128.3', `tcp port 21'. If there is no proto quali-
fier, all protocols consistent with the type are assumed.
E.g., `src foo' means `(ip or arp
or rarp) src foo'
(except the latter is not legal syntax), `net bar' means
`(ip or arp or rarp) net bar' and `port 53' means `(tcp
or udp) port 53'.
[`fddi' is actually an alias for `ether'; the parser treats them
identically as meaning ``the data link level used on the speci-
fied network interface.'' FDDI headers contain
Ethernet-like
source and destination addresses, and often contain
Ethernet-
like packet types, so you can filter on these FDDI fields
just
as with the analogous Ethernet fields. FDDI headers
also con-
tain other fields, but you cannot name them explicitly in a fil-
ter expression.
Similarly, `tr' and `wlan' are aliases for `ether'; the previous
paragraph's statements about FDDI headers also apply
to Token
Ring and 802.11 wireless LAN headers. For 802.11
headers, the
destination address is the DA field and the source
address is
the SA field; the BSSID, RA, and TA fields aren't tested.]
In addition to the above, there are some
special `primitive'
keywords that don't follow the pattern:
gateway, broadcast,
less, greater and arithmetic
expressions. All of these are
described below.
More complex filter expressions are built up by using the words
and, or and not to combine primitives. E.g., `host foo and
not
port ftp and not port ftp-data'. To save
typing, identical
qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-
data or domain' is exactly the same as `tcp dst port ftp or tcp
dst port ftp-data or tcp dst port domain'.
Allowable primitives are: [usually the last item is your value]
dst host host [the 2nd "host"
is a variable, like "www.cnn.com"]
True if the IPv4/v6 destination field of the packet is
host, which may be either an address or a name.
src host host
True if the IPv4/v6 source field of the packet is host.
host host
True if either the IPv4/v6 source or destination of the
packet is host. Any of
the above host expressions can be
prepended with the keywords, ip, arp, rarp, or ip6 as in:
ip host host
which is equivalent to:
ether proto \ip and host host
If host is a name with
multiple IP addresses, each
address will be checked for a match.
ether dst ehost
True if the ethernet destination address is ehost. Ehost
may be either a name from /etc/ethers or a number (see
ethers(3N) for numeric format).
ether src ehost
True if the ethernet source address is ehost.
ether host ehost
True if either the ethernet source or destination address
is ehost.
gateway host
True if the packet used host as a
gateway. I.e., the
ethernet source or destination address was host but nei-
ther the IP source nor the IP destination was host. Host
must be a name and must be found both by the machine's
host-name-to-IP-address resolution mechanisms (host name
file, DNS, NIS, etc.) and by the machine's host-name-to-
Ethernet-address resolution
mechanism (/etc/ethers,
etc.). (An equivalent expression is
ether host ehost and not host host
which can be used with either names or numbers for host /
ehost.) This syntax does not work in IPv6-enabled con-
figuration at this moment.
dst net net
True if the IPv4/v6 destination address of the packet has
a network number of net.
Net may be either a name from
/etc/networks or a network number (see networks(4) for
details).
src net net
True if the IPv4/v6 source address of the packet has a
network number of net.
net net
True if either the IPv4/v6 source or destination address
of the packet has a network number of net.
net net mask netmask
[2nd "net" and "netmask"
are variables]
True if the IP address matches net
with the specific
netmask. May be
qualified with src or dst. Note that this
syntax is not valid for IPv6 net.
net net/len [net/len like 130.207.0.0/16]
True if the IPv4/v6 address matches net with a netmask
len bits wide. May be qualified with src or dst.
dst port port
True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp
and has a destination port value of port. The port can
be a number or a name used in /etc/services (see tcp(4P)
and udp(4P)). If a name is used, both the port
number
and protocol are checked. If a number or ambiguous name
is used, only the port number is checked (e.g., dst port
513 will print both tcp/login traffic and udp/who traf-
fic, and port domain will print
both tcp/domain and
udp/domain traffic).
src port port
True if the packet has a source port value of port.
port port
True if either the source or destination port
of the
packet is port. Any of
the above port expressions can be
prepended with the keywords, tcp or udp, as in:
tcp src port port
which matches only tcp packets whose source port is port.
less length
[length should be a
number]
True if the packet has a length less than or
equal to
length. This is equivalent to:
len <= length.
greater length
True if the packet has a length greater than or equal to
length. This is equivalent to:
len >= length.
ip proto protocol
True if the packet is an IP packet (see ip(4P)) of proto-
col type protocol. Protocol
can be a number or
one of
the names icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp,
udp, or tcp.
ip6 proto protocol
True if the packet is an IPv6 packet of
protocol type
protocol. Note that this
primitive does not
chase the
protocol header chain.
ip6 protochain protocol
True if the packet is IPv6 packet, and contains protocol
header with type protocol in its protocol header chain.
For example,
ip6 protochain 6
matches any IPv6 packet with TCP protocol header in the
protocol header chain. The packet may contain, for exam-
ple, authentication header, routing header, or hop-by-hop
option header, between IPv6 header and TCP header. The
BPF code emitted by this primitive is complex and cannot
be optimized by BPF optimizer code in tcpdump, so this
can be somewhat slow.
ip protochain protocol
Equivalent to ip6 protochain protocol, but this is for
IPv4.
ether broadcast
True if the packet is an ethernet broadcast packet. The
ether keyword is optional.
ip broadcast
True if the packet is an IPv4
broadcast packet. It
checks for both the all-zeroes and all-ones
broadcast
conventions, and looks up the subnet mask on the inter-
face on which the capture is being done.
If the subnet mask of the interface on which the capture
is being done is not available, either because the inter-
face on which capture is being done has no
netmask or
because the capture is being done on the
Linux "any"
interface, which can capture on more than one interface,
this check will not work correctly.
ether multicast
True if the packet is an ethernet multicast packet. The
ether keyword is optional. This
is shorthand for
`ether[0] & 1 != 0'.
ip multicast
True if the packet is an IP multicast packet.
ip6 multicast
True if the packet is an IPv6 multicast packet.
ether proto protocol
True if the packet is of ether type protocol. Protocol
can be a number or one of the names ip, ip6, arp, rarp,
atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp,
ipx, or netbeui.
iso, sap, and netbeui
tcpdump checks for an 802.3 frame and then checks
the LLC header as it does for FDDI, Token Ring,
and 802.11;
atalk tcpdump checks both for the AppleTalk etype in an
Ethernet frame and for a SNAP-format packet as it
does for FDDI, Token Ring, and 802.11;
aarp tcpdump checks for the AppleTalk
ARP etype in
either an Ethernet frame or an 802.2 SNAP frame
with an OUI of 0x000000;
ipx tcpdump checks for the IPX etype in
an Ethernet
frame, the IPX DSAP in the
LLC header, the
802.3-with-no-LLC-header encapsulation of IPX, and
the IPX etype in a SNAP frame.
decnet src host
True if the DECNET source address is host, which may be
an address of the form ``10.123'', or a DECNET host name.
[DECNET host name support is only available on
ULTRIX
systems that are configured to run DECNET.]
decnet dst host
True if the DECNET destination address is host.
decnet host host
True if either the DECNET source or destination address
is host.
ifname interface
True if the packet was logged as coming from the speci-
fied interface (applies only to
packets logged by
OpenBSD's pf(4)).
rnr num
True if the packet was logged as matching the specified
PF rule number (applies only to
packets logged by
OpenBSD's pf(4)).
rulenum num
Synonomous with the rnr modifier.
reason code
True if the packet was logged with the specified PF rea-
son code. The known codes are: match, bad-offset, frag-
ment, short, normalize, and memory (applies only to pack-
ets logged by OpenBSD's pf(4)).
rset name
True if the packet was logged as matching the specified
PF ruleset name of an anchored ruleset (applies only to
packets logged by pf(4)).
ruleset name
Synonomous with the rset modifier.
srnr num
True if the packet was logged as matching the specified
PF rule number of an anchored ruleset (applies only to
packets logged by pf(4)).
subrulenum num
Synonomous with the srnr modifier.
action act
True if PF took the specified action when the packet was
logged. Known actions are: pass and block (applies only
to packets logged by OpenBSD's pf(4)).
ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
Abbreviations for:
ether proto p
where p is one of the above protocols.
lat, moprc, mopdl
Abbreviations for:
ether proto p
where p is one of the above protocols. Note that tcpdump
does not currently know how to parse these protocols.
vlan [vlan_id]
True if the packet is an IEEE 802.1Q VLAN
packet. If
[vlan_id] is specified, only true is the packet has the
specified vlan_id. Note that the
first vlan keyword
encountered in expression changes the decoding offsets
for the remainder of expression on the assumption that
the packet is a VLAN packet.
tcp, udp, icmp
Abbreviations for:
ip proto p or ip6 proto p
where p is one of the above protocols.
iso proto protocol
True if the packet is an OSI packet of protocol type pro-
tocol. Protocol can be a number or
one of the names
clnp, esis, or isis.
clnp, esis, isis
Abbreviations for:
iso proto p
where p is one of the above protocols.
l1, l2, iih, lsp, snp, csnp, psnp
Abbreviations for IS-IS PDU types.
vpi n True if the packet is an ATM
packet, for SunATM on
Solaris, with a virtual path identifier of n.
vci n True if the packet is
an ATM packet, for SunATM on
Solaris, with a virtual channel identifier of n.
lane True if the packet is an ATM
packet, for SunATM on
Solaris, and is an ATM LANE packet. Note that the first
lane keyword encountered in expression changes the tests
done in the remainder of expression on the
assumption
that the packet is either a LANE emulated Ethernet packet
or a LANE LE Control packet. If lane isn't
specified,
the tests are done under the assumption that the packet
is an LLC-encapsulated packet.
llc True if the packet
is an ATM packet, for SunATM on
Solaris, and is an LLC-encapsulated packet.
oamf4s True if the packet is an ATM
packet, for SunATM on
Solaris, and is a segment OAM F4
flow cell (VPI=0 &
VCI=3).
oamf4e True if the packet is an ATM
packet, for SunATM on
Solaris, and is an end-to-end OAM F4 flow cell (VPI=0 &
VCI=4).
oamf4 True if the packet is an ATM
packet, for SunATM on
Solaris, and is a segment or end-to-end OAM F4 flow cell
(VPI=0 & (VCI=3 | VCI=4)).
oam True if the packet is an
ATM packet, for SunATM on
Solaris, and is a segment or end-to-end OAM F4 flow cell
(VPI=0 & (VCI=3 | VCI=4)).
metac True if the packet is an ATM
packet, for SunATM on
Solaris, and is on a meta signaling
circuit (VPI=0 &
VCI=1).
bcc True if the packet is an
ATM packet, for SunATM on
Solaris, and is on a broadcast signaling circuit (VPI=0 &
VCI=2).
sc True if the packet is an
ATM packet, for SunATM on
Solaris, and is on a signaling circuit (VPI=0 & VCI=5).
ilmic True if the packet is
an ATM packet, for SunATM on
Solaris, and is on an ILMI circuit (VPI=0 & VCI=16).
connectmsg
True if the packet is an ATM packet,
for SunATM on
Solaris, and is on a signaling circuit and is a Q.2931
Setup, Call Proceeding, Connect, Connect Ack, Release, or
Release Done message.
metaconnect
True if the packet is an ATM
packet, for SunATM on
Solaris, and is on a meta signaling circuit and
is a
Q.2931 Setup, Call Proceeding, Connect,
Release, or
Release Done message.
expr relop expr
True if the relation holds, where relop is one of >,
<,
>=, <=, =, !=, and expr is an arithmetic expression com-
posed of integer constants (expressed in standard C syn-
tax), the normal binary operators [+, -, *, /, &, |, <<,
>>], a length operator, and special packet data
acces-
sors. To access data inside the packet, use the follow-
ing syntax:
proto [ expr : size ]
Proto is one of ether, fddi, tr, wlan, ppp, slip, link,
ip, arp, rarp, tcp, udp, icmp or ip6, and indicates the
protocol layer for the index operation. (ether,
fddi,
wlan, tr, ppp, slip and link
all refer to the link
layer.) Note that tcp, udp and other upper-layer proto-
col types only apply to IPv4, not IPv6
(this will be
fixed in the future). The byte offset, relative to the
indicated protocol layer, is given by
expr. Size is
optional and indicates the number of bytes in the field
of interest; it can be either one, two,
or four, and
defaults to one. The length operator, indicated by the
keyword len, gives the length of the packet.
For example, `ether[0] & 1 != 0' catches all
multicast
traffic. The expression `ip[0] & 0xf != 5'
catches all
IP packets with options. The
expression `ip[6:2] &
0x1fff = 0' catches only unfragmented datagrams and frag
zero of fragmented 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-redi-
rect, icmp-echo, icmp-routeradvert, icmp-routersolicit,
icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstam-
preply, 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.
Primitives may be combined using:
A parenthesized group of primitives and operators (paren-
theses are special to the Shell and must be escaped).
Negation (`!' or `not').
Concatenation (`&&' or `and').
Alternation (`||' or `or').
Negation has highest precedence. Alternation and
concatenation
have equal precedence and associate left to
right. Note that
explicit and tokens, not juxtaposition, are now
required for
concatenation.
If an identifier is given without a keyword,
the most recent
keyword is assumed. For example,
not host vs and ace
is short for
not host vs and host ace
which should not be confused with
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.
EXAMPLES
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 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 eth-
ernet 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'
= = =
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 | FIN
Let's assume that we want to watch
packets used in establishing a TCP
connection.
Recall that TCP uses a 3-way handshake protocol when it
initializes a new connection; the
connection sequence with regard to
the TCP control bits is
1) Caller sends SYN
2) Recipient responds with SYN, ACK
3) Caller sends ACK
Now we're
interested in capturing packets that have only the SYN bit
set (Step 1). Note that we
don't want packets from step 2 (SYN-ACK),
just a plain initial
SYN. What we need is a correct filter expression
for tcpdump.
Recall the structure of a TCP
header without options:
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 |
-----------------------------------------------------------------
A TCP header usually holds
20 octets of data, unless options
are
present. The first line of
the graph contains octets 0 - 3, the second
line shows octets 4 - 7 etc.
Starting to count with 0, the
relevant TCP control bits are contained
in octet 13:
0
7|
15|
23|
31
----------------|---------------|---------------|----------------
| HL |
rsvd |C|E|U|A|P|R|S|F|
window
size |
----------------|---------------|---------------|----------------
|
| 13th octet
|
|
|
Let's have a closer look at octet
no. 13:
|
|
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
These are the TCP control
bits we are interested in. We have numbered
the bits in this octet from 0 to
7, right to left, so the PSH bit is
bit number 3, while the URG bit is
number 5.
Recall that we
want to capture packets with only SYN set. Let's see
what happens to octet 13 if a TCP
datagram arrives with the SYN bit set
in its header:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
Looking at the control bits
section we see that only bit number 1 (SYN)
is set.
Assuming that octet number 13 is
an 8-bit unsigned integer in network
byte order, the binary value of
this octet is
00000010
and its decimal representation is
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
We're almost
done, because now we know that if only SYN is set, the
value of the 13th octet in the TCP
header, when interpreted as a 8-bit
unsigned integer in network byte
order, must be exactly 2.
This relationship can be expressed
as
tcp[13] == 2
We can use this expression
as the filter for tcpdump in order to watch
packets which have only SYN set:
tcpdump -i xl0 tcp[13] == 2
The expression says "let the 13th
octet of a TCP datagram have the dec-
imal value 2", which is exactly
what we want.
Now, let's
assume that we need to capture SYN packets, but we don't
care if ACK or any other TCP
control bit is set at the same time.
Let's see what happens to octet 13
when a TCP datagram with SYN-ACK set
arrives:
|C|E|U|A|P|R|S|F|
|---------------|
|0 0
0 1 0 0 1 0|
|---------------|
|7 6
5 4 3 2 1 0|
Now bits 1 and 4 are set in the
13th octet. The binary value of octet
13 is
00010010
which translates to decimal
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
Now we can't just use 'tcp[13] ==
18' in the tcpdump filter expression,
because that would select only
those packets that have SYN-ACK set, but
not those with only SYN set.
Remember that we don't care if ACK or any
other control bit is set as long
as SYN is set.
In order to achieve our goal, we
need to logically AND the binary value
of octet 13
with some other value to preserve the SYN bit. We know
that we want SYN to be set in any
case, so we'll logically AND the
value in the 13th octet with the
binary value of a SYN:
00010010
SYN-ACK
00000010 SYN
AND 00000010 (we want SYN) AND 00000010 (we
want SYN)
--------
--------
=
00000010
= 00000010
We see that
this AND operation delivers the same result regardless
whether ACK or another TCP control
bit is set. The decimal representa-
tion of the
AND value as well as the result of this operation is 2
(binary 00000010), so we know that
for packets with SYN set the follow-
ing relation must hold true:
( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )
This points us to the tcpdump
filter expression
tcpdump -i xl0 'tcp[13] & 2 == 2'
Note that you should use single
quotes or a backslash in the expression
to hide the AND ('&') special
character from the shell. [not used
in ethereal]
UDP Packets
UDP format is illustrated by this
rwho packet:
actinide.who > broadcast.who: udp 84
This says that port who on host
actinide sent a udp datagram to port
who on host broadcast, the
Internet broadcast address. The packet con-
tained 84 bytes of user data.
Some UDP services are recognized
(from the source or destination port
number) and the higher level
protocol information printed. In particu-
lar, Domain Name service requests
(RFC-1034/1035) and Sun RPC calls
(RFC-1050) to NFS.
UDP Name Server Requests
(N.B.:The following
description assumes familiarity with the Domain
Service protocol described in
RFC-1035. If you are not familiar with
the protocol,
the following description will appear to be written in
greek.)
Name server requests are formatted
as
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
Host h2opolo asked the domain
server on helios for an address record
(qtype=A) associated
with the name ucbvax.berkeley.edu. The query id
was `3'. The `+' indicates
the recursion desired flag was set. The
query length was 37 bytes,
not including the UDP and IP protocol head-
ers. The query operation was
the normal one, Query, so the op field
was omitted.
If the op had been anything else, it would have been
printed between the `3' and the
`+'. Similarly, the qclass was the
normal one,
C_IN, and omitted. Any other qclass
would have been
printed immediately after the `A'.
A few anomalies are checked and
may result in extra fields enclosed in
square brackets:
If a query contains an answer, authority records or
additional records section,
ancount, nscount, or arcount are printed as
`[na]', `[nn]' or `[nau]'
where n is the appropriate count. If any of
the response bits are set (AA, RA
or rcode) or any of the `must be
zero' bits are set in bytes two
and three, `[b2&3=x]' is printed, where
x is the hex value of header bytes
two and three.
UDP Name Server Responses
Name server responses are
formatted as
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)
In the first example, helios
responds to query id 3 from h2opolo with 3
answer records,
3 name server records and 7 additional records. The
first answer record is type
A (address) and its data is internet
address
128.32.137.3. The total size of the response was 273
bytes,
excluding UDP and IP
headers. The op (Query) and response code (NoEr-
ror) were omitted, as was the
class (C_IN) of the A record.
In the second example,
helios responds to query 2 with a response code
of non-existent domain (NXDomain)
with no answers, one name server and
no authority records.
The `*' indicates that the authoritative answer
bit was set. Since there
were no answers, no type, class or data were
printed.
Other flag characters
that might appear are `-' (recursion available,
RA, not set) and `|' (truncated
message, TC, set). If the `question'
section doesn't contain exactly
one entry, `[nq]' is printed.
Note that name server
requests and responses tend to be large and the
default snaplen of 68 bytes may
not capture enough of the packet to
print. Use
the -s flag to increase the snaplen if you need to seri-
ously investigate name server
traffic. `-s 128' has worked well for
me.
Timestamps
By default, all output lines are
preceded by a timestamp. The time-
stamp is the current clock time in
the form
hh:mm:ss.frac
and is as accurate as
the kernel's clock. The timestamp reflects the
time the kernel first saw the
packet. No attempt is made to account
for the time lag between when the
ethernet interface removed the packet
from the wire and when the kernel
serviced the `new packet' interrupt.
===
tcpdump is currently being
maintained by tcpdump.org.
The current version is available
via http:
http://www.tcpdump.org/