CHANGELOG
---------
20050726 - ipw2200-07 patch.  Uses true variable length headers.  Libpcap can
           understand these as of 0.9.3+.
20050726 - Regenerated patch since I seem to have screwed up 05
20050720 - ipw2200-05 patch, only memset the part of the static buffer not used
20050720 - ipw2200-04 patch, treat antsignal as s8 not u8, don't endian-flip
            channel bitmasks.  (someone want to confirm this on a BE system?)
20050719 - ipw2200-03 patch, general cleanup, plus properly handling data rate
            and signal levels
           ieee80211-02 patch, move ARPHRD temp def into this header
20050719 - ipw2200-02 patch, properly zeroes out head of skb after moving
           packet data further down
20050719 - Initial patches for ipw2200, ieee80211, libpcap

Patches
-------
Patches apply to what they say in the filename (at the moment, the iee80211
1.0.3 stack, ipw2200 1.0.6, and libpcap of almost any recent version).  Once
this is reviewed, I will start making patches for other drivers.

Patches are numbered by release.  You only need 1 patch per component (so
don't apply foo-02 and then try to apply foo-03 on top of it, foo-03 is a 
complete patch of its own).

Linux RadioTap
--------------
These patches add RadioTap support to the Linux IEEE80211 stack.

RadioTap was first developed on NetBSD and provides a common signal layer for
all the different wireless drivers.  It's extendable and cross-platform.

At the moment this code assumes we will be assigned ARPHRD 803 for radiotap.

RadioTap
--------
Radiotap is a standard header format for signal layer information from wireless
cards (similar to the Wlan-NG Prism and AVS header formats).  It is used on
Net, Free, and OpenBSD to carry information.

The radiotap headers consist of a bitfield of included fields, and the field
data itself.  It contains the expected antenna, signal, noise, channel,
and MAC timing fields, as well as a set of flags to indicate appended FCS
bytes and other fields.

Why?
----
Linux is finally getting a unified 802.11 stack.  I'd like to see this done
right, so that we have a standard format for getting data from cards that
provides all the information we need.  One option is to expand the AVS headers,
however they are not without their limitations.  By adding radiotap support,
we come in line with other systems providing info and we allow the same 
dissection code to work in userspace across multiple operating systems.
Besides, if a standard already exists with all the components we need, does
inventing a new one make sense?


Mike Kershaw