From: James K. <jke...@li...> - 2005-09-13 23:35:22
|
Added ieee80211_radiotap.h to enhance statistic reporting to user space from wireless drivers. Signed-off-by: James Ketrenos <jke...@li...> --- include/net/ieee80211_radiotap.h | 237 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 237 insertions(+), 0 deletions(-) create mode 100644 include/net/ieee80211_radiotap.h 4965d2bc32db09b663753aaf7ae3c9218bfac5b9 diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h new file mode 100644 --- /dev/null +++ b/include/net/ieee80211_radiotap.h @@ -0,0 +1,237 @@ +/* $FreeBSD: src/sys/net80211/ieee80211_radiotap.h,v 1.5 2005/01/22 20:12:05 sam Exp $ */ +/* $NetBSD: ieee80211_radiotap.h,v 1.11 2005/06/22 06:16:02 dyoung Exp $ */ + +/*- + * Copyright (c) 2003, 2004 David Young. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of David Young may not be used to endorse or promote + * products derived from this software without specific prior + * written permission. + * + * THIS SOFTWARE IS PROVIDED BY DAVID YOUNG ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, + * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DAVID + * YOUNG BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED + * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY + * OF SUCH DAMAGE. + */ + +/* + * Modifications to fit into the linux IEEE 802.11 stack, + * Mike Kershaw (dr...@ki...) + */ + +#ifndef IEEE80211RADIOTAP_H +#define IEEE80211RADIOTAP_H + +#include <linux/version.h> +#include <linux/if_ether.h> +#include <linux/kernel.h> + +/* Kluge the radiotap linktype for now if we don't have it */ +#ifndef ARPHRD_IEEE80211_RADIOTAP +#define ARPHRD_IEEE80211_RADIOTAP 803 +#endif + +/* Radiotap header version (from official NetBSD feed) */ +#define IEEE80211RADIOTAP_VERSION "1.5" +/* Base version of the radiotap packet header data */ +#define PKTHDR_RADIOTAP_VERSION 0 + +/* A generic radio capture format is desirable. There is one for + * Linux, but it is neither rigidly defined (there were not even + * units given for some fields) nor easily extensible. + * + * I suggest the following extensible radio capture format. It is + * based on a bitmap indicating which fields are present. + * + * I am trying to describe precisely what the application programmer + * should expect in the following, and for that reason I tell the + * units and origin of each measurement (where it applies), or else I + * use sufficiently weaselly language ("is a monotonically nondecreasing + * function of...") that I cannot set false expectations for lawyerly + * readers. + */ + +/* XXX tcpdump/libpcap do not tolerate variable-length headers, + * yet, so we pad every radiotap header to 64 bytes. Ugh. + */ +#define IEEE80211_RADIOTAP_HDRLEN 64 + +/* The radio capture header precedes the 802.11 header. */ +struct ieee80211_radiotap_header { + u_int8_t it_version; /* Version 0. Only increases + * for drastic changes, + * introduction of compatible + * new fields does not count. + */ + u_int8_t it_pad; + u_int16_t it_len; /* length of the whole + * header in bytes, including + * it_version, it_pad, + * it_len, and data fields. + */ + u_int32_t it_present; /* A bitmap telling which + * fields are present. Set bit 31 + * (0x80000000) to extend the + * bitmap by another 32 bits. + * Additional extensions are made + * by setting bit 31. + */ +}; + +/* Name Data type Units + * ---- --------- ----- + * + * IEEE80211_RADIOTAP_TSFT u_int64_t microseconds + * + * Value in microseconds of the MAC's 64-bit 802.11 Time + * Synchronization Function timer when the first bit of the + * MPDU arrived at the MAC. For received frames, only. + * + * IEEE80211_RADIOTAP_CHANNEL 2 x u_int16_t MHz, bitmap + * + * Tx/Rx frequency in MHz, followed by flags (see below). + * + * IEEE80211_RADIOTAP_FHSS u_int16_t see below + * + * For frequency-hopping radios, the hop set (first byte) + * and pattern (second byte). + * + * IEEE80211_RADIOTAP_RATE u_int8_t 500kb/s + * + * Tx/Rx data rate + * + * IEEE80211_RADIOTAP_DBM_ANTSIGNAL int8_t decibels from + * one milliwatt (dBm) + * + * RF signal power at the antenna, decibel difference from + * one milliwatt. + * + * IEEE80211_RADIOTAP_DBM_ANTNOISE int8_t decibels from + * one milliwatt (dBm) + * + * RF noise power at the antenna, decibel difference from one + * milliwatt. + * + * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_t decibel (dB) + * + * RF signal power at the antenna, decibel difference from an + * arbitrary, fixed reference. + * + * IEEE80211_RADIOTAP_DB_ANTNOISE u_int8_t decibel (dB) + * + * RF noise power at the antenna, decibel difference from an + * arbitrary, fixed reference point. + * + * IEEE80211_RADIOTAP_LOCK_QUALITY u_int16_t unitless + * + * Quality of Barker code lock. Unitless. Monotonically + * nondecreasing with "better" lock strength. Called "Signal + * Quality" in datasheets. (Is there a standard way to measure + * this?) + * + * IEEE80211_RADIOTAP_TX_ATTENUATION u_int16_t unitless + * + * Transmit power expressed as unitless distance from max + * power set at factory calibration. 0 is max power. + * Monotonically nondecreasing with lower power levels. + * + * IEEE80211_RADIOTAP_DB_TX_ATTENUATION u_int16_t decibels (dB) + * + * Transmit power expressed as decibel distance from max power + * set at factory calibration. 0 is max power. Monotonically + * nondecreasing with lower power levels. + * + * IEEE80211_RADIOTAP_DBM_TX_POWER int8_t decibels from + * one milliwatt (dBm) + * + * Transmit power expressed as dBm (decibels from a 1 milliwatt + * reference). This is the absolute power level measured at + * the antenna port. + * + * IEEE80211_RADIOTAP_FLAGS u_int8_t bitmap + * + * Properties of transmitted and received frames. See flags + * defined below. + * + * IEEE80211_RADIOTAP_ANTENNA u_int8_t antenna index + * + * Unitless indication of the Rx/Tx antenna for this packet. + * The first antenna is antenna 0. + * + * IEEE80211_RADIOTAP_FCS u_int32_t data + * + * FCS from frame in network byte order. + */ +enum ieee80211_radiotap_type { + IEEE80211_RADIOTAP_TSFT = 0, + IEEE80211_RADIOTAP_FLAGS = 1, + IEEE80211_RADIOTAP_RATE = 2, + IEEE80211_RADIOTAP_CHANNEL = 3, + IEEE80211_RADIOTAP_FHSS = 4, + IEEE80211_RADIOTAP_DBM_ANTSIGNAL = 5, + IEEE80211_RADIOTAP_DBM_ANTNOISE = 6, + IEEE80211_RADIOTAP_LOCK_QUALITY = 7, + IEEE80211_RADIOTAP_TX_ATTENUATION = 8, + IEEE80211_RADIOTAP_DB_TX_ATTENUATION = 9, + IEEE80211_RADIOTAP_DBM_TX_POWER = 10, + IEEE80211_RADIOTAP_ANTENNA = 11, + IEEE80211_RADIOTAP_DB_ANTSIGNAL = 12, + IEEE80211_RADIOTAP_DB_ANTNOISE = 13, + IEEE80211_RADIOTAP_EXT = 31, +}; + +/* Channel flags. */ +#define IEEE80211_CHAN_TURBO 0x0010 /* Turbo channel */ +#define IEEE80211_CHAN_CCK 0x0020 /* CCK channel */ +#define IEEE80211_CHAN_OFDM 0x0040 /* OFDM channel */ +#define IEEE80211_CHAN_2GHZ 0x0080 /* 2 GHz spectrum channel. */ +#define IEEE80211_CHAN_5GHZ 0x0100 /* 5 GHz spectrum channel */ +#define IEEE80211_CHAN_PASSIVE 0x0200 /* Only passive scan allowed */ +#define IEEE80211_CHAN_DYN 0x0400 /* Dynamic CCK-OFDM channel */ +#define IEEE80211_CHAN_GFSK 0x0800 /* GFSK channel (FHSS PHY) */ + +/* For IEEE80211_RADIOTAP_FLAGS */ +#define IEEE80211_RADIOTAP_F_CFP 0x01 /* sent/received + * during CFP + */ +#define IEEE80211_RADIOTAP_F_SHORTPRE 0x02 /* sent/received + * with short + * preamble + */ +#define IEEE80211_RADIOTAP_F_WEP 0x04 /* sent/received + * with WEP encryption + */ +#define IEEE80211_RADIOTAP_F_FRAG 0x08 /* sent/received + * with fragmentation + */ +#define IEEE80211_RADIOTAP_F_FCS 0x10 /* frame includes FCS */ +#define IEEE80211_RADIOTAP_F_DATAPAD 0x20 /* frame has padding between + * 802.11 header and payload + * (to 32-bit boundary) + */ + +/* Ugly macro to convert literal channel numbers into their mhz equivalents + * There are certianly some conditions that will break this (like feeding it '30') + * but they shouldn't arise since nothing talks on channel 30. */ +#define ieee80211chan2mhz(x) \ + (((x) <= 14) ? \ + (((x) == 14) ? 2484 : ((x) * 5) + 2407) : \ + ((x) + 1000) * 5) + +#endif /* IEEE80211_RADIOTAP_H */ |
From: Michael Wu <fla...@so...> - 2005-09-13 23:57:53
|
(resend, sent to oss.sgi.com by mistake) On Tuesday 13 September 2005 19:35, James Ketrenos wrote: > Added ieee80211_radiotap.h to enhance statistic reporting to user space > from wireless drivers. > > Signed-off-by: James Ketrenos <jke...@li...> I'm not sure, but didn't Mike Kershaw create this patch? I was expecting a signed-off-by line by him. -Michael Wu |
From: James K. <jke...@li...> - 2005-09-14 01:36:08
|
Michael Wu wrote: >(resend, sent to oss.sgi.com by mistake) > >On Tuesday 13 September 2005 19:35, James Ketrenos wrote: > > >>Added ieee80211_radiotap.h to enhance statistic reporting to user space >>from wireless drivers. >> >>Signed-off-by: James Ketrenos <jke...@li...> >> >> >I'm not sure, but didn't Mike Kershaw create this patch? > Yes. Building ieee80211_radiotap.h was all his work. He also put together patches to the ipw2200 to use those headers (which are a part of that series that will be sent out after I send out a driver compatibility series for the ieee80211 patches) >I was expecting a >signed-off-by line by him. > > I'm not sure where that signed-off-line went. I'm pretty sure I had typed it in during the original commit; now that I've rebased 3 times, I don't actually have the original commit logs though -- so not sure if I just don't remember, or what. The GIT log in the bughost.org repository does list him as the author. The git-format-patch-script didn't seem to make emails with legible author information though (it stuck the author information in between the first line of the commit message and the rest of the message) James |
From: Michael Wu <fla...@so...> - 2005-09-14 02:22:24
|
On Tuesday 13 September 2005 21:35, James Ketrenos wrote: > Michael Wu wrote: > >(resend, sent to oss.sgi.com by mistake) > > > >On Tuesday 13 September 2005 19:35, James Ketrenos wrote: > >>Added ieee80211_radiotap.h to enhance statistic reporting to user space > >>from wireless drivers. > >> > >>Signed-off-by: James Ketrenos <jke...@li...> > > > >I'm not sure, but didn't Mike Kershaw create this patch? > > Yes. Building ieee80211_radiotap.h was all his work. He also put > together patches to the ipw2200 to use those headers (which are a part > of that series that will be sent out after I send out a driver > compatibility series for the ieee80211 patches) > Oh, that reminds me. A bunch of information that is put into the radiotap header is put inside struct ieee80211_rx_stats when the driver passes the frame to the ieee80211 layer. I think it is a better idea to expand ieee80211_rx_stats to include all information necessary for filling in a radiotap header, and let the ieee80211 tack on the header. I would prefer either that or giving drivers access to the generic monitor mode path so frames can be passed to userspace ASAP. Also, we probably want an ioctl or some way to switch between raw ieee80211 frames and radiotap headers. -Michael Wu |
From: Mike K. <dr...@ki...> - 2005-09-14 02:44:32
|
> A bunch of information that is put into the radiotap header is put inside= =20 > struct ieee80211_rx_stats when the driver passes the frame to the ieee802= 11=20 > layer. I think it is a better idea to expand ieee80211_rx_stats to includ= e=20 > all information necessary for filling in a radiotap header, and let the= =20 > ieee80211 tack on the header. Yeah, we talked about this, I was just waiting for things to settle in the tree before I tackled it. > I would prefer either that or giving drivers access to the generic monito= r=20 > mode path so frames can be passed to userspace ASAP. I'm of 2 minds here... For a driver to implement radiotap, all it takes is a struct that the driver fills in that LOOKS like a radiotap dynamic header to userspace, but is really just a static struct fill. For the ieee80211 layer to do the same, it will have to actually dynamically contstruct the header, per frame, based on what the driver gives us. It's quicker to do per-driver header construction. I don't mind implementing both, and including a field that ieee80211 layer can pick to do headers dynamically or not. Maybe this is too weird an idea, and we should just pick "80211" or "driver". I'm willing to write the code for either use case. I suppose that rfmon is a fairly special case and won't be as much of a cpu drain as a wired ethernet NIC or normal mode would be. > Also, we probably want an ioctl or some way to switch between raw ieee802= 11=20 > frames and radiotap headers. Sure, *as long as every driver uses the same ioctl* :) PLEASE PLEASE PLEASE lets pick a constant ioctl name for this. I assume we'll want it as an iwpriv ioctl, thats where the other behavior of this ilk lives. If we're going to implement an iwpriv control for it, shall we plan forward and make it an integer not a boolean, so we can have different headers if we need them? The ioctl is pretty trivial in any case, but you're right, we should have it. -m --=20 Mike Kershaw/Dragorn <dr...@ki...> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 "Dear Die-ary, Today I stuffed some dolls with dead rats I put in a blender. I'm beginning to wonder if, maybe, I really am screwed up." -- Johnny C. (JtHM) |
From: Michael Wu <fla...@so...> - 2005-09-14 03:13:34
|
On Tuesday 13 September 2005 22:44, Mike Kershaw wrote: > > I would prefer either that or giving drivers access to the generic > > monitor mode path so frames can be passed to userspace ASAP. > > I'm of 2 minds here... For a driver to implement radiotap, all it takes > is a struct that the driver fills in that LOOKS like a radiotap dynamic > header to userspace, but is really just a static struct fill. For the > ieee80211 layer to do the same, it will have to actually dynamically > contstruct the header, per frame, based on what the driver gives us. > It's quicker to do per-driver header construction. > > I don't mind implementing both, and including a field that ieee80211 > layer can pick to do headers dynamically or not. > > Maybe this is too weird an idea, and we should just pick "80211" or > "driver". I'm willing to write the code for either use case. I suppose > that rfmon is a fairly special case and won't be as much of a cpu drain > as a wired ethernet NIC or normal mode would be. > I'm currently leaning towards taking the monitor mode stuff out of the ieee80211 rx path and letting the driver decide when to hook in the monitor mode stuff. Then the radiotap headers would be constructed in the driver. > > Also, we probably want an ioctl or some way to switch between raw > > ieee80211 frames and radiotap headers. > > Sure, *as long as every driver uses the same ioctl* :) PLEASE PLEASE > PLEASE lets pick a constant ioctl name for this. I assume we'll want it > as an iwpriv ioctl, thats where the other behavior of this ilk lives. > If we're going to implement an iwpriv control for it, shall we plan > forward and make it an integer not a boolean, so we can have different > headers if we need them? > By ioctl, I mean Wireless Extensions, so hopefully some future version of WE will have it. I somehow doubt that we will need much more than extensions of radiotap headers in the future.. it looks like it can cover everything. However, an int is easy, so why not.. -Michael Wu |
From: Christoph H. <hc...@in...> - 2005-09-14 10:53:21
|
On Tue, Sep 13, 2005 at 06:35:13PM -0500, James Ketrenos wrote: > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distribution. > + * 3. The name of David Young may not be used to endorse or promote > + * products derived from this software without specific prior > + * written permission. Is this actually GPL-compatible? > +#include <linux/version.h> shouldn;t be beeded, > +#include <linux/if_ether.h> > +#include <linux/kernel.h> > + > +/* Kluge the radiotap linktype for now if we don't have it */ > +#ifndef ARPHRD_IEEE80211_RADIOTAP > +#define ARPHRD_IEEE80211_RADIOTAP 803 > +#endif please get that right. > +/* The radio capture header precedes the 802.11 header. */ > +struct ieee80211_radiotap_header { > + u_int8_t it_version; /* Version 0. Only increases > + * for drastic changes, > + * introduction of compatible > + * new fields does not count. > + */ > + u_int8_t it_pad; please use u8/etc types as in the rest of the kernel, or SuS uint8_t/etc types if you really want to. |
From: James K. <jke...@li...> - 2005-09-14 14:01:25
|
Christoph Hellwig wrote: >On Tue, Sep 13, 2005 at 06:35:13PM -0500, James Ketrenos wrote: > > >>+ * are met: >>+ * 1. Redistributions of source code must retain the above copyright >>+ * notice, this list of conditions and the following disclaimer. >>+ * 2. Redistributions in binary form must reproduce the above copyright >>+ * notice, this list of conditions and the following disclaimer in the >>+ * documentation and/or other materials provided with the distribution. >>+ * 3. The name of David Young may not be used to endorse or promote >>+ * products derived from this software without specific prior >>+ * written permission. >> >> > >Is this actually GPL-compatible? > > Per FSF[1], the modified BSD license is compatible with the GPL. Its used throughout other files in the kernel tree (grep for 'may not be used' or 'redistributions of source code must'). >>+#include <linux/version.h> >> >> > >shouldn;t be beeded, > > Removed. >>+/* Kluge the radiotap linktype for now if we don't have it */ >>+#ifndef ARPHRD_IEEE80211_RADIOTAP >>+#define ARPHRD_IEEE80211_RADIOTAP 803 >>+#endif >> >> > >please get that right. > > This should go into include/linux/if_arp.h anyway, correct? >>+ u_int8_t it_version; /* Version 0. Only increases >> >> >please use u8/etc types as in the rest of the kernel, or SuS >uint8_t/etc types if you really want to. > > A quick sed script now has them set to uN vs. u_intN_t. Patch covering the above changes follows. Thanks, James --- include/linux/if_arp.h | 1 + include/net/ieee80211_radiotap.h | 38 ++++++++++++++++---------------------- 2 files changed, 17 insertions(+), 22 deletions(-) --- diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h --- a/include/linux/if_arp.h +++ b/include/linux/if_arp.h @@ -84,6 +84,7 @@ #define ARPHRD_IEEE802_TR 800 /* Magic type ident for TR */ #define ARPHRD_IEEE80211 801 /* IEEE 802.11 */ #define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */ +#define ARPHRD_IEEE80211_RADIOTAP 803 /* IEEE 802.11 + Radiotap header */ #define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */ #define ARPHRD_NONE 0xFFFE /* zero header length */ diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h --- a/include/net/ieee80211_radiotap.h +++ b/include/net/ieee80211_radiotap.h @@ -38,15 +38,9 @@ #ifndef IEEE80211RADIOTAP_H #define IEEE80211RADIOTAP_H -#include <linux/version.h> #include <linux/if_ether.h> #include <linux/kernel.h> -/* Kluge the radiotap linktype for now if we don't have it */ -#ifndef ARPHRD_IEEE80211_RADIOTAP -#define ARPHRD_IEEE80211_RADIOTAP 803 -#endif - /* Radiotap header version (from official NetBSD feed) */ #define IEEE80211RADIOTAP_VERSION "1.5" /* Base version of the radiotap packet header data */ @@ -74,18 +68,18 @@ /* The radio capture header precedes the 802.11 header. */ struct ieee80211_radiotap_header { - u_int8_t it_version; /* Version 0. Only increases + u8 it_version; /* Version 0. Only increases * for drastic changes, * introduction of compatible * new fields does not count. */ - u_int8_t it_pad; - u_int16_t it_len; /* length of the whole + u8 it_pad; + u16 it_len; /* length of the whole * header in bytes, including * it_version, it_pad, * it_len, and data fields. */ - u_int32_t it_present; /* A bitmap telling which + u32 it_present; /* A bitmap telling which * fields are present. Set bit 31 * (0x80000000) to extend the * bitmap by another 32 bits. @@ -97,22 +91,22 @@ struct ieee80211_radiotap_header { /* Name Data type Units * ---- --------- ----- * - * IEEE80211_RADIOTAP_TSFT u_int64_t microseconds + * IEEE80211_RADIOTAP_TSFT u64 microseconds * * Value in microseconds of the MAC's 64-bit 802.11 Time * Synchronization Function timer when the first bit of the * MPDU arrived at the MAC. For received frames, only. * - * IEEE80211_RADIOTAP_CHANNEL 2 x u_int16_t MHz, bitmap + * IEEE80211_RADIOTAP_CHANNEL 2 x u16 MHz, bitmap * * Tx/Rx frequency in MHz, followed by flags (see below). * - * IEEE80211_RADIOTAP_FHSS u_int16_t see below + * IEEE80211_RADIOTAP_FHSS u16 see below * * For frequency-hopping radios, the hop set (first byte) * and pattern (second byte). * - * IEEE80211_RADIOTAP_RATE u_int8_t 500kb/s + * IEEE80211_RADIOTAP_RATE u8 500kb/s * * Tx/Rx data rate * @@ -128,30 +122,30 @@ struct ieee80211_radiotap_header { * RF noise power at the antenna, decibel difference from one * milliwatt. * - * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_t decibel (dB) + * IEEE80211_RADIOTAP_DB_ANTSIGNAL u8 decibel (dB) * * RF signal power at the antenna, decibel difference from an * arbitrary, fixed reference. * - * IEEE80211_RADIOTAP_DB_ANTNOISE u_int8_t decibel (dB) + * IEEE80211_RADIOTAP_DB_ANTNOISE u8 decibel (dB) * * RF noise power at the antenna, decibel difference from an * arbitrary, fixed reference point. * - * IEEE80211_RADIOTAP_LOCK_QUALITY u_int16_t unitless + * IEEE80211_RADIOTAP_LOCK_QUALITY u16 unitless * * Quality of Barker code lock. Unitless. Monotonically * nondecreasing with "better" lock strength. Called "Signal * Quality" in datasheets. (Is there a standard way to measure * this?) * - * IEEE80211_RADIOTAP_TX_ATTENUATION u_int16_t unitless + * IEEE80211_RADIOTAP_TX_ATTENUATION u16 unitless * * Transmit power expressed as unitless distance from max * power set at factory calibration. 0 is max power. * Monotonically nondecreasing with lower power levels. * - * IEEE80211_RADIOTAP_DB_TX_ATTENUATION u_int16_t decibels (dB) + * IEEE80211_RADIOTAP_DB_TX_ATTENUATION u16 decibels (dB) * * Transmit power expressed as decibel distance from max power * set at factory calibration. 0 is max power. Monotonically @@ -164,17 +158,17 @@ struct ieee80211_radiotap_header { * reference). This is the absolute power level measured at * the antenna port. * - * IEEE80211_RADIOTAP_FLAGS u_int8_t bitmap + * IEEE80211_RADIOTAP_FLAGS u8 bitmap * * Properties of transmitted and received frames. See flags * defined below. * - * IEEE80211_RADIOTAP_ANTENNA u_int8_t antenna index + * IEEE80211_RADIOTAP_ANTENNA u8 antenna index * * Unitless indication of the Rx/Tx antenna for this packet. * The first antenna is antenna 0. * - * IEEE80211_RADIOTAP_FCS u_int32_t data + * IEEE80211_RADIOTAP_FCS u32 data * * FCS from frame in network byte order. */ --- [1]http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses |