Le 11/05/2010 12:48, Johannes Berg a écrit :
On Sat, 2010-05-08 at 01:01 +0200, Benoit Papillault wrote:
It would be helpful if you were to rebase over my patch that adds the
channel type tracking.
Your patches are now in wireless-testing, so I am doing it at the moment.
Thanks.
+ if (channel_type != NL80211_CHAN_NO_HT&&
+ sband->ht_cap.ht_supported) {
You shouldn't be able to get here with an HT channel but !ht_supported,
no? Or is that to support the case where you have HT only on one band?
Good point. I think there are several cases here :
- a non-HT STA is joining an HT IBSS (we need to check 802.11n-2009 to
see how it's supposed to be handled). In this case channel_type could be
ht40+ and ht_supported = false
Hmm, true.
- an HT STA is joining a non-HT IBSS. It's clear in this case that no HT
IE should be sent, which is catched by (channel_type !=
NL80211_CHAN_NO_HT) condition.
Right.
Could we examine those cases in a follow up patch?
Well what do we actually need to do then?
I thought again about 2 HT STA joining a non-HT IBSS. If we want those 2
STA to be able to send/receive HT frames then they must know each other
capabilities. So HT Capabilities should be sent if ht_supported = true,
even if channel_type is CHAN_NO_HT
+}
+
+int ieee80211_add_ht_info(u8 **ppos,
+ struct ieee80211_supported_band *sband,
+ struct ieee80211_channel *channel,
+ enum nl80211_channel_type channel_type)
what's wrong with ieee80211_add_ht_ie()
Seems it's close to what I'm doing, but not entirely the same. I will
read it. If applicable, should I move ieee80211_add_ht_ie to util.c (and
declaration to ieee80211_i.h) then ?
Yes.
Done. I still keep both ieee80211_add_ht_ie and ieee80211_add_ht_cap.
What is done in ieee80211_add_ht_ie is only required for an HT AP, not
an HT IBSS STA. I guess we should pass "sdata" to those functions before
merging them.
Also I just noticed that there's a TODO item in rx.c when we receive an
HT frame from a peer we don't know about yet. Not sure what to do there,
but you'll need to look at it.
I did some patch in this area in my tree. Basically, the peer STA is
created only on beacon/probe response since only those frames contains
peer capabilities. Any frames received before is simply ignored.
johannes
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
