tcpdump filters
By default, when frames arrive at a target interface, the packet capture library that underlies tcpdump captures them all. Sometimes you want less than that. That's what tcpdump's capture filters are for. For example:
Get all: tcpdump -i eth0
UDP only: tcpdump -i eth0 udp
While there is great variety in filter expressions that tcp allows, this simplest case "udp" illustrates. The expressions moreover offer great precision in qualifying what frames are of interest by tests of their contents down to the bit level. The expressions' syntax, however, is low level and so is their documentation. And even if you master their syntax, effective usage demands detailed knowledge of packet structure. It's not enough to know how to measure without knowing what to measure and where to find it so you can apply the measuring tool.
Here's what you have to work with. Headers. The "master container" in an ethernet network is the frame:
It contains higher-level protocols:
 |
 |
 |
 |
 |
 |
The exercise for you to perform:
1 - the capture file frame-exercise1.pcap is the product of capturing the datastream while transfering a file using ftp. It contains 1350 frames of which a majority are of size 1514 (the maximum possible per ethernet's rules). Obtain the file in its native form, or its alternative zipped form.
Compose a filter expression that will cause tcpdump to select for display only the 1514-byte frames as it reads through the capture file, ignoring other sizes. tcpdump prints a single line of output for each such frame. Send those lines (pipe the output) to a utility (wc) that will count them. Once you have figured out a filter expression that'll work, the tcpdump command will look something like:
tcpdump -r frame-exercise1.pcap <filter exp. for frames of that size> | wc -l
Use a filter expression that examines the IP header's "total
length" field (make sure you know what it depicts the total length of). How
many 1514-byte frames are there?
2 - filter arp message traffic with 2 different tcpdump filter expressions
The hard one does it by looking in the frames' ethertype fields checking for
equality with arp's signature code, hexadecimal 0806. The easy one just uses the
tcpdump protocol specifier "arp". You will have to generate your own
arp traffic to filter. You can so so by setting up 2 terminal windows, running
tcpdump in one while using the other to ping another local machine. Using the
ping utility will cause an arp exchange first, followed by the icmp echo
request/reply exchange (the actual ping activity). In this exercise your filter
will obscure the latter while displaying the former only. If you get no arp
activity it's because the arp cache already contains the desired information, no
need to ask. Clear it out of the cache, to allow arp to happen next time you
ping. "arp -n" shows the cache, and "arp -d <targetIP>"
clears the entry of a particular IP.
3 - what value for ping's " -s <packet size> " option is the threshold to be captured by tcpdump's " ip[2:2]>512 " filter expression?
Again, 2 windows. In one, run
tcpdump -i eth0 'ip[2:2]>512'
and in the other issue ping packets (to anywhere) of various sizes, by varying the value of ping's "-s" option. ( ip[2:2] is notation referencing the 3rd and 4th bytes of the IP header). When you use ping without -s, tcpdump doesn't show anything. That's because ping's default packet size is much smaller than tcpdump is looking for. Please use -s and experimentally raise its parameter value till your packets get fat enough to start showing up in tcpdump. Determine at exactly what parameter value they first appear. That is, how big must the packets be according to "-s" in order for them to be "big enough" according to tcpdump's filter expression? The answer to that question is not 512, though the filter expression says 512. That means the ping and tcpdump are talking about the sizes of two different (though related) things. Of similar potential confusion, look at the numbers in this screenshot and the excerpt from the ping man page:
Why does the ping utility's output variously suggest that the number of bytes it is slinging around is 56, 84, and 64? Bytes of what?
So if ping and tcpdump are talking about measuring different things, figure out what each measures. Demonstrate your understanding by drawing a diagram showing the full frame including whatever nested components it contains and label a) the exact portion that the -s controls, b) the exact portion that the ip[2:2] measures, and c) the portion referred to as "64 bytes from..." in the above ping output. State on the page what the threshold number you determined above is.
Notes: in interpreting above diagrams, ping is not distinct from icmp. ping is icmp, in that the icmp messages generated by the ping utility are a certain type of icmp. icmp has over a dozen message types of which ping uses 2 ("echo request" and "echo reply").
Diagrams from http://www.sans.org/resources/tcpip.pdf and http://en.wikipedia.org/wiki/Ethernet.