B.2 tcpdump and Other Packet Sniffers

Throughout the text, we use tcpdump to watch the on-the-wire behavior of the tunnels and VPNs that we study. It's worth taking a moment to specify how we use tcpdump to capture this data and how we reformat the data for better presentation in the text.

To show the effect of the various tcpdump options, let's ping from linux to bsd and capture the results. If we run tcpdump without any options, we get

16:17:37.684842 IP linux.jcs.local > bsd.jcs.local: icmp 64: echo request seq 1
16:17:37.684948 IP bsd.jcs.local > linux.jcs.local: icmp 64: echo reply seq 1

This output is set in smaller type so that it will fit on one line and appear exactly as it does on a terminal screen.

Often, it is more useful to see the IP addresses than it is the host names. Indeed, that is the way most of the captures in the text are run. To do this, we use the -n option with tcpdump. That gives us the result

16:17:37.684842 IP 172.30.0.4 > 172.30.0.1: icmp 64: echo request seq 1
16:17:37.684948 IP 172.30.0.1 > 172.30.0.4: icmp 64: echo reply seq 1

If we want to see exactly what's in the packet instead of relying on tcpdump to decode it for us, we can specify the -x option, which gives us a hex dump of the packet, or the -X option, which gives us a hex and ASCII dump. Be aware that tcpdump captures only the first few bytes by default, so if we want to examine the entire packet contents, we should tell tcpdump to capture as much data as we're interested in.

The amount of data that tcpdump captures by default depends on the platform it's running on. It's usually 68 bytes, but some packet-capture interfaces support other lengths.

We can set the amount of data to capture with the -s option.

Almost all the examples in the text invoke tcpdump as

tcpdump -nXs 1500 filter_expression

where filter_expression specifies which packets tcpdump should capture. If we don't specify a filter, tcpdump will capture all packets. If we were interested only in packets from linux to bsd, we would specify a filter of src linux and dst bsd. The tcpdump filter language is surprisingly rich and therefore complicated. It is described in detail in the tcpdump man page.

For our ping example, we are interested only in ICMP packets, so we can specify a filter of icmp and capture only ICMP packets. We capture the results of our ping with

tcpdump -nXs 1500 icmp

and get

16:17:37.684842 IP 172.30.0.4 > 172.30.0.1: icmp 64: echo request seq 1
    0x0000: 4500 0054 0000 4000 4001 e267 ac1e 0004   E..T..@.@..g....
    0x0010: ac1e 0001 0800 aab1 0e0b 0001 e189 5942   ..............YB
    0x0020: 0f73 0a00 0809 0a0b 0c0d 0e0f 1011 1213   .s..............
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   .............!"#
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233   $%&'()*+,-./0123
    0x0050: 3435 3637 4567
16:17:37.684948 IP 172.30.0.1 > 172.30.0.4: icmp 64: echo reply seq 1
    0x0000: 4500 0054 8c8b 4000 4001 55dc ac1e 0001   E..T..@.@.U.....
    0x0010: ac1e 0004 0000 b2b1 0e0b 0001 e189 5942   ..............YB
    0x0020: 0f73 0a00 0809 0a0b 0c0d 0e0f 1011 1213   .s..............
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   .............!"#
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233   $%&'()*+,-./0123
    0x0050: 3435 3637                                 4567

Notice that tcpdump does not number the lines the way we do in the text. Instead, it gives the offsetfrom the start of the packetof the first byte of each line. Such output is usually the most useful when debugging a VPN by looking at its behavior on the wire.

When using tcpdump to diagnose VPN and tunnel behavior, it is imperative to understand how and where it works. Figure B.2 shows a typical invocation of tcpdump.

Notice that tcpdump uses the pcap library (libpcap) to filter and capture the packets. The pcap library provides general packet capture and filtering facilities and can be used by other programs that need to examine packets as seen by the interface layer. We'll see an example of this when we discuss ssldump.

Figure B.2 shows tcpdump using the Berkeley Packet Filter (BPF) mechanism to capture the packets. BPF is the kernel interface to the pcap library used in BSD-derived UNIX systems. Other operating systems have other kernel interfaces, but the concepts are the same.

The important thing to note in Figure B.2 is where the packet is captured. Pcap grabs a copy just after it's received from the network hardware (NIC) or just before it's sent to the NIC. Thus, we will see the packet before any processing by the TCP/IP stackin the case of inbound packetsor after all such processing is completein the case of outbound packets.

We are not counting the I/O processing that the interface layer uses to read from or write to the NIC, of course.

This can be a little confusing when pseudointerfaces, such as the tun or tun/tap interfaces, come into play, because the packets may have been partially processed before they get to such interfaces. If we remember that the tun interface, say, looks like a normal NIC interface driver to the rest of the stack, we can usually understand what tcpdump is showing us when we capture data at such interfaces.

Although we use exclusively tcpdump in the text, it's not the only possibility. Some UNIX systems have their own packet sniffers. Solaris has snoop, and IBM AIX has iptrace, for example. Nonetheless, tcpdump runs on Solaris, AIX, Windows, and virtually all other UNIX systems. Because it is generally available on all systems, it pays to be familiar with it and its operation.

For those who prefer a graphical user interface, the ethereal sniffer is an ideal solution. It too runs on virtually all UNIX and Windows systems. The ethereal sniffer can read packet captures from several other sniffers, including tcpdump, etherpeek (Windows), snoop (Solaris), LANalyzer (Novell), iptrace (AIX), nettl (HP-UX), and other, less common formats as well.

Tip 34 of ETCP covers the use of tcpdump in greater detail. The latest version of tcpdump is available from <http://www.tcpdump.org>. The ethereal sniffer is available from <http://www.ethereal.com>.