Search:

• View
• Edit
• History
• Print

Users of the ietf2005 tcpdump (also known as pcap dump) data may encounter problems when using pcap filters.
Symptom: Use of pcap filters causes no packets to be returned, even though packets matching the filter are in the dump file. For example, the command $ gzip -dc chan1-dump-03-09_00001_20050309115333-anon.gz | tcpdump -nr - tcp | head returns no row, even though there are plenty of tcp packets in the data.
Cause: The ietf2005 pcap dumps were captured with a linktype of "802.11 plus Prism header", known internally to tcpdump and libpcap as DLT_PRISM_HEADER. The packets, however, start with WLANCAP_MAGIC_COOKIE_V1 (0x80211001), which according to tcpdump's print-802_11.c:

/*
 * For DLT_PRISM_HEADER; like DLT_IEEE802_11, but with an extra header,
 * containing information such as radio information, which we
 * currently ignore.
 *
 * If, however, the packet begins with WLANCAP_MAGIC_COOKIE_V1, it's
 * really DLT_IEEE802_11_RADIO (currently, on Linux, there's no
 * ARPHRD_ type for DLT_IEEE802_11_RADIO, as there is a
 * ARPHRD_IEEE80211_PRISM for DLT_PRISM_HEADER, so
 * ARPHRD_IEEE80211_PRISM is used for DLT_IEEE802_11_RADIO, and
 * the first 4 bytes of the header are used to indicate which it is).
 */

While tcpdump's printing routines handle this correctly (hence, if you don't use a pcap filter, tcpdump will print everything out correctly), the pcap filter generation code in libpcap do not recognize this special case, and still tries to treat these packets as real Prism packets, instead of 802.11 Radio packets in disguise. Since Prism headers are much longer than 802.11 Radio headers, the pcap filters try to look past the end of the captured packet, resulting in a non-match for all packets.
Solution: The right thing to do would be to fix libpcap's gencode.c to generate a check for the WLANCAP_MAGIC_COOKIE_V1 and fork the control of the filter appropriately. This was more work than I was prepared to do, so we have the
Workaround: I have hacked gencode.c to treat all Prism files as 802.11 Radio files. This is not a general solution, and you will get incorrect results if you try to use it with pcap filters on real Prism dumps, which is why I'm not submitting it to the libpcap developers.

1. Untar both libpcap-0.9.4 and @@tcpdump-3.9.8@ from the same parent directory
2. Take the following and put it in a file called pcap-prism.patch in the libpcap-0.9.4 directory:

--- libpcap-0.9.4/gencode.c     2005-09-05 02:08:04.000000000 -0700
+++ libpcap-0.9.4-fixed/gencode.c       2007-12-07 07:25:13.000000000 -0800
@@ -955,10 +955,14 @@
                 * XXX - same variable-length header problem; at least
                 * the Prism header is fixed-length.
                 */
-               off_ll = 144;
-               off_linktype = 144+24;
-               off_nl = 144+32;        /* Prism+802.11+802.2+SNAP */
-               off_nl_nosnap = 144+27; /* Prism+802.11+802.2 */
+               /* This is a hack for files marked as having a Prism
+                * linktype, which are actually 802.11 Radios.
+                */
+               off_ll = 64;
+               off_linktype = 24; /* off_ll gets added by gen_load_a() */
+                /* I have not tested the following two values */
+               off_nl = 64+32; /* Prism+802.11+802.2+SNAP */
+               off_nl_nosnap = 64+27;  /* Prism+802.11+802.2 */
                return;

        case DLT_IEEE802_11_RADIO_AVS:

1. cd libpcap-0.9.4
2. patch -p1 pcap-prism.patch
3. ./configure && make
4. cd ../tcpdump-3.9.8
5. ./configure && make
6. You can then run tcpdump right from that tcpdump-3.9.8 directory, for example:

$ gzip -dc chan1-dump-03-09_00001_20050309115333-anon.gz | ~/tmp/tcpdump-3.9.8/tcpdump -nr - tcp | head
reading from file -, link-type PRISM_HEADER (802.11 plus Prism header)
09:53:33.391598 IP 232.241.129.144.139 > 130.129.135.119.2543: . ack 3690797063 win 8472
09:53:33.476176 IP 238.227.88.79.80 > 130.129.131.194.52621: . 924915458:924916918(1460) ack 2842245893 win 6813
09:53:33.482969 IP 238.227.88.79.80 > 130.129.131.194.52621: . 1460:2920(1460) ack 1 win 6813
09:53:33.495663 IP 238.227.88.79.80 > 130.129.131.194.52621: . 2920:4380(1460) ack 1 win 6813
09:53:33.495834 
09:53:33.499267 IP 238.227.88.79.80 > 130.129.131.194.52621: . 2920:4380(1460) ack 1 win 6813
09:53:33.499435 
09:53:33.509596 IP 238.227.88.79.80 > 130.129.131.194.52621: . 4380:5840(1460) ack 1 win 6813
09:53:33.537109 IP 130.129.132.219.1128 > 234.1.102.251.110: P 986327120:986327129(9) ack 2718035882 win 17105
09:53:33.541286 IP 238.227.88.79.80 > 130.129.131.194.52621: . 7300:8760(1460) ack 1 win 6813

For issues with this patch, contact Terry Brugger <zow at acm dot org>.