2004-01-31 04:40:09 +00:00
/*
2012-05-02 04:03:49 +00:00
* packet - ieee80211 - radiotap . c
2004-01-31 04:40:09 +00:00
* Decode packets with a Radiotap header
*
2006-05-21 04:49:01 +00:00
* Wireshark - Network traffic analyzer
* By Gerald Combs < gerald @ wireshark . org >
2004-01-31 04:40:09 +00:00
* Copyright 1998 Gerald Combs
*
* Copied from README . developer
*
* This program is free software ; you can redistribute it and / or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation ; either version 2
* of the License , or ( at your option ) any later version .
*
* This program is distributed in the hope that it will be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
* GNU General Public License for more details .
*
* You should have received a copy of the GNU General Public License
* along with this program ; if not , write to the Free Software
2012-06-28 23:18:38 +00:00
* Foundation , Inc . , 51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA .
2004-01-31 04:40:09 +00:00
*/
2010-10-13 21:30:27 +00:00
# include "config.h"
2004-01-31 04:40:09 +00:00
2010-10-14 17:56:06 +00:00
# include <errno.h>
2004-01-31 04:40:09 +00:00
# include <epan/packet.h>
2013-11-09 15:44:29 +00:00
# include <wsutil/pint.h>
2011-08-31 09:00:54 +00:00
# include <epan/crc32-tvb.h>
2015-06-11 22:05:44 +00:00
# include <wsutil/frequency-utils.h>
2008-11-27 08:34:41 +00:00
# include <epan/tap.h>
2009-05-17 19:18:18 +00:00
# include <epan/prefs.h>
2010-10-14 17:56:06 +00:00
# include <epan/addr_resolv.h>
2012-08-08 12:32:04 +00:00
# include <epan/expert.h>
2004-01-31 04:40:09 +00:00
# include "packet-ieee80211.h"
2012-05-02 04:03:49 +00:00
# include "packet-ieee80211-radiotap.h"
# include "packet-ieee80211-radiotap-iter.h"
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/* protocol */
static int proto_radiotap = - 1 ;
static int hf_radiotap_version = - 1 ;
static int hf_radiotap_pad = - 1 ;
static int hf_radiotap_length = - 1 ;
static int hf_radiotap_present = - 1 ;
static int hf_radiotap_mactime = - 1 ;
2013-01-31 17:55:31 +00:00
/* static int hf_radiotap_channel = -1; */
2012-08-08 12:56:37 +00:00
static int hf_radiotap_channel_frequency = - 1 ;
static int hf_radiotap_channel_flags = - 1 ;
static int hf_radiotap_channel_flags_turbo = - 1 ;
static int hf_radiotap_channel_flags_cck = - 1 ;
static int hf_radiotap_channel_flags_ofdm = - 1 ;
static int hf_radiotap_channel_flags_2ghz = - 1 ;
static int hf_radiotap_channel_flags_5ghz = - 1 ;
static int hf_radiotap_channel_flags_passive = - 1 ;
static int hf_radiotap_channel_flags_dynamic = - 1 ;
static int hf_radiotap_channel_flags_gfsk = - 1 ;
static int hf_radiotap_channel_flags_gsm = - 1 ;
static int hf_radiotap_channel_flags_sturbo = - 1 ;
static int hf_radiotap_channel_flags_half = - 1 ;
static int hf_radiotap_channel_flags_quarter = - 1 ;
static int hf_radiotap_rxflags = - 1 ;
static int hf_radiotap_rxflags_badplcp = - 1 ;
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
static int hf_radiotap_xchannel_channel = - 1 ;
2012-08-08 12:56:37 +00:00
static int hf_radiotap_xchannel_frequency = - 1 ;
static int hf_radiotap_xchannel_flags = - 1 ;
static int hf_radiotap_xchannel_flags_turbo = - 1 ;
static int hf_radiotap_xchannel_flags_cck = - 1 ;
static int hf_radiotap_xchannel_flags_ofdm = - 1 ;
static int hf_radiotap_xchannel_flags_2ghz = - 1 ;
static int hf_radiotap_xchannel_flags_5ghz = - 1 ;
static int hf_radiotap_xchannel_flags_passive = - 1 ;
static int hf_radiotap_xchannel_flags_dynamic = - 1 ;
static int hf_radiotap_xchannel_flags_gfsk = - 1 ;
static int hf_radiotap_xchannel_flags_gsm = - 1 ;
static int hf_radiotap_xchannel_flags_sturbo = - 1 ;
static int hf_radiotap_xchannel_flags_half = - 1 ;
static int hf_radiotap_xchannel_flags_quarter = - 1 ;
static int hf_radiotap_xchannel_flags_ht20 = - 1 ;
static int hf_radiotap_xchannel_flags_ht40u = - 1 ;
static int hf_radiotap_xchannel_flags_ht40d = - 1 ;
#if 0
static int hf_radiotap_xchannel_maxpower = - 1 ;
# endif
static int hf_radiotap_fhss_hopset = - 1 ;
static int hf_radiotap_fhss_pattern = - 1 ;
static int hf_radiotap_datarate = - 1 ;
static int hf_radiotap_antenna = - 1 ;
static int hf_radiotap_dbm_antsignal = - 1 ;
static int hf_radiotap_db_antsignal = - 1 ;
static int hf_radiotap_dbm_antnoise = - 1 ;
static int hf_radiotap_db_antnoise = - 1 ;
static int hf_radiotap_tx_attenuation = - 1 ;
static int hf_radiotap_db_tx_attenuation = - 1 ;
static int hf_radiotap_txpower = - 1 ;
static int hf_radiotap_vendor_ns = - 1 ;
static int hf_radiotap_ven_oui = - 1 ;
static int hf_radiotap_ven_subns = - 1 ;
static int hf_radiotap_ven_skip = - 1 ;
static int hf_radiotap_ven_data = - 1 ;
static int hf_radiotap_mcs = - 1 ;
static int hf_radiotap_mcs_known = - 1 ;
static int hf_radiotap_mcs_have_bw = - 1 ;
static int hf_radiotap_mcs_have_index = - 1 ;
static int hf_radiotap_mcs_have_gi = - 1 ;
static int hf_radiotap_mcs_have_format = - 1 ;
static int hf_radiotap_mcs_have_fec = - 1 ;
static int hf_radiotap_mcs_have_stbc = - 1 ;
2015-06-20 22:23:35 +00:00
static int hf_radiotap_mcs_have_ness = - 1 ;
static int hf_radiotap_mcs_ness_bit1 = - 1 ;
2012-08-08 12:56:37 +00:00
static int hf_radiotap_mcs_bw = - 1 ;
static int hf_radiotap_mcs_index = - 1 ;
static int hf_radiotap_mcs_gi = - 1 ;
static int hf_radiotap_mcs_format = - 1 ;
static int hf_radiotap_mcs_fec = - 1 ;
static int hf_radiotap_mcs_stbc = - 1 ;
2015-06-20 22:23:35 +00:00
static int hf_radiotap_mcs_ness_bit0 = - 1 ;
2012-08-08 12:56:37 +00:00
static int hf_radiotap_ampdu = - 1 ;
static int hf_radiotap_ampdu_ref = - 1 ;
static int hf_radiotap_ampdu_flags = - 1 ;
static int hf_radiotap_ampdu_flags_report_zerolen = - 1 ;
static int hf_radiotap_ampdu_flags_is_zerolen = - 1 ;
static int hf_radiotap_ampdu_flags_last_known = - 1 ;
static int hf_radiotap_ampdu_flags_is_last = - 1 ;
static int hf_radiotap_ampdu_flags_delim_crc_error = - 1 ;
static int hf_radiotap_ampdu_delim_crc = - 1 ;
2012-09-18 20:46:05 +00:00
static int hf_radiotap_vht = - 1 ;
static int hf_radiotap_vht_known = - 1 ;
static int hf_radiotap_vht_have_stbc = - 1 ;
static int hf_radiotap_vht_have_txop_ps = - 1 ;
static int hf_radiotap_vht_have_gi = - 1 ;
static int hf_radiotap_vht_have_sgi_nsym_da = - 1 ;
static int hf_radiotap_vht_have_ldpc_extra = - 1 ;
static int hf_radiotap_vht_have_bf = - 1 ;
static int hf_radiotap_vht_have_bw = - 1 ;
static int hf_radiotap_vht_have_gid = - 1 ;
static int hf_radiotap_vht_have_p_aid = - 1 ;
static int hf_radiotap_vht_stbc = - 1 ;
static int hf_radiotap_vht_txop_ps = - 1 ;
static int hf_radiotap_vht_gi = - 1 ;
static int hf_radiotap_vht_sgi_nsym_da = - 1 ;
static int hf_radiotap_vht_ldpc_extra = - 1 ;
static int hf_radiotap_vht_bf = - 1 ;
static int hf_radiotap_vht_bw = - 1 ;
static int hf_radiotap_vht_nsts [ 4 ] = { - 1 , - 1 , - 1 , - 1 } ;
static int hf_radiotap_vht_mcs [ 4 ] = { - 1 , - 1 , - 1 , - 1 } ;
static int hf_radiotap_vht_nss [ 4 ] = { - 1 , - 1 , - 1 , - 1 } ;
static int hf_radiotap_vht_coding [ 4 ] = { - 1 , - 1 , - 1 , - 1 } ;
static int hf_radiotap_vht_datarate [ 4 ] = { - 1 , - 1 , - 1 , - 1 } ;
static int hf_radiotap_vht_gid = - 1 ;
static int hf_radiotap_vht_p_aid = - 1 ;
static int hf_radiotap_vht_user = - 1 ;
2012-08-08 12:56:37 +00:00
/* "Present" flags */
static int hf_radiotap_present_tsft = - 1 ;
static int hf_radiotap_present_flags = - 1 ;
static int hf_radiotap_present_rate = - 1 ;
static int hf_radiotap_present_channel = - 1 ;
static int hf_radiotap_present_fhss = - 1 ;
static int hf_radiotap_present_dbm_antsignal = - 1 ;
static int hf_radiotap_present_dbm_antnoise = - 1 ;
static int hf_radiotap_present_lock_quality = - 1 ;
static int hf_radiotap_present_tx_attenuation = - 1 ;
static int hf_radiotap_present_db_tx_attenuation = - 1 ;
static int hf_radiotap_present_dbm_tx_power = - 1 ;
static int hf_radiotap_present_antenna = - 1 ;
static int hf_radiotap_present_db_antsignal = - 1 ;
static int hf_radiotap_present_db_antnoise = - 1 ;
static int hf_radiotap_present_hdrfcs = - 1 ;
static int hf_radiotap_present_rxflags = - 1 ;
static int hf_radiotap_present_xchannel = - 1 ;
static int hf_radiotap_present_mcs = - 1 ;
static int hf_radiotap_present_ampdu = - 1 ;
2012-09-18 20:46:05 +00:00
static int hf_radiotap_present_vht = - 1 ;
2012-08-08 12:56:37 +00:00
static int hf_radiotap_present_reserved = - 1 ;
static int hf_radiotap_present_rtap_ns = - 1 ;
static int hf_radiotap_present_vendor_ns = - 1 ;
static int hf_radiotap_present_ext = - 1 ;
/* "present.flags" flags */
static int hf_radiotap_flags = - 1 ;
static int hf_radiotap_flags_cfp = - 1 ;
static int hf_radiotap_flags_preamble = - 1 ;
static int hf_radiotap_flags_wep = - 1 ;
static int hf_radiotap_flags_frag = - 1 ;
static int hf_radiotap_flags_fcs = - 1 ;
static int hf_radiotap_flags_datapad = - 1 ;
static int hf_radiotap_flags_badfcs = - 1 ;
static int hf_radiotap_flags_shortgi = - 1 ;
static int hf_radiotap_quality = - 1 ;
static int hf_radiotap_fcs = - 1 ;
static int hf_radiotap_fcs_bad = - 1 ;
static gint ett_radiotap = - 1 ;
static gint ett_radiotap_present = - 1 ;
static gint ett_radiotap_flags = - 1 ;
static gint ett_radiotap_rxflags = - 1 ;
static gint ett_radiotap_channel_flags = - 1 ;
static gint ett_radiotap_xchannel_flags = - 1 ;
static gint ett_radiotap_vendor = - 1 ;
static gint ett_radiotap_mcs = - 1 ;
static gint ett_radiotap_mcs_known = - 1 ;
static gint ett_radiotap_ampdu = - 1 ;
static gint ett_radiotap_ampdu_flags = - 1 ;
2012-09-18 20:46:05 +00:00
static gint ett_radiotap_vht = - 1 ;
static gint ett_radiotap_vht_known = - 1 ;
static gint ett_radiotap_vht_user = - 1 ;
2012-08-08 12:56:37 +00:00
2013-09-02 23:32:31 +00:00
static expert_field ei_radiotap_data_past_header = EI_INIT ;
static expert_field ei_radiotap_present_reserved = EI_INIT ;
static expert_field ei_radiotap_present = EI_INIT ;
2015-06-20 22:57:57 +00:00
static dissector_handle_t ieee80211_radio_handle ;
2012-08-08 12:56:37 +00:00
static int radiotap_tap = - 1 ;
/* Settings */
static gboolean radiotap_bit14_fcs = FALSE ;
static void
dissect_radiotap ( tvbuff_t * tvb , packet_info * pinfo , proto_tree * tree ) ;
# define BITNO_32(x) (((x) >> 16) ? 16 + BITNO_16((x) >> 16) : BITNO_16((x)))
# define BITNO_16(x) (((x) >> 8) ? 8 + BITNO_8((x) >> 8) : BITNO_8((x)))
2012-11-27 14:34:27 +00:00
# define BITNO_8(x) (((x) >> 4) ? 4 + BITNO_4((x) >> 4) : BITNO_4((x)))
# define BITNO_4(x) (((x) >> 2) ? 2 + BITNO_2((x) >> 2) : BITNO_2((x)))
# define BITNO_2(x) (((x) & 2) ? 1 : 0)
2015-04-30 22:39:16 +00:00
# define BIT(n) (1U << n)
2012-08-08 12:56:37 +00:00
2010-10-14 17:56:06 +00:00
/* not officially defined (yet) */
# define IEEE80211_RADIOTAP_F_SHORTGI 0x80
# define IEEE80211_RADIOTAP_XCHANNEL 18
2004-01-31 04:40:09 +00:00
2009-07-02 20:35:46 +00:00
/* Official specifcation:
2006-10-25 15:16:49 +00:00
*
2009-07-02 20:35:46 +00:00
* http : //www.radiotap.org/
*
* Unofficial and historical specifications :
2010-01-16 03:34:07 +00:00
* http : //madwifi-project.org/wiki/DevDocs/RadiotapHeader
2007-01-30 20:57:51 +00:00
* NetBSD ' s ieee80211_radiotap . h file
2006-10-25 15:16:49 +00:00
*/
2004-01-31 04:40:09 +00:00
/*
* Useful combinations of channel characteristics .
*/
# define IEEE80211_CHAN_FHSS \
( IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_GFSK )
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
# define IEEE80211_CHAN_DSSS \
( IEEE80211_CHAN_2GHZ )
2004-01-31 04:40:09 +00:00
# define IEEE80211_CHAN_A \
( IEEE80211_CHAN_5GHZ | IEEE80211_CHAN_OFDM )
# define IEEE80211_CHAN_B \
( IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_CCK )
# define IEEE80211_CHAN_PUREG \
( IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_OFDM )
# define IEEE80211_CHAN_G \
( IEEE80211_CHAN_2GHZ | IEEE80211_CHAN_DYN )
2015-06-22 22:04:28 +00:00
# define IEEE80211_CHAN_108A \
( IEEE80211_CHAN_A | IEEE80211_CHAN_TURBO )
2004-01-31 04:40:09 +00:00
# define IEEE80211_CHAN_108G \
( IEEE80211_CHAN_G | IEEE80211_CHAN_TURBO )
# define IEEE80211_CHAN_108PUREG \
( IEEE80211_CHAN_PUREG | IEEE80211_CHAN_TURBO )
2015-06-22 22:04:28 +00:00
# define IEEE80211_CHAN_ST \
( IEEE80211_CHAN_108A | IEEE80211_CHAN_STURBO )
2004-01-31 04:40:09 +00:00
2012-09-18 20:46:05 +00:00
# define MAX_MCS_VHT_INDEX 9
/*
* Maps a VHT bandwidth index to ieee80211_vhtinfo . rates index .
*/
static const int ieee80211_vht_bw2rate_index [ ] = {
/* 20Mhz total */ 0 ,
/* 40Mhz total */ 1 , 0 , 0 ,
/* 80Mhz total */ 2 , 1 , 1 , 0 , 0 , 0 , 0 ,
/* 160Mhz total */ 3 , 2 , 2 , 1 , 1 , 1 , 1 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0
} ;
struct mcs_vht_info {
2012-12-26 05:57:06 +00:00
const char * modulation ;
const char * coding_rate ;
float rates [ 4 ] [ 2 ] ;
2012-09-18 20:46:05 +00:00
} ;
static const struct mcs_vht_info ieee80211_vhtinfo [ MAX_MCS_VHT_INDEX + 1 ] = {
/* MCS 0 */
{ " BPSK " , " 1/2 " ,
{ /* 20 Mhz */ { 6.5f , /* SGI */ 7.2f , } ,
/* 40 Mhz */ { 13.5f , /* SGI */ 15.0f , } ,
/* 80 Mhz */ { 29.3f , /* SGI */ 32.5f , } ,
/* 160 Mhz */ { 58.5f , /* SGI */ 65.0f , }
}
} ,
/* MCS 1 */
{ " QPSK " , " 1/2 " ,
{ /* 20 Mhz */ { 13.0f , /* SGI */ 14.4f , } ,
/* 40 Mhz */ { 27.0f , /* SGI */ 30.0f , } ,
/* 80 Mhz */ { 58.5f , /* SGI */ 65.0f , } ,
/* 160 Mhz */ { 117.0f , /* SGI */ 130.0f , }
}
} ,
/* MCS 2 */
{ " QPSK " , " 3/4 " ,
{ /* 20 Mhz */ { 19.5f , /* SGI */ 21.7f , } ,
/* 40 Mhz */ { 40.5f , /* SGI */ 45.0f , } ,
/* 80 Mhz */ { 87.8f , /* SGI */ 97.5f , } ,
/* 160 Mhz */ { 175.5f , /* SGI */ 195.0f , }
}
} ,
/* MCS 3 */
{ " 16-QAM " , " 1/2 " ,
{ /* 20 Mhz */ { 26.0f , /* SGI */ 28.9f , } ,
/* 40 Mhz */ { 54.0f , /* SGI */ 60.0f , } ,
/* 80 Mhz */ { 117.0f , /* SGI */ 130.0f , } ,
/* 160 Mhz */ { 234.0f , /* SGI */ 260.0f , }
}
} ,
/* MCS 4 */
{ " 16-QAM " , " 3/4 " ,
{ /* 20 Mhz */ { 39.0f , /* SGI */ 43.3f , } ,
/* 40 Mhz */ { 81.0f , /* SGI */ 90.0f , } ,
/* 80 Mhz */ { 175.5f , /* SGI */ 195.0f , } ,
/* 160 Mhz */ { 351.0f , /* SGI */ 390.0f , }
}
} ,
/* MCS 5 */
{ " 64-QAM " , " 2/3 " ,
{ /* 20 Mhz */ { 52.0f , /* SGI */ 57.8f , } ,
/* 40 Mhz */ { 108.0f , /* SGI */ 120.0f , } ,
/* 80 Mhz */ { 234.0f , /* SGI */ 260.0f , } ,
/* 160 Mhz */ { 468.0f , /* SGI */ 520.0f , }
}
} ,
/* MCS 6 */
{ " 64-QAM " , " 3/4 " ,
{ /* 20 Mhz */ { 58.5f , /* SGI */ 65.0f , } ,
/* 40 Mhz */ { 121.5f , /* SGI */ 135.0f , } ,
/* 80 Mhz */ { 263.3f , /* SGI */ 292.5f , } ,
/* 160 Mhz */ { 526.5f , /* SGI */ 585.0f , }
}
} ,
/* MCS 7 */
{ " 64-QAM " , " 5/6 " ,
{ /* 20 Mhz */ { 65.0f , /* SGI */ 72.2f , } ,
/* 40 Mhz */ { 135.0f , /* SGI */ 150.0f , } ,
/* 80 Mhz */ { 292.5f , /* SGI */ 325.0f , } ,
/* 160 Mhz */ { 585.0f , /* SGI */ 650.0f , }
}
} ,
/* MCS 8 */
{ " 256-QAM " , " 3/4 " ,
{ /* 20 Mhz */ { 78.0f , /* SGI */ 86.7f , } ,
/* 40 Mhz */ { 162.0f , /* SGI */ 180.0f , } ,
/* 80 Mhz */ { 351.0f , /* SGI */ 390.0f , } ,
/* 160 Mhz */ { 702.0f , /* SGI */ 780.0f , }
}
} ,
/* MCS 9 */
{ " 256-QAM " , " 5/6 " ,
{ /* 20 Mhz */ { 0.0f , /* SGI */ 0.0f , } ,
/* 40 Mhz */ { 180.0f , /* SGI */ 200.0f , } ,
/* 80 Mhz */ { 390.0f , /* SGI */ 433.3f , } ,
/* 160 Mhz */ { 780.0f , /* SGI */ 866.7f , }
}
}
} ;
2012-11-27 14:34:27 +00:00
/* In order by value */
2012-09-18 20:46:05 +00:00
static const value_string vht_bandwidth [ ] = {
2012-11-27 14:34:27 +00:00
{ IEEE80211_RADIOTAP_VHT_BW_20 , " 20 MHz " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40 , " 40 MHz " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20L , " 20 MHz lower " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20U , " 20 MHz upper " } ,
{ IEEE80211_RADIOTAP_VHT_BW_80 , " 80 MHz " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40L , " 40 MHz lower " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40U , " 40 MHz upper " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20LL , " 20 MHz, channel 1/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20LU , " 20 MHz, channel 2/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20UL , " 20 MHz, channel 3/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20UU , " 20 MHz, channel 4/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_160 , " 160 MHz " } ,
{ IEEE80211_RADIOTAP_VHT_BW_80L , " 80 MHz lower " } ,
{ IEEE80211_RADIOTAP_VHT_BW_80U , " 80 MHz upper " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40LL , " 40 MHz, channel 1/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40LU , " 40 MHz, channel 2/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40UL , " 40 MHz, channel 3/4 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_40UU , " 40 MHz, channel 4/4 " } ,
2012-09-18 20:46:05 +00:00
{ IEEE80211_RADIOTAP_VHT_BW_20LLL , " 20 MHz, channel 1/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20LLU , " 20 MHz, channel 2/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20LUL , " 20 MHz, channel 3/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20LUU , " 20 MHz, channel 4/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20ULL , " 20 MHz, channel 5/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20ULU , " 20 MHz, channel 6/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20UUL , " 20 MHz, channel 7/8 " } ,
{ IEEE80211_RADIOTAP_VHT_BW_20UUU , " 20 MHz, channel 8/8 " } ,
{ 0 , NULL }
} ;
2012-11-27 14:34:27 +00:00
static value_string_ext vht_bandwidth_ext = VALUE_STRING_EXT_INIT ( vht_bandwidth ) ;
2012-09-18 20:46:05 +00:00
2012-08-08 12:56:37 +00:00
static const value_string mcs_bandwidth [ ] = {
2012-11-27 14:34:27 +00:00
{ IEEE80211_RADIOTAP_MCS_BW_20 , " 20 MHz " } ,
{ IEEE80211_RADIOTAP_MCS_BW_40 , " 40 MHz " } ,
2012-08-08 12:56:37 +00:00
{ IEEE80211_RADIOTAP_MCS_BW_20L , " 20 MHz lower " } ,
{ IEEE80211_RADIOTAP_MCS_BW_20U , " 20 MHz upper " } ,
{ 0 , NULL }
} ;
2006-10-25 15:16:49 +00:00
2012-08-08 12:56:37 +00:00
static const value_string mcs_format [ ] = {
{ 0 , " mixed " } ,
{ 1 , " greenfield " } ,
{ 0 , NULL } ,
} ;
2008-11-27 08:34:41 +00:00
2012-08-08 12:56:37 +00:00
static const value_string mcs_fec [ ] = {
{ 0 , " BCC " } ,
{ 1 , " LDPC " } ,
{ 0 , NULL }
} ;
2009-05-17 19:18:18 +00:00
2012-08-08 12:56:37 +00:00
static const value_string mcs_gi [ ] = {
{ 0 , " long " } ,
{ 1 , " short " } ,
{ 0 , NULL }
} ;
2004-01-31 04:40:09 +00:00
2012-08-08 12:56:37 +00:00
static const true_false_string preamble_type = {
" Short " ,
" Long " ,
} ;
2006-01-23 16:56:34 +00:00
2006-10-31 01:28:29 +00:00
/*
2006-11-16 22:27:47 +00:00
* The NetBSD ieee80211_radiotap man page
* ( http : //netbsd.gw.com/cgi-bin/man-cgi?ieee80211_radiotap+9+NetBSD-current)
* says :
*
* Radiotap capture fields must be naturally aligned . That is , 16 - , 32 - ,
* and 64 - bit fields must begin on 16 - , 32 - , and 64 - bit boundaries , respec -
* tively . In this way , drivers can avoid unaligned accesses to radiotap
* capture fields . radiotap - compliant drivers must insert padding before a
* capture field to ensure its natural alignment . radiotap - compliant packet
* dissectors , such as tcpdump ( 8 ) , expect the padding .
2006-10-31 01:28:29 +00:00
*/
2006-11-16 22:27:47 +00:00
2004-01-31 04:40:09 +00:00
void
2010-10-13 21:30:27 +00:00
capture_radiotap ( const guchar * pd , int offset , int len , packet_counts * ld )
2004-01-31 04:40:09 +00:00
{
2010-10-13 21:30:27 +00:00
guint16 it_len ;
2010-10-14 17:56:06 +00:00
guint32 present , xpresent ;
2012-11-27 14:34:27 +00:00
guint8 rflags ;
2013-12-14 14:33:46 +00:00
const struct ieee80211_radiotap_header * hdr ;
2010-10-13 21:30:27 +00:00
2010-10-14 17:56:06 +00:00
if ( ! BYTES_ARE_IN_FRAME ( offset , len ,
sizeof ( struct ieee80211_radiotap_header ) ) ) {
2010-10-13 21:30:27 +00:00
ld - > other + + ;
return ;
}
2013-12-14 14:33:46 +00:00
hdr = ( const struct ieee80211_radiotap_header * ) pd ;
2013-11-29 18:59:06 +00:00
it_len = pletoh16 ( & hdr - > it_len ) ;
2010-10-13 21:30:27 +00:00
if ( ! BYTES_ARE_IN_FRAME ( offset , len , it_len ) ) {
ld - > other + + ;
return ;
2006-01-23 23:21:02 +00:00
}
2010-10-13 21:30:27 +00:00
if ( it_len > len ) {
/* Header length is bigger than total packet length */
ld - > other + + ;
return ;
2006-01-23 23:21:02 +00:00
}
2010-10-13 21:30:27 +00:00
2010-10-14 17:56:06 +00:00
if ( it_len < sizeof ( struct ieee80211_radiotap_header ) ) {
2010-10-13 21:30:27 +00:00
/* Header length is shorter than fixed-length portion of header */
ld - > other + + ;
return ;
2006-01-23 16:56:34 +00:00
}
2010-10-13 21:30:27 +00:00
2013-11-29 18:59:06 +00:00
present = pletoh32 ( & hdr - > it_present ) ;
2012-12-26 05:57:06 +00:00
offset + = ( int ) sizeof ( struct ieee80211_radiotap_header ) ;
it_len - = ( int ) sizeof ( struct ieee80211_radiotap_header ) ;
2010-10-14 17:56:06 +00:00
/* skip over other present bitmaps */
xpresent = present ;
while ( xpresent & BIT ( IEEE80211_RADIOTAP_EXT ) ) {
if ( ! BYTES_ARE_IN_FRAME ( offset , 4 , it_len ) ) {
ld - > other + + ;
return ;
}
2013-11-29 18:59:06 +00:00
xpresent = pletoh32 ( pd + offset ) ;
2010-10-14 17:56:06 +00:00
offset + = 4 ;
it_len - = 4 ;
}
2010-10-13 21:30:27 +00:00
rflags = 0 ;
/*
2010-10-14 17:56:06 +00:00
* IEEE80211_RADIOTAP_TSFT is the lowest - order bit ,
* just skip over it .
2010-10-13 21:30:27 +00:00
*/
if ( present & BIT ( IEEE80211_RADIOTAP_TSFT ) ) {
2010-10-14 17:56:06 +00:00
/* align it properly */
if ( offset & 7 ) {
int pad = 8 - ( offset & 7 ) ;
offset + = pad ;
it_len - = pad ;
}
2010-10-13 21:30:27 +00:00
if ( it_len < 8 ) {
/* No room in header for this field. */
ld - > other + + ;
return ;
}
2010-10-14 17:56:06 +00:00
/* That field is present, and it's 8 bytes long. */
2010-10-13 21:30:27 +00:00
offset + = 8 ;
it_len - = 8 ;
}
/*
* IEEE80211_RADIOTAP_FLAGS is the next bit .
*/
if ( present & BIT ( IEEE80211_RADIOTAP_FLAGS ) ) {
if ( it_len < 1 ) {
/* No room in header for this field. */
ld - > other + + ;
return ;
}
/* That field is present; fetch it. */
if ( ! BYTES_ARE_IN_FRAME ( offset , len , 1 ) ) {
ld - > other + + ;
return ;
}
rflags = pd [ offset ] ;
}
/* 802.11 header follows */
if ( rflags & IEEE80211_RADIOTAP_F_DATAPAD )
capture_ieee80211_datapad ( pd , offset + it_len , len , ld ) ;
else
capture_ieee80211 ( pd , offset + it_len , len , ld ) ;
2004-01-31 04:40:09 +00:00
}
2012-08-08 12:56:37 +00:00
static void
dissect_radiotap ( tvbuff_t * tvb , packet_info * pinfo , proto_tree * tree )
2004-01-31 04:40:09 +00:00
{
2012-11-27 14:34:27 +00:00
proto_tree * radiotap_tree = NULL ;
2013-05-11 02:02:31 +00:00
proto_tree * pt = NULL , * present_tree = NULL ;
2012-08-08 12:56:37 +00:00
proto_tree * ft ;
2012-11-27 14:34:27 +00:00
proto_item * ti = NULL ;
2012-08-08 12:56:37 +00:00
proto_item * hidden_item ;
2012-11-27 14:34:27 +00:00
int offset ;
tvbuff_t * next_tvb ;
guint8 version ;
guint length ;
2015-06-22 23:07:20 +00:00
guint16 cflags ;
2012-11-27 14:34:27 +00:00
guint32 freq ;
2012-08-08 12:56:37 +00:00
proto_item * rate_ti ;
2012-11-27 14:34:27 +00:00
gint8 dbm , db ;
2015-06-22 22:04:28 +00:00
gboolean have_rflags = FALSE ;
2012-11-27 14:34:27 +00:00
guint8 rflags = 0 ;
2015-06-22 23:07:20 +00:00
guint32 xcflags ;
2012-08-08 12:56:37 +00:00
/* backward compat with bit 14 == fcs in header */
2012-11-27 14:34:27 +00:00
proto_item * hdr_fcs_ti = NULL ;
int hdr_fcs_offset = 0 ;
guint32 sent_fcs = 0 ;
guint32 calc_fcs ;
gint err = - ENOENT ;
void * data ;
struct _radiotap_info * radiotap_info ;
static struct _radiotap_info rtp_info_arr ;
struct ieee80211_radiotap_iterator iter ;
2015-06-18 20:12:43 +00:00
struct ieee_802_11_phdr phdr ;
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
/* our non-standard overrides */
static struct radiotap_override overrides [ ] = {
{ IEEE80211_RADIOTAP_XCHANNEL , 4 , 8 } , /* xchannel */
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
/* keep last */
{ 14 , 4 , 4 } , /* FCS in header */
2010-10-13 21:30:27 +00:00
} ;
2012-08-08 12:56:37 +00:00
guint n_overrides = array_length ( overrides ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( ! radiotap_bit14_fcs )
n_overrides - - ;
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
radiotap_info = & rtp_info_arr ;
2011-01-27 17:45:45 +00:00
2015-06-18 20:12:43 +00:00
/* We don't have any 802.11 metadata yet. */
phdr . fcs_len = - 1 ;
phdr . decrypted = FALSE ;
2015-06-20 22:57:57 +00:00
phdr . datapad = FALSE ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_UNKNOWN ;
2015-06-18 20:12:43 +00:00
phdr . presence_flags = 0 ;
2012-08-08 12:56:37 +00:00
col_set_str ( pinfo - > cinfo , COL_PROTOCOL , " WLAN " ) ;
col_clear ( pinfo - > cinfo , COL_INFO ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
version = tvb_get_guint8 ( tvb , 0 ) ;
length = tvb_get_letohs ( tvb , 2 ) ;
2004-01-31 04:40:09 +00:00
2012-08-08 12:56:37 +00:00
radiotap_info - > radiotap_length = length ;
2006-10-25 15:16:49 +00:00
2012-08-08 12:56:37 +00:00
col_add_fstr ( pinfo - > cinfo , COL_INFO , " Radiotap Capture v%u, Length %u " ,
version , length ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Dissect the packet */
if ( tree ) {
ti = proto_tree_add_protocol_format ( tree , proto_radiotap ,
tvb , 0 , length ,
" Radiotap Header v%u, Length %u " ,
version , length ) ;
radiotap_tree = proto_item_add_subtree ( ti , ett_radiotap ) ;
proto_tree_add_uint ( radiotap_tree , hf_radiotap_version ,
tvb , 0 , 1 , version ) ;
proto_tree_add_item ( radiotap_tree , hf_radiotap_pad ,
tvb , 1 , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_uint ( radiotap_tree , hf_radiotap_length ,
tvb , 2 , 2 , length ) ;
}
2010-10-13 21:30:27 +00:00
2013-09-22 15:50:55 +00:00
data = tvb_memdup ( wmem_packet_scope ( ) , tvb , 0 , length ) ;
2012-08-08 12:56:37 +00:00
if ( ! data )
return ;
2010-10-13 21:30:27 +00:00
2013-03-17 16:48:47 +00:00
if ( ieee80211_radiotap_iterator_init ( & iter , ( struct ieee80211_radiotap_header * ) data , length , NULL ) ) {
2012-08-08 12:56:37 +00:00
if ( tree )
proto_item_append_text ( ti , " (invalid) " ) ;
/* maybe the length was correct anyway ... */
goto hand_off_to_80211 ;
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
iter . overrides = overrides ;
iter . n_overrides = n_overrides ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Add the "present flags" bitmaps. */
if ( tree ) {
2012-11-27 14:34:27 +00:00
guchar * bmap_start = ( guchar * ) data + 4 ;
guint n_bitmaps = ( guint ) ( iter . this_arg - bmap_start ) / 4 ;
guint i ;
gboolean rtap_ns ;
gboolean rtap_ns_next = TRUE ;
guint rtap_ns_offset ;
guint rtap_ns_offset_next = 0 ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
pt = proto_tree_add_item ( radiotap_tree , hf_radiotap_present ,
tvb , 4 , n_bitmaps * 4 ,
ENC_NA ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
for ( i = 0 ; i < n_bitmaps ; i + + ) {
2013-11-29 18:59:06 +00:00
guint32 bmap = pletoh32 ( bmap_start + 4 * i ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
rtap_ns_offset = rtap_ns_offset_next ;
rtap_ns_offset_next + = 32 ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
present_tree =
proto_item_add_subtree ( pt , ett_radiotap_present ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
offset = 4 * i ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
rtap_ns = rtap_ns_next ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Evaluate what kind of namespaces will come next */
if ( bmap & BIT ( IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE ) ) {
rtap_ns_next = TRUE ;
rtap_ns_offset_next = 0 ;
}
if ( bmap & BIT ( IEEE80211_RADIOTAP_VENDOR_NAMESPACE ) )
rtap_ns_next = FALSE ;
if ( ( bmap & ( BIT ( IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE ) |
BIT ( IEEE80211_RADIOTAP_VENDOR_NAMESPACE ) ) )
= = ( BIT ( IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE ) |
2013-05-10 23:21:42 +00:00
BIT ( IEEE80211_RADIOTAP_VENDOR_NAMESPACE ) ) ) {
2013-09-09 00:44:09 +00:00
expert_add_info_format ( pinfo , pt , & ei_radiotap_present ,
2013-05-10 23:21:42 +00:00
" Both radiotap and vendor namespace specified in bitmask word %u " ,
i ) ;
2012-08-08 12:56:37 +00:00
goto malformed ;
2013-05-10 23:21:42 +00:00
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( ! rtap_ns )
goto always_bits ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Currently, we don't know anything about bits >= 32 */
if ( rtap_ns_offset )
goto always_bits ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( present_tree ,
hf_radiotap_present_tsft , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_flags , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_rate , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_channel , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_fhss , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_dbm_antsignal ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_dbm_antnoise ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_lock_quality ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_tx_attenuation ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_db_tx_attenuation ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_dbm_tx_power ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_antenna , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_db_antsignal ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_db_antnoise ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
if ( radiotap_bit14_fcs ) {
proto_tree_add_item ( present_tree ,
hf_radiotap_present_hdrfcs ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
} else {
proto_tree_add_item ( present_tree ,
hf_radiotap_present_rxflags ,
tvb , offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
}
proto_tree_add_item ( present_tree ,
hf_radiotap_present_xchannel , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( present_tree ,
hf_radiotap_present_mcs , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_ampdu , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
2012-09-18 20:46:05 +00:00
proto_tree_add_item ( present_tree ,
hf_radiotap_present_vht , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
2012-08-08 12:56:37 +00:00
ti = proto_tree_add_item ( present_tree ,
hf_radiotap_present_reserved , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
/* Check if Reserved/Not Defined is not "zero" */
if ( bmap & IEEE80211_RADIOTAP_NOTDEFINED )
{
2013-09-02 23:32:31 +00:00
expert_add_info ( pinfo , pt , & ei_radiotap_present_reserved ) ;
2012-08-08 12:56:37 +00:00
}
always_bits :
proto_tree_add_item ( present_tree ,
hf_radiotap_present_rtap_ns , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_vendor_ns , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( present_tree ,
hf_radiotap_present_ext , tvb ,
offset + 4 , 4 , ENC_LITTLE_ENDIAN ) ;
}
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
while ( ! ( err = ieee80211_radiotap_iterator_next ( & iter ) ) ) {
offset = ( int ) ( ( guchar * ) iter . this_arg - ( guchar * ) data ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( iter . this_arg_index = = IEEE80211_RADIOTAP_VENDOR_NAMESPACE
& & tree ) {
proto_tree * vt , * ven_tree = NULL ;
const gchar * manuf_name ;
guint8 subns ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
manuf_name = tvb_get_manuf_name ( tvb , offset ) ;
subns = tvb_get_guint8 ( tvb , offset + 3 ) ;
2010-10-13 21:30:27 +00:00
2013-09-29 18:19:29 +00:00
vt = proto_tree_add_bytes_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_vendor_ns ,
tvb , offset ,
iter . this_arg_size ,
NULL ,
2013-09-29 18:19:29 +00:00
" %s-%d " ,
2012-08-08 12:56:37 +00:00
manuf_name , subns ) ;
ven_tree = proto_item_add_subtree ( vt , ett_radiotap_vendor ) ;
2013-09-29 18:19:29 +00:00
proto_tree_add_bytes_format_value ( ven_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_ven_oui , tvb ,
offset , 3 , NULL ,
2013-09-29 18:19:29 +00:00
" %s " , manuf_name ) ;
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( ven_tree , hf_radiotap_ven_subns ,
tvb , offset + 3 , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( ven_tree , hf_radiotap_ven_skip , tvb ,
offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( ven_tree , hf_radiotap_ven_data , tvb ,
offset + 6 , iter . this_arg_size - 6 ,
ENC_NA ) ;
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( ! iter . is_radiotap_ns )
continue ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
switch ( iter . this_arg_index ) {
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_TSFT :
radiotap_info - > tsft = tvb_get_letoh64 ( tvb , offset ) ;
2015-06-20 22:57:57 +00:00
phdr . tsf_timestamp = radiotap_info - > tsft ;
phdr . presence_flags | = PHDR_802_11_HAS_TSF_TIMESTAMP ;
2012-08-08 12:56:37 +00:00
if ( tree ) {
proto_tree_add_uint64 ( radiotap_tree ,
hf_radiotap_mactime , tvb ,
offset , 8 ,
radiotap_info - > tsft ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_FLAGS : {
rflags = tvb_get_guint8 ( tvb , offset ) ;
2015-06-22 22:04:28 +00:00
have_rflags = TRUE ;
2015-06-20 22:57:57 +00:00
if ( rflags & IEEE80211_RADIOTAP_F_DATAPAD )
phdr . datapad = TRUE ;
2015-06-18 20:12:43 +00:00
if ( rflags & IEEE80211_RADIOTAP_F_FCS )
phdr . fcs_len = 4 ;
else
phdr . fcs_len = 0 ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . short_preamble = ( rflags & IEEE80211_RADIOTAP_F_SHORTPRE ) ! = 0 ;
2015-06-18 20:12:43 +00:00
2012-08-08 12:56:37 +00:00
if ( tree ) {
2012-11-27 14:34:27 +00:00
proto_tree * flags_tree ;
2012-08-08 12:56:37 +00:00
ft = proto_tree_add_item ( radiotap_tree ,
hf_radiotap_flags ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
flags_tree =
proto_item_add_subtree ( ft ,
ett_radiotap_flags ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_cfp ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_preamble ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_wep ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_frag ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_fcs ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_datapad ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_badfcs ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( flags_tree ,
hf_radiotap_flags_shortgi ,
tvb , offset , 1 , ENC_BIG_ENDIAN ) ;
}
break ;
}
2010-10-13 21:30:27 +00:00
2012-11-27 14:34:27 +00:00
case IEEE80211_RADIOTAP_RATE : {
guint32 rate ;
2012-08-08 12:56:37 +00:00
rate = tvb_get_guint8 ( tvb , offset ) ;
/*
* XXX On FreeBSD rate & 0x80 means we have an MCS . On
* Linux and AirPcap it does not . ( What about
* Mac OS X , NetBSD , OpenBSD , and DragonFly BSD ? )
*
* This is an issue either for proprietary extensions
* to 11 a or 11 g , which do exist , or for 11 n
* implementations that stuff a rate value into
* this field , which also appear to exist .
*
* We currently handle that by assuming that
* if the 0x80 bit is set * and * the remaining
* bits have a value between 0 and 15 it ' s
* an MCS value , otherwise it ' s a rate . If
* there are cases where systems that use
* " 0x80 + MCS index " for MCS indices > 15 ,
* or stuff a rate value here between 64 and
* 71.5 Mb / s in here , we ' ll need a preference
* setting . Such rates do exist , e . g . 11 n
* MCS 7 at 20 MHz with a long guard interval .
*/
if ( rate > = 0x80 & & rate < = 0x8f ) {
/*
* XXX - we don ' t know the channel width
* or guard interval length , so we can ' t
* convert this to a data rate .
*
* If you want us to show a data rate ,
* use the MCS field , not the Rate field ;
* the MCS field includes not only the
* MCS index , it also includes bandwidth
* and guard interval information .
*
* XXX - can we get the channel width
* from XChannel and the guard interval
* information from Flags , at least on
* FreeBSD ?
*/
if ( tree ) {
proto_tree_add_uint ( radiotap_tree ,
hf_radiotap_mcs_index ,
tvb , offset , 1 ,
rate & 0x7f ) ;
}
} else {
col_add_fstr ( pinfo - > cinfo , COL_TX_RATE , " %d.%d " ,
rate / 2 , rate & 1 ? 5 : 0 ) ;
if ( tree ) {
proto_tree_add_float_format ( radiotap_tree ,
hf_radiotap_datarate ,
tvb , offset , 1 ,
( float ) rate / 2 ,
" Data Rate: %.1f Mb/s " ,
( float ) rate / 2 ) ;
}
radiotap_info - > rate = rate ;
2015-06-20 22:57:57 +00:00
phdr . presence_flags | = PHDR_802_11_HAS_DATA_RATE ;
phdr . data_rate = rate ;
2012-08-08 12:56:37 +00:00
}
break ;
2012-11-27 14:34:27 +00:00
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_CHANNEL : {
2015-06-22 23:07:20 +00:00
freq = tvb_get_letohs ( tvb , offset ) ;
2015-06-20 22:57:57 +00:00
if ( freq ! = 0 ) {
/*
* XXX - some captures have 0 , which is
* obviously bogus .
*/
phdr . presence_flags | = PHDR_802_11_HAS_FREQUENCY ;
phdr . frequency = freq ;
}
2015-06-22 23:07:20 +00:00
cflags = tvb_get_letohs ( tvb , offset + 2 ) ;
switch ( cflags & IEEE80211_CHAN_ALLTURBO ) {
2015-06-22 22:04:28 +00:00
case IEEE80211_CHAN_FHSS :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11_FHSS ;
phdr . phy_info . info_11_fhss . presence_flags = 0 ;
break ;
case IEEE80211_CHAN_DSSS :
phdr . phy = PHDR_802_11_PHY_11_DSSS ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_A :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11A ;
phdr . phy_info . info_11a . presence_flags = PHDR_802_11A_HAS_TURBO_TYPE ;
phdr . phy_info . info_11a . turbo_type = PHDR_802_11A_TURBO_TYPE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_B :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11B ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_PUREG :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_G :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_108A :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11A ;
phdr . phy_info . info_11a . presence_flags = PHDR_802_11A_HAS_TURBO_TYPE ;
/* We assume non-STURBO is dynamic turbo */
phdr . phy_info . info_11a . turbo_type = PHDR_802_11A_TURBO_TYPE_DYNAMIC_TURBO ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_108PUREG :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_SUPER_G ;
2015-06-22 22:04:28 +00:00
break ;
}
2012-08-08 12:56:37 +00:00
if ( tree ) {
2012-11-27 14:34:27 +00:00
gchar * chan_str ;
2014-11-30 17:51:30 +00:00
static const int * channel_flags [ ] = {
& hf_radiotap_channel_flags_turbo ,
& hf_radiotap_channel_flags_cck ,
& hf_radiotap_channel_flags_ofdm ,
& hf_radiotap_channel_flags_2ghz ,
& hf_radiotap_channel_flags_5ghz ,
& hf_radiotap_channel_flags_passive ,
& hf_radiotap_channel_flags_dynamic ,
& hf_radiotap_channel_flags_gfsk ,
& hf_radiotap_channel_flags_gsm ,
& hf_radiotap_channel_flags_sturbo ,
& hf_radiotap_channel_flags_half ,
& hf_radiotap_channel_flags_quarter ,
NULL
} ;
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
chan_str = ieee80211_mhz_to_str ( freq ) ;
col_add_fstr ( pinfo - > cinfo ,
COL_FREQ_CHAN , " %s " , chan_str ) ;
2013-09-15 01:48:30 +00:00
proto_tree_add_uint_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_channel_frequency ,
tvb , offset , 2 , freq ,
2013-09-15 01:48:30 +00:00
" %s " ,
2012-08-08 12:56:37 +00:00
chan_str ) ;
g_free ( chan_str ) ;
2014-11-30 17:51:30 +00:00
2012-08-08 12:56:37 +00:00
/* We're already 2-byte aligned. */
2014-11-30 17:51:30 +00:00
proto_tree_add_bitmask ( radiotap_tree , tvb , offset + 2 , hf_radiotap_channel_flags , ett_radiotap_channel_flags , channel_flags , ENC_LITTLE_ENDIAN ) ;
2012-08-08 12:56:37 +00:00
radiotap_info - > freq = freq ;
2015-06-22 23:07:20 +00:00
radiotap_info - > flags = cflags ;
2012-08-08 12:56:37 +00:00
}
break ;
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_FHSS :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
/*
* Just in case we didn ' t have a Channel field or
* it said this was something other than 11 legacy
* FHSS .
*/
phdr . phy = PHDR_802_11_PHY_11_FHSS ;
phdr . phy_info . info_11_fhss . presence_flags =
PHDR_802_11_FHSS_HAS_HOP_SET |
PHDR_802_11_FHSS_HAS_HOP_PATTERN ;
phdr . phy_info . info_11_fhss . hop_set = tvb_get_guint8 ( tvb , offset ) ;
phdr . phy_info . info_11_fhss . hop_pattern = tvb_get_guint8 ( tvb , offset + 1 ) ;
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( radiotap_tree ,
hf_radiotap_fhss_hopset , tvb ,
offset , 1 , ENC_BIG_ENDIAN ) ;
proto_tree_add_item ( radiotap_tree ,
hf_radiotap_fhss_pattern , tvb ,
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
offset + 1 , 1 , ENC_BIG_ENDIAN ) ;
2012-08-08 12:56:37 +00:00
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DBM_ANTSIGNAL :
2012-11-27 14:34:27 +00:00
dbm = ( gint8 ) tvb_get_guint8 ( tvb , offset ) ;
2015-06-24 00:18:45 +00:00
phdr . presence_flags | = PHDR_802_11_HAS_SIGNAL_DBM ;
phdr . signal_dbm = dbm ;
2012-08-08 12:56:37 +00:00
col_add_fstr ( pinfo - > cinfo , COL_RSSI , " %d dBm " , dbm ) ;
2013-09-30 16:10:40 +00:00
proto_tree_add_int_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_dbm_antsignal ,
tvb , offset , 1 , dbm ,
2013-09-30 16:10:40 +00:00
" %d dBm " ,
2012-08-08 12:56:37 +00:00
dbm ) ;
radiotap_info - > dbm_antsignal = dbm ;
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DBM_ANTNOISE :
dbm = ( gint8 ) tvb_get_guint8 ( tvb , offset ) ;
2015-06-24 00:18:45 +00:00
phdr . presence_flags | = PHDR_802_11_HAS_NOISE_DBM ;
phdr . noise_dbm = dbm ;
2012-08-08 12:56:37 +00:00
if ( tree ) {
2013-09-30 16:10:40 +00:00
proto_tree_add_int_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_dbm_antnoise ,
tvb , offset , 1 , dbm ,
2013-09-30 16:10:40 +00:00
" %d dBm " ,
2012-08-08 12:56:37 +00:00
dbm ) ;
}
radiotap_info - > dbm_antnoise = dbm ;
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_LOCK_QUALITY :
if ( tree ) {
proto_tree_add_uint ( radiotap_tree ,
hf_radiotap_quality , tvb ,
offset , 2 ,
tvb_get_letohs ( tvb ,
offset ) ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_TX_ATTENUATION :
proto_tree_add_item ( radiotap_tree ,
hf_radiotap_tx_attenuation , tvb ,
offset , 2 , ENC_BIG_ENDIAN ) ;
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DB_TX_ATTENUATION :
proto_tree_add_item ( radiotap_tree ,
hf_radiotap_db_tx_attenuation , tvb ,
offset , 2 , ENC_BIG_ENDIAN ) ;
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DBM_TX_POWER :
if ( tree ) {
proto_tree_add_int ( radiotap_tree ,
hf_radiotap_txpower , tvb ,
offset , 1 ,
tvb_get_guint8 ( tvb , offset ) ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_ANTENNA :
if ( tree ) {
proto_tree_add_uint ( radiotap_tree ,
hf_radiotap_antenna , tvb ,
offset , 1 ,
tvb_get_guint8 ( tvb ,
offset ) ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DB_ANTSIGNAL :
db = tvb_get_guint8 ( tvb , offset ) ;
col_add_fstr ( pinfo - > cinfo , COL_RSSI , " %u dB " , db ) ;
if ( tree ) {
2013-09-16 10:39:06 +00:00
proto_tree_add_uint_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_db_antsignal ,
tvb , offset , 1 , db ,
2013-09-16 10:39:06 +00:00
" %u dB " ,
2012-08-08 12:56:37 +00:00
db ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_DB_ANTNOISE :
db = tvb_get_guint8 ( tvb , offset ) ;
if ( tree ) {
2013-09-16 10:39:06 +00:00
proto_tree_add_uint_format_value ( radiotap_tree ,
2012-08-08 12:56:37 +00:00
hf_radiotap_db_antnoise ,
tvb , offset , 1 , db ,
2013-09-16 10:39:06 +00:00
" %u dB " ,
2012-08-08 12:56:37 +00:00
db ) ;
}
break ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_RX_FLAGS : {
if ( radiotap_bit14_fcs ) {
if ( tree ) {
2012-11-27 14:34:27 +00:00
sent_fcs = tvb_get_ntohl ( tvb , offset ) ;
2012-08-08 12:56:37 +00:00
hdr_fcs_ti = proto_tree_add_uint ( radiotap_tree ,
hf_radiotap_fcs , tvb ,
offset , 4 , sent_fcs ) ;
hdr_fcs_offset = offset ;
}
} else {
2014-11-30 17:51:30 +00:00
static const int * rxflags [ ] = {
& hf_radiotap_rxflags_badplcp ,
NULL
} ;
2010-10-13 21:30:27 +00:00
2014-11-30 17:51:30 +00:00
proto_tree_add_bitmask ( radiotap_tree , tvb , offset , hf_radiotap_rxflags , ett_radiotap_rxflags , rxflags , ENC_LITTLE_ENDIAN ) ;
2012-08-08 12:56:37 +00:00
}
break ;
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
case IEEE80211_RADIOTAP_XCHANNEL : {
2015-06-22 23:07:20 +00:00
xcflags = tvb_get_letohl ( tvb , offset ) ;
switch ( xcflags & IEEE80211_CHAN_ALLTURBO ) {
2015-06-22 22:04:28 +00:00
case IEEE80211_CHAN_FHSS :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
/*
* Don ' t overwrite any FHSS information
* we ' ve seen before this .
*/
if ( phdr . phy ! = PHDR_802_11_PHY_11_FHSS ) {
phdr . phy = PHDR_802_11_PHY_11_FHSS ;
phdr . phy_info . info_11_fhss . presence_flags = 0 ;
}
break ;
case IEEE80211_CHAN_DSSS :
phdr . phy = PHDR_802_11_PHY_11_DSSS ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_A :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11A ;
phdr . phy_info . info_11a . presence_flags = PHDR_802_11A_HAS_TURBO_TYPE ;
phdr . phy_info . info_11a . turbo_type = PHDR_802_11A_TURBO_TYPE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_B :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11B ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_PUREG :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_G :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_NORMAL ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_108A :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11A ;
phdr . phy_info . info_11a . presence_flags = PHDR_802_11A_HAS_TURBO_TYPE ;
/* We assume non-STURBO is dynamic turbo */
phdr . phy_info . info_11a . turbo_type = PHDR_802_11A_TURBO_TYPE_DYNAMIC_TURBO ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_108PUREG :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11G ;
phdr . presence_flags | = PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11g . presence_flags = PHDR_802_11G_HAS_MODE ;
phdr . phy_info . info_11g . mode = PHDR_802_11G_MODE_SUPER_G ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_ST :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11A ;
phdr . phy_info . info_11a . presence_flags = PHDR_802_11A_HAS_TURBO_TYPE ;
phdr . phy_info . info_11a . turbo_type = PHDR_802_11A_TURBO_TYPE_STATIC_TURBO ;
2015-06-22 22:04:28 +00:00
break ;
case IEEE80211_CHAN_A | IEEE80211_CHAN_HT20 :
case IEEE80211_CHAN_A | IEEE80211_CHAN_HT40D :
case IEEE80211_CHAN_A | IEEE80211_CHAN_HT40U :
case IEEE80211_CHAN_G | IEEE80211_CHAN_HT20 :
case IEEE80211_CHAN_G | IEEE80211_CHAN_HT40U :
case IEEE80211_CHAN_G | IEEE80211_CHAN_HT40D :
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy = PHDR_802_11_PHY_11N ;
/* 11n only has "short preamble" in 11b/11g mode */
phdr . presence_flags & = ~ PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11n . presence_flags = 0 ;
2015-06-22 22:04:28 +00:00
/*
* This doesn ' t supply " short GI " information ,
* so use the 0x80 bit in the Flags field ,
* if we have it ; it ' s " Currently unspecified
* but used " for that purpose, according to
* the radiotap . org page for that field .
*/
2015-06-22 23:16:23 +00:00
if ( have_rflags ) {
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_SHORT_GI ;
2015-06-22 23:16:23 +00:00
if ( rflags & 0x80 )
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . short_gi = 1 ;
2015-06-22 23:16:23 +00:00
else
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . short_gi = 0 ;
2015-06-22 23:16:23 +00:00
}
2015-06-22 22:04:28 +00:00
break ;
}
2015-06-22 23:07:20 +00:00
freq = tvb_get_letohs ( tvb , offset + 4 ) ;
if ( freq ! = 0 ) {
/*
* XXX - some captures have 0 , which is
* obviously bogus .
*/
phdr . presence_flags | = PHDR_802_11_HAS_FREQUENCY ;
phdr . frequency = freq ;
}
phdr . presence_flags | = PHDR_802_11_HAS_CHANNEL ;
phdr . channel = tvb_get_guint8 ( tvb , offset + 6 ) ;
2015-06-22 22:04:28 +00:00
if ( tree ) {
static const int * xchannel_flags [ ] = {
& hf_radiotap_xchannel_flags_turbo ,
& hf_radiotap_xchannel_flags_cck ,
& hf_radiotap_xchannel_flags_ofdm ,
& hf_radiotap_xchannel_flags_2ghz ,
& hf_radiotap_xchannel_flags_5ghz ,
& hf_radiotap_xchannel_flags_passive ,
& hf_radiotap_xchannel_flags_dynamic ,
& hf_radiotap_xchannel_flags_gfsk ,
& hf_radiotap_xchannel_flags_gsm ,
& hf_radiotap_xchannel_flags_sturbo ,
& hf_radiotap_xchannel_flags_half ,
& hf_radiotap_xchannel_flags_quarter ,
& hf_radiotap_xchannel_flags_ht20 ,
& hf_radiotap_xchannel_flags_ht40u ,
& hf_radiotap_xchannel_flags_ht40d ,
NULL
} ;
proto_tree_add_item ( radiotap_tree ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
hf_radiotap_xchannel_channel ,
2015-06-22 22:04:28 +00:00
tvb , offset + 6 , 1 ,
ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( radiotap_tree ,
hf_radiotap_xchannel_frequency ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_bitmask ( radiotap_tree , tvb , offset , hf_radiotap_xchannel_flags , ett_radiotap_xchannel_flags , xchannel_flags , ENC_LITTLE_ENDIAN ) ;
2014-11-30 17:51:30 +00:00
2012-08-08 08:16:34 +00:00
2012-08-08 12:56:37 +00:00
#if 0
2015-06-22 22:04:28 +00:00
proto_tree_add_uint ( radiotap_tree ,
hf_radiotap_xchannel_maxpower ,
tvb , offset + 7 , 1 , maxpower ) ;
2012-08-08 12:56:37 +00:00
# endif
2015-06-22 22:04:28 +00:00
}
2012-08-08 12:56:37 +00:00
break ;
}
case IEEE80211_RADIOTAP_MCS : {
2014-11-30 17:51:30 +00:00
proto_tree * mcs_tree = NULL ;
2012-11-27 14:34:27 +00:00
guint8 mcs_known , mcs_flags ;
guint8 mcs ;
guint bandwidth ;
guint gi_length ;
gboolean can_calculate_rate ;
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/*
* Start out assuming that we can calculate the rate ;
* if we are missing any of the MCS index , channel
* width , or guard interval length , we can ' t .
*/
can_calculate_rate = TRUE ;
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
mcs_known = tvb_get_guint8 ( tvb , offset ) ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
/*
* If there ' s actually any data here , not an
* empty field , this is 802.11 n .
*/
if ( mcs_known ! = 0 ) {
phdr . phy = PHDR_802_11_PHY_11N ;
/* 11n only has "short preamble" in 11b/11g mode */
phdr . presence_flags & = ~ PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11n . presence_flags = 0 ;
}
2012-08-08 12:56:37 +00:00
mcs_flags = tvb_get_guint8 ( tvb , offset + 1 ) ;
2015-06-20 22:57:57 +00:00
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_MCS ) {
mcs = tvb_get_guint8 ( tvb , offset + 2 ) ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_MCS_INDEX ;
phdr . phy_info . info_11n . mcs_index = mcs ;
2015-06-20 22:57:57 +00:00
} else {
mcs = 0 ;
can_calculate_rate = FALSE ; /* no MCS index */
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_BW ) {
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_BANDWIDTH ;
phdr . phy_info . info_11n . bandwidth = ( mcs_flags & IEEE80211_RADIOTAP_MCS_BW_MASK ) ;
2015-06-20 22:57:57 +00:00
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_GI ) {
gi_length = ( mcs_flags & IEEE80211_RADIOTAP_MCS_SGI ) ?
1 : 0 ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_SHORT_GI ;
phdr . phy_info . info_11n . short_gi = ( gi_length = = 0 ) ;
2015-06-20 22:57:57 +00:00
} else {
gi_length = 0 ;
can_calculate_rate = FALSE ; /* no GI width */
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_FMT ) {
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_GREENFIELD ;
phdr . phy_info . info_11n . greenfield = ( mcs_flags & IEEE80211_RADIOTAP_MCS_FMT_GF ) ! = 0 ;
2015-06-20 22:57:57 +00:00
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_FEC ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_FEC ;
phdr . phy_info . info_11n . fec = ( mcs_flags & IEEE80211_RADIOTAP_MCS_FEC_LDPC ) ? 1 : 0 ;
2015-06-20 22:57:57 +00:00
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_STBC ) {
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_STBC_STREAMS ;
phdr . phy_info . info_11n . stbc_streams = ( mcs_flags & IEEE80211_RADIOTAP_MCS_STBC_MASK ) > > IEEE80211_RADIOTAP_MCS_STBC_SHIFT ;
2015-06-20 22:57:57 +00:00
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_NESS ) {
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . presence_flags | = PHDR_802_11N_HAS_NESS ;
2015-06-20 22:57:57 +00:00
/* This is stored a bit weirdly */
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11n . ness =
2015-06-20 22:57:57 +00:00
( ( mcs_known & IEEE80211_RADIOTAP_MCS_NESS_BIT1 ) > > 6 ) |
( ( mcs_flags & IEEE80211_RADIOTAP_MCS_NESS_BIT0 ) > > 7 ) ;
}
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
if ( tree ) {
2012-11-27 14:34:27 +00:00
proto_item * it ;
2015-06-20 22:23:35 +00:00
static const int * mcs_haves_with_ness_bit1 [ ] = {
2014-11-30 17:51:30 +00:00
& hf_radiotap_mcs_have_bw ,
& hf_radiotap_mcs_have_index ,
& hf_radiotap_mcs_have_gi ,
& hf_radiotap_mcs_have_format ,
& hf_radiotap_mcs_have_fec ,
& hf_radiotap_mcs_have_stbc ,
2015-06-20 22:23:35 +00:00
& hf_radiotap_mcs_have_ness ,
& hf_radiotap_mcs_ness_bit1 ,
NULL
} ;
static const int * mcs_haves_without_ness_bit1 [ ] = {
& hf_radiotap_mcs_have_bw ,
& hf_radiotap_mcs_have_index ,
& hf_radiotap_mcs_have_gi ,
& hf_radiotap_mcs_have_format ,
& hf_radiotap_mcs_have_fec ,
& hf_radiotap_mcs_have_stbc ,
& hf_radiotap_mcs_have_ness ,
2014-11-30 17:51:30 +00:00
NULL
} ;
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
it = proto_tree_add_item ( radiotap_tree , hf_radiotap_mcs ,
tvb , offset , 3 , ENC_NA ) ;
mcs_tree = proto_item_add_subtree ( it , ett_radiotap_mcs ) ;
2014-11-30 17:51:30 +00:00
2015-06-20 22:23:35 +00:00
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_NESS )
proto_tree_add_bitmask ( mcs_tree , tvb , offset , hf_radiotap_mcs_known , ett_radiotap_mcs_known , mcs_haves_with_ness_bit1 , ENC_LITTLE_ENDIAN ) ;
else
proto_tree_add_bitmask ( mcs_tree , tvb , offset , hf_radiotap_mcs_known , ett_radiotap_mcs_known , mcs_haves_without_ness_bit1 , ENC_LITTLE_ENDIAN ) ;
2012-08-08 12:56:37 +00:00
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_BW ) {
bandwidth = ( ( mcs_flags & IEEE80211_RADIOTAP_MCS_BW_MASK ) = = IEEE80211_RADIOTAP_MCS_BW_40 ) ?
1 : 0 ;
2014-11-30 17:51:30 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_bw ,
2012-08-08 12:56:37 +00:00
tvb , offset + 1 , 1 , mcs_flags ) ;
} else {
bandwidth = 0 ;
can_calculate_rate = FALSE ; /* no bandwidth */
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_GI ) {
2014-11-30 17:51:30 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_gi ,
2012-08-08 12:56:37 +00:00
tvb , offset + 1 , 1 , mcs_flags ) ;
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_FMT ) {
2014-11-30 17:51:30 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_format ,
2012-08-08 12:56:37 +00:00
tvb , offset + 1 , 1 , mcs_flags ) ;
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_FEC ) {
2014-11-30 17:51:30 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_fec ,
2012-08-08 12:56:37 +00:00
tvb , offset + 1 , 1 , mcs_flags ) ;
}
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_STBC ) {
2015-06-18 02:08:13 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_stbc ,
2012-08-08 12:56:37 +00:00
tvb , offset + 1 , 1 , mcs_flags ) ;
}
2015-06-20 22:23:35 +00:00
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_NESS ) {
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_ness_bit0 ,
tvb , offset + 1 , 1 , mcs_flags ) ;
}
2012-08-08 12:56:37 +00:00
if ( mcs_known & IEEE80211_RADIOTAP_MCS_HAVE_MCS ) {
2014-11-30 17:51:30 +00:00
proto_tree_add_uint ( mcs_tree , hf_radiotap_mcs_index ,
2012-08-08 12:56:37 +00:00
tvb , offset + 2 , 1 , mcs ) ;
2015-06-20 22:57:57 +00:00
}
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/*
* If we have the MCS index , channel width , and
* guard interval length , and the MCS index is
* valid , we can compute the rate . If the resulting
* rate is non - zero , report it . ( If it ' s zero ,
* it ' s an MCS / channel width / GI combination that
* 802.11 n doesn ' t support . )
*/
if ( can_calculate_rate & & mcs < = MAX_MCS_INDEX
& & ieee80211_float_htrates [ mcs ] [ bandwidth ] [ gi_length ] ! = 0.0 ) {
col_add_fstr ( pinfo - > cinfo , COL_TX_RATE , " %.1f " ,
ieee80211_float_htrates [ mcs ] [ bandwidth ] [ gi_length ] ) ;
if ( tree ) {
rate_ti = proto_tree_add_float_format ( radiotap_tree ,
hf_radiotap_datarate ,
tvb , offset , 3 ,
ieee80211_float_htrates [ mcs ] [ bandwidth ] [ gi_length ] ,
" Data Rate: %.1f Mb/s " ,
ieee80211_float_htrates [ mcs ] [ bandwidth ] [ gi_length ] ) ;
PROTO_ITEM_SET_GENERATED ( rate_ti ) ;
}
}
break ;
}
case IEEE80211_RADIOTAP_AMPDU_STATUS : {
proto_item * it ;
proto_tree * ampdu_tree = NULL , * ampdu_flags_tree ;
2015-06-22 22:04:28 +00:00
guint16 ampdu_flags ;
2012-11-27 14:34:27 +00:00
2015-06-22 22:04:28 +00:00
ampdu_flags = tvb_get_letohs ( tvb , offset + 4 ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( tree ) {
it = proto_tree_add_item ( radiotap_tree , hf_radiotap_ampdu ,
tvb , offset , 8 , ENC_NA ) ;
ampdu_tree = proto_item_add_subtree ( it , ett_radiotap_ampdu ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
proto_tree_add_item ( ampdu_tree , hf_radiotap_ampdu_ref ,
tvb , offset , 4 , ENC_LITTLE_ENDIAN ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
it = proto_tree_add_item ( ampdu_tree , hf_radiotap_ampdu_flags ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
ampdu_flags_tree = proto_item_add_subtree ( it , ett_radiotap_ampdu_flags ) ;
proto_tree_add_item ( ampdu_flags_tree , hf_radiotap_ampdu_flags_report_zerolen ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( ampdu_flags_tree , hf_radiotap_ampdu_flags_is_zerolen ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( ampdu_flags_tree , hf_radiotap_ampdu_flags_last_known ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( ampdu_flags_tree , hf_radiotap_ampdu_flags_is_last ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( ampdu_flags_tree , hf_radiotap_ampdu_flags_delim_crc_error ,
tvb , offset + 4 , 2 , ENC_LITTLE_ENDIAN ) ;
}
2015-06-22 22:04:28 +00:00
if ( ampdu_flags & IEEE80211_RADIOTAP_AMPDU_DELIM_CRC_KNOWN ) {
2012-08-08 12:56:37 +00:00
if ( ampdu_tree )
proto_tree_add_item ( ampdu_tree , hf_radiotap_ampdu_delim_crc ,
tvb , offset + 6 , 1 , ENC_NA ) ;
}
break ;
}
2012-09-18 20:46:05 +00:00
case IEEE80211_RADIOTAP_VHT : {
proto_item * it , * it_root = NULL ;
2012-11-27 14:34:27 +00:00
proto_tree * vht_tree = NULL , * vht_known_tree = NULL , * user_tree = NULL ;
guint16 known , nsts ;
2015-06-22 22:04:28 +00:00
guint8 vht_flags , bw , mcs_nss ;
2012-11-27 14:34:27 +00:00
guint bandwidth = 0 ;
guint gi_length = 0 ;
guint nss = 0 ;
guint mcs = 0 ;
gboolean can_calculate_rate ;
guint i ;
2012-09-18 20:46:05 +00:00
/*
* Start out assuming that we can calculate the rate ;
* if we are missing any of the MCS index , channel
* width , or guard interval length , we can ' t .
*/
can_calculate_rate = TRUE ;
known = tvb_get_letohs ( tvb , offset ) ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
/*
* If there ' s actually any data here , not an
* empty field , this is 802.11 ac .
*/
if ( known ! = 0 ) {
phdr . phy = PHDR_802_11_PHY_11AC ;
phdr . presence_flags & = ~ PHDR_802_11_HAS_SHORT_PREAMBLE ;
phdr . phy_info . info_11ac . presence_flags = 0 ;
}
2015-06-22 22:04:28 +00:00
vht_flags = tvb_get_guint8 ( tvb , offset + 2 ) ;
2012-09-18 20:46:05 +00:00
if ( tree ) {
it_root = proto_tree_add_item ( radiotap_tree , hf_radiotap_vht ,
tvb , offset , 12 , ENC_NA ) ;
vht_tree = proto_item_add_subtree ( it_root , ett_radiotap_vht ) ;
it = proto_tree_add_item ( vht_tree , hf_radiotap_vht_known ,
tvb , offset , 2 , known ) ;
vht_known_tree = proto_item_add_subtree ( it , ett_radiotap_vht_known ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_stbc ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_txop_ps ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_gi ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_sgi_nsym_da ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_ldpc_extra ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_bf ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_bw ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_gid ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_item ( vht_known_tree , hf_radiotap_vht_have_p_aid ,
tvb , offset , 2 , ENC_LITTLE_ENDIAN ) ;
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_STBC ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_STBC ;
phdr . phy_info . info_11ac . stbc = ( vht_flags & IEEE80211_RADIOTAP_VHT_STBC ) ! = 0 ;
2012-09-18 20:46:05 +00:00
if ( vht_tree )
proto_tree_add_item ( vht_tree , hf_radiotap_vht_stbc ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_TXOP_PS ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_TXOP_PS_NOT_ALLOWED ;
phdr . phy_info . info_11ac . txop_ps_not_allowed = ( vht_flags & IEEE80211_RADIOTAP_VHT_TXOP_PS ) ! = 0 ;
2012-09-18 20:46:05 +00:00
if ( vht_tree )
proto_tree_add_item ( vht_tree , hf_radiotap_vht_txop_ps ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_GI ) {
2015-06-22 22:04:28 +00:00
gi_length = ( vht_flags & IEEE80211_RADIOTAP_VHT_SGI ) ? 1 : 0 ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_SHORT_GI ;
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . short_gi = gi_length ;
2012-09-18 20:46:05 +00:00
if ( vht_tree ) {
proto_tree_add_item ( vht_tree , hf_radiotap_vht_gi ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
}
} else {
can_calculate_rate = FALSE ; /* no GI width */
}
2013-08-19 00:11:50 +00:00
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_SGI_NSYM_DA ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_SHORT_GI_NSYM_DISAMBIG ;
phdr . phy_info . info_11ac . short_gi_nsym_disambig = ( vht_flags & IEEE80211_RADIOTAP_VHT_SGI_NSYM_DA ) ! = 0 ;
2013-08-19 00:11:50 +00:00
if ( vht_tree ) {
it = proto_tree_add_item ( vht_tree , hf_radiotap_vht_sgi_nsym_da ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
2015-06-22 22:04:28 +00:00
if ( ( vht_flags & IEEE80211_RADIOTAP_VHT_SGI_NSYM_DA ) & &
2013-08-19 00:11:50 +00:00
( known & IEEE80211_RADIOTAP_VHT_HAVE_GI ) & &
2015-06-22 22:04:28 +00:00
! ( vht_flags & IEEE80211_RADIOTAP_VHT_SGI ) )
2013-08-19 00:11:50 +00:00
proto_item_append_text ( it , " (invalid) " ) ;
}
}
2012-09-18 20:46:05 +00:00
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_LDPC_EXTRA ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_LDPC_EXTRA_OFDM_SYMBOL ;
phdr . phy_info . info_11ac . ldpc_extra_ofdm_symbol = ( vht_flags & IEEE80211_RADIOTAP_VHT_LDPC_EXTRA ) ! = 0 ;
2012-09-18 20:46:05 +00:00
if ( vht_tree ) {
proto_tree_add_item ( vht_tree , hf_radiotap_vht_ldpc_extra ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
}
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_BF ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_BEAMFORMED ;
phdr . phy_info . info_11ac . beamformed = ( vht_flags & IEEE80211_RADIOTAP_VHT_BF ) ! = 0 ;
2012-09-18 20:46:05 +00:00
if ( vht_tree )
proto_tree_add_item ( vht_tree , hf_radiotap_vht_bf ,
tvb , offset + 2 , 1 , ENC_LITTLE_ENDIAN ) ;
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_BW ) {
2015-06-22 22:04:28 +00:00
bw = tvb_get_guint8 ( tvb , offset + 3 ) & IEEE80211_RADIOTAP_VHT_BW_MASK ;
Clean up 802.11 radio information handling.
Have a field that holds the PHY type but nothing else. Have
a union with structures holding PHY-type-specific information, as a
bunch of attributes are PHY-specific.
If we have a channel and band, but don't have the frequency, attempt to
calculate the frequency, and add that to the radio information if we
succeed. If we have the frequency, but don't have the channel, attempt
to calculate the channel, and add that to the radio information if we
succeed.
Handle FHSS information, 11a "half/quarter-clocked" and turbo
information, 11g normal vs. Super G, additional 11n and 11ac
information, and the "short preamble" flag for 11b and 11g.
Add a PHY type for 11 legacy DSSS and detect it if possible.
Clean up the AVS dissector - make all fields wlancap. fields (if you
want generic fields, use the wlan_radio. fields).
Set more fields when writing out Commview Wi-Fi files.
Change-Id: I691ac59f5e9e1a23779b56a65124049914b72e69
Reviewed-on: https://code.wireshark.org/review/9146
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-25 19:14:39 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_BANDWIDTH ;
phdr . phy_info . info_11ac . bandwidth = bw ;
2013-06-20 22:21:24 +00:00
if ( bw < sizeof ( ieee80211_vht_bw2rate_index ) / sizeof ( ieee80211_vht_bw2rate_index [ 0 ] ) )
2012-09-18 20:46:05 +00:00
bandwidth = ieee80211_vht_bw2rate_index [ bw ] ;
else
can_calculate_rate = FALSE ; /* unknown bandwidth */
if ( vht_tree )
proto_tree_add_item ( vht_tree , hf_radiotap_vht_bw ,
tvb , offset + 3 , 1 , ENC_LITTLE_ENDIAN ) ;
} else {
can_calculate_rate = FALSE ; /* no bandwidth */
}
for ( i = 0 ; i < 4 ; i + + ) {
mcs_nss = tvb_get_guint8 ( tvb , offset + 4 + i ) ;
nss = ( mcs_nss & IEEE80211_RADIOTAP_VHT_NSS ) ;
mcs = ( mcs_nss & IEEE80211_RADIOTAP_VHT_MCS ) > > 4 ;
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . mcs [ i ] = mcs ;
phdr . phy_info . info_11ac . nss [ i ] = nss ;
2012-09-18 20:46:05 +00:00
2015-06-22 22:04:28 +00:00
if ( ( known & IEEE80211_RADIOTAP_VHT_HAVE_STBC ) & & ( vht_flags & IEEE80211_RADIOTAP_VHT_STBC ) )
2012-09-18 20:46:05 +00:00
nsts = 2 * nss ;
else
nsts = nss ;
if ( nss ) {
if ( vht_tree ) {
it = proto_tree_add_item ( vht_tree , hf_radiotap_vht_user ,
tvb , offset + 4 , 5 , ENC_NA ) ;
proto_item_append_text ( it , " %d: MCS %u " , i , mcs ) ;
user_tree = proto_item_add_subtree ( it , ett_radiotap_vht_user ) ;
it = proto_tree_add_item ( user_tree , hf_radiotap_vht_mcs [ i ] ,
tvb , offset + 4 + i , 1 ,
ENC_LITTLE_ENDIAN ) ;
if ( mcs > MAX_MCS_VHT_INDEX ) {
proto_item_append_text ( it , " (invalid) " ) ;
} else {
proto_item_append_text ( it , " (%s %s) " ,
ieee80211_vhtinfo [ mcs ] . modulation ,
ieee80211_vhtinfo [ mcs ] . coding_rate ) ;
}
proto_tree_add_item ( user_tree , hf_radiotap_vht_nss [ i ] ,
tvb , offset + 4 + i , 1 , ENC_LITTLE_ENDIAN ) ;
proto_tree_add_uint ( user_tree , hf_radiotap_vht_nsts [ i ] ,
tvb , offset + 4 + i , 1 , nsts ) ;
proto_tree_add_item ( user_tree , hf_radiotap_vht_coding [ i ] ,
tvb , offset + 8 , 1 , ENC_LITTLE_ENDIAN ) ;
}
2013-12-26 14:01:37 +00:00
if ( can_calculate_rate & & mcs < = MAX_MCS_VHT_INDEX ) {
2012-09-18 20:46:05 +00:00
float rate = ieee80211_vhtinfo [ mcs ] . rates [ bandwidth ] [ gi_length ] * nss ;
if ( rate ! = 0.0f & & user_tree ) {
rate_ti = proto_tree_add_float_format ( user_tree ,
hf_radiotap_vht_datarate [ i ] ,
tvb , offset , 12 , rate ,
" Data Rate: %.1f Mb/s " , rate ) ;
PROTO_ITEM_SET_GENERATED ( rate_ti ) ;
}
}
}
}
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . fec = tvb_get_guint8 ( tvb , offset + 8 ) ;
2012-09-18 20:46:05 +00:00
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_GID ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_GROUP_ID ;
phdr . phy_info . info_11ac . group_id = tvb_get_guint8 ( tvb , offset + 9 ) ;
2012-09-18 20:46:05 +00:00
if ( vht_tree )
proto_tree_add_item ( vht_tree , hf_radiotap_vht_gid ,
tvb , offset + 9 , 1 , ENC_LITTLE_ENDIAN ) ;
}
if ( known & IEEE80211_RADIOTAP_VHT_HAVE_PAID ) {
2015-06-26 18:28:25 +00:00
phdr . phy_info . info_11ac . presence_flags | = PHDR_802_11AC_HAS_PARTIAL_AID ;
phdr . phy_info . info_11ac . partial_aid = tvb_get_letohs ( tvb , offset + 10 ) ;
2012-09-18 20:46:05 +00:00
if ( vht_tree ) {
proto_tree_add_item ( vht_tree , hf_radiotap_vht_p_aid ,
tvb , offset + 10 , 2 , ENC_LITTLE_ENDIAN ) ;
}
}
break ;
}
2012-08-08 12:56:37 +00:00
}
}
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
if ( err ! = - ENOENT & & tree ) {
2013-09-02 23:32:31 +00:00
expert_add_info ( pinfo , pt , & ei_radiotap_data_past_header ) ;
2012-08-08 12:56:37 +00:00
malformed :
proto_item_append_text ( ti , " (malformed) " ) ;
}
2004-01-31 04:40:09 +00:00
2012-08-08 12:56:37 +00:00
hand_off_to_80211 :
/* Grab the rest of the frame. */
next_tvb = tvb_new_subset_remaining ( tvb , length ) ;
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/* If we had an in-header FCS, check it.
* This can only happen if the backward - compat configuration option
* is chosen by the user . */
if ( hdr_fcs_ti ) {
2015-06-18 20:12:43 +00:00
guint captured_length = tvb_captured_length ( next_tvb ) ;
guint reported_length = tvb_reported_length ( next_tvb ) ;
guint fcs_len = ( phdr . fcs_len > 0 ) ? phdr . fcs_len : 0 ;
2012-08-08 12:56:37 +00:00
/* It would be very strange for the header to have an FCS for the
* frame * and * the frame to have the FCS at the end , but it ' s possible , so
* take that into account by using the FCS length recorded in pinfo . */
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/* Watch out for [erroneously] short frames */
2015-06-18 20:12:43 +00:00
if ( captured_length > = reported_length & &
captured_length > fcs_len ) {
2012-08-08 12:56:37 +00:00
calc_fcs =
2015-06-24 04:30:15 +00:00
crc32_802_tvb ( next_tvb , tvb_captured_length ( next_tvb ) - fcs_len ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* By virtue of hdr_fcs_ti being set, we know that 'tree' is set,
* so there ' s no need to check it here . */
if ( calc_fcs = = sent_fcs ) {
proto_item_append_text ( hdr_fcs_ti ,
" [correct] " ) ;
} else {
proto_item_append_text ( hdr_fcs_ti ,
" [incorrect, should be 0x%08x] " ,
calc_fcs ) ;
hidden_item =
proto_tree_add_boolean ( radiotap_tree ,
hf_radiotap_fcs_bad ,
tvb , hdr_fcs_offset ,
4 , TRUE ) ;
PROTO_ITEM_SET_HIDDEN ( hidden_item ) ;
}
} else {
proto_item_append_text ( hdr_fcs_ti ,
" [cannot verify - not enough data] " ) ;
}
}
2010-10-13 21:30:27 +00:00
2015-06-18 20:12:43 +00:00
/* dissect the 802.11 packet next */
2015-06-20 22:57:57 +00:00
call_dissector_with_data ( ieee80211_radio_handle , next_tvb , pinfo ,
2015-06-18 20:12:43 +00:00
tree , & phdr ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
tap_queue_packet ( radiotap_tap , pinfo , radiotap_info ) ;
}
2010-10-13 21:30:27 +00:00
2015-06-20 22:23:35 +00:00
static const true_false_string tfs_1_0 = { " 1 " , " 0 " } ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
void proto_register_radiotap ( void )
{
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
static hf_register_info hf [ ] = {
{ & hf_radiotap_version ,
{ " Header revision " , " radiotap.version " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Version of radiotap header format " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_pad ,
{ " Header pad " , " radiotap.pad " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Padding " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_length ,
{ " Header length " , " radiotap.length " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Length of header including version, pad, length and data fields " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present ,
{ " Present flags " , " radiotap.present " ,
FT_NONE , BASE_NONE , NULL , 0x0 ,
" Bitmask indicating which fields are present " , HFILL } } ,
2010-04-30 08:26:12 +00:00
2012-08-08 12:56:37 +00:00
# define RADIOTAP_MASK(name) BIT(IEEE80211_RADIOTAP_ ##name)
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
/* Boolean 'present' flags */
{ & hf_radiotap_present_tsft ,
{ " TSFT " , " radiotap.present.tsft " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( TSFT ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the Time Synchronization Function Timer field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_flags ,
{ " Flags " , " radiotap.present.flags " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( FLAGS ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the channel flags field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_rate ,
{ " Rate " , " radiotap.present.rate " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( RATE ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the transmit/receive rate field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_channel ,
{ " Channel " , " radiotap.present.channel " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( CHANNEL ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the transmit/receive frequency field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_fhss ,
{ " FHSS " , " radiotap.present.fhss " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( FHSS ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the hop set and pattern is present for frequency hopping radios " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_dbm_antsignal ,
{ " dBm Antenna Signal " , " radiotap.present.dbm_antsignal " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DBM_ANTSIGNAL ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the antenna signal strength in dBm is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_dbm_antnoise ,
{ " dBm Antenna Noise " , " radiotap.present.dbm_antnoise " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DBM_ANTNOISE ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the RF noise power at antenna field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_lock_quality ,
{ " Lock Quality " , " radiotap.present.lock_quality " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( LOCK_QUALITY ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the signal quality field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_tx_attenuation ,
{ " TX Attenuation " , " radiotap.present.tx_attenuation " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( TX_ATTENUATION ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the transmit power distance from max power field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_db_tx_attenuation ,
{ " dB TX Attenuation " , " radiotap.present.db_tx_attenuation " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DB_TX_ATTENUATION ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the transmit power distance from max power (in dB) field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_dbm_tx_power ,
{ " dBm TX Power " , " radiotap.present.dbm_tx_power " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DBM_TX_POWER ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the transmit power (in dBm) field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_antenna ,
{ " Antenna " , " radiotap.present.antenna " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( ANTENNA ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the antenna number field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_db_antsignal ,
{ " dB Antenna Signal " , " radiotap.present.db_antsignal " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DB_ANTSIGNAL ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the RF signal power at antenna in dB field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_db_antnoise ,
{ " dB Antenna Noise " , " radiotap.present.db_antnoise " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( DB_ANTNOISE ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the RF signal power at antenna in dBm field is present " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_rxflags ,
{ " RX flags " , " radiotap.present.rxflags " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( RX_FLAGS ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the RX flags field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_hdrfcs ,
{ " FCS in header " , " radiotap.present.fcs " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( RX_FLAGS ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the FCS field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_xchannel ,
{ " Channel+ " , " radiotap.present.xchannel " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( XCHANNEL ) ,
2012-11-27 14:34:27 +00:00
" Specifies if the extended channel info field is present " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_mcs ,
{ " HT information " , " radiotap.present.mcs " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( MCS ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the HT field is present " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_ampdu ,
{ " A-MPDU Status " , " radiotap.present.ampdu " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( AMPDU_STATUS ) ,
2012-08-08 12:56:37 +00:00
" Specifies if the A-MPDU status field is present " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_present_vht ,
{ " VHT information " , " radiotap.present.vht " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( VHT ) ,
2012-09-18 20:46:05 +00:00
" Specifies if the VHT field is present " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_reserved ,
{ " Reserved " , " radiotap.present.reserved " ,
FT_UINT32 , BASE_HEX , NULL , IEEE80211_RADIOTAP_NOTDEFINED ,
2015-06-20 22:41:42 +00:00
" Not (yet) defined present flags (Must be zero) " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_rtap_ns ,
{ " Radiotap NS next " , " radiotap.present.rtap_ns " ,
FT_BOOLEAN , 32 , NULL , RADIOTAP_MASK ( RADIOTAP_NAMESPACE ) ,
" Specifies a reset to the radiotap namespace " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_vendor_ns ,
{ " Vendor NS next " , " radiotap.present.vendor_ns " ,
FT_BOOLEAN , 32 , NULL , RADIOTAP_MASK ( VENDOR_NAMESPACE ) ,
2012-11-27 14:34:27 +00:00
" Specifies that the next bitmap is in a vendor namespace " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_present_ext ,
{ " Ext " , " radiotap.present.ext " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 32 , TFS ( & tfs_present_absent ) , RADIOTAP_MASK ( EXT ) ,
2012-11-27 14:34:27 +00:00
" Specifies if there are any extensions to the header present " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Boolean 'present.flags' flags */
{ & hf_radiotap_flags ,
{ " Flags " , " radiotap.flags " ,
FT_UINT8 , BASE_HEX , NULL , 0x0 , NULL , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_cfp ,
{ " CFP " , " radiotap.flags.cfp " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_CFP ,
" Sent/Received during CFP " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_preamble ,
{ " Preamble " , " radiotap.flags.preamble " ,
FT_BOOLEAN , 8 , TFS ( & preamble_type ) ,
IEEE80211_RADIOTAP_F_SHORTPRE ,
" Sent/Received with short preamble " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_wep ,
{ " WEP " , " radiotap.flags.wep " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_WEP ,
" Sent/Received with WEP encryption " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_frag ,
{ " Fragmentation " , " radiotap.flags.frag " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_FRAG ,
" Sent/Received with fragmentation " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_fcs ,
{ " FCS at end " , " radiotap.flags.fcs " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_FCS ,
" Frame includes FCS at end " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_datapad ,
{ " Data Pad " , " radiotap.flags.datapad " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_DATAPAD ,
2012-11-27 14:34:27 +00:00
" Frame has padding between 802.11 header and payload " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_badfcs ,
{ " Bad FCS " , " radiotap.flags.badfcs " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_BADFCS ,
" Frame received with bad FCS " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_flags_shortgi ,
{ " Short GI " , " radiotap.flags.shortgi " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_F_SHORTGI ,
" Frame Sent/Received with HT short Guard Interval " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mactime ,
{ " MAC timestamp " , " radiotap.mactime " ,
FT_UINT64 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Value in microseconds of the MAC's Time Synchronization Function timer "
2014-10-06 16:55:18 +00:00
" when the first bit of the MPDU arrived at the MAC. " ,
2012-08-08 12:56:37 +00:00
HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_quality ,
{ " Signal Quality " , " radiotap.quality " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
" Signal quality (unitless measure) " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_fcs ,
{ " 802.11 FCS " , " radiotap.fcs " ,
FT_UINT32 , BASE_HEX , NULL , 0x0 ,
" Frame check sequence of this frame " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2013-01-31 17:55:31 +00:00
#if 0
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel ,
{ " Channel " , " radiotap.channel " ,
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" 802.11 channel number that this frame was sent/received on " , HFILL } } ,
2013-01-31 17:55:31 +00:00
# endif
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_frequency ,
{ " Channel frequency " , " radiotap.channel.freq " ,
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Channel frequency in megahertz that this frame was sent/received on " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Channel flags " , " radiotap.channel.flags " ,
FT_UINT16 , BASE_HEX , NULL , 0x0 ,
2012-08-08 12:56:37 +00:00
NULL , HFILL } } ,
{ & hf_radiotap_channel_flags_turbo ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Turbo " , " radiotap.channel.flags.turbo " ,
FT_BOOLEAN , 16 , NULL , 0x0010 , " Channel Flags Turbo " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_cck ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Complementary Code Keying (CCK) " , " radiotap.channel.flags.cck " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 16 , NULL , 0x0020 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Complementary Code Keying (CCK) Modulation " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_ofdm ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Orthogonal Frequency-Division Multiplexing (OFDM) " , " radiotap.channel.flags.ofdm " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 16 , NULL , 0x0040 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Orthogonal Frequency-Division Multiplexing (OFDM) " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_2ghz ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " 2 GHz spectrum " , " radiotap.channel.flags.2ghz " ,
FT_BOOLEAN , 16 , NULL , 0x0080 , " Channel Flags 2 GHz spectrum " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_5ghz ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " 5 GHz spectrum " , " radiotap.channel.flags.5ghz " ,
FT_BOOLEAN , 16 , NULL , 0x0100 , " Channel Flags 5 GHz spectrum " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_passive ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Passive " , " radiotap.channel.flags.passive " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , 0x0200 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Passive " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_dynamic ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Dynamic CCK-OFDM " , " radiotap.channel.flags.dynamic " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 16 , NULL , 0x0400 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Dynamic CCK-OFDM Channel " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_gfsk ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Gaussian Frequency Shift Keying (GFSK) " , " radiotap.channel.flags.gfsk " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 16 , NULL , 0x0800 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Gaussian Frequency Shift Keying (GFSK) Modulation " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_gsm ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " GSM (900MHz) " , " radiotap.channel.flags.gsm " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , 0x1000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags GSM " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_sturbo ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Static Turbo " , " radiotap.channel.flags.sturbo " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , 0x2000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Status Turbo " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_half ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Half Rate Channel (10MHz Channel Width) " , " radiotap.channel.flags.half " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , 0x4000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Half Rate " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_channel_flags_quarter ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Quarter Rate Channel (5MHz Channel Width) " , " radiotap.channel.flags.quarter " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , 0x8000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Quarter Rate " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_rxflags ,
{ " RX flags " , " radiotap.rxflags " ,
2012-11-27 14:34:27 +00:00
FT_UINT16 , BASE_HEX , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_rxflags_badplcp ,
{ " Bad PLCP " , " radiotap.rxflags.badplcp " ,
FT_BOOLEAN , 24 , NULL , IEEE80211_RADIOTAP_F_RX_BADPLCP ,
" Frame with bad PLCP " , HFILL } } ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ & hf_radiotap_xchannel_channel ,
{ " Channel number " , " radiotap.xchannel.channel " ,
2012-11-27 14:34:27 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_frequency ,
{ " Channel frequency " , " radiotap.xchannel.freq " ,
2012-11-27 14:34:27 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Channel flags " , " radiotap.xchannel.flags " ,
FT_UINT32 , BASE_HEX , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_turbo ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Turbo " , " radiotap.xchannel.flags.turbo " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x0010 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Turbo " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_cck ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Complementary Code Keying (CCK) " , " radiotap.xchannel.flags.cck " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 24 , NULL , 0x0020 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Complementary Code Keying (CCK) Modulation " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_ofdm ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Orthogonal Frequency-Division Multiplexing (OFDM) " , " radiotap.xchannel.flags.ofdm " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 24 , NULL , 0x0040 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Orthogonal Frequency-Division Multiplexing (OFDM) " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_2ghz ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " 2 GHz spectrum " , " radiotap.xchannel.flags.2ghz " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x0080 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags 2 GHz spectrum " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_5ghz ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " 5 GHz spectrum " , " radiotap.xchannel.flags.5ghz " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x0100 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags 5 GHz spectrum " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_passive ,
{ " Passive " , " radiotap.channel.xtype.passive " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x0200 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Passive " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_dynamic ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Dynamic CCK-OFDM " , " radiotap.xchannel.flags.dynamic " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 24 , NULL , 0x0400 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Dynamic CCK-OFDM Channel " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_gfsk ,
{ " Gaussian Frequency Shift Keying (GFSK) " ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" radiotap.xchannel.flags.gfsk " ,
2012-08-08 12:56:37 +00:00
FT_BOOLEAN , 24 , NULL , 0x0800 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Gaussian Frequency Shift Keying (GFSK) Modulation " ,
2012-08-08 12:56:37 +00:00
HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_gsm ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " GSM (900MHz) " , " radiotap.xchannel.flags.gsm " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x1000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags GSM " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_sturbo ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Static Turbo " , " radiotap.xchannel.flags.sturbo " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x2000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Status Turbo " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_half ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Half Rate Channel (10MHz Channel Width) " , " radiotap.xchannel.flags.half " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x4000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Half Rate " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_quarter ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " Quarter Rate Channel (5MHz Channel Width) " , " radiotap.xchannel.flags.quarter " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x8000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags Quarter Rate " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_ht20 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " HT Channel (20MHz Channel Width) " , " radiotap.xchannel.flags.ht20 " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x10000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags HT/20 " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_ht40u ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " HT Channel (40MHz Channel Width with Extension channel above) " , " radiotap.xchannel.flags.ht40u " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x20000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags HT/40+ " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_xchannel_flags_ht40d ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
{ " HT Channel (40MHz Channel Width with Extension channel below) " , " radiotap.xchannel.flags.ht40d " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 24 , NULL , 0x40000 ,
Treat channel flags fields as just collections of bits, not as type fields.
The radiotap and PPI specs don't call them type fields, and don't list
them as having type values, they call them flags fields and list the
individual bits.
Listing them as type fields is especially confusing with radiotap, as
you can have multiple fields giving *different* channel types, as per,
for example
https://ask.wireshark.org/questions/42888/multiple-channel-types-and-mcs-missing
where an 802.11ac packet has one "channel type" field claiming it's
802.11a and another one claiming it's 802.11n when it is, in fact,
*neither* 11a *nor* 11n.
If you want to know the channel type, look at the "802.11 radio
information" tree that comes before the 802.11 header tree; it gives a
reasonable summary of most of the radio metadata, giving the *correct*
channel type, and not showing any field multiple times. Look at the
radiotap or PPI or... tree only if either 1) you're debugging a driver
that creates those headers or 2) there's some data in the header that
*doesn't* show up in any form in the 802.11 radio information tree (in
which case the code for radio information probably needs to be changed
to show it).
Change-Id: I545b81b08a993dbb219fa7a4f54daac3637ea071
Reviewed-on: https://code.wireshark.org/review/9051
Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-06-23 06:59:59 +00:00
" Channel Flags HT/40- " , HFILL } } ,
2012-08-08 12:56:37 +00:00
#if 0
{ & hf_radiotap_xchannel_maxpower ,
{ " Max transmit power " , " radiotap.xchannel.maxpower " ,
2012-11-27 14:34:27 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-08-08 12:56:37 +00:00
# endif
{ & hf_radiotap_fhss_hopset ,
{ " FHSS Hop Set " , " radiotap.fhss.hopset " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Frequency Hopping Spread Spectrum hopset " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_fhss_pattern ,
{ " FHSS Pattern " , " radiotap.fhss.pattern " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Frequency Hopping Spread Spectrum hop pattern " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_datarate ,
{ " Data rate (Mb/s) " , " radiotap.datarate " ,
FT_FLOAT , BASE_NONE , NULL , 0x0 ,
" Speed this frame was sent/received at " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_antenna ,
{ " Antenna " , " radiotap.antenna " ,
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Antenna number this frame was sent/received over (starting at 0) " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_dbm_antsignal ,
2013-09-30 16:10:40 +00:00
{ " SSI Signal " , " radiotap.dbm_antsignal " ,
2012-08-08 12:56:37 +00:00
FT_INT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" RF signal power at the antenna from a fixed, "
2014-10-06 16:55:18 +00:00
" arbitrary value in decibels from one milliwatt " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_db_antsignal ,
2013-09-16 10:39:06 +00:00
{ " SSI Signal " , " radiotap.db_antsignal " ,
2012-08-08 12:56:37 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" RF signal power at the antenna from a fixed, arbitrary value in decibels " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_dbm_antnoise ,
2013-09-30 16:10:40 +00:00
{ " SSI Noise " , " radiotap.dbm_antnoise " ,
2012-08-08 12:56:37 +00:00
FT_INT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" RF noise power at the antenna from a fixed, arbitrary value "
2014-10-06 16:55:18 +00:00
" in decibels per one milliwatt " , HFILL } } ,
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_db_antnoise ,
2013-09-16 10:39:06 +00:00
{ " SSI Noise " , " radiotap.db_antnoise " ,
2012-08-08 12:56:37 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" RF noise power at the antenna from a fixed, arbitrary value "
2014-10-06 16:55:18 +00:00
" in decibels " , HFILL } } ,
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_tx_attenuation ,
{ " Transmit attenuation " , " radiotap.txattenuation " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Transmit power expressed as unitless distance from max power "
2014-10-06 16:55:18 +00:00
" set at factory (0 is max power) " , HFILL } } ,
2011-01-27 17:45:45 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_db_tx_attenuation ,
{ " Transmit attenuation (dB) " , " radiotap.db_txattenuation " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Transmit power expressed as decibels from max power "
2014-10-06 16:55:18 +00:00
" set at factory (0 is max power) " , HFILL } } ,
2011-04-27 21:59:47 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_txpower ,
{ " Transmit power " , " radiotap.txpower " ,
FT_INT32 , BASE_DEC , NULL , 0x0 ,
" Transmit power in decibels per one milliwatt (dBm) " , HFILL } } ,
2012-08-08 08:16:34 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs ,
{ " MCS information " , " radiotap.mcs " ,
2012-11-27 14:34:27 +00:00
FT_NONE , BASE_NONE , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_known ,
{ " Known MCS information " , " radiotap.mcs.known " ,
FT_UINT8 , BASE_HEX , NULL , 0x0 ,
" Bit mask indicating what MCS information is present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_have_bw ,
{ " Bandwidth " , " radiotap.mcs.have_bw " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_BW ,
2012-08-08 12:56:37 +00:00
" Bandwidth information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2015-06-20 22:57:57 +00:00
{ & hf_radiotap_mcs_have_index ,
{ " MCS index " , " radiotap.mcs.have_index " ,
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_MCS ,
" MCS index information present " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_have_gi ,
{ " Guard interval " , " radiotap.mcs.have_gi " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_GI ,
2012-08-08 12:56:37 +00:00
" Sent/Received guard interval information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_have_format ,
{ " Format " , " radiotap.mcs.have_format " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_FMT ,
2012-08-08 12:56:37 +00:00
" Format information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_have_fec ,
2015-06-18 02:08:13 +00:00
{ " FEC type " , " radiotap.mcs.have_fec " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_FEC ,
2015-06-18 02:08:13 +00:00
" Forward error correction type information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_have_stbc ,
2015-06-18 02:08:13 +00:00
{ " STBC streams " , " radiotap.mcs.have_stbc " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_STBC ,
2015-06-18 02:08:13 +00:00
" Space Time Block Coding streams information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2015-06-20 22:23:35 +00:00
{ & hf_radiotap_mcs_have_ness ,
{ " Number of extension spatial streams " , " radiotap.mcs.have_ness " ,
2015-06-20 22:41:42 +00:00
FT_BOOLEAN , 8 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_MCS_HAVE_NESS ,
2015-06-20 22:23:35 +00:00
" Number of extension spatial streams information present " , HFILL } } ,
{ & hf_radiotap_mcs_ness_bit1 ,
{ " Number of extension spatial streams bit 1 " , " radiotap.mcs.ness_bit1 " ,
FT_BOOLEAN , 8 , TFS ( & tfs_1_0 ) , IEEE80211_RADIOTAP_MCS_NESS_BIT1 ,
" Bit 1 of number of extension spatial streams information " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_bw ,
{ " Bandwidth " , " radiotap.mcs.bw " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_bandwidth ) ,
IEEE80211_RADIOTAP_MCS_BW_MASK , NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_gi ,
{ " Guard interval " , " radiotap.mcs.gi " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_gi ) , IEEE80211_RADIOTAP_MCS_SGI ,
" Sent/Received guard interval " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_format ,
{ " Format " , " radiotap.mcs.format " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_format ) , IEEE80211_RADIOTAP_MCS_FMT_GF ,
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_fec ,
2015-06-18 02:08:13 +00:00
{ " FEC type " , " radiotap.mcs.fec " ,
2012-08-08 12:56:37 +00:00
FT_UINT8 , BASE_DEC , VALS ( mcs_fec ) , IEEE80211_RADIOTAP_MCS_FEC_LDPC ,
2015-06-18 02:08:13 +00:00
" Forward error correction type " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_stbc ,
2015-06-18 02:08:13 +00:00
{ " STBC streams " , " radiotap.mcs.stbc " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_MCS_STBC_MASK ,
" Number of Space Time Block Code streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2015-06-20 22:23:35 +00:00
{ & hf_radiotap_mcs_ness_bit0 ,
{ " Number of extension spatial streams bit 0 " , " radiotap.mcs.ness_bit1 " ,
FT_BOOLEAN , 8 , TFS ( & tfs_1_0 ) , IEEE80211_RADIOTAP_MCS_NESS_BIT1 ,
" Bit 0 of number of extension spatial streams information " , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_mcs_index ,
{ " MCS index " , " radiotap.mcs.index " ,
2012-11-27 14:34:27 +00:00
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-08-08 08:16:34 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu ,
{ " A-MPDU status " , " radiotap.ampdu " ,
2012-11-27 14:34:27 +00:00
FT_NONE , BASE_NONE , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_ref ,
{ " A-MPDU reference number " , " radiotap.ampdu.reference " ,
2012-11-27 14:34:27 +00:00
FT_UINT32 , BASE_DEC , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags ,
{ " A-MPDU flags " , " radiotap.ampdu.flags " ,
FT_UINT16 , BASE_HEX , NULL , 0x0 ,
" A-MPDU status flags " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags_report_zerolen ,
{ " Driver reports 0-length subframes in this A-MPDU " , " radiotap.ampdu.flags.report_zerolen " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags_is_zerolen ,
{ " This is a 0-length subframe " , " radiotap.ampdu.flags.is_zerolen " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , IEEE80211_RADIOTAP_AMPDU_IS_ZEROLEN ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags_last_known ,
{ " Last subframe of this A-MPDU is known " , " radiotap.ampdu.flags.lastknown " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , IEEE80211_RADIOTAP_AMPDU_LAST_KNOWN ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags_is_last ,
{ " This is the last subframe of this A-MPDU " , " radiotap.ampdu.flags.last " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , IEEE80211_RADIOTAP_AMPDU_IS_LAST ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_flags_delim_crc_error ,
{ " Delimiter CRC error on this subframe " , " radiotap.ampdu.flags.delim_crc_error " ,
2012-11-27 14:34:27 +00:00
FT_BOOLEAN , 16 , NULL , IEEE80211_RADIOTAP_AMPDU_DELIM_CRC_ERR ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ampdu_delim_crc ,
{ " A-MPDU subframe delimiter CRC " , " radiotap.ampdu.delim_crc " ,
2012-11-27 14:34:27 +00:00
FT_UINT8 , BASE_HEX , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-08-08 08:16:34 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht ,
{ " VHT information " , " radiotap.vht " ,
2012-11-27 14:34:27 +00:00
FT_NONE , BASE_NONE , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_known ,
{ " Known VHT information " , " radiotap.vht.known " ,
FT_UINT8 , BASE_HEX , NULL , 0x0 ,
" Bit mask indicating what VHT information is present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_user ,
{ " User " , " radiotap.vht.user " ,
2012-11-27 14:34:27 +00:00
FT_NONE , BASE_NONE , NULL , 0x0 ,
2014-10-06 16:55:18 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_stbc ,
{ " STBC " , " radiotap.vht.have_stbc " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_STBC ,
2012-09-18 20:46:05 +00:00
" Space Time Block Coding information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_txop_ps ,
{ " TXOP_PS_NOT_ALLOWED " , " radiotap.vht.have_txop_ps " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_TXOP_PS ,
2012-09-18 20:46:05 +00:00
" TXOP_PS_NOT_ALLOWED information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_gi ,
{ " Guard interval " , " radiotap.vht.have_gi " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_GI ,
2012-09-18 20:46:05 +00:00
" Short/Long guard interval information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_sgi_nsym_da ,
{ " SGI Nsym disambiguation " , " radiotap.vht.have_sgi_nsym_da " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_SGI_NSYM_DA ,
2012-09-18 20:46:05 +00:00
" Short guard interval Nsym disambiguation information present " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_ldpc_extra ,
{ " LDPC extra OFDM symbol " , " radiotap.vht.ldpc_extra " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_LDPC_EXTRA ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_bf ,
{ " Beamformed " , " radiotap.vht.have_beamformed " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_BF ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_bw ,
{ " Bandwidth " , " radiotap.mcs.have_bw " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_BW ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_gid ,
{ " Group ID " , " radiotap.mcs.have_gid " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_GID ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_have_p_aid ,
{ " Partial AID " , " radiotap.mcs.have_paid " ,
2015-06-26 19:03:04 +00:00
FT_BOOLEAN , 16 , TFS ( & tfs_present_absent ) , IEEE80211_RADIOTAP_VHT_HAVE_PAID ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_stbc ,
{ " STBC " , " radiotap.vht.stbc " ,
FT_BOOLEAN , 8 , TFS ( & tfs_on_off ) , IEEE80211_RADIOTAP_VHT_STBC ,
" Space Time Block Coding flag " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_txop_ps ,
{ " TXOP_PS_NOT_ALLOWED " , " radiotap.vht.txop_ps " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_VHT_TXOP_PS ,
" Flag indicating whether STAs may doze during TXOP " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_gi ,
{ " Guard interval " , " radiotap.vht.gi " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_gi ) , IEEE80211_RADIOTAP_VHT_SGI ,
" Short/Long guard interval " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_sgi_nsym_da ,
{ " SGI Nsym disambiguation " , " radiotap.vht.sgi_nsym_da " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_VHT_SGI_NSYM_DA ,
" Short Guard Interval Nsym disambiguation " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_ldpc_extra ,
{ " LDPC extra OFDM symbol " , " radiotap.vht.ldpc_extra " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_VHT_LDPC_EXTRA ,
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_bf ,
{ " Beamformed " , " radiotap.vht.beamformed " ,
FT_BOOLEAN , 8 , NULL , IEEE80211_RADIOTAP_VHT_BF ,
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_bw ,
{ " Bandwidth " , " radiotap.vht.bw " ,
2012-11-27 14:34:27 +00:00
FT_UINT8 , BASE_DEC | BASE_EXT_STRING , & vht_bandwidth_ext , 0x0 ,
2012-09-18 20:46:05 +00:00
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nsts [ 0 ] ,
{ " Space-time streams 0 " , " radiotap.vht.nsts.0 " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Number of Space-time streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nsts [ 1 ] ,
{ " Space-time streams 1 " , " radiotap.vht.nsts.1 " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Number of Space-time streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nsts [ 2 ] ,
{ " Space-time streams 2 " , " radiotap.vht.nsts.2 " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Number of Space-time streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nsts [ 3 ] ,
{ " Space-time streams 3 " , " radiotap.vht.nsts.3 " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Number of Space-time streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_mcs [ 0 ] ,
{ " MCS index 0 " , " radiotap.vht.mcs.0 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_MCS ,
" MCS index " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_mcs [ 1 ] ,
{ " MCS index 1 " , " radiotap.vht.mcs.1 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_MCS ,
" MCS index " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_mcs [ 2 ] ,
{ " MCS index 2 " , " radiotap.vht.mcs.2 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_MCS ,
" MCS index " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_mcs [ 3 ] ,
{ " MCS index 3 " , " radiotap.vht.mcs.3 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_MCS ,
" MCS index " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nss [ 0 ] ,
{ " Spatial streams 0 " , " radiotap.vht.nss.0 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_NSS ,
" Number of spatial streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nss [ 1 ] ,
{ " Spatial streams 1 " , " radiotap.vht.nss.1 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_NSS ,
" Number of spatial streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nss [ 2 ] ,
{ " Spatial streams 2 " , " radiotap.vht.nss.2 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_NSS ,
" Number of spatial streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_nss [ 3 ] ,
{ " Spatial streams 3 " , " radiotap.vht.nss.3 " ,
FT_UINT8 , BASE_DEC , NULL , IEEE80211_RADIOTAP_VHT_NSS ,
" Number of spatial streams " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_coding [ 0 ] ,
{ " Coding 0 " , " radiotap.vht.coding.0 " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_fec ) , 0x0 ,
" Coding " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_coding [ 1 ] ,
{ " Coding 1 " , " radiotap.vht.coding.1 " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_fec ) , 0x0 ,
" Coding " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_coding [ 2 ] ,
{ " Coding 2 " , " radiotap.vht.coding.2 " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_fec ) , 0x0 ,
" Coding " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_coding [ 3 ] ,
{ " Coding 3 " , " radiotap.vht.coding.3 " ,
FT_UINT8 , BASE_DEC , VALS ( mcs_fec ) , 0x0 ,
" Coding " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_datarate [ 0 ] ,
{ " Data rate (Mb/s) 0 " , " radiotap.vht.datarate.0 " ,
FT_FLOAT , BASE_NONE , NULL , 0x0 ,
" Speed this frame was sent/received at " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_datarate [ 1 ] ,
{ " Data rate (Mb/s) 1 " , " radiotap.vht.datarate.1 " ,
FT_FLOAT , BASE_NONE , NULL , 0x0 ,
" Speed this frame was sent/received at " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_datarate [ 2 ] ,
{ " Data rate (Mb/s) 2 " , " radiotap.vht.datarate.2 " ,
FT_FLOAT , BASE_NONE , NULL , 0x0 ,
" Speed this frame was sent/received at " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_datarate [ 3 ] ,
{ " Data rate (Mb/s) 3 " , " radiotap.vht.datarate.3 " ,
FT_FLOAT , BASE_NONE , NULL , 0x0 ,
" Speed this frame was sent/received at " , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_gid ,
{ " Group Id " , " radiotap.vht.gid " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
NULL , HFILL } } ,
2012-11-27 14:34:27 +00:00
2012-09-18 20:46:05 +00:00
{ & hf_radiotap_vht_p_aid ,
{ " Partial AID " , " radiotap.vht.paid " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
NULL , HFILL } } ,
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_vendor_ns ,
{ " Vendor namespace " , " radiotap.vendor_namespace " ,
FT_BYTES , BASE_NONE , NULL , 0x0 ,
NULL , HFILL } } ,
2012-08-08 08:16:34 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ven_oui ,
{ " Vendor OUI " , " radiotap.vendor_oui " ,
FT_BYTES , BASE_NONE , NULL , 0x0 ,
NULL , HFILL } } ,
2010-04-30 08:26:12 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ven_subns ,
{ " Vendor sub namespace " , " radiotap.vendor_subns " ,
FT_UINT8 , BASE_DEC , NULL , 0x0 ,
" Vendor-specified sub namespace " , HFILL } } ,
2010-10-14 17:56:06 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ven_skip ,
{ " Vendor data length " , " radiotap.vendor_data_len " ,
FT_UINT16 , BASE_DEC , NULL , 0x0 ,
" Length of vendor-specified data " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
{ & hf_radiotap_ven_data ,
{ " Vendor data " , " radiotap.vendor_data " ,
FT_NONE , BASE_NONE , NULL , 0x0 ,
" Vendor-specified data " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
/* Special variables */
{ & hf_radiotap_fcs_bad ,
{ " Bad FCS " , " radiotap.fcs_bad " ,
FT_BOOLEAN , BASE_NONE , NULL , 0x0 ,
2012-11-27 14:34:27 +00:00
" Specifies if this frame has a bad frame check sequence " , HFILL } } ,
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
} ;
static gint * ett [ ] = {
& ett_radiotap ,
& ett_radiotap_present ,
& ett_radiotap_flags ,
& ett_radiotap_rxflags ,
& ett_radiotap_channel_flags ,
& ett_radiotap_xchannel_flags ,
& ett_radiotap_vendor ,
& ett_radiotap_mcs ,
& ett_radiotap_mcs_known ,
& ett_radiotap_ampdu ,
& ett_radiotap_ampdu_flags ,
2012-09-18 20:46:05 +00:00
& ett_radiotap_vht ,
& ett_radiotap_vht_known ,
& ett_radiotap_vht_user
2012-08-08 12:56:37 +00:00
} ;
2013-09-02 23:32:31 +00:00
static ei_register_info ei [ ] = {
{ & ei_radiotap_present , { " radiotap.present.radiotap_and_vendor " , PI_MALFORMED , PI_ERROR , " Both radiotap and vendor namespace specified in bitmask word " , EXPFILL } } ,
{ & ei_radiotap_present_reserved , { " radiotap.present.reserved.unknown " , PI_UNDECODED , PI_NOTE , " Unknown Radiotap fields, code not implemented, Please check radiotap documentation, Contact Wireshark developers if you want this supported " , EXPFILL } } ,
{ & ei_radiotap_data_past_header , { " radiotap.data_past_header " , PI_MALFORMED , PI_ERROR , " Radiotap data goes past the end of the radiotap header " , EXPFILL } } ,
} ;
2012-08-08 12:56:37 +00:00
module_t * radiotap_module ;
2013-09-02 23:32:31 +00:00
expert_module_t * expert_radiotap ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
proto_radiotap =
2013-09-02 23:32:31 +00:00
proto_register_protocol ( " IEEE 802.11 Radiotap Capture header " , " 802.11 Radiotap " , " radiotap " ) ;
2012-08-08 12:56:37 +00:00
proto_register_field_array ( proto_radiotap , hf , array_length ( hf ) ) ;
proto_register_subtree_array ( ett , array_length ( ett ) ) ;
2013-09-02 23:32:31 +00:00
expert_radiotap = expert_register_protocol ( proto_radiotap ) ;
expert_register_field_array ( expert_radiotap , ei , array_length ( ei ) ) ;
2012-08-08 12:56:37 +00:00
register_dissector ( " radiotap " , dissect_radiotap , proto_radiotap ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
radiotap_tap = register_tap ( " radiotap " ) ;
2010-10-13 21:30:27 +00:00
2012-08-08 12:56:37 +00:00
radiotap_module = prefs_register_protocol ( proto_radiotap , NULL ) ;
prefs_register_bool_preference ( radiotap_module , " bit14_fcs_in_header " ,
" Assume bit 14 means FCS in header " ,
" Radiotap has a bit to indicate whether the FCS is still on the frame or not. "
" Some generators (e.g. AirPcap) use a non-standard radiotap flag 14 to put "
" the FCS into the header. " ,
& radiotap_bit14_fcs ) ;
2004-01-31 04:40:09 +00:00
}
2010-10-13 21:30:27 +00:00
void proto_reg_handoff_radiotap ( void )
2004-01-31 04:40:09 +00:00
{
2010-10-13 21:30:27 +00:00
dissector_handle_t radiotap_handle ;
2004-01-31 04:40:09 +00:00
2015-06-20 22:57:57 +00:00
/* handle for 802.11+radio information dissector */
ieee80211_radio_handle = find_dissector ( " wlan_radio " ) ;
2004-01-31 04:40:09 +00:00
2010-10-13 21:30:27 +00:00
radiotap_handle = find_dissector ( " radiotap " ) ;
2004-01-31 04:40:09 +00:00
2012-05-02 03:11:00 +00:00
dissector_add_uint ( " wtap_encap " , WTAP_ENCAP_IEEE_802_11_RADIOTAP ,
2012-11-27 14:34:27 +00:00
radiotap_handle ) ;
2004-01-31 04:40:09 +00:00
}
2008-10-24 23:35:50 +00:00
/*
2010-10-13 21:30:27 +00:00
* Editor modelines - http : //www.wireshark.org/tools/modelines.html
2008-10-24 23:35:50 +00:00
*
2010-10-13 21:30:27 +00:00
* Local variables :
* c - basic - offset : 8
2008-10-24 23:35:50 +00:00
* tab - width : 8
* indent - tabs - mode : t
* End :
*
2011-09-21 16:28:53 +00:00
* vi : set shiftwidth = 8 tabstop = 8 noexpandtab :
2010-10-13 21:30:27 +00:00
* : indentSize = 8 : tabSize = 8 : noTabs = false :
2009-05-17 21:41:00 +00:00
*/