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
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
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).
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
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
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
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 <[email protected]>
---
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
Signed-off-by: Oleksij Rempel <[email protected]>
---
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
Signed-off-by: Oleksij Rempel <[email protected]>
---
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
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
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
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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
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"
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.
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
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
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
Signed-off-by: Oleksij Rempel <[email protected]>
---
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