Packet Capture, part 2 - Page 10

In this segment from the O'Reilly book, Network Troubleshooting Tools, you will learn all abut how to use the tcpdump in relation to packet capturing.

By O'Reilly Press | Posted Nov 13, 2001
Page 10 of 10   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

1.4.2.4.4. Compound filters.

All the examples thus far have consisted of simple commands with a single test. Compound filters can be constructed in tcpdump using logical operator and, or, and not. These are often abbreviated &&, ||, and ! respectively. Negation has the highest precedence. Precedence is left to right in the absence of parentheses. While parentheses can be used to change precedence, remember that they must be escaped or quoted.

Earlier it was noted that the following will not limit capture to just IP traffic:

bsd1# tcpdump host 205.153.63.30 

If you really only want IP traffic in this case, use the command:

bsd1# tcpdump host 205.153.63.30 and ip

On the other hand, if you want all traffic to the host except IP traffic, you could use:

bsd1# tcpdump host 205.153.63.30 and not ip 

If you need to capture all traffic to and from the host and all non-IP traffic, replace the and with an or.

With complex expressions, you have to be careful of the precedence. Consider the two commands:

bsd1# tcpdump host lnx1 and udp or arp
bsd1# tcpdump "host lnx1 and (udp or arp)" 

The first will capture all UDP traffic to or from lnx1 and all ARP traffic. What you probably want is the second, which captures all UDP or ARP traffic to or from lxn1. But beware, this will also capture ARP broadcast traffic. To beat a dead horse, be sure to test your filters.

I mentioned earlier that running tcpdump on a remote station using telnet was one way to collect data across your network, except that the Telnet traffic itself would be captured. It should be clear now that the appropriate filter can be used to avoid this problem. To eliminate a specific TCP connection, you need four pieces of information -- the source and destination IP addresses and the source and destination port numbers. In practice, the two IP addresses and the well-known port number is often enough.

For example, suppose you are interested in capturing traffic on the host lnx1, you are logged onto the host bsd1, and you are using telnet to connect from bsd1 to lnx1. To capture all the traffic at lnx1, excluding the Telnet traffic between bsd1 and lnx1, the following command will probably work adequately in most cases:

lnx1# tcpdump -n "not (tcp port telnet and host lnx1 and host bsd1)"

We can't just exclude Telnet traffic since that would exclude all Telnet traffic between lnx1 and any host. We can't just exclude traffic to or from one of the hosts because that would exclude non-Telnet traffic as well. What we want to exclude is just traffic that is Telnet traffic, has lnx1 as a host, and has bsd1 as a host. So we take the negation of these three requirements to get everything else.

While this filter is usually adequate, this filter excludes all Telnet sessions between the two hosts, not just yours. If you really want to capture other Telnet traffic between lnx1 and bsd1, you would need to include a fourth term in the negation giving the ephemeral port assigned by telnet. You'll need to run tcpdump twice, first to discover the ephemeral port number for your current session since it will be different with every session, and then again with the full filter to capture the traffic you are interested in.

One other observation -- while we are not reporting the traffic, the traffic is still there. If you are investigating a bandwidth problem, you have just added to the traffic. You can, however, minimize this traffic during the capture if you write out your trace to a file on lnx1 using the -w option. This is true, however, only if you are using a local filesystem. Finally, note the use of the -n option. This is required to prevent name resolution. Otherwise, tcpdump would be creating additional network traffic in trying to resolve IP numbers into names as noted earlier.

Once you have mastered the basic syntax of tcpdump, you should run tcpdump on your own system without any filters. It is worthwhile to do this occasionally just to see what sorts of traffic you have on your network. There are likely to be a number of surprises. In particular, there may be router protocols, switch topology information exchange, or traffic from numerous PC-based protocols that you aren't expecting. It is very helpful to know that this is normal traffic so when you have problems you won't blame the problems on this strange traffic.

This has not been an exhaustive treatment of tcpdump, but I hope that it adequately covers the basics. The manpage for tcpdump contains a wealth of additional information, including several detailed examples with explanations. One issue I have avoided has been how to interpret tcpdump data. Unfortunately, this depends upon the protocol and is really beyond the scope of a book such as this. Ultimately, you must learn the details of the protocols. For TCP/IP, Richard W. Stevens' TCP/IP Illustrated, vol. 1, The Protocols has extensive examples using tcpdump. But the best way to learn is to use tcpdump to examine the behavior of working systems.

Network Troubleshooting Tools - click to go to publisher's site

 

--
The next segment from Network Troubleshooting Tools will cover analysis tools.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter