From: Benoit Papillault <benoit.papillault@free.fr>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] mac80211: Add HT IE to IBSS beacons and probe responses.
Date: Sat, 08 May 2010 01:01:49 +0200 [thread overview]
Message-ID: <4BE49BDD.8010803@free.fr> (raw)
In-Reply-To: <1273128051.3573.17.camel@jlt3.sipsolutions.net>
Le 06/05/2010 08:40, Johannes Berg a écrit :
> On Thu, 2010-05-06 at 00:36 +0200, Benoit Papillault wrote:
>> When an HT IBSS is configured, we add HT Information and HT Capabilities
>> IE to beacons& probe responses. This is done according to channel_type
>> transmitted by iw/cfg80211.
>>
>> v2: Added helpers to build HT Capability& HT Information IE
>
> This line belongs after the --- so it's not part of the commit log.
>
>> local->oper_channel = chan;
>> - local->oper_channel_type = NL80211_CHAN_NO_HT;
>> + local->oper_channel_type = channel_type;
>
> 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.
>
>> @@ -165,6 +169,14 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>> memcpy(pos,&supp_rates[8], rates);
>> }
>>
>> + 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
- 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.
Could we examine those cases in a follow up patch?
>
>> + }
>> +
>
> trailing whitespace
>
>> @@ -202,6 +214,9 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>> u32 basic_rates;
>> int i, j;
>> u16 beacon_int = cbss->beacon_interval;
>> + const u8 * ht_info_ie;
>
> CodingStyle.
>
>> @@ -223,9 +238,28 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
>> }
>> }
>>
>> + /* parse HT Information IE, if present */
>> + ht_info_ie = ieee80211_bss_get_ie(cbss, WLAN_EID_HT_INFORMATION);
>> + if (ht_info_ie) {
>> + ht_info = (const struct ieee80211_ht_info *)(ht_info_ie + 2);
>> + switch (ht_info->ht_param
>> + & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
>
> The parser in mlme.c looks different. Please see there and also make it
> a helper function.
Thanks. I did not notice.
>
>> --- a/net/mac80211/ieee80211_i.h
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -404,6 +404,7 @@ struct ieee80211_if_ibss {
>> u8 ssid_len, ie_len;
>> u8 *ie;
>> struct ieee80211_channel *channel;
>> + enum nl80211_channel_type channel_type;
>>
>> unsigned long ibss_join_req;
>> /* probe response/beacon for IBSS */
>> @@ -1193,6 +1194,15 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
>> u16 transaction, u16 auth_alg,
>> u8 *extra, size_t extra_len, const u8 *bssid,
>> const u8 *key, u8 key_len, u8 key_idx);
>> +
>> +int ieee80211_add_ht_cap(u8 **ppos,
>> + struct ieee80211_supported_band *sband);
>
> The length is fixed anyway, so how about just passing in
> ...(u8 *buffer, ... sband)
>
>> +int ieee80211_add_ht_info(u8 **ppos,
>> + struct ieee80211_supported_band *sband,
>> + struct ieee80211_channel *channel,
>> + enum nl80211_channel_type channel_type);
>
> same here.
>
>> --- a/net/mac80211/util.c
>> +++ b/net/mac80211/util.c
>> @@ -898,6 +898,82 @@ void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
>> ieee80211_tx_skb(sdata, skb);
>> }
>>
>> +int ieee80211_add_ht_cap(u8 **ppos,
>> + struct ieee80211_supported_band *sband)
>> +{
>
> Actually ... please split up the patches.
>
> 1) pure code moving from the mlme code to helper functions
> 2) helper function rewrite using the structures, like you did
> 3) this patch
>
>> + u16 cap = sband->ht_cap.cap;
>> + struct ieee80211_ht_cap ht_cap;
>> + u8 *pos = *ppos;
>> +
>> + if (ieee80211_disable_40mhz_24ghz&&
>> + sband->band == IEEE80211_BAND_2GHZ) {
>> + cap&= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>> + cap&= ~IEEE80211_HT_CAP_SGI_40;
>> + }
>> +
>> + ht_cap.cap_info = cpu_to_le16(cap);
>> + ht_cap.ampdu_params_info = sband->ht_cap.ampdu_factor |
>> + (sband->ht_cap.ampdu_density<<
>> + IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
>> + ht_cap.mcs = sband->ht_cap.mcs;
>> + ht_cap.extended_ht_cap_info = cpu_to_le16(0);
>> + ht_cap.tx_BF_cap_info = cpu_to_le32(0);
>> + ht_cap.antenna_selection_info = 0;
>> +
>> + /* HT Capabilities element */
>> + *pos++ = WLAN_EID_HT_CAPABILITY;
>> + *pos++ = sizeof(struct ieee80211_ht_cap);
>> + memcpy(pos,&ht_cap, sizeof(struct ieee80211_ht_cap));
>> + pos += sizeof(struct ieee80211_ht_cap);
>> +
>> + *ppos = pos;
>> +
>> + return 1;
>
> oh and get rid of the entirely useless return value.
Let's do so.
>
>> +}
>> +
>> +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 ?
>
> Some more effort please! Patches with such _basic_ errors are no fun to
> review!
I will try to do better next time, sorry about that.
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2010-05-07 23:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 22:36 [PATCH v2] cfg80211: Parse channel_type in NL80211_CMD_JOIN_IBSS Benoit Papillault
2010-05-05 22:36 ` [PATCH v2] mac80211: Add HT IE to IBSS beacons and probe responses Benoit Papillault
2010-05-06 6:40 ` Johannes Berg
2010-05-07 23:01 ` Benoit Papillault [this message]
2010-05-11 10:48 ` Johannes Berg
2010-05-12 21:02 ` Benoit Papillault
2010-05-13 0:47 ` Bruno Randolf
2010-05-13 7:09 ` Benoit Papillault
2010-05-14 13:58 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE49BDD.8010803@free.fr \
--to=benoit.papillault@free.fr \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.