den16s02-in-f19.1e100.net., PTR iad23s26-in-f211.1e100.net., PTR
den16s02-in-f19.1e100.net., PTR iad23s26-in-f211.1e100.net.
(
142
)
10:26:26.585725 IP binkley.lan.64437 > testwifi.here.domain: 23125+ PTR?
0.0.0.0.in-addr.arpa.
(
38
)
10:26:26.598434 IP testwifi.here.domain > binkley.lan.64437:
23125
NXDomain
0/1/0
(
106
)
10:26:26.637639 IP binkley.lan.51994 > 239.255.255.250.ssdp: UDP, length 174
The first column in the output in
Example 2-9
is the timestamp. This is not anything
that has been determined from the packet itself, since time is not transmitted as part
of any of the headers. What we get is the time as the hours, minutes, seconds, and
fractions of seconds after midnight. In other words, it’s the time of day down to a
fraction of a second. The second field is the transport protocol. We don’t get the layer
2 protocol because it’s determined by the network interface, so it goes without saying.
In order to know the layer 2 protocol, you need to know something about your net‐
work interface. Commonly, the layer 2 protocol will be Ethernet.
The next set of data is the two endpoints of the conversation. This includes not only
the IP addresses but also the port information. So,
binkley.lan
is the source of the first
packet, and
testwifi.here
is the destination. Without telling it not to,
tcpdump
will con‐
vert IP addresses to hostnames. To disable that function, you would need to provide
an
-n
on the command line. This would speed up your capture and lower the number
of packets captured, since your system won’t be doing a DNS lookup for every frame
that comes by.
You will notice that along with each IP address is another value. From our source
address,
binkley.lan.57137
, the 57137 is a port number. This is the source port, and on
the receiving side, you can see
testwifi.here.domain
. This means that
testwifi.here
is
receiving a message on the port used by domain name servers. Again, just as in the
hostname versus IP address, if you don’t want
tcpdump
to do a lookup on the port
number, based on well-known port numbers, you can add
-n
to the command line,
and
tcpdump
will just present you numeric information. In this case
.domain
trans‐
lates to
.53
, which is the numeric value. We know that this is a UDP message because
it tells us after the destination information.
Primarily, what you see in
Example 2-10
are DNS requests and responses. This is a
result of having
tcpdump
doing reverse DNS lookups to determine the hostname
associated with the IP address. The remainder of each line from
tcpdump
output is a
description of the packet. In the case of a TCP message, you may see the flags that are
set in the TCP header or you may see sequence number information.
This time, we’ll take a look at more verbose output by using the
-v
flag.
tcpdump
sup‐
ports multiple
-v
flags, depending on the level of verbosity you are looking for. We’ll
also take a look at using the
-n
flag to see what it looks like without any address
lookup.
Example 2-11
shows the more verbose output.
