RadioTap Archive on lore.kernel.org
 help / color / Atom feed
* [RFC] VHT fields
@ 2012-06-12 15:05 Alwin Beukers
       [not found] ` <C6E8EE2D6B3ACB4582C1249E834B306505D68C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Alwin Beukers @ 2012-06-12 15:05 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw
  Cc: Arend Van Spriel, Pieter-Paul Giesberts, Bill Stafford

Hi everyone,

This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:

http://www.radiotap.org/suggested-fields/SU_VHT
http://www.radiotap.org/suggested-fields/MU_VHT
http://www.radiotap.org/suggested-fields/GROUP_ID
http://www.radiotap.org/suggested-fields/PARTIAL_AID

A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.

Any thoughts?

Thanks,
Alwin

---

Index: epan/dissectors/packet-ieee80211-radiotap-defs.h
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap-defs.h	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap-defs.h	(working copy)
@@ -204,6 +204,10 @@
 	IEEE80211_RADIOTAP_DATA_RETRIES = 17,
 	IEEE80211_RADIOTAP_XCHANNEL = 18, /* Unofficial, used by FreeBSD */
 	IEEE80211_RADIOTAP_MCS = 19,
+	IEEE80211_RADIOTAP_SU_VHT = 20,
+	IEEE80211_RADIOTAP_GROUP_ID = 21,
+	IEEE80211_RADIOTAP_PARTIAL_AID = 22,
+	IEEE80211_RADIOTAP_MU_VHT = 23,
 
 	/* valid in every it_present bitmap, even vendor namespaces */
 	IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,
@@ -270,4 +274,60 @@
 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC		0x10
 #define IEEE80211_RADIOTAP_MCS_STBC		0x20
 
+/* For IEEE80211_RADIOTAP_SU_VHT */
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC	0x01
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS	0x02
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_GI	0x04
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING	0x08
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_BF	0x10
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_BW	0x20
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS	0x40
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS	0x80
+
+#define IEEE80211_RADIOTAP_SU_VHT_STBC		0x01
+#define IEEE80211_RADIOTAP_SU_VHT_TXOP_PS	0x02
+#define IEEE80211_RADIOTAP_SU_VHT_SGI		0x04
+#define IEEE80211_RADIOTAP_SU_VHT_SGI_NSYM_DA	0x08
+#define IEEE80211_RADIOTAP_SU_VHT_CODING_LDPC	0x10
+#define IEEE80211_RADIOTAP_SU_VHT_LDPC_EXTRA	0x20
+#define IEEE80211_RADIOTAP_SU_VHT_BF		0x40
+
+#define IEEE80211_RADIOTAP_SU_VHT_NSTS		0x0f
+#define IEEE80211_RADIOTAP_SU_VHT_BW		0xf0
+
+#define IEEE80211_RADIOTAP_SU_VHT_MCS		0x0f
+#define IEEE80211_RADIOTAP_SU_VHT_NSS		0x70
+
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20		IEEE80211_RADIOTAP_MCS_BW_20
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40		IEEE80211_RADIOTAP_MCS_BW_40
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20L	IEEE80211_RADIOTAP_MCS_BW_20L
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20U	IEEE80211_RADIOTAP_MCS_BW_20U
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80		4
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40L	5
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40U	6
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LL	7
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LU	8
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UL	9
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UU	10
+#define IEEE80211_RADIOTAP_SU_VHT_BW_160	11
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80L	12
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80U	13
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40LL	14
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40LU	15
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40UL	16
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40UU	17
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LLL	18
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LLU	19
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LUL	20
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LUU	21
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20ULL	22
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20ULU	23
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UUL	24
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UUU	25
+
+/* For IEEE80211_RADIOTAP_MU_VHT */
+#define IEEE80211_RADIOTAP_MU_VHT_NSTS_MASK	0x07
+#define IEEE80211_RADIOTAP_MU_VHT_CODING_LDPC	0x08
+#define IEEE80211_RADIOTAP_MU_VHT_MCS		0xf0
+
 #endif				/* IEEE80211_RADIOTAP_H */
Index: epan/dissectors/packet-ieee80211-radiotap.c
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap.c	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap.c	(working copy)
@@ -79,6 +79,137 @@
 #define	IEEE80211_CHAN_108PUREG \
 	(IEEE80211_CHAN_PUREG | IEEE80211_CHAN_TURBO)
 
+#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 {
+	char *modulation;
+	char *coding_rate;
+	float rates[4][2];
+};
+
+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, }
+				}
+		}
+};
+
+static const value_string vht_bandwidth[] = {
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20, "20 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20L, "20 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20U, "20 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40, "40 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LL, "20 MHz, channel 1/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LU, "20 MHz, channel 2/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UL, "20 MHz, channel 3/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UU, "20 MHz, channel 4/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40L, "40 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40U, "40 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80, "80 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LLL, "20 MHz, channel 1/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LLU, "20 MHz, channel 2/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LUL, "20 MHz, channel 3/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LUU, "20 MHz, channel 4/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20ULL, "20 MHz, channel 5/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20ULU, "20 MHz, channel 6/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UUL, "20 MHz, channel 7/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UUU, "20 MHz, channel 8/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40LL, "40 MHz, channel 1/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40LU, "40 MHz, channel 2/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40UL, "40 MHz, channel 3/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40UU, "40 MHz, channel 4/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80L, "80 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80U, "80 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_160, "160 MHz" },
+	{ 0, NULL }
+};
+
 #define MAX_MCS_INDEX	76
 
 /*
@@ -553,6 +684,29 @@
 static int hf_radiotap_mcs_format = -1;
 static int hf_radiotap_mcs_fec = -1;
 static int hf_radiotap_mcs_stbc = -1;
+static int hf_radiotap_su_vht = -1;
+static int hf_radiotap_su_vht_known = -1;
+static int hf_radiotap_su_vht_have_stbc = -1;
+static int hf_radiotap_su_vht_have_txop_ps = -1;
+static int hf_radiotap_su_vht_have_gi = -1;
+static int hf_radiotap_su_vht_have_coding = -1;
+static int hf_radiotap_su_vht_have_bf = -1;
+static int hf_radiotap_su_vht_have_bw = -1;
+static int hf_radiotap_su_vht_have_nsts = -1;
+static int hf_radiotap_su_vht_have_mcs_nss = -1;
+static int hf_radiotap_su_vht_stbc = -1;
+static int hf_radiotap_su_vht_txop_ps = -1;
+static int hf_radiotap_su_vht_gi = -1;
+static int hf_radiotap_su_vht_sgi_nsym_da = -1;
+static int hf_radiotap_su_vht_coding = -1;
+static int hf_radiotap_su_vht_ldpc_extra = -1;
+static int hf_radiotap_su_vht_bf = -1;
+static int hf_radiotap_su_vht_bw = -1;
+static int hf_radiotap_su_vht_nsts = -1;
+static int hf_radiotap_su_vht_mcs = -1;
+static int hf_radiotap_su_vht_nss = -1;
+static int hf_radiotap_gid = -1;
+static int hf_radiotap_aid = -1;
 
 /* "Present" flags */
 static int hf_radiotap_present_tsft = -1;
@@ -573,6 +727,7 @@
 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_su_vht = -1;
 static int hf_radiotap_present_rtap_ns = -1;
 static int hf_radiotap_present_vendor_ns = -1;
 static int hf_radiotap_present_ext = -1;
@@ -601,6 +756,8 @@
 static gint ett_radiotap_vendor = -1;
 static gint ett_radiotap_mcs = -1;
 static gint ett_radiotap_mcs_known = -1;
+static gint ett_radiotap_su_vht = -1;
+static gint ett_radiotap_su_vht_known = -1;
 
 static dissector_handle_t ieee80211_handle;
 static dissector_handle_t ieee80211_datapad_handle;
@@ -905,6 +1062,11 @@
 		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(MCS),
 		  "Specifies if the HT field is present", HFILL}},
 
+		{&hf_radiotap_present_su_vht,
+		 {"VHT information", "radiotap.present.su_vht",
+		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(SU_VHT),
+		  "Specifies if the VHT field is present", HFILL}},
+
 		{&hf_radiotap_present_rtap_ns,
 		 {"Radiotap NS next", "radiotap.present.rtap_ns",
 		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(RADIOTAP_NAMESPACE),
@@ -1261,6 +1423,100 @@
 		 {"MCS index", "radiotap.mcs.index",
 		  FT_UINT8, BASE_DEC, NULL, 0x0, NULL, HFILL}},
 
+		{&hf_radiotap_su_vht,
+		 {"VHT information", "radiotap.vht",
+		  FT_NONE, BASE_NONE, NULL, 0x0, NULL, HFILL}},
+		{&hf_radiotap_su_vht_known,
+		 {"Known VHT information", "radiotap.vht.known",
+		  FT_UINT8, BASE_HEX, NULL, 0x0,
+		  "Bit mask indicating what VHT information is present", HFILL}},
+		{&hf_radiotap_su_vht_have_stbc,
+		 {"STBC", "radiotap.vht.have_stbc",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC,
+		  "Space Time Block Coding information present", HFILL}},
+		{&hf_radiotap_su_vht_have_txop_ps,
+		 {"TXOP_PS_NOT_ALLOWED", "radiotap.vht.have_txop_ps",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS,
+		  "TXOP_PS_NOT_ALLOWED information present", HFILL}},
+		{&hf_radiotap_su_vht_have_gi,
+		 {"Guard interval and SGI Nsym disambiguation", "radiotap.vht.have_gi",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_GI,
+		  "Short/Long guard interval and SGI Nsym disambiguation information present", HFILL}},
+		{&hf_radiotap_su_vht_have_coding,
+		 {"Coding and LDPC extra symbol", "radiotap.vht.have_coding",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING,
+		  "Coding and LDPC extra OFDM symbol information present", HFILL}},
+		{&hf_radiotap_su_vht_have_bf,
+		 {"Beamformed", "radiotap.vht.have_beamformed",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_BF,
+		  "Beamformed information present", HFILL}},
+		{&hf_radiotap_su_vht_have_bw,
+		 {"Bandwidth", "radiotap.mcs.have_bw",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_BW,
+		  "Bandwidth information present", HFILL}},
+		{&hf_radiotap_su_vht_have_nsts,
+		 {"Nsts", "radiotap.vht.have_nsts",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS,
+		  "Number of Space-time streams information present", HFILL}},
+		{&hf_radiotap_su_vht_have_mcs_nss,
+		 {"MCS index and Nss count", "radiotap.vht.have_mcs_nss",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS,
+		  "MCS index and Nss information present", HFILL}},
+		{&hf_radiotap_su_vht_stbc,
+		 {"STBC", "radiotap.vht.stbc",
+		  FT_BOOLEAN, 8, TFS(&tfs_on_off), IEEE80211_RADIOTAP_SU_VHT_STBC,
+		  "Space Time Block Coding flag", HFILL}},
+		{&hf_radiotap_su_vht_txop_ps,
+		 {"TXOP_PS_NOT_ALLOWED", "radiotap.vht.txop_ps",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_TXOP_PS,
+		  "Flag indicating whether STAs may doze during TXOP", HFILL}},
+		{&hf_radiotap_su_vht_gi,
+		 {"Guard interval", "radiotap.vht.gi",
+		  FT_UINT8, BASE_DEC, VALS(mcs_gi), IEEE80211_RADIOTAP_SU_VHT_SGI,
+		  "Short/Long guard interval", HFILL}},
+		{&hf_radiotap_su_vht_sgi_nsym_da,
+		 {"SGI Nsym disambiguation", "radiotap.vht.nsym_da",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_SGI_NSYM_DA,
+		  "Short Guard Interval Nsym disambiguation", HFILL}},
+		{&hf_radiotap_su_vht_coding,
+		 {"Coding", "radiotap.vht.coding",
+		  FT_UINT8, BASE_DEC, VALS(mcs_fec), IEEE80211_RADIOTAP_SU_VHT_CODING_LDPC,
+		  "Coding", HFILL}},
+		{&hf_radiotap_su_vht_ldpc_extra,
+		 {"LDPC extra OFDM symbol", "radiotap.vht.ldpc_extra",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_LDPC_EXTRA,
+		  "LDPC extra OFDM symbol", HFILL}},
+		{&hf_radiotap_su_vht_bf,
+		 {"Beamformed", "radiotap.vht.beamformed",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_BF,
+		  "Beamformed", HFILL}},
+		{&hf_radiotap_su_vht_bw,
+		 {"Bandwidth", "radiotap.vht.bw",
+		  FT_UINT8, BASE_DEC, VALS(vht_bandwidth), IEEE80211_RADIOTAP_SU_VHT_BW,
+		  "Bandwidth", HFILL}},
+		{&hf_radiotap_su_vht_nsts,
+		 {"Nsts", "radiotap.vht.nsts",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_NSTS,
+		  "Number of Space-time streams", HFILL}},
+		{&hf_radiotap_su_vht_mcs,
+		 {"MCS index", "radiotap.vht.mcs",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_MCS,
+		  "MCS index", HFILL}},
+		{&hf_radiotap_su_vht_nss,
+		 {"Nss", "radiotap.vht.nss",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_NSS,
+		  "Number of spatial streams", HFILL}},
+
+		{&hf_radiotap_gid,
+		 {"Group Id", "radiotap.gid",
+		  FT_UINT8, BASE_DEC, NULL, 0x0,
+		  "VHT Group Id", HFILL}},
+
+		{&hf_radiotap_aid,
+		 {"Partial AID", "radiotap.aid",
+		  FT_UINT16, BASE_DEC, NULL, 0x0,
+		  "VHT partial AID", HFILL}},
+
 		{&hf_radiotap_vendor_ns,
 		 {"Vendor namespace", "radiotap.vendor_namespace",
 		  FT_BYTES, BASE_NONE, NULL, 0x0,
@@ -1304,6 +1560,8 @@
 		&ett_radiotap_vendor,
 		&ett_radiotap_mcs,
 		&ett_radiotap_mcs_known,
+		&ett_radiotap_su_vht,
+		&ett_radiotap_su_vht_known
 	};
 	module_t *radiotap_module;
 
@@ -1509,6 +1767,10 @@
 			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_su_vht, tvb,
+					    offset + 4, 4, ENC_LITTLE_ENDIAN);
+
  always_bits:
 			proto_tree_add_item(present_tree,
 					    hf_radiotap_present_rtap_ns, tvb,
@@ -1939,6 +2201,7 @@
 			}
 			break;
 		}
+
 		case IEEE80211_RADIOTAP_MCS: {
 			proto_item *it;
 			proto_tree *mcs_tree = NULL, *mcs_known_tree;
@@ -2045,7 +2308,178 @@
 			}
 			break;
 		}
+
+		case IEEE80211_RADIOTAP_SU_VHT: {
+			proto_item *it;
+			proto_tree *mcs_tree = NULL, *mcs_known_tree;
+			guint8 mcs_known, mcs_flags, mcs_bw, mcs;
+			guint bandwidth = 0;
+			guint gi_length = 0;
+			guint nss = 0;
+			guint mcs_index = 0;
+			gboolean can_calculate_rate;
+
+			/*
+			 * 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;
+
+			mcs_known = tvb_get_guint8(tvb, offset);
+			mcs_flags = tvb_get_guint8(tvb, offset + 1);
+			mcs_bw = tvb_get_guint8(tvb, offset + 2);
+			mcs = tvb_get_guint8(tvb, offset + 3);
+
+			if (tree) {
+				it = proto_tree_add_item(radiotap_tree, hf_radiotap_su_vht,
+						tvb, offset, 4, ENC_NA);
+				mcs_tree = proto_item_add_subtree(it, ett_radiotap_su_vht);
+				it = proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_known,
+						tvb, offset, 1, mcs_known);
+				mcs_known_tree = proto_item_add_subtree(it, ett_radiotap_su_vht_known);
+
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_stbc,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_txop_ps,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_gi,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_coding,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_bf,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_bw,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_nsts,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_mcs_nss,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_stbc,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_txop_ps,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_GI) {
+				gi_length = (mcs_flags & IEEE80211_RADIOTAP_SU_VHT_SGI) ? 1 : 0;
+				if (mcs_tree) {
+					proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_gi,
+							tvb, offset + 1, 1, mcs_flags);
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_sgi_nsym_da,
+							tvb, offset + 1, 1, mcs_flags);
+				}
+			} else {
+				can_calculate_rate = FALSE;	/* no GI width */
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING) {
+				if (mcs_tree) {
+					proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_coding,
+							tvb, offset + 1, 1, mcs_flags);
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_ldpc_extra,
+							tvb, offset + 1, 1, mcs_flags);
+				}
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_BF) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_bf,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_BW) {
+				guint bw_index = (mcs_bw & IEEE80211_RADIOTAP_SU_VHT_BW) >> 4;
+				if (bw_index <= sizeof(ieee80211_vht_bw2rate_index)/sizeof(ieee80211_vht_bw2rate_index[0]))
+					bandwidth = ieee80211_vht_bw2rate_index[bw_index];
+				else
+					can_calculate_rate = FALSE; /* unknown bandwidth */
+
+				if (mcs_tree)
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_bw,
+							tvb, offset + 2, 1, bw_index,
+							"Bandwidth: %s",
+							val_to_str(bw_index, vht_bandwidth, "Unknown (0x%02x)"));
+			} else {
+				can_calculate_rate = FALSE;	/* no bandwidth */
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS) {
+				guint nsts = (mcs_bw & IEEE80211_RADIOTAP_SU_VHT_NSTS);
+				if (mcs_tree)
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_nsts,
+							tvb, offset + 2, 1, nsts,
+							"Space-time streams: %u", nsts);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS) {
+				mcs_index = (mcs & IEEE80211_RADIOTAP_SU_VHT_MCS);
+				nss = ((mcs & IEEE80211_RADIOTAP_SU_VHT_NSS) >> 4) + 1;
+				if (mcs_index > MAX_MCS_VHT_INDEX)
+					can_calculate_rate = FALSE;	/* Invalid index */
+
+				if (mcs_tree) {
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_nss,
+							tvb, offset + 3, 1, nss,
+							"Spatial streams: %u", nss);
+					ti = proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_mcs,
+							tvb, offset + 3, 1, mcs_index,
+							"MCS: %u", mcs_index);
+
+					if (mcs_index > MAX_MCS_VHT_INDEX)
+						proto_item_append_text(ti, " (invalid)");
+					else
+						proto_item_append_text(ti, " (%s %s)",
+								ieee80211_vhtinfo[mcs_index].modulation,
+								ieee80211_vhtinfo[mcs_index].coding_rate);
+				}
+			} else {
+				can_calculate_rate = FALSE;	/* no MCS index */
+			}
+
+			if (can_calculate_rate) {
+				if (ieee80211_vhtinfo[mcs_index].rates[bandwidth][gi_length] != 0.0) {
+					float rate = ieee80211_vhtinfo[mcs_index].rates[bandwidth][gi_length] * nss;
+					col_add_fstr(pinfo->cinfo, COL_TX_RATE, "%.1f", rate);
+					if (radiotap_tree) {
+						rate_ti = proto_tree_add_float_format(radiotap_tree,
+								hf_radiotap_datarate,
+								tvb, offset, 5, rate,
+								"Data Rate: %.1f Mb/s", rate);
+						PROTO_ITEM_SET_GENERATED(rate_ti);
+					}
+				}
+			}
+
+			break;
 		}
+
+		case IEEE80211_RADIOTAP_GROUP_ID:
+			if (tree) {
+				proto_tree_add_uint(radiotap_tree,
+						hf_radiotap_gid, tvb,
+						offset, 1,
+						tvb_get_guint8(tvb, offset));
+			}
+			break;
+
+		case IEEE80211_RADIOTAP_PARTIAL_AID:
+			if (tree) {
+				proto_tree_add_uint(radiotap_tree,
+						hf_radiotap_aid, tvb,
+						offset, 2,
+						tvb_get_letohs(tvb, offset));
+			}
+			break;
+		}
 	}
 
 	if (err != -ENOENT && tree) {
Index: epan/dissectors/packet-ieee80211-radiotap-iter.c
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap-iter.c	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap-iter.c	(working copy)
@@ -50,11 +50,16 @@
 	/* [IEEE80211_RADIOTAP_RTS_RETRIES] = 16 */		{ 1, 1 },
 	/* [IEEE80211_RADIOTAP_DATA_RETRIES] = 17 */		{ 1, 1 },
 	/* [IEEE80211_RADIOTAP_XCHANNEL] = 18 */		{ 0, 0 }, /* Unofficial, used by FreeBSD */
-	/* [IEEE80211_RADIOTAP_MCS] = 19 */			{ 1, 3 }
+	/* [IEEE80211_RADIOTAP_MCS] = 19 */			{ 1, 3 },
+	/* [IEEE80211_RADIOTAP_SU_VHT] = 20 */			{ 1, 4 },
+	/* [IEEE80211_RADIOTAP_GID] = 21 */			{ 1, 1 },
+	/* [IEEE80211_RADIOTAP_AID] = 22 */			{ 2, 2 },
 	/*
 	 * add more here as they are defined in
 	 * include/net/ieee80211_radiotap.h
 	 */
+	{ 0, 0 }, // TODO
+	{ 1, 5 }
 };
 
 static const struct ieee80211_radiotap_namespace radiotap_ns = {

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found] ` <C6E8EE2D6B3ACB4582C1249E834B306505D68C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-06-12 16:51   ` Johannes Berg
       [not found]     ` <1339519879.4531.13.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
  2012-07-04 17:18   ` Alwin Beukers
  2012-07-05  9:08   ` Johannes Berg
  2 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2012-06-12 16:51 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> Hi everyone,
> 
> This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:
> 
> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/GROUP_ID
> http://www.radiotap.org/suggested-fields/PARTIAL_AID
> 
> A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.

What's the reason for splitting it up?

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found]     ` <1339519879.4531.13.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-06-13 10:42       ` Alwin Beukers
       [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306505E99C@SJEXCHMB13.corp.ad.broadcom.com>
       [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306505DF7F-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  0 siblings, 2 replies; 15+ messages in thread
From: Alwin Beukers @ 2012-06-13 10:42 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

[-- Warning: decoded text below may be mangled --]
[-- Attachment #0: Type: text/plain; charset=utf-8, Size: 1185 bytes --]

:tî{m5ÛNµÙ«uçN~ÓM4\x02\"œ\x17®‘êìº-xxž½êò¢w“†+"±ªk¢š,jWè­§]Šx,ºšh®×è¯Í6×Vœ\x16‹«~'¥vÌ\x1e­æuçm¢Ø^²è zË^uøž•Û,yËb¢xm¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÒQQÓ†Ûiÿü0¶Š‹Z¦ŠàþË ë-y×âzWlüÅ\x15\x1d8m¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÆDå\x0f 8m¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÏ\x01\x14È\0°\b\f\x05¢­ë!j¹)j×!~Šéj»"ž\x04”TtÆDå\x0f 6§tð\x11L€\v\0€â±«miÈ^uhZ¶Ëaz·š²‰ß¢»)–+mŠx"¶êI¢\x16§ë\x13…êÞjÊ'~Šì¦X­¶)àŠÛ©ŠËhjú"uìm­ª/z¸^iÚÞ•«^vÚ\fPÂ\f;\b^×¬r¸›Šx\x15\x1d4”<ðÔ±8^±êZ­«b¢x¬m«\x1ev‰í…çb}÷«z{O,#áy§^­ú+™«lTtÒ `5ü\r¿\x05ú+IF§tÅ\x0f<5,ICÏ\rK\x0ež\¨ãRM#\x02I©Ý
‡bž\aâzWOj»bjP\b\x0e'^žØŸ‰ë+yÈ©‰éí\x1aº.¤€â±©pk+4i×kzË\x1evÚ\0?ùž²\x14“\x02Šúݧ]­ë,yÛhI0\fPóÃRÃRM#\x02I©Ý
‡bž\aâzWl~Šî¦Ú\x1f¢êî±êì=ªí‰©@ 8¬ž‹Z¦™bq¦åxj躒\x03ŠÍzØ	e~'¥vÇ(šj'¶†è¶\x14”jwLQªÞŠ{ay%\x15\x1d7âzWS…ã\x14Tt߉é]r‰íj)ìi×b¶*'jX§~Šæjبú+1CÏ\rK\x13…á‘9CÈ\r©Ý<\x04S \x02À 7âzWl…«Þ½ªòŠx/j[ž¢¶©¦Xœi¸¥ŠÜ’¡ú+ICÏ\rK2¢ì(ºWeŠG¥Ê\x16¯y%\x15\x1d6§tð\x11L€\v\0€ß‰é]±©Ý™¬›y¡‘9CÈ\røž•×è­%-…á‘9CÈ\røž•Ú'—*k¢øzÇb­ç-Š‰âú-…«\¢é]j[(mç^µêæŠw~º&<\x04S \x02À 6§wú+0\0¡y§^¬Z+1CÏ\rK2¢ì(ºWaj÷’QQÓ~Ší…ç(šj'~'¥vƬÁéejÃRM/Ì	/¡اú+¶\x17ŸŠ»-ºÇ«1EGMú+5$ÒüÀ’ü*\x1dŠx\x1f¢¶v+b¢v¥ºÇ«±©Ý\x19\x13”<€ÁÉÊ&n)âž\aâzWlÁç\x1až·¹Çœ¢je{\x18­É«m…ç±¥éìz‡ì¢g¢ÊÞjǝ¢÷«…æÂ\x16­j·²¢ê톋 †Û(ž\x18¬\x02[(#\x06¬Â‰Ýz¸§‚'ðzwžu©e¡ûazIèÂwåj\v"%\x15\x1d4áxÀ’~'¥u§íz¼!‰ÈRQQÓÁ«&¡×¥yÖ¥²ˆZ²Ø^±æî´‡hžÙ'£\vaz¶­Š‰Ú•æÞ†)ݶ\x17¦	©èæ¬²éžiÚâ½êájÇî–Vœqë,¶‹axòÂ>\x17šuêڝÛaºÇ\x1aø¥–)æ¢Ëh}øž•Û"žØ^IEGMøž•Ôájy,\x02\"ž:!jyÞ

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found]             ` <1339672828.4461.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-06-14 12:05               ` Arend van Spriel
  0 siblings, 0 replies; 15+ messages in thread
From: Arend van Spriel @ 2012-06-14 12:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Alwin Beukers, radiotap-sUITvd46vNxg9hUCZPvPmw

On 06/14/2012 01:20 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 08:19 +0000, Alwin Beukers wrote:
>> Hi Johannes,
>>
>> I'm not seeing my reply to you (and cc to radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org) showing up on the list, am I doing something wrong?
> 
> Not sure, I don't see it either but never had issues with the list
> before
> 
> johannes
> 

I registered to radiotap list a couple of weeks ago, but never received
any email from it apart from the confirmation email (from
majordomo-qavaossjCcEdnm+yROfE0A@public.gmane.org). Any idea who to contact. First let me see if this
message is getting through ;-)

Gr. AvS

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Sorry for the line noise, was: Re: [RFC] VHT fields
       [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306505DF7F-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-06-15  9:03           ` " S.P.Zeidler
  0 siblings, 0 replies; 15+ messages in thread
From: S.P.Zeidler @ 2012-06-15  9:03 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: Johannes Berg, radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

Hi,

the following is the result of trying to force majordomo to propagate a mail
it previously had refused, not the original content sent:

Thus wrote Alwin Beukers (alwin-dY08KVG/lbpWk0Htik3J/w@public.gmane.org):

> :t?{m5?N?٫u?N~?M4\x02\"?\x17????º-xx?????w??+"??k??,jW譧]?x,??h?????6?V?\x16??~'?v?\x1e???u?m??^?? z?^u????,y?b?xm????\f+iب??h?\x0f??\b\x1e?ם~'?v??QQӆ?i??0¶???Z????ˠ??-y??zWl??\x15\x1d8m????\f+iب??h?\x0f??\b\x1e?ם~'?v??D?\x0f 8m????\f+iب??h?\x0f??\b\x1e?ם~'?v??\x01\x14?

From a first look at the mail that's causing problems (and mail that's not),
base64 encoded utf-8 meets a bug. Fixing that will take a while.

regards,
	spz

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found] ` <C6E8EE2D6B3ACB4582C1249E834B306505D68C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  2012-06-12 16:51   ` Johannes Berg
@ 2012-07-04 17:18   ` Alwin Beukers
       [not found]     ` <C6E8EE2D6B3ACB4582C1249E834B306506E807-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  2012-07-05  9:08   ` Johannes Berg
  2 siblings, 1 reply; 15+ messages in thread
From: Alwin Beukers @ 2012-07-04 17:18 UTC (permalink / raw)
  To: radiotap-sUITvd46vNxg9hUCZPvPmw
  Cc: Arend Van Spriel, Pieter-Paul Giesberts, Bill Stafford,
	Alwin Beukers, Johannes Berg

Hi everyone,

Thanks for the feedback on the 802.11ac fields.

If there are no further suggestions, I would like to request the SU_VHT, MU_VHT and 
PARTIAL_AID fields to be moved to the defined-fields section and have their bit numbers
assigned. As the group ID was merged into SU_VHT, the GROUP_ID field can be dropped.

With the bit numbers assigned I can deliver the Wireshark patch for parsing these fields.

Thanks,
Alwin

> Hi everyone,
> 
> This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:
> 
> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/GROUP_ID
> http://www.radiotap.org/suggested-fields/PARTIAL_AID
>
> A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.
> 
> Any thoughts?
> 
> Thanks,
> Alwin

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found]     ` <C6E8EE2D6B3ACB4582C1249E834B306506E807-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-07-05  8:37       ` Johannes Berg
       [not found]         ` <1341477463.4455.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2012-07-05  8:37 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Wed, 2012-07-04 at 17:18 +0000, Alwin Beukers wrote:
> Hi everyone,
> 
> Thanks for the feedback on the 802.11ac fields.
> 
> If there are no further suggestions, I would like to request the SU_VHT, MU_VHT and 
> PARTIAL_AID fields to be moved to the defined-fields section and have their bit numbers
> assigned. As the group ID was merged into SU_VHT, the GROUP_ID field can be dropped.
> 
> With the bit numbers assigned I can deliver the Wireshark patch for parsing these fields.

Can we also have a producer of the fields? I realise that may be hard to
do now without a driver? :-)

Please just use the next free bit numbers though, swapping those out
later will be easy, and that way we can see the code before adopting the
changes, this helps flush out implementation issues.

See also http://www.radiotap.org/Standardisation

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found] ` <C6E8EE2D6B3ACB4582C1249E834B306505D68C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  2012-06-12 16:51   ` Johannes Berg
  2012-07-04 17:18   ` Alwin Beukers
@ 2012-07-05  9:08   ` Johannes Berg
       [not found]     ` <1341479327.4455.35.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
  2 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2012-07-05  9:08 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:

> http://www.radiotap.org/suggested-fields/GROUP_ID

(I just deleted that)

> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/PARTIAL_AID

So one thing that strikes me is that this is not extensible at all any
more now inside the VHT fields, all the known flags are already used up.
I don't know if there's anything else in VHT that could possibly be of
relevance in the future though? Also, how stable is the VHT amendment? I
haven't followed it closely.

With the SU_VHT field being 5 bytes and the PARTIAL_AID requiring 2 byte
alignment, having them follow each other wastes a byte. I'm not worried
about that at all, but I wonder if splitting this into three fields is
really worth it? Given the many dependencies on SU/MU in all fields, it
almost seems that making them all one (slightly bigger) VHT field would
be easier to use?

If we wanted to go there, we could even use a union:

require 2 byte alignment of the VHT field, and then have
u8 known
u8 flags
u8 bw
u8 mcs
u8 gid
union {
	struct {
		u8 pad
		u16 partial_aid
	} su
	struct {
		u8 user1, user2, user3
	} mu
}



Also, looking at the fields in more detail, does it really make sense to
have the bits packed so tightly? NSTS and bandwidth for example, do they
really belong into the same field?

Also I think the coding/NSTS for the first and three other users should
be more regular? It seems then it wouldn't be possible to squeeze it all
into one byte per user, but ... does that really matter so much? This
isn't a huge amount of data.

Ok wait, I don't even see now how to distinguish between SU and MU
frames, except by the presence of the other fields? That's a bit
awkward, don't you think?

I think overall I'd probably just use a bit more space and make the
format more regular instead of packing MU/SU fields like MCS in with
common fields like NSS.


How about this:

u8 known         - maybe split this up further, or are there technical
                   reasons that e.g. if the coding is known the LDPC
                   extra symbol must also be known?
u8 flags         - add a MU/SU flag (and hope that all receivers know
                   this, or add a known flag?)
u8 bw            - only the bandwidth, not NSTS
u8 nss           - or maybe this could be packed with the bandwidth
u16 P_AID        - partial AID, valid only if SU
u8 NSTS[4]       - NSTS for up to 4 users
u8 mcs_coding[4] - MCS/coding/coding_known(?) for up to 4 users


Overall, this is just 6 bytes longer than your previous encoding (or
maybe 7 or 8 if flags/known now need to be extended), but I think it's
much more regular?

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found]         ` <1341477463.4455.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-07-23 13:43           ` Alwin Beukers
  0 siblings, 0 replies; 15+ messages in thread
From: Alwin Beukers @ 2012-07-23 13:43 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford


> On Wed, 2012-07-04 at 17:18 +0000, Alwin Beukers wrote:
> > Hi everyone,
> >
> > Thanks for the feedback on the 802.11ac fields.
> >
> > If there are no further suggestions, I would like to request the SU_VHT,
> > MU_VHT and
> > PARTIAL_AID fields to be moved to the defined-fields section and have
> > their bit numbers
> > assigned. As the group ID was merged into SU_VHT, the GROUP_ID field
> > can be dropped.
> >
> > With the bit numbers assigned I can deliver the Wireshark patch for parsing
> > these fields.
> 
> Can we also have a producer of the fields? I realise that may be hard to
> do now without a driver? :-)

Yes, that is somewhat of a challenge :-) 

I do have packet captures with the VHT field that could be made available,
although I realize it's not ideal...

Alwin
 
> Please just use the next free bit numbers though, swapping those out
> later will be easy, and that way we can see the code before adopting the
> changes, this helps flush out implementation issues.
> 
> See also http://www.radiotap.org/Standardisation
> 
> johannes
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found]     ` <1341479327.4455.35.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-07-23 14:47       ` Alwin Beukers
       [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306508054B-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Alwin Beukers @ 2012-07-23 14:47 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

> On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> 
> > http://www.radiotap.org/suggested-fields/GROUP_ID
> 
> (I just deleted that)
> 
> > http://www.radiotap.org/suggested-fields/SU_VHT
> > http://www.radiotap.org/suggested-fields/MU_VHT
> > http://www.radiotap.org/suggested-fields/PARTIAL_AID
> 
> So one thing that strikes me is that this is not extensible at all any
> more now inside the VHT fields, all the known flags are already used up.
> I don't know if there's anything else in VHT that could possibly be of
> relevance in the future though? Also, how stable is the VHT amendment? I
> haven't followed it closely.

I agree, it's a tight fit. I can't comment on the stability of the VHT amendment,
but it would be good to have some room left anyway. We might even want 
to add some info for 802.11ad at some point in the future, as it's also VHT.

> With the SU_VHT field being 5 bytes and the PARTIAL_AID requiring 2 byte
> alignment, having them follow each other wastes a byte. I'm not worried
> about that at all, but I wonder if splitting this into three fields is
> really worth it? Given the many dependencies on SU/MU in all fields, it
> almost seems that making them all one (slightly bigger) VHT field would
> be easier to use?
> 
> If we wanted to go there, we could even use a union:
> 
> require 2 byte alignment of the VHT field, and then have
> u8 known
> u8 flags
> u8 bw
> u8 mcs
> u8 gid
> union {
> 	struct {
> 		u8 pad
> 		u16 partial_aid
> 	} su
> 	struct {
> 		u8 user1, user2, user3
> 	} mu
> }
> 
> 
> 
> Also, looking at the fields in more detail, does it really make sense to
> have the bits packed so tightly? NSTS and bandwidth for example, do they
> really belong into the same field?
> 
> Also I think the coding/NSTS for the first and three other users should
> be more regular? It seems then it wouldn't be possible to squeeze it all
> into one byte per user, but ... does that really matter so much? This
> isn't a huge amount of data.
> 
> Ok wait, I don't even see now how to distinguish between SU and MU
> frames, except by the presence of the other fields? That's a bit
> awkward, don't you think?
> 
> I think overall I'd probably just use a bit more space and make the
> format more regular instead of packing MU/SU fields like MCS in with
> common fields like NSS.

These are all valid points. If using a bit more space is not an issue,
combining these three fields would simplify things significantly.
 
> How about this:
> 
> u8 known         - maybe split this up further, or are there technical
>                    reasons that e.g. if the coding is known the LDPC
>                    extra symbol must also be known?
> u8 flags         - add a MU/SU flag (and hope that all receivers know
>                    this, or add a known flag?)
> u8 bw            - only the bandwidth, not NSTS
> u8 nss           - or maybe this could be packed with the bandwidth
> u16 P_AID        - partial AID, valid only if SU
> u8 NSTS[4]       - NSTS for up to 4 users
> u8 mcs_coding[4] - MCS/coding/coding_known(?) for up to 4 users

I have put a new proposal at http://www.radiotap.org/suggested-fields/VHT
which is basically the format you are proposing but with a few tweaks.

As there is a fixed relation between NSS and NSTS, we can get by with only
having four per-user NSS values in the field and drop NSTS[4], which saves
one byte. The per-user MCS and NSS values are combined as they go
naturally together.

There is no explicit difference between MU and SU frames, all the info
is available in the VHT field. If required, one can still determine MU or SU 
from the group ID and hide information that is not applicable.
 
> Overall, this is just 6 bytes longer than your previous encoding (or
> maybe 7 or 8 if flags/known now need to be extended), but I think it's
> much more regular?

The combined field is now 12 bytes and has some room to spare. I think
it's a nice improvement over the previous proposal, would you agree?

Alwin
 
> johannes
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306508054B-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-07-23 15:25           ` Johannes Berg
       [not found]             ` <1343057111.4584.22.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2012-07-23 15:25 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Mon, 2012-07-23 at 14:47 +0000, Alwin Beukers wrote:

> > So one thing that strikes me is that this is not extensible at all any
> > more now inside the VHT fields, all the known flags are already used up.
> > I don't know if there's anything else in VHT that could possibly be of
> > relevance in the future though? Also, how stable is the VHT amendment? I
> > haven't followed it closely.
> 
> I agree, it's a tight fit. I can't comment on the stability of the VHT amendment,
> but it would be good to have some room left anyway. We might even want 
> to add some info for 802.11ad at some point in the future, as it's also VHT.

Yeah, though that could be done as a separate field too.

> I have put a new proposal at http://www.radiotap.org/suggested-fields/VHT
> which is basically the format you are proposing but with a few tweaks.
> 
> As there is a fixed relation between NSS and NSTS, we can get by with only
> having four per-user NSS values in the field and drop NSTS[4], which saves
> one byte. The per-user MCS and NSS values are combined as they go
> naturally together.

Makes sense.

> There is no explicit difference between MU and SU frames, all the info
> is available in the VHT field. If required, one can still determine MU or SU 
> from the group ID and hide information that is not applicable.

Right, that also makes sense.
 
> The combined field is now 12 bytes and has some room to spare. I think
> it's a nice improvement over the previous proposal, would you agree?

Yes, I like it.

One question on this:

"Note: for receive capture, the total bandwidth of the transmitter is
not generally known, so the bandwidth will only be recorded as 20, 40,
80, or 160, with the Channel field indicating the transmission center
frequency."

I'm not sure that's generally true, though it points out something that
we may need to define in more detail: we have (in Linux at least) always
had the Channel field indicate the control channel, not the transmission
center frequency.

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found]             ` <1343057111.4584.22.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-07-27 14:41               ` Alwin Beukers
       [not found]                 ` <C6E8EE2D6B3ACB4582C1249E834B306508499C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Alwin Beukers @ 2012-07-27 14:41 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

> One question on this:
> 
> "Note: for receive capture, the total bandwidth of the transmitter is
> not generally known, so the bandwidth will only be recorded as 20, 40,
> 80, or 160, with the Channel field indicating the transmission center
> frequency."
> 
> I'm not sure that's generally true, though it points out something that
> we may need to define in more detail: we have (in Linux at least) always
> had the Channel field indicate the control channel, not the transmission
> center frequency.

I think indicating the control channel wouldn't work very well in this case, 
especially for >40MHz bandwidths.

How do you feel about extending [X]Channel with a flag that indicates 
we're specifying transmission center frequency?

Alwin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found]                 ` <C6E8EE2D6B3ACB4582C1249E834B306508499C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-08-20 16:42                   ` Johannes Berg
       [not found]                     ` <1345480938.4459.40.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2012-08-20 16:42 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Fri, 2012-07-27 at 14:41 +0000, Alwin Beukers wrote:
> > One question on this:
> > 
> > "Note: for receive capture, the total bandwidth of the transmitter is
> > not generally known, so the bandwidth will only be recorded as 20, 40,
> > 80, or 160, with the Channel field indicating the transmission center
> > frequency."
> > 
> > I'm not sure that's generally true, though it points out something that
> > we may need to define in more detail: we have (in Linux at least) always
> > had the Channel field indicate the control channel, not the transmission
> > center frequency.
> 
> I think indicating the control channel wouldn't work very well in this case, 
> especially for >40MHz bandwidths.
> 
> How do you feel about extending [X]Channel with a flag that indicates 
> we're specifying transmission center frequency?

I don't think that'd be a good idea, it wouldn't be backward compatible.
We're just discussing for Linux how to specify the channel parameters
and we need to consider 80+80 as well. Maybe these discussions should
cross-pollinate.

I see two basic options:
 * continue what we do now, and specify the control channel & type
   around it (40+/40+,...)
   + this is how linux works now
   - many many channel types (4 for 80 MHz, 8 for 160 MHz)
   - doesn't handle 80+80
 * specify the center frequency, width & control channel offset
   + more aligned with the spec (?)
   - requires backward compat handling
   - doesn't handle 80+80

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: [RFC] VHT fields
       [not found]                     ` <1345480938.4459.40.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
@ 2012-08-24  7:46                       ` Alwin Beukers
       [not found]                         ` <C6E8EE2D6B3ACB4582C1249E834B30650B4151-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
  0 siblings, 1 reply; 15+ messages in thread
From: Alwin Beukers @ 2012-08-24  7:46 UTC (permalink / raw)
  To: Johannes Berg
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

> We're just discussing for Linux how to specify the channel parameters
> and we need to consider 80+80 as well. Maybe these discussions should
> cross-pollinate.

Yes. However, this issue isn't directly related to or blocking the VHT field 
proposal, is it? Can I go ahead and post an adaptation request for that?

> I see two basic options:
>  * continue what we do now, and specify the control channel & type
>    around it (40+/40+,...)
>    + this is how linux works now
>    - many many channel types (4 for 80 MHz, 8 for 160 MHz)
>    - doesn't handle 80+80

When it comes to radiotap, this might do as an interim solution for chips
that don't support 80+80 yet. The new channel types would fit in the
XChannel field.

>  * specify the center frequency, width & control channel offset
>    + more aligned with the spec (?)
>    - requires backward compat handling
>    - doesn't handle 80+80

I feel this is the best long-term solution. The 80+80 case could be handled 
By adding a secondary center frequency.

Regards,
Alwin


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [RFC] VHT fields
       [not found]                         ` <C6E8EE2D6B3ACB4582C1249E834B30650B4151-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
@ 2012-08-24  9:00                           ` Johannes Berg
  0 siblings, 0 replies; 15+ messages in thread
From: Johannes Berg @ 2012-08-24  9:00 UTC (permalink / raw)
  To: Alwin Beukers
  Cc: radiotap-sUITvd46vNxg9hUCZPvPmw, Arend Van Spriel,
	Pieter-Paul Giesberts, Bill Stafford

On Fri, 2012-08-24 at 07:46 +0000, Alwin Beukers wrote:
> > We're just discussing for Linux how to specify the channel parameters
> > and we need to consider 80+80 as well. Maybe these discussions should
> > cross-pollinate.
> 
> Yes. However, this issue isn't directly related to or blocking the VHT field 
> proposal, is it? Can I go ahead and post an adaptation request for that?

Right.

> > I see two basic options:
> >  * continue what we do now, and specify the control channel & type
> >    around it (40+/40+,...)
> >    + this is how linux works now
> >    - many many channel types (4 for 80 MHz, 8 for 160 MHz)
> >    - doesn't handle 80+80
> 
> When it comes to radiotap, this might do as an interim solution for chips
> that don't support 80+80 yet. The new channel types would fit in the
> XChannel field.

We could even do both unless the channel is 80+80 for older parsers like
existing wireshark since they'd then be able to parse at least
something.

> >  * specify the center frequency, width & control channel offset
> >    + more aligned with the spec (?)
> >    - requires backward compat handling
> >    - doesn't handle 80+80
> 
> I feel this is the best long-term solution. The 80+80 case could be handled 
> By adding a secondary center frequency.

Yeah, something like that. We need to work that out in Linux too, not
even sure there are chips that will support 80+80 though?

johannes

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-12 15:05 [RFC] VHT fields Alwin Beukers
     [not found] ` <C6E8EE2D6B3ACB4582C1249E834B306505D68C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-06-12 16:51   ` Johannes Berg
     [not found]     ` <1339519879.4531.13.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-06-13 10:42       ` Alwin Beukers
     [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306505E99C@SJEXCHMB13.corp.ad.broadcom.com>
     [not found]           ` <1339672828.4461.0.camel@jlt3.sipsolutions.net>
     [not found]             ` <1339672828.4461.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-06-14 12:05               ` Arend van Spriel
     [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306505DF7F-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-06-15  9:03           ` Sorry for the line noise, was: " S.P.Zeidler
2012-07-04 17:18   ` Alwin Beukers
     [not found]     ` <C6E8EE2D6B3ACB4582C1249E834B306506E807-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-07-05  8:37       ` Johannes Berg
     [not found]         ` <1341477463.4455.17.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-07-23 13:43           ` Alwin Beukers
2012-07-05  9:08   ` Johannes Berg
     [not found]     ` <1341479327.4455.35.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-07-23 14:47       ` Alwin Beukers
     [not found]         ` <C6E8EE2D6B3ACB4582C1249E834B306508054B-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-07-23 15:25           ` Johannes Berg
     [not found]             ` <1343057111.4584.22.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-07-27 14:41               ` Alwin Beukers
     [not found]                 ` <C6E8EE2D6B3ACB4582C1249E834B306508499C-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-08-20 16:42                   ` Johannes Berg
     [not found]                     ` <1345480938.4459.40.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-08-24  7:46                       ` Alwin Beukers
     [not found]                         ` <C6E8EE2D6B3ACB4582C1249E834B30650B4151-HXj2mutaA2obnnZVN+9SiJr/X4hKkxxPpWgKQ6/u3Fg@public.gmane.org>
2012-08-24  9:00                           ` Johannes Berg

RadioTap Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/radiotap/0 radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ https://lore.kernel.org/radiotap \
		radiotap@radiotap.org
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.netbsd.radiotap


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git