* Patches for STBC Standartisation [not found] ` <1367527479.11375.19.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2013-05-03 19:53 ` Oleksij Rempel 2013-05-07 7:40 ` Standardisation - adding 2 bit STBC and Ness to MCS Oleksij Rempel 1 sibling, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 19:53 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Cc: Oleksij Rempel Here are two series of patches. First are kernel patches and ath9k driver patch. Second, is patch for tcpdump. All of them was tested for 1,2 and 3 stream scenarious. Sinse i do not have hardware which can recive more than 1 STBC stream, i did some hacks to to produce this kind of captures. Oleksij Rempel (3): mac80211: add STBC flag for radiotap ath9k: remove useless flag conversation. ath9k: check for Rx-STBC flag and pass it to ieee80211 -- 1.8.1.2 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <1367527479.11375.19.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2013-05-03 19:53 ` Patches for STBC Standartisation Oleksij Rempel @ 2013-05-07 7:40 ` Oleksij Rempel 1 sibling, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-07 7:40 UTC (permalink / raw) To: Johannes Berg Cc: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA Am 02.05.2013 22:44, schrieb Johannes Berg: > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: > >>> With this I believe we have everything needed to start the 3 week >>> comment period. > > Yeah, I guess there was plenty of time. I would have preferred a > separate thread, but I guess there's little enough traffic on this list > so it doesn't really matter. > >> There is a bit more then 3 week now. I would like to have this approved :) >> Are there any thing needed to finish this? > > http://www.radiotap.org/Standardisation > > johannes > ping. Johannes, are you the one who says last word on standardisation for radiotap? -- Regards, Oleksij ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <1367610836-3303-1-git-send-email-linux@rempel-privat.de>]
[parent not found: <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]
* [PATCH 1/3] mac80211: add STBC flag for radiotap [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> @ 2013-05-03 19:53 ` Oleksij Rempel 2013-05-03 19:53 ` [PATCH 2/3] ath9k: remove useless flag conversation Oleksij Rempel ` (3 subsequent siblings) 4 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 19:53 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Cc: Oleksij Rempel Signed-off-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> --- include/net/ieee80211_radiotap.h | 7 +++++++ include/net/mac80211.h | 4 ++++ net/mac80211/main.c | 3 ++- net/mac80211/rx.c | 4 ++++ net/mac80211/status.c | 3 ++- 5 files changed, 19 insertions(+), 2 deletions(-) diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h index c399963..c6d07cb 100644 --- a/include/net/ieee80211_radiotap.h +++ b/include/net/ieee80211_radiotap.h @@ -269,6 +269,7 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT 0x08 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC 0x10 +#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20 #define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03 #define IEEE80211_RADIOTAP_MCS_BW_20 0 @@ -278,6 +279,12 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_SGI 0x04 #define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10 +#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60 +#define IEEE80211_RADIOTAP_MCS_STBC_1 1 +#define IEEE80211_RADIOTAP_MCS_STBC_2 2 +#define IEEE80211_RADIOTAP_MCS_STBC_3 3 + +#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5 /* For IEEE80211_RADIOTAP_AMPDU_STATUS */ #define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN 0x0001 diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 04c2d46..2b8faeb 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -805,6 +805,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info) * on this subframe * @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC * is stored in the @ampdu_delimiter_crc field) + * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3 */ enum mac80211_rx_flags { RX_FLAG_MMIC_ERROR = BIT(0), @@ -832,8 +833,11 @@ enum mac80211_rx_flags { RX_FLAG_80MHZ = BIT(23), RX_FLAG_80P80MHZ = BIT(24), RX_FLAG_160MHZ = BIT(25), + RX_FLAG_STBC_MASK = BIT(26) | BIT(27), }; +#define RX_FLAG_STBC_SHIFT 26 + /** * struct ieee80211_rx_status - receive status * diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 8a7bfc4..44191a3 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -589,7 +589,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len, local->hw.conf.short_frame_max_tx_count = wiphy->retry_short; local->hw.radiotap_mcs_details = IEEE80211_RADIOTAP_MCS_HAVE_MCS | IEEE80211_RADIOTAP_MCS_HAVE_GI | - IEEE80211_RADIOTAP_MCS_HAVE_BW; + IEEE80211_RADIOTAP_MCS_HAVE_BW | + IEEE80211_RADIOTAP_MCS_HAVE_STBC; local->hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI | IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH; local->hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES; diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index c8447af..c6b3c62 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local, pos += 2; if (status->flag & RX_FLAG_HT) { + unsigned int stbc = status->flag & RX_FLAG_STBC_MASK; rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS); *pos++ = local->hw.radiotap_mcs_details; *pos = 0; @@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local, *pos |= IEEE80211_RADIOTAP_MCS_BW_40; if (status->flag & RX_FLAG_HT_GF) *pos |= IEEE80211_RADIOTAP_MCS_FMT_GF; + if (stbc) + *pos |= (stbc >> RX_FLAG_STBC_SHIFT) + << IEEE80211_RADIOTAP_MCS_STBC_SHIFT; pos++; *pos++ = status->rate_idx; } diff --git a/net/mac80211/status.c b/net/mac80211/status.c index 4343920..41143f8 100644 --- a/net/mac80211/status.c +++ b/net/mac80211/status.c @@ -312,7 +312,8 @@ static void ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS); pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS | IEEE80211_RADIOTAP_MCS_HAVE_GI | - IEEE80211_RADIOTAP_MCS_HAVE_BW; + IEEE80211_RADIOTAP_MCS_HAVE_BW | + IEEE80211_RADIOTAP_MCS_HAVE_STBC; if (info->status.rates[0].flags & IEEE80211_TX_RC_SHORT_GI) pos[1] |= IEEE80211_RADIOTAP_MCS_SGI; if (info->status.rates[0].flags & IEEE80211_TX_RC_40_MHZ_WIDTH) -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 2/3] ath9k: remove useless flag conversation. [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-03 19:53 ` [PATCH 1/3] mac80211: add STBC flag for radiotap Oleksij Rempel @ 2013-05-03 19:53 ` Oleksij Rempel 2013-05-03 19:53 ` [PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211 Oleksij Rempel ` (2 subsequent siblings) 4 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 19:53 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Cc: Oleksij Rempel some flags used only outside of ath9k - In this case we can use "enum mac80211_rx_flags" and pass it upstream without extra conversation. Signed-off-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> --- drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++-- drivers/net/wireless/ath/ath9k/mac.c | 11 +++++++---- drivers/net/wireless/ath/ath9k/mac.h | 1 + drivers/net/wireless/ath/ath9k/recv.c | 5 +---- 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c index 301bf72..5163abd 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c @@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs, rxs->rs_status = 0; rxs->rs_flags = 0; + rxs->flag = 0; rxs->rs_datalen = rxsp->status2 & AR_DataLen; rxs->rs_tstamp = rxsp->status3; @@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs, rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0; rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0; rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7); - rxs->rs_flags = (rxsp->status4 & AR_GI) ? ATH9K_RX_GI : 0; - rxs->rs_flags |= (rxsp->status4 & AR_2040) ? ATH9K_RX_2040 : 0; + rxs->flag |= (rxsp->status4 & AR_GI) ? RX_FLAG_SHORT_GI : 0; + rxs->flag |= (rxsp->status4 & AR_2040) ? RX_FLAG_40MHZ : 0; rxs->evm0 = rxsp->status6; rxs->evm1 = rxsp->status7; diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c index 498fee0..a52081d 100644 --- a/drivers/net/wireless/ath/ath9k/mac.c +++ b/drivers/net/wireless/ath/ath9k/mac.c @@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, rs->rs_status = 0; rs->rs_flags = 0; + rs->flag = 0; rs->rs_datalen = ads.ds_rxstatus1 & AR_DataLen; rs->rs_tstamp = ads.AR_RcvTimestamp; @@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, rs->rs_moreaggr = (ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0; rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna); - rs->rs_flags = - (ads.ds_rxstatus3 & AR_GI) ? ATH9K_RX_GI : 0; - rs->rs_flags |= - (ads.ds_rxstatus3 & AR_2040) ? ATH9K_RX_2040 : 0; + + /* directly mapped flags for ieee80211_rx_status */ + rs->flag |= + (ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0; + rs->flag |= + (ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0; if (ads.ds_rxstatus8 & AR_PreDelimCRCErr) rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE; diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h index 5865f92..3f1e775 100644 --- a/drivers/net/wireless/ath/ath9k/mac.h +++ b/drivers/net/wireless/ath/ath9k/mac.h @@ -149,6 +149,7 @@ struct ath_rx_status { u32 evm2; u32 evm3; u32 evm4; + u32 flag; /* see enum mac80211_rx_flags */ }; struct ath_htc_rx_status { diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c index 8be2b5d..b4b758d 100644 --- a/drivers/net/wireless/ath/ath9k/recv.c +++ b/drivers/net/wireless/ath/ath9k/recv.c @@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common, if (rx_stats->rs_rate & 0x80) { /* HT rate */ rxs->flag |= RX_FLAG_HT; - if (rx_stats->rs_flags & ATH9K_RX_2040) - rxs->flag |= RX_FLAG_40MHZ; - if (rx_stats->rs_flags & ATH9K_RX_GI) - rxs->flag |= RX_FLAG_SHORT_GI; + rxs->flag |= rx_stats->flag; rxs->rate_idx = rx_stats->rs_rate & 0x7f; return 0; } -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211 [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-03 19:53 ` [PATCH 1/3] mac80211: add STBC flag for radiotap Oleksij Rempel 2013-05-03 19:53 ` [PATCH 2/3] ath9k: remove useless flag conversation Oleksij Rempel @ 2013-05-03 19:53 ` Oleksij Rempel 2013-05-03 19:53 ` [PATCH] tcpdump: add STBC Rx support Oleksij Rempel 2013-05-04 6:22 ` Patch for radiotap library Oleksij Rempel 4 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 19:53 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Cc: Oleksij Rempel Signed-off-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> --- drivers/net/wireless/ath/ath9k/mac.c | 5 +++++ drivers/net/wireless/ath/ath9k/mac.h | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c index a52081d..d055e38 100644 --- a/drivers/net/wireless/ath/ath9k/mac.c +++ b/drivers/net/wireless/ath/ath9k/mac.c @@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds, (ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0; rs->flag |= (ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0; + if (AR_SREV_9280_20_OR_LATER(ah)) + rs->flag |= + (ads.ds_rxstatus3 & AR_STBC) ? + /* we can only Nss=1 STBC */ + (1 << RX_FLAG_STBC_SHIFT) : 0; if (ads.ds_rxstatus8 & AR_PreDelimCRCErr) rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE; diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h index 3f1e775..b02dfce 100644 --- a/drivers/net/wireless/ath/ath9k/mac.h +++ b/drivers/net/wireless/ath/ath9k/mac.h @@ -534,7 +534,8 @@ struct ar5416_desc { #define AR_2040 0x00000002 #define AR_Parallel40 0x00000004 #define AR_Parallel40_S 2 -#define AR_RxStatusRsvd30 0x000000f8 +#define AR_STBC 0x00000008 /* on ar9280 and later */ +#define AR_RxStatusRsvd30 0x000000f0 #define AR_RxAntenna 0xffffff00 #define AR_RxAntenna_S 8 -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH] tcpdump: add STBC Rx support [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> ` (2 preceding siblings ...) 2013-05-03 19:53 ` [PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211 Oleksij Rempel @ 2013-05-03 19:53 ` Oleksij Rempel 2013-05-04 6:22 ` Patch for radiotap library Oleksij Rempel 4 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 19:53 UTC (permalink / raw) To: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Cc: Oleksij Rempel Signed-off-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> --- ieee802_11_radio.h | 6 ++++++ print-802_11.c | 5 +++++ 2 files changed, 11 insertions(+) diff --git a/ieee802_11_radio.h b/ieee802_11_radio.h index 5aff137..65c25df 100644 --- a/ieee802_11_radio.h +++ b/ieee802_11_radio.h @@ -277,6 +277,7 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_GUARD_INTERVAL_KNOWN 0x04 #define IEEE80211_RADIOTAP_MCS_HT_FORMAT_KNOWN 0x08 #define IEEE80211_RADIOTAP_MCS_FEC_TYPE_KNOWN 0x10 +#define IEEE80211_RADIOTAP_MCS_STBC_KNOWN 0x20 /* For IEEE80211_RADIOTAP_MCS flags */ #define IEEE80211_RADIOTAP_MCS_BANDWIDTH_MASK 0x03 @@ -287,5 +288,10 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_SHORT_GI 0x04 /* short guard interval */ #define IEEE80211_RADIOTAP_MCS_HT_GREENFIELD 0x08 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10 +#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60 +#define IEEE80211_RADIOTAP_MCS_STBC_1 1 +#define IEEE80211_RADIOTAP_MCS_STBC_2 2 +#define IEEE80211_RADIOTAP_MCS_STBC_3 3 +#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5 #endif /* _NET_IF_IEEE80211RADIOTAP_H_ */ diff --git a/print-802_11.c b/print-802_11.c index 97badb9..5f65752 100644 --- a/print-802_11.c +++ b/print-802_11.c @@ -2184,6 +2184,11 @@ print_radiotap_field(struct cpack_state *s, u_int32_t bit, u_int8_t *flags, (u2.u8 & IEEE80211_RADIOTAP_MCS_FEC_LDPC) ? "LDPC" : "BCC"); } + if (u.u8 & IEEE80211_RADIOTAP_MCS_STBC_KNOWN) { + printf("RX-STBC%u ", + (u2.u8 & IEEE80211_RADIOTAP_MCS_STBC_MASK) >> IEEE80211_RADIOTAP_MCS_STBC_SHIFT); + } + break; } } -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Patch for radiotap library [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> ` (3 preceding siblings ...) 2013-05-03 19:53 ` [PATCH] tcpdump: add STBC Rx support Oleksij Rempel @ 2013-05-04 6:22 ` Oleksij Rempel 4 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-04 6:22 UTC (permalink / raw) Cc: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A [-- Attachment #1: Type: text/plain, Size: 579 bytes --] Am 03.05.2013 21:53, schrieb Oleksij Rempel: > Here are two series of patches. First are kernel patches > and ath9k driver patch. > Second, is patch for tcpdump. > > All of them was tested for 1,2 and 3 stream scenarious. > Sinse i do not have hardware which can recive more than 1 STBC > stream, i did some hacks to to produce this kind of captures. > > Oleksij Rempel (3): > mac80211: add STBC flag for radiotap > ath9k: remove useless flag conversation. > ath9k: check for Rx-STBC flag and pass it to ieee80211 One more patch for radiotap lib. -- Regards, Oleksij [-- Attachment #2: 0001-radiotap-add-STBC-Rx-fields.patch --] [-- Type: text/x-patch, Size: 1250 bytes --] >From cf3cea707b5766d822ae595cc75849efa78cdb1e Mon Sep 17 00:00:00 2001 From: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> Date: Sat, 4 May 2013 08:19:07 +0200 Subject: [PATCH] radiotap: add STBC Rx fields. Signed-off-by: Oleksij Rempel <linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> --- radiotap.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/radiotap.h b/radiotap.h index a566024..2538433 100644 --- a/radiotap.h +++ b/radiotap.h @@ -267,6 +267,7 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT 0x08 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC 0x10 +#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20 #define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03 #define IEEE80211_RADIOTAP_MCS_BW_20 0 @@ -276,5 +277,10 @@ enum ieee80211_radiotap_type { #define IEEE80211_RADIOTAP_MCS_SGI 0x04 #define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10 +#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60 +#define IEEE80211_RADIOTAP_MCS_STBC_1 1 +#define IEEE80211_RADIOTAP_MCS_STBC_2 2 +#define IEEE80211_RADIOTAP_MCS_STBC_3 3 +#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5 #endif /* IEEE80211_RADIOTAP_H */ -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
[parent not found: <1367610836-3303-5-git-send-email-linux@rempel-privat.de>]
[parent not found: <1367610836-3303-5-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]
* Re: [PATCH] tcpdump: add STBC Rx support [not found] ` <1367610836-3303-5-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> @ 2013-05-03 19:58 ` Guy Harris [not found] ` <15EBD372-C4E3-4DA3-9ED9-47B238654587-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 0 siblings, 1 reply; 18+ messages in thread From: Guy Harris @ 2013-05-03 19:58 UTC (permalink / raw) To: Oleksij Rempel Cc: ath9k-devel-juf53994utBLZpfksSYvnA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A You might want to fork the tcpdump Git repository on GitHub: https://github.com/the-tcpdump-group/tcpdump make your changes, and submit a pull request for the tcpdump repository; that's the preferred way to submit changes to tcpdump (and, *mutatis mutandis*, to libpcap). ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <15EBD372-C4E3-4DA3-9ED9-47B238654587-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>]
* Re: [PATCH] tcpdump: add STBC Rx support [not found] ` <15EBD372-C4E3-4DA3-9ED9-47B238654587-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> @ 2013-05-03 20:04 ` Oleksij Rempel 0 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-03 20:04 UTC (permalink / raw) To: Guy Harris Cc: ath9k-devel-juf53994utBLZpfksSYvnA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, radiotap-qavaossjCcEdnm+yROfE0A Am 03.05.2013 21:58, schrieb Guy Harris: > You might want to fork the tcpdump Git repository on GitHub: > > https://github.com/the-tcpdump-group/tcpdump > > make your changes, and submit a pull request for the tcpdump repository; that's the preferred way to submit changes to tcpdump (and, *mutatis mutandis*, to libpcap). > Ok, i'll do that. I thought is should be posted first on radiotap list as part of standardisation process. May be some constructive comments and change will come ;) -- Regards, Oleksij ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <5188AFFE.6070804@rempel-privat.de>]
[parent not found: <5188AFFE.6070804-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <5188AFFE.6070804-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> @ 2013-05-07 13:54 ` Johannes Berg 0 siblings, 0 replies; 18+ messages in thread From: Johannes Berg @ 2013-05-07 13:54 UTC (permalink / raw) To: Oleksij Rempel Cc: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: > Am 02.05.2013 22:44, schrieb Johannes Berg: > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: > > > >>> With this I believe we have everything needed to start the 3 week > >>> comment period. > > > > Yeah, I guess there was plenty of time. I would have preferred a > > separate thread, but I guess there's little enough traffic on this list > > so it doesn't really matter. > > > >> There is a bit more then 3 week now. I would like to have this approved :) > >> Are there any thing needed to finish this? > > > > http://www.radiotap.org/Standardisation > > > > johannes > > > > ping. > > Johannes, are you the one who says last word on standardisation for > radiotap? No? I thought the link made that pretty clear. But since nobody poked holes in this and it's been a long time, I think you should probably just post "this has been adopted now" ... johannes ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <1367934867.8328.31.camel@jlt4.sipsolutions.net>]
[parent not found: <1367934867.8328.31.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <1367934867.8328.31.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2013-05-07 13:55 ` Johannes Berg 0 siblings, 0 replies; 18+ messages in thread From: Johannes Berg @ 2013-05-07 13:55 UTC (permalink / raw) To: Oleksij Rempel Cc: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote: > On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: > > Am 02.05.2013 22:44, schrieb Johannes Berg: > > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: > > > > > >>> With this I believe we have everything needed to start the 3 week > > >>> comment period. > > > > > > Yeah, I guess there was plenty of time. I would have preferred a > > > separate thread, but I guess there's little enough traffic on this list > > > so it doesn't really matter. > > > > > >> There is a bit more then 3 week now. I would like to have this approved :) > > >> Are there any thing needed to finish this? > > > > > > http://www.radiotap.org/Standardisation > > > > > > johannes > > > > > > > ping. > > > > Johannes, are you the one who says last word on standardisation for > > radiotap? > > No? I thought the link made that pretty clear. > > But since nobody poked holes in this and it's been a long time, I think > you should probably just post "this has been adopted now" ... Or actually, go to step 5, preferably reposting it as a separate thread. johannes ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <1367934904.8328.32.camel@jlt4.sipsolutions.net>]
[parent not found: <1367934904.8328.32.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <1367934904.8328.32.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2013-05-07 14:25 ` Oleksij Rempel 0 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-07 14:25 UTC (permalink / raw) To: Johannes Berg Cc: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA Am 07.05.2013 15:55, schrieb Johannes Berg: > On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote: >> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: >>> Am 02.05.2013 22:44, schrieb Johannes Berg: >>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: >>>> >>>>>> With this I believe we have everything needed to start the 3 week >>>>>> comment period. >>>> >>>> Yeah, I guess there was plenty of time. I would have preferred a >>>> separate thread, but I guess there's little enough traffic on this list >>>> so it doesn't really matter. >>>> >>>>> There is a bit more then 3 week now. I would like to have this approved :) >>>>> Are there any thing needed to finish this? >>>> >>>> http://www.radiotap.org/Standardisation >>>> >>>> johannes >>>> >>> >>> ping. >>> >>> Johannes, are you the one who says last word on standardisation for >>> radiotap? >> >> No? I thought the link made that pretty clear. >> >> But since nobody poked holes in this and it's been a long time, I think >> you should probably just post "this has been adopted now" ... > > Or actually, go to step 5, preferably reposting it as a separate thread. Simon, will you do it? You stared it and did most of the work... -- Regards, Oleksij ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <518916D1.4070902@gmail.com>]
[parent not found: <518916D1.4070902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <518916D1.4070902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2013-05-07 15:03 ` Oleksij Rempel 0 siblings, 0 replies; 18+ messages in thread From: Oleksij Rempel @ 2013-05-07 15:03 UTC (permalink / raw) To: Jonathan Bither Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, radiotap-qavaossjCcEdnm+yROfE0A Am 07.05.2013 16:59, schrieb Jonathan Bither: > > > On 05/07/2013 09:55 AM, Johannes Berg wrote: >> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote: >>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: >>>> Am 02.05.2013 22:44, schrieb Johannes Berg: >>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: >>>>> >>>>>>> With this I believe we have everything needed to start the 3 week >>>>>>> comment period. >>>>> >>>>> Yeah, I guess there was plenty of time. I would have preferred a >>>>> separate thread, but I guess there's little enough traffic on this >>>>> list >>>>> so it doesn't really matter. >>>>> >>>>>> There is a bit more then 3 week now. I would like to have this >>>>>> approved :) >>>>>> Are there any thing needed to finish this? >>>>> >>>>> http://www.radiotap.org/Standardisation >>>>> >>>>> johannes >>>>> >>>> >>>> ping. >>>> >>>> Johannes, are you the one who says last word on standardisation for >>>> radiotap? >>> >>> No? I thought the link made that pretty clear. >>> >>> But since nobody poked holes in this and it's been a long time, I think >>> you should probably just post "this has been adopted now" ... >> >> Or actually, go to step 5, preferably reposting it as a separate thread. > It looks as if someone already proposed this as a suggested field on > '2012-05-14 23:49:35' without any replies as far as I can tell. > http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness Yes, Simon did it last year. I send this link on my first email... In my opinion, this should be just ACKed. Every thing what was needed to do, is already done. -- Regards, Oleksij ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <518917C4.9090607@rempel-privat.de>]
[parent not found: <518917C4.9090607-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <518917C4.9090607-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> @ 2013-05-07 16:09 ` Jonathan Bither 0 siblings, 0 replies; 18+ messages in thread From: Jonathan Bither @ 2013-05-07 16:09 UTC (permalink / raw) To: Oleksij Rempel Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, radiotap-S783fYmB3Ccdnm+yROfE0A On Tue 07 May 2013 11:03:32 AM EDT, Oleksij Rempel wrote: > Am 07.05.2013 16:59, schrieb Jonathan Bither: >> >> >> On 05/07/2013 09:55 AM, Johannes Berg wrote: >>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote: >>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote: >>>>> Am 02.05.2013 22:44, schrieb Johannes Berg: >>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: >>>>>> >>>>>>>> With this I believe we have everything needed to start the 3 week >>>>>>>> comment period. >>>>>> >>>>>> Yeah, I guess there was plenty of time. I would have preferred a >>>>>> separate thread, but I guess there's little enough traffic on this >>>>>> list >>>>>> so it doesn't really matter. >>>>>> >>>>>>> There is a bit more then 3 week now. I would like to have this >>>>>>> approved :) >>>>>>> Are there any thing needed to finish this? >>>>>> >>>>>> http://www.radiotap.org/Standardisation >>>>>> >>>>>> johannes >>>>>> >>>>> >>>>> ping. >>>>> >>>>> Johannes, are you the one who says last word on standardisation for >>>>> radiotap? >>>> >>>> No? I thought the link made that pretty clear. >>>> >>>> But since nobody poked holes in this and it's been a long time, I >>>> think >>>> you should probably just post "this has been adopted now" ... >>> >>> Or actually, go to step 5, preferably reposting it as a separate >>> thread. >> It looks as if someone already proposed this as a suggested field on >> '2012-05-14 23:49:35' without any replies as far as I can tell. >> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness >> > > Yes, Simon did it last year. I send this link on my first email... > In my opinion, this should be just ACKed. Every thing what was needed > to do, is already done. > Whoops, one of those days I guess. Sorry for the noise. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <518127ED.9060900-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org>]
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <518127ED.9060900-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> @ 2013-05-02 20:44 ` Johannes Berg 2013-05-03 21:12 ` Simon Barber 1 sibling, 0 replies; 18+ messages in thread From: Johannes Berg @ 2013-05-02 20:44 UTC (permalink / raw) To: Oleksij Rempel Cc: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote: > > With this I believe we have everything needed to start the 3 week > > comment period. Yeah, I guess there was plenty of time. I would have preferred a separate thread, but I guess there's little enough traffic on this list so it doesn't really matter. > There is a bit more then 3 week now. I would like to have this approved :) > Are there any thing needed to finish this? http://www.radiotap.org/Standardisation johannes ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <518127ED.9060900-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-02 20:44 ` Johannes Berg @ 2013-05-03 21:12 ` Simon Barber 1 sibling, 0 replies; 18+ messages in thread From: Simon Barber @ 2013-05-03 21:12 UTC (permalink / raw) To: Oleksij Rempel Cc: radiotap-qavaossjCcEdnm+yROfE0A, johannes-cdvu00un1VgdHxzADdlk8Q, Adrian Chadd, ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ, linux-wireless-u79uwXL29TY76Z2rM5mHXA I did post example code as attachments to the suggested-fields page a few months ago. Click on 'attachments' to view them. There are 3: 1. Intel wlan driver patch 2. Kernel patch 3. Wireshark patch. Simon On 05/01/2013 07:34 AM, Oleksij Rempel wrote: > Hallo all, > > >> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness >> >> >> I have posted 3 patches on the proposal page (see Attachments): >> >> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new >> STBC and Ness parameters from a wireless driver, and add them into the >> MCS radiotap field. >> 2. A patch to the Intel wireless driver in the kernel to collect STBC >> and Ness information. >> 3. A patch to wireshark to display STBC and Ness information. >> >> With this I believe we have everything needed to start the 3 week >> comment period. > > There is a bit more then 3 week now. I would like to have this approved :) > Are there any thing needed to finish this? > > Beside, i have one question about how STBC work. According to differnet > docs, i assume that: > - STBC is done by sending, at least, two stream with same data in > different order. > - It means for me, that real use of STBC can be made only on MIMO hardware. > - If 1x1 receiver indicates that it got STBC encoded frame, it dos not > meant, it would be able to use redundant data from second stream. > - There are fallowing STBC schemes: Alamouti’s > STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit > antennas. > > According to this information, what do we call 1,2 or 3 stream STBC? > Since STBC should have minimal 2 stream, but in same time we have 1x1 > and 2x2 hardware which able to receive and decode STBC stream i assume: > - RX-STBC1 is for compatibility only. No data redundancy. > - RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly > used method. > - RX-STBC123 - is orthogonal schema and not widely used method. > Since last method use wide spectrum to transmit data comparable to SISO > stream, it makes almost no sense. But 3-stream method get optimal error > corect in compare with 2 and 4 strea schemas. > > Do this assumptions correct? > > PS: My assumptions based on "MIMO Space-Time Block Coding (STBC): > Simulations and Results" ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Standardisation - adding 2 bit STBC and Ness to MCS
@ 2013-05-01 14:34 Oleksij Rempel
0 siblings, 0 replies; 18+ messages in thread
From: Oleksij Rempel @ 2013-05-01 14:34 UTC (permalink / raw)
To: radiotap-qavaossjCcEdnm+yROfE0A, simon-vp0mx6+5gkqFX2APIN6yfw,
johannes-cdvu00un1VgdHxzADdlk8Q, Adrian Chadd
Cc: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hallo all,
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> I have posted 3 patches on the proposal page (see Attachments):
>
> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
> STBC and Ness parameters from a wireless driver, and add them into the
> MCS radiotap field.
> 2. A patch to the Intel wireless driver in the kernel to collect STBC
> and Ness information.
> 3. A patch to wireshark to display STBC and Ness information.
>
> With this I believe we have everything needed to start the 3 week
> comment period.
There is a bit more then 3 week now. I would like to have this approved :)
Are there any thing needed to finish this?
Beside, i have one question about how STBC work. According to differnet
docs, i assume that:
- STBC is done by sending, at least, two stream with same data in
different order.
- It means for me, that real use of STBC can be made only on MIMO hardware.
- If 1x1 receiver indicates that it got STBC encoded frame, it dos not
meant, it would be able to use redundant data from second stream.
- There are fallowing STBC schemes: Alamouti’s
STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit
antennas.
According to this information, what do we call 1,2 or 3 stream STBC?
Since STBC should have minimal 2 stream, but in same time we have 1x1
and 2x2 hardware which able to receive and decode STBC stream i assume:
- RX-STBC1 is for compatibility only. No data redundancy.
- RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly used
method.
- RX-STBC123 - is orthogonal schema and not widely used method. Since
last method use wide spectrum to transmit data comparable to SISO
stream, it makes almost no sense. But 3-stream method get optimal error
corect in compare with 2 and 4 strea schemas.
Do this assumptions correct?
PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
Simulations and Results"
--
Regards,
Oleksij
^ permalink raw reply [flat|nested] 18+ messages in thread
* MCS field - STBC and Ness @ 2012-05-11 0:31 Simon Barber 2012-05-11 7:04 ` Wojciech Dubowik 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-05-11 0:31 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw, wojciech.dubowik-ASv44eHyqLVBDgjK7y7TUQ Hi all, I am writing a Wireshark extension to visualise 802.11 frames on a timeline. In order to do this I need to be able to calculate the duration from start of TX to end of TX for each frame. For 802.11n I need to know the number of HT-DLTF and HT-ELTF training symbols that are sent in the header - I have everything else needed to calculate the duration. Given the MCS and the STBC and the Ness (Number of extension spatial streams) I can calculate the number of training symbols. Both STBC and Ness are encoded in the HT-SIG transmitted at the start of each HT frame. The current proposal (or has it not yet been accepted?) for STBC allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, but this does not solve the problem of how to encode the modes with 2 spatial streams and 2 additional streams for STBC. Does anyone know what current hardware supports - STBC values or 0,1,2? Ness values of 0-3? Any suggestions for how to convey these Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-05-11 7:04 ` Wojciech Dubowik 2012-05-11 16:44 ` Simon Barber 0 siblings, 1 reply; 18+ messages in thread From: Wojciech Dubowik @ 2012-05-11 7:04 UTC (permalink / raw) To: Simon Barber; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw Hello, Atheros families 9002 and 9003 support only one STBC stream. I think I have seen a Ralink chipset which supports 2 stream at least on receive. I am not sure about transmiter. On Atheros you get STBC flag and two bits Ness field for received packets but In the patch there is is only flag reading but you could add Ness yourself it's only two bits left from the flag. Myself I have tested only one stream but I did it only by looking whether other party is setting rx descriptor bit. I don't know how it looks "in the air". I trust manufacturer;o) It's true that only one bit was allocated in wireshark extension. Should have been two but it's a bit waste. My proposal wasn't accepted but in the end I think it's ok becasue I have managed to get all info in vendor namesapes where I can do what I want. Br, Wojtek > > I am writing a Wireshark extension to visualise 802.11 frames on a > timeline. In order to do this I need to be able to calculate the > duration from start of TX to end of TX for each frame. > > For 802.11n I need to know the number of HT-DLTF and HT-ELTF training > symbols that are sent in the header - I have everything else needed to > calculate the duration. Given the MCS and the STBC and the Ness > (Number of extension spatial streams) I can calculate the number of > training symbols. > > Both STBC and Ness are encoded in the HT-SIG transmitted at the start > of each HT frame. > > The current proposal (or has it not yet been accepted?) for STBC > allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. > > Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, > but this does not solve the problem of how to encode the modes with 2 > spatial streams and 2 additional streams for STBC. > > Does anyone know what current hardware supports - STBC values or > 0,1,2? Ness values of 0-3? > > Any suggestions for how to convey these > > Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-05-11 16:44 ` Simon Barber 2012-05-11 16:53 ` Simon Barber 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-05-11 16:44 UTC (permalink / raw) To: Wojciech Dubowik; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw One possible solution would be to adopt your proposal to add a single bit STBC, but also add a second bit to the 'knows' byte - STBC2. If this second bit is set, then it indicates STBC=2. This would leave one remaining bit in the 'knows' byte, to indicate the presence of Ness information, and 2 bits in the 'flags' byte for 2 bits of Ness information. Copying the MCS definition from the radiotap.org website: The known field indicates which information is known: known definition 0x01 bandwidth 0x02 MCS index known (in mcs part of the field) 0x04 guard interval 0x08 HT format 0x10 FEC type 0x20 STBC - STBC is known 0x40 STBC2 - 2 STBC streams are present 0x80 Ness - Number of extra spatial streams is known The flags field is any combination of the following: flag definition 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U 0x04 guard interval - 0: long GI, 1: short GI 0x08 HT format - 0: mixed, 1: greenfield 0x10 FEC type - 0: BCC, 1: LDPC 0x20 STBC - 0: no STBC streams, 1: 1 or 2 STBC streams (see STBC2) 0xc0 Ness - Number of extra spatial streams. Simon On Fri 11 May 2012 12:04:51 AM PDT, Wojciech Dubowik wrote: > Hello, > Atheros families 9002 and 9003 support only one STBC stream. I think I > have seen a Ralink chipset > which supports 2 stream at least on receive. I am not sure about > transmiter. > On Atheros you get STBC flag and two bits Ness field for received > packets but In the patch there is is only flag reading but you could > add Ness yourself it's only two bits left from the flag. > > Myself I have tested only one stream but I did it only by looking > whether other party is setting rx descriptor bit. I don't know how it > looks "in the air". I trust manufacturer;o) > > It's true that only one bit was allocated in wireshark extension. > Should have been two but it's a bit waste. My proposal wasn't accepted > but in the end I think it's ok becasue I have managed to get all info > in vendor namesapes where I can do what I want. > > Br, > Wojtek > >> >> I am writing a Wireshark extension to visualise 802.11 frames on a >> timeline. In order to do this I need to be able to calculate the >> duration from start of TX to end of TX for each frame. >> >> For 802.11n I need to know the number of HT-DLTF and HT-ELTF training >> symbols that are sent in the header - I have everything else needed >> to calculate the duration. Given the MCS and the STBC and the Ness >> (Number of extension spatial streams) I can calculate the number of >> training symbols. >> >> Both STBC and Ness are encoded in the HT-SIG transmitted at the start >> of each HT frame. >> >> The current proposal (or has it not yet been accepted?) for STBC >> allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. >> >> Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, >> but this does not solve the problem of how to encode the modes with 2 >> spatial streams and 2 additional streams for STBC. >> >> Does anyone know what current hardware supports - STBC values or >> 0,1,2? Ness values of 0-3? >> >> Any suggestions for how to convey these >> >> Simon > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-05-11 16:53 ` Simon Barber 2012-05-11 18:35 ` Johannes Berg 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-05-11 16:53 UTC (permalink / raw) To: Wojciech Dubowik; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw OK - perhaps a simpler/better suggestion would be for the STBC2 bit to just be the second bit of STBC information. Simon On Fri 11 May 2012 09:44:20 AM PDT, Simon Barber wrote: > One possible solution would be to adopt your proposal to add a single > bit STBC, but also add a second bit to the 'knows' byte - STBC2. If > this second bit is set, then it indicates STBC=2. This would leave one > remaining bit in the 'knows' byte, to indicate the presence of Ness > information, and 2 bits in the 'flags' byte for 2 bits of Ness > information. > > Copying the MCS definition from the radiotap.org website: > > The known field indicates which information is known: > > known definition > 0x01 bandwidth > 0x02 MCS index known (in mcs part of the field) > 0x04 guard interval > 0x08 HT format > 0x10 FEC type > 0x20 STBC - STBC is known > 0x40 STBC2 - 2 STBC streams are present > 0x80 Ness - Number of extra spatial streams is known > > The flags field is any combination of the following: > > flag definition > 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U > 0x04 guard interval - 0: long GI, 1: short GI > 0x08 HT format - 0: mixed, 1: greenfield > 0x10 FEC type - 0: BCC, 1: LDPC > 0x20 STBC - 0: no STBC streams, 1: 1 or 2 STBC streams (see STBC2) > 0xc0 Ness - Number of extra spatial streams. > > Simon > > > > On Fri 11 May 2012 12:04:51 AM PDT, Wojciech Dubowik wrote: >> Hello, >> Atheros families 9002 and 9003 support only one STBC stream. I think I >> have seen a Ralink chipset >> which supports 2 stream at least on receive. I am not sure about >> transmiter. >> On Atheros you get STBC flag and two bits Ness field for received >> packets but In the patch there is is only flag reading but you could >> add Ness yourself it's only two bits left from the flag. >> >> Myself I have tested only one stream but I did it only by looking >> whether other party is setting rx descriptor bit. I don't know how it >> looks "in the air". I trust manufacturer;o) >> >> It's true that only one bit was allocated in wireshark extension. >> Should have been two but it's a bit waste. My proposal wasn't accepted >> but in the end I think it's ok becasue I have managed to get all info >> in vendor namesapes where I can do what I want. >> >> Br, >> Wojtek >> >>> >>> I am writing a Wireshark extension to visualise 802.11 frames on a >>> timeline. In order to do this I need to be able to calculate the >>> duration from start of TX to end of TX for each frame. >>> >>> For 802.11n I need to know the number of HT-DLTF and HT-ELTF training >>> symbols that are sent in the header - I have everything else needed >>> to calculate the duration. Given the MCS and the STBC and the Ness >>> (Number of extension spatial streams) I can calculate the number of >>> training symbols. >>> >>> Both STBC and Ness are encoded in the HT-SIG transmitted at the start >>> of each HT frame. >>> >>> The current proposal (or has it not yet been accepted?) for STBC >>> allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. >>> >>> Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, >>> but this does not solve the problem of how to encode the modes with 2 >>> spatial streams and 2 additional streams for STBC. >>> >>> Does anyone know what current hardware supports - STBC values or >>> 0,1,2? Ness values of 0-3? >>> >>> Any suggestions for how to convey these >>> >>> Simon >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-05-11 18:35 ` Johannes Berg 2012-05-12 4:27 ` Simon Barber 0 siblings, 1 reply; 18+ messages in thread From: Johannes Berg @ 2012-05-11 18:35 UTC (permalink / raw) To: Simon Barber; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw On Fri, 2012-05-11 at 09:53 -0700, Simon Barber wrote: > OK - perhaps a simpler/better suggestion would be for the STBC2 bit to > just be the second bit of STBC information. Seems reasonable to me, then we'll have filled all the bits anyway. johannes > Simon > > > On Fri 11 May 2012 09:44:20 AM PDT, Simon Barber wrote: > > One possible solution would be to adopt your proposal to add a single > > bit STBC, but also add a second bit to the 'knows' byte - STBC2. If > > this second bit is set, then it indicates STBC=2. This would leave one > > remaining bit in the 'knows' byte, to indicate the presence of Ness > > information, and 2 bits in the 'flags' byte for 2 bits of Ness > > information. > > > > Copying the MCS definition from the radiotap.org website: > > > > The known field indicates which information is known: > > > > known definition > > 0x01 bandwidth > > 0x02 MCS index known (in mcs part of the field) > > 0x04 guard interval > > 0x08 HT format > > 0x10 FEC type > > 0x20 STBC - STBC is known > > 0x40 STBC2 - 2 STBC streams are present > > 0x80 Ness - Number of extra spatial streams is known > > > > The flags field is any combination of the following: > > > > flag definition > > 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U > > 0x04 guard interval - 0: long GI, 1: short GI > > 0x08 HT format - 0: mixed, 1: greenfield > > 0x10 FEC type - 0: BCC, 1: LDPC > > 0x20 STBC - 0: no STBC streams, 1: 1 or 2 STBC streams (see STBC2) > > 0xc0 Ness - Number of extra spatial streams. > > > > Simon > > > > > > > > On Fri 11 May 2012 12:04:51 AM PDT, Wojciech Dubowik wrote: > >> Hello, > >> Atheros families 9002 and 9003 support only one STBC stream. I think I > >> have seen a Ralink chipset > >> which supports 2 stream at least on receive. I am not sure about > >> transmiter. > >> On Atheros you get STBC flag and two bits Ness field for received > >> packets but In the patch there is is only flag reading but you could > >> add Ness yourself it's only two bits left from the flag. > >> > >> Myself I have tested only one stream but I did it only by looking > >> whether other party is setting rx descriptor bit. I don't know how it > >> looks "in the air". I trust manufacturer;o) > >> > >> It's true that only one bit was allocated in wireshark extension. > >> Should have been two but it's a bit waste. My proposal wasn't accepted > >> but in the end I think it's ok becasue I have managed to get all info > >> in vendor namesapes where I can do what I want. > >> > >> Br, > >> Wojtek > >> > >>> > >>> I am writing a Wireshark extension to visualise 802.11 frames on a > >>> timeline. In order to do this I need to be able to calculate the > >>> duration from start of TX to end of TX for each frame. > >>> > >>> For 802.11n I need to know the number of HT-DLTF and HT-ELTF training > >>> symbols that are sent in the header - I have everything else needed > >>> to calculate the duration. Given the MCS and the STBC and the Ness > >>> (Number of extension spatial streams) I can calculate the number of > >>> training symbols. > >>> > >>> Both STBC and Ness are encoded in the HT-SIG transmitted at the start > >>> of each HT frame. > >>> > >>> The current proposal (or has it not yet been accepted?) for STBC > >>> allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. > >>> > >>> Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, > >>> but this does not solve the problem of how to encode the modes with 2 > >>> spatial streams and 2 additional streams for STBC. > >>> > >>> Does anyone know what current hardware supports - STBC values or > >>> 0,1,2? Ness values of 0-3? > >>> > >>> Any suggestions for how to convey these > >>> > >>> Simon > >> > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-05-12 4:27 ` Simon Barber 2012-07-05 9:12 ` Johannes Berg 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-05-12 4:27 UTC (permalink / raw) To: Johannes Berg; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw Another slight tweak - I think STBC is more commonly used than Ness (as witnessed by Wojciech's interest), so give STBC the simpler encoding. I believe Ness is used for beamforming soundings. Spec would look like this: known definition 0x01 bandwidth 0x02 MCS index known (in mcs part of the field) 0x04 guard interval 0x08 HT format 0x10 FEC type 0x20 STBC 0x40 Ness - Number of extension spatial streams is known 0x80 Ness2 - bit 1 (MSB) of Number of extension spatial streams. The flags field is any combination of the following: flag definition 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U 0x04 guard interval - 0: long GI, 1: short GI 0x08 HT format - 0: mixed, 1: greenfield 0x10 FEC type - 0: BCC, 1: LDPC 0x60 STBC - 0, 1 or 2: number of STBC streams 0x80 Ness - bit 0 (LSB) of Number of extension spatial streams. What should I do to advance this as an approved radiotap extension? Simon On Fri 11 May 2012 11:35:46 AM PDT, Johannes Berg wrote: > On Fri, 2012-05-11 at 09:53 -0700, Simon Barber wrote: >> OK - perhaps a simpler/better suggestion would be for the STBC2 bit to >> just be the second bit of STBC information. > > Seems reasonable to me, then we'll have filled all the bits anyway. > > johannes > >> Simon >> >> >> On Fri 11 May 2012 09:44:20 AM PDT, Simon Barber wrote: >>> One possible solution would be to adopt your proposal to add a single >>> bit STBC, but also add a second bit to the 'knows' byte - STBC2. If >>> this second bit is set, then it indicates STBC=2. This would leave one >>> remaining bit in the 'knows' byte, to indicate the presence of Ness >>> information, and 2 bits in the 'flags' byte for 2 bits of Ness >>> information. >>> >>> Copying the MCS definition from the radiotap.org website: >>> >>> The known field indicates which information is known: >>> >>> known definition >>> 0x01 bandwidth >>> 0x02 MCS index known (in mcs part of the field) >>> 0x04 guard interval >>> 0x08 HT format >>> 0x10 FEC type >>> 0x20 STBC - STBC is known >>> 0x40 STBC2 - 2 STBC streams are present >>> 0x80 Ness - Number of extra spatial streams is known >>> >>> The flags field is any combination of the following: >>> >>> flag definition >>> 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U >>> 0x04 guard interval - 0: long GI, 1: short GI >>> 0x08 HT format - 0: mixed, 1: greenfield >>> 0x10 FEC type - 0: BCC, 1: LDPC >>> 0x20 STBC - 0: no STBC streams, 1: 1 or 2 STBC streams (see STBC2) >>> 0xc0 Ness - Number of extra spatial streams. >>> >>> Simon >>> >>> >>> >>> On Fri 11 May 2012 12:04:51 AM PDT, Wojciech Dubowik wrote: >>>> Hello, >>>> Atheros families 9002 and 9003 support only one STBC stream. I think I >>>> have seen a Ralink chipset >>>> which supports 2 stream at least on receive. I am not sure about >>>> transmiter. >>>> On Atheros you get STBC flag and two bits Ness field for received >>>> packets but In the patch there is is only flag reading but you could >>>> add Ness yourself it's only two bits left from the flag. >>>> >>>> Myself I have tested only one stream but I did it only by looking >>>> whether other party is setting rx descriptor bit. I don't know how it >>>> looks "in the air". I trust manufacturer;o) >>>> >>>> It's true that only one bit was allocated in wireshark extension. >>>> Should have been two but it's a bit waste. My proposal wasn't accepted >>>> but in the end I think it's ok becasue I have managed to get all info >>>> in vendor namesapes where I can do what I want. >>>> >>>> Br, >>>> Wojtek >>>> >>>>> >>>>> I am writing a Wireshark extension to visualise 802.11 frames on a >>>>> timeline. In order to do this I need to be able to calculate the >>>>> duration from start of TX to end of TX for each frame. >>>>> >>>>> For 802.11n I need to know the number of HT-DLTF and HT-ELTF training >>>>> symbols that are sent in the header - I have everything else needed >>>>> to calculate the duration. Given the MCS and the STBC and the Ness >>>>> (Number of extension spatial streams) I can calculate the number of >>>>> training symbols. >>>>> >>>>> Both STBC and Ness are encoded in the HT-SIG transmitted at the start >>>>> of each HT frame. >>>>> >>>>> The current proposal (or has it not yet been accepted?) for STBC >>>>> allocates just 1 bit - but the STBC field can have values or 0, 1 or 2. >>>>> >>>>> Ness can be 0-3, so the remaining 2 bits could be allocated to Ness, >>>>> but this does not solve the problem of how to encode the modes with 2 >>>>> spatial streams and 2 additional streams for STBC. >>>>> >>>>> Does anyone know what current hardware supports - STBC values or >>>>> 0,1,2? Ness values of 0-3? >>>>> >>>>> Any suggestions for how to convey these >>>>> >>>>> Simon >>>> >> > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-07-05 9:12 ` Johannes Berg 2012-11-01 0:22 ` Simon Barber 0 siblings, 1 reply; 18+ messages in thread From: Johannes Berg @ 2012-07-05 9:12 UTC (permalink / raw) To: Simon Barber; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote: > Another slight tweak - I think STBC is more commonly used than Ness (as > witnessed by Wojciech's interest), so give STBC the simpler encoding. I > believe Ness is used for beamforming soundings. > > Spec would look like this: > > known definition > 0x01 bandwidth > 0x02 MCS index known (in mcs part of the field) > 0x04 guard interval > 0x08 HT format > 0x10 FEC type > 0x20 STBC > 0x40 Ness - Number of extension spatial streams is known > 0x80 Ness2 - bit 1 (MSB) of Number of extension spatial streams. > > The flags field is any combination of the following: > > flag definition > 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U > 0x04 guard interval - 0: long GI, 1: short GI > 0x08 HT format - 0: mixed, 1: greenfield > 0x10 FEC type - 0: BCC, 1: LDPC > 0x60 STBC - 0, 1 or 2: number of STBC streams > 0x80 Ness - bit 0 (LSB) of Number of extension spatial streams. > > What should I do to advance this as an approved radiotap extension? I suppose you already have patches for wireshark for this? I can help you out with a patch for the Linux kernel as an example producer of this, and then I think just repost it to the list again to leave some more discussion time. johannes ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-11-01 0:22 ` Simon Barber 2012-11-02 0:24 ` Simon Barber 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-11-01 0:22 UTC (permalink / raw) To: Johannes Berg; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw Hi Johannes & Wojciech, My work has been on hold, but has recently come off hold. I'm getting the patches together. As I rebase my work onto the current wireshark trunk I've found a simpler implementation of STBC has been applied by Wojciech. My proposal extends the STBC from his implemented 1 bit to the full 2 bits allowed in the 11n specification, and also includes 2 bits of Ness. I've posted an ieee80211 patch, and an intel driver patch (both attached to the proposed radiotap extension page). l'll post a wireshark patch shortly to start the comment period. Simon On Thu 05 Jul 2012 02:12:30 AM PDT, Johannes Berg wrote: > On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote: >> Another slight tweak - I think STBC is more commonly used than Ness (as >> witnessed by Wojciech's interest), so give STBC the simpler encoding. I >> believe Ness is used for beamforming soundings. >> >> Spec would look like this: >> >> known definition >> 0x01 bandwidth >> 0x02 MCS index known (in mcs part of the field) >> 0x04 guard interval >> 0x08 HT format >> 0x10 FEC type >> 0x20 STBC >> 0x40 Ness - Number of extension spatial streams is known >> 0x80 Ness2 - bit 1 (MSB) of Number of extension spatial streams. >> >> The flags field is any combination of the following: >> >> flag definition >> 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U >> 0x04 guard interval - 0: long GI, 1: short GI >> 0x08 HT format - 0: mixed, 1: greenfield >> 0x10 FEC type - 0: BCC, 1: LDPC >> 0x60 STBC - 0, 1 or 2: number of STBC streams >> 0x80 Ness - bit 0 (LSB) of Number of extension spatial streams. >> >> What should I do to advance this as an approved radiotap extension? > > I suppose you already have patches for wireshark for this? I can help > you out with a patch for the Linux kernel as an example producer of > this, and then I think just repost it to the list again to leave some > more discussion time. > > johannes > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MCS field - STBC and Ness @ 2012-11-02 0:24 ` Simon Barber [not found] ` <509312DB.7070100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 0 siblings, 1 reply; 18+ messages in thread From: Simon Barber @ 2012-11-02 0:24 UTC (permalink / raw) To: Johannes Berg; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw OK - I have now posted 3 patches on the proposal page (see Attachments): 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new STBC and Ness parameters from a wireless driver, and add them into the MCS radiotap field. 2. A patch to the Intel wireless driver in the kernel to collect STBC and Ness information. 3. A patch to wireshark to display STBC and Ness information. With this I believe we have everything needed to start the 3 week comment period. Simon On 10/31/2012 05:22 PM, Simon Barber wrote: > Hi Johannes & Wojciech, > > My work has been on hold, but has recently come off hold. I'm getting > the patches together. As I rebase my work onto the current wireshark > trunk I've found a simpler implementation of STBC has been applied by > Wojciech. My proposal extends the STBC from his implemented 1 bit to the > full 2 bits allowed in the 11n specification, and also includes 2 bits > of Ness. I've posted an ieee80211 patch, and an intel driver patch (both > attached to the proposed radiotap extension page). l'll post a wireshark > patch shortly to start the comment period. > > Simon > > > On Thu 05 Jul 2012 02:12:30 AM PDT, Johannes Berg wrote: >> On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote: >>> Another slight tweak - I think STBC is more commonly used than Ness (as >>> witnessed by Wojciech's interest), so give STBC the simpler encoding. I >>> believe Ness is used for beamforming soundings. >>> >>> Spec would look like this: >>> >>> known definition >>> 0x01 bandwidth >>> 0x02 MCS index known (in mcs part of the field) >>> 0x04 guard interval >>> 0x08 HT format >>> 0x10 FEC type >>> 0x20 STBC >>> 0x40 Ness - Number of extension spatial streams is known >>> 0x80 Ness2 - bit 1 (MSB) of Number of extension spatial streams. >>> >>> The flags field is any combination of the following: >>> >>> flag definition >>> 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U >>> 0x04 guard interval - 0: long GI, 1: short GI >>> 0x08 HT format - 0: mixed, 1: greenfield >>> 0x10 FEC type - 0: BCC, 1: LDPC >>> 0x60 STBC - 0, 1 or 2: number of STBC streams >>> 0x80 Ness - bit 0 (LSB) of Number of extension spatial streams. >>> >>> What should I do to advance this as an approved radiotap extension? >> >> I suppose you already have patches for wireshark for this? I can help >> you out with a patch for the Linux kernel as an example producer of >> this, and then I think just repost it to the list again to leave some >> more discussion time. >> >> johannes >> ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <509312DB.7070100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* Standardisation - adding 2 bit STBC and Ness to MCS [not found] ` <509312DB.7070100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> @ 2012-11-17 6:32 ` Simon Barber 0 siblings, 0 replies; 18+ messages in thread From: Simon Barber @ 2012-11-17 6:32 UTC (permalink / raw) To: Simon Barber; +Cc: Wojciech Dubowik, radiotap-sUITvd46vNxg9hUCZPvPmw http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness I have posted 3 patches on the proposal page (see Attachments): 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new STBC and Ness parameters from a wireless driver, and add them into the MCS radiotap field. 2. A patch to the Intel wireless driver in the kernel to collect STBC and Ness information. 3. A patch to wireshark to display STBC and Ness information. With this I believe we have everything needed to start the 3 week comment period. Simon Barber ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-05-07 16:09 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <518127ED.9060900@rempel-privat.de> [not found] ` <1367527479.11375.19.camel@jlt4.sipsolutions.net> [not found] ` <1367527479.11375.19.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2013-05-03 19:53 ` Patches for STBC Standartisation Oleksij Rempel 2013-05-07 7:40 ` Standardisation - adding 2 bit STBC and Ness to MCS Oleksij Rempel [not found] ` <1367610836-3303-1-git-send-email-linux@rempel-privat.de> [not found] ` <1367610836-3303-1-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-03 19:53 ` [PATCH 1/3] mac80211: add STBC flag for radiotap Oleksij Rempel 2013-05-03 19:53 ` [PATCH 2/3] ath9k: remove useless flag conversation Oleksij Rempel 2013-05-03 19:53 ` [PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211 Oleksij Rempel 2013-05-03 19:53 ` [PATCH] tcpdump: add STBC Rx support Oleksij Rempel 2013-05-04 6:22 ` Patch for radiotap library Oleksij Rempel [not found] ` <1367610836-3303-5-git-send-email-linux@rempel-privat.de> [not found] ` <1367610836-3303-5-git-send-email-linux-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-03 19:58 ` [PATCH] tcpdump: add STBC Rx support Guy Harris [not found] ` <15EBD372-C4E3-4DA3-9ED9-47B238654587-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> 2013-05-03 20:04 ` Oleksij Rempel [not found] ` <5188AFFE.6070804@rempel-privat.de> [not found] ` <5188AFFE.6070804-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-07 13:54 ` Standardisation - adding 2 bit STBC and Ness to MCS Johannes Berg [not found] ` <1367934867.8328.31.camel@jlt4.sipsolutions.net> [not found] ` <1367934867.8328.31.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2013-05-07 13:55 ` Johannes Berg [not found] ` <1367934904.8328.32.camel@jlt4.sipsolutions.net> [not found] ` <1367934904.8328.32.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2013-05-07 14:25 ` Oleksij Rempel [not found] ` <518916D1.4070902@gmail.com> [not found] ` <518916D1.4070902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2013-05-07 15:03 ` Oleksij Rempel [not found] ` <518917C4.9090607@rempel-privat.de> [not found] ` <518917C4.9090607-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-07 16:09 ` Jonathan Bither [not found] ` <518127ED.9060900-YEK0n+YFykbzxQdaRaTXBw@public.gmane.org> 2013-05-02 20:44 ` Johannes Berg 2013-05-03 21:12 ` Simon Barber 2013-05-01 14:34 Oleksij Rempel -- strict thread matches above, loose matches on Subject: below -- 2012-05-11 0:31 MCS field - STBC and Ness Simon Barber 2012-05-11 7:04 ` Wojciech Dubowik 2012-05-11 16:44 ` Simon Barber 2012-05-11 16:53 ` Simon Barber 2012-05-11 18:35 ` Johannes Berg 2012-05-12 4:27 ` Simon Barber 2012-07-05 9:12 ` Johannes Berg 2012-11-01 0:22 ` Simon Barber 2012-11-02 0:24 ` Simon Barber [not found] ` <509312DB.7070100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 2012-11-17 6:32 ` Standardisation - adding 2 bit STBC and Ness to MCS Simon Barber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).