Hi all,
Does anyone know if the 11n standard says that the set of TX rates has to be a subset of the set of RX rates? This seems to be enforced now: when I set up one node to be 2x1, i.e. transmit 2 streams but only able to receive 1, then the mac80211 code only lets it transmit 1 streams (even with a 2-stream-capable receiver at the other end).
A quick diff to net/mac80211/ht.c that fixes this for equal modulation streams is attached; the problem is still there for unequal modulation directly below. Before I send it up I wanted to make sure I'm not crazy.
A second question: my understanding is that if I am a 2x2 node and I associate to a 3x3 AP, the same code will mask out the fact that the AP can receive 3 streams since I can't transmit 3 streams. Is there a way to access this info from the driver if I want it?
Thanks!
Dan
---
From: Daniel Halperin <[email protected]>
Date: Tue, 20 Apr 2010 00:00:29 -0700
Subject: [PATCH] mac80211: support devices with more transmit than receive MCS supported
There is an implicit assumption built into mac80211 that an 11n NIC has a
receive MCS set that contains its TX MCS set, even when
IEEE80211_HT_MCS_TX_RX_DIFF is set. Then, a 2x1 node that can transmit 2
streams but only receive 1 will be unable to transmit 2 streams. Fix this for
equal modulation MCS sets by properly handling the IEEE80211_HT_MCS_TX_RX_DIFF
case.
Signed-off-by: Daniel Halperin <[email protected]>
---
net/mac80211/ht.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index 2ab106a..249805b 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -24,6 +24,7 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
{
u8 ampdu_info, tx_mcs_set_cap;
int i, max_tx_streams;
+ bool use_rx_mask;
BUG_ON(!ht_cap);
@@ -71,12 +72,15 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
return;
/* Counting from 0, therefore +1 */
- if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF)
+ if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_RX_DIFF) {
max_tx_streams =
((tx_mcs_set_cap & IEEE80211_HT_MCS_TX_MAX_STREAMS_MASK)
>> IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT) + 1;
- else
+ use_rx_mask = 0;
+ } else {
max_tx_streams = IEEE80211_HT_MCS_TX_MAX_STREAMS;
+ use_rx_mask = 1;
+ }
/*
* 802.11n D5.0 20.3.5 / 20.6 says:
@@ -87,7 +91,8 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
*/
for (i = 0; i < max_tx_streams; i++)
ht_cap->mcs.rx_mask[i] =
- sband->ht_cap.mcs.rx_mask[i] & ht_cap_ie->mcs.rx_mask[i];
+ (use_rx_mask ? sband->ht_cap.mcs.rx_mask[i] : 0xFF) &
+ ht_cap_ie->mcs.rx_mask[i];
if (tx_mcs_set_cap & IEEE80211_HT_MCS_TX_UNEQUAL_MODULATION)
for (i = IEEE80211_HT_MCS_UNEQUAL_MODULATION_START_BYTE;
--
1.5.4.3
On Tue, Apr 20, 2010 at 7:10 PM, Daniel Halperin
<[email protected]> wrote:
> Hi Johannes,
>
> On Apr 20, 2010, at 1:22 AM, Johannes Berg wrote:
>>> Does anyone know if the 11n standard says that the set of TX rates has
>>> to be a subset of the set of RX rates? This seems to be enforced now:
>>> when I set up one node to be 2x1, i.e. transmit 2 streams but only
>>> able to receive 1, then the mac80211 code only lets it transmit 1
>>> streams (even with a 2-stream-capable receiver at the other end).
>>
>> I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
>> about the "Rx Highest Supported Data Rate" field. Seems like maybe you
>> could set the "RX MCS bitmask" to more than is supported, limit it by
>> the highest supported data rate, and then use the bitmask for TX?
>
> First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I assume the section numbers haven't changed). For me that section represents the "Supported MCS Set field".
>
> (An aside: I don't actually *have* 7.3.2.56. I'm using IEEE 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57 and beyond] --- In which document are the missing sections?)
>
> Can you point me at which text in the section you think implies this requirement?
>
> In any case, maybe this discussion is silly: I don't know of any devices with this strange configuration. Typically clients assume downlink-heavy and might support a 1x2 connection but 2x1, i.e. designed for uplink, seems unlikely.
Unless we are talking about an AP...
>
>>> A second question: my understanding is that if I am a 2x2 node and I
>>> associate to a 3x3 AP, the same code will mask out the fact that the
>>> AP can receive 3 streams since I can't transmit 3 streams. Is there a
>>> way to access this info from the driver if I want it?
>>
>> Unfortunately not, at this point. We could keep track of it, what would
>> you need it for?
>
> Okay, that's what I figured; I can hack around it locally. I'm working on an alternative rate selection algorithm that at one point tries to take into account how much receive diversity the other endpoint has. The intuition is that how well (e.g.) 2-stream rates work is going to depend not just on the channel, but also on how many excess antennas the receiver has. I would benefit from knowing whether they have 2 or 3 antennas even if I can only send them at most 2 streams.
>
> Thanks,
> Dan--
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Dan,
> > I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
> > about the "Rx Highest Supported Data Rate" field. Seems like maybe you
> > could set the "RX MCS bitmask" to more than is supported, limit it by
> > the highest supported data rate, and then use the bitmask for TX?
>
> First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I
> assume the section numbers haven't changed). For me that section
> represents the "Supported MCS Set field".
I guess they did change then :)
> (An aside: I don't actually *have* 7.3.2.56. I'm using IEEE
> 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57
> and beyond] --- In which document are the missing sections?)
I am looking at 802.11n final.
> Can you point me at which text in the section you think implies this
> requirement?
It has a lot of tables .. not easily copied.
> In any case, maybe this discussion is silly: I don't know of any
> devices with this strange configuration. Typically clients assume
> downlink-heavy and might support a 1x2 connection but 2x1, i.e.
> designed for uplink, seems unlikely.
And APs would typically be symmetric, countering Gabor's argument :)
But I don't really understand the standard text here, we'll have to find
somebody more familiar with 11n details.
> >> A second question: my understanding is that if I am a 2x2 node and I
> >> associate to a 3x3 AP, the same code will mask out the fact that the
> >> AP can receive 3 streams since I can't transmit 3 streams. Is there a
> >> way to access this info from the driver if I want it?
> >
> > Unfortunately not, at this point. We could keep track of it, what would
> > you need it for?
>
> Okay, that's what I figured; I can hack around it locally. I'm working
> on an alternative rate selection algorithm that at one point tries to
> take into account how much receive diversity the other endpoint has.
> The intuition is that how well (e.g.) 2-stream rates work is going to
> depend not just on the channel, but also on how many excess antennas
> the receiver has. I would benefit from knowing whether they have 2 or
> 3 antennas even if I can only send them at most 2 streams.
Ah. That makes some sense. So far nothing has needed it, but it _could_
also be useful for debugging, so I wouldn't necessarily mind tracking it
in mac80211.
johannes
Hi Dan,
> Does anyone know if the 11n standard says that the set of TX rates has
> to be a subset of the set of RX rates? This seems to be enforced now:
> when I set up one node to be 2x1, i.e. transmit 2 streams but only
> able to receive 1, then the mac80211 code only lets it transmit 1
> streams (even with a 2-stream-capable receiver at the other end).
I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
about the "Rx Highest Supported Data Rate" field. Seems like maybe you
could set the "RX MCS bitmask" to more than is supported, limit it by
the highest supported data rate, and then use the bitmask for TX?
> A quick diff to net/mac80211/ht.c that fixes this for equal modulation
> streams is attached; the problem is still there for unequal modulation
> directly below. Before I send it up I wanted to make sure I'm not
> crazy.
Hmm, ok. I interpreted the standard differently here, but your
interpretation actually makes more sense I guess. Anyone who's more
familiar with the standard?
> A second question: my understanding is that if I am a 2x2 node and I
> associate to a 3x3 AP, the same code will mask out the fact that the
> AP can receive 3 streams since I can't transmit 3 streams. Is there a
> way to access this info from the driver if I want it?
Unfortunately not, at this point. We could keep track of it, what would
you need it for?
johannes
Hi Johannes,
On Apr 20, 2010, at 1:22 AM, Johannes Berg wrote:
>> Does anyone know if the 11n standard says that the set of TX rates has
>> to be a subset of the set of RX rates? This seems to be enforced now:
>> when I set up one node to be 2x1, i.e. transmit 2 streams but only
>> able to receive 1, then the mac80211 code only lets it transmit 1
>> streams (even with a 2-stream-capable receiver at the other end).
>
> I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
> about the "Rx Highest Supported Data Rate" field. Seems like maybe you
> could set the "RX MCS bitmask" to more than is supported, limit it by
> the highest supported data rate, and then use the bitmask for TX?
First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I assume the section numbers haven't changed). For me that section represents the "Supported MCS Set field".
(An aside: I don't actually *have* 7.3.2.56. I'm using IEEE 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57 and beyond] --- In which document are the missing sections?)
Can you point me at which text in the section you think implies this requirement?
In any case, maybe this discussion is silly: I don't know of any devices with this strange configuration. Typically clients assume downlink-heavy and might support a 1x2 connection but 2x1, i.e. designed for uplink, seems unlikely.
>> A second question: my understanding is that if I am a 2x2 node and I
>> associate to a 3x3 AP, the same code will mask out the fact that the
>> AP can receive 3 streams since I can't transmit 3 streams. Is there a
>> way to access this info from the driver if I want it?
>
> Unfortunately not, at this point. We could keep track of it, what would
> you need it for?
Okay, that's what I figured; I can hack around it locally. I'm working on an alternative rate selection algorithm that at one point tries to take into account how much receive diversity the other endpoint has. The intuition is that how well (e.g.) 2-stream rates work is going to depend not just on the channel, but also on how many excess antennas the receiver has. I would benefit from knowing whether they have 2 or 3 antennas even if I can only send them at most 2 streams.
Thanks,
Dan