linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Simon <alexander.simon@saxnet.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 4/4] mac80211: Add HT operation modes for IBSS
Date: Wed, 10 Aug 2011 17:31:08 +0200	[thread overview]
Message-ID: <1312990268.3128.22.camel@alex-2> (raw)
In-Reply-To: <1312985033.4325.19.camel@jlt3.sipsolutions.net>

Am Mittwoch, den 10.08.2011, 16:03 +0200 schrieb Johannes Berg:
> On Mon, 2011-08-08 at 14:10 +0200, Alexander Simon wrote:
> > This means setting channel into HT mode and adding HT IEs in beacons.
> > Check if regdom allows this first.
> > 
> > If joining another HT network, use its HT mode.
> > If joining a non-HT network, use HT mode given by iw.
> > Join as legacy if neither iw nor remote beacon set an HT mode.
> 
> Do we really want this? I'm wondering if we shouldn't always do HT IBSS
> when joining, even if you didn't ask for it? Not really sure though.
> Thoughts? Are we joining as HT20 if you didn't ask for HT40? And are we
> joining as HT20 if you asked for HT40- but the network is HT40+?
In short: The HT parameter shall behave similar to the frequency:
Non-fixed mode: Only used when starting an IBSS or starting HT in an
non-IBSS.
Fixed mode: Only join when HT modes match.

This should answer your last questions:
When not fixed, the BSSID configuration always is preferred. Thus, we
would join as HT40 even though not requested.
So, when we requsted HT40-, but the IBSS is HT40+, we would work on -.

I wanted to have the opportunity to start HT on an existing IBSS.
The problem is that legacy station may "kill" the HT configuration:
If STA A starts in HT IBSS and lets say Windows STA B joins, B would
advertise that IBSS as non-HT as it ignores our HT IE.
Then, if STA A dies and STA C joins, it will be non-HT.
> > If we receive a beacon from another station within our BSSID with a different HT
> > mode than us, we switch to its HT mode. If there are several stations with
> > different HT modes, it may take some time until all will have the same mode.
> > There is no way we can distinguish the "older" station.
> 
> Actually, you can ... the highest TSF should win.
No, pretty sure not. We *are* already joined. That means the TSFs of all
stations *within* our BSSID match. TSFs can only tell whitch BSSID is
older...
So there is no way to distinguish which station first joined.
Or am i wrong? That would be good in that case :)
> 
> > Except for fixed channel mode, HT mode is also fixed. Join or merge ONLY if
> > channel AND HT mode matches.
> 
> makes sense.
> 
> > +++ b/net/mac80211/ibss.c
> > @@ -35,6 +35,76 @@
> >  
> >  #define IEEE80211_IBSS_MAX_STA_ENTRIES 128
> >  
> > +static bool ieee80211_can_use_ext_chan(struct ieee80211_sub_if_data *sdata,
> > +				       struct ieee80211_channel *channel,
> > +				       enum nl80211_channel_type channel_type)
> > +{
> > +	/* check if we are legally allowed to use HT extension channel */
> > +	if ((channel_type == NL80211_CHAN_HT40PLUS) ||
> > +			(channel_type == NL80211_CHAN_HT40MINUS)) {
> > +		int sec_freq = channel->center_freq +
> > +			     (channel_type == NL80211_CHAN_HT40PLUS ? 20 : -20);
> > +		struct ieee80211_channel *sec_chan =
> > +			     ieee80211_get_channel(sdata->wdev.wiphy, sec_freq);
> > +		if (!sec_chan || sec_chan->flags & (IEEE80211_CHAN_DISABLED |
> > +					   IEEE80211_CHAN_PASSIVE_SCAN |
> > +					   IEEE80211_CHAN_NO_IBSS |
> > +					   IEEE80211_CHAN_RADAR)) {
> > +			return false;
> > +		}
> > +	}
> > +	return true;
> > +}
> 
> Isn't that already a function in cfg80211 that you could rename &
> export?
Hmm... Didn't want to do any changes to the module exports, but I'll use
it.
> 
> > +static void ieee80211_update_ht_elems(struct ieee80211_sub_if_data *sdata,
> > +				      struct ieee80211_mgmt *mgmt,
> > +				      struct ieee80211_ht_info *ht_info)
> > +{
> > +	struct ieee80211_local *local = sdata->local;
> > +	struct ieee80211_supported_band *sband =
> > +			local->hw.wiphy->bands[local->oper_channel->band];
> > +	enum nl80211_channel_type channel_type =
> > +			ieee80211_ht_info_to_channel_type(ht_info);
> > +
> > +	if (!ieee80211_can_use_ext_chan(sdata, local->oper_channel, channel_type))
> > +		channel_type = NL80211_CHAN_HT20;
> > +
> > +	if (channel_type != local->_oper_channel_type) {
> > +		struct sk_buff *skb = rcu_dereference_protected(
> > +				sdata->u.ibss.presp,
> > +				lockdep_is_held(&ifibss->mtx));
> > +		struct sk_buff *nskb;
> > +		u8 *ht_ie;
> > +
> > +		/* update HT IE. If not yet existing, create one */
> > +		nskb = skb_copy(skb, GFP_ATOMIC);
> > +		ht_ie = (u8 *)cfg80211_find_ie(WLAN_EID_HT_CAPABILITY,
> > +					       (const u8 *)(nskb->data + 24 +
> > +							sizeof(mgmt->u.beacon)),
> > +					       nskb->len - 24 -
> > +							sizeof(mgmt->u.beacon));
> > +		if (!ht_ie)
> > +			ht_ie = skb_put(nskb, 4 +
> > +					      sizeof(struct ieee80211_ht_cap) +
> > +					      sizeof(struct ieee80211_ht_info));
> > +
> > +		ht_ie = ieee80211_ie_build_ht_cap(ht_ie, sband,
> > +						  sband->ht_cap.cap);
> > +		ht_ie = ieee80211_ie_build_ht_info(ht_ie, &sband->ht_cap,
> > +					     local->oper_channel, channel_type);
> > +		rcu_assign_pointer(sdata->u.ibss.presp, nskb);
> > +		kfree_skb(skb);
> 
> RCU race here.
> 
> > @@ -104,8 +175,17 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
> >  
> >  	sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
> >  
> > +	/* entering a legacy IBSS. Use given HT configuration. */
> > +	if (channel_type == NL80211_CHAN_NO_HT)
> > +		channel_type = ifibss->channel_type;
> >  	local->oper_channel = chan;
> > -	WARN_ON(!ieee80211_set_channel_type(local, sdata, NL80211_CHAN_NO_HT));
> > +
> > +	/* if phy is on a different extension channel, setting ht40 will fail */
> > +	if (!ieee80211_set_channel_type(local, sdata, channel_type)) {
> > +		channel_type = NL80211_CHAN_HT20;
> > +		WARN_ON(!ieee80211_set_channel_type(local, sdata,
> > +				                                 channel_type));
> > +	}
> 
> indentation
> 
> > @@ -404,7 +525,7 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
> >  		ieee80211_sta_join_ibss(sdata, bss);
> >  		supp_rates = ieee80211_sta_get_rates(local, elems, band);
> >  		ieee80211_ibss_add_sta(sdata, mgmt->bssid, mgmt->sa,
> > -				       supp_rates, GFP_KERNEL);
> > +				    supp_rates, elems->ht_cap_elem, GFP_KERNEL);
> 
> indentation
> 
> johannes
> 



  reply	other threads:[~2011-08-10 15:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 12:02 [PATCH 1/4] nl80211: Parse channel type attribute in an IBSS join request Alexander Simon
2011-08-08 12:04 ` [PATCH 2/4] cfg80211: Add cfg80211_get_bss_ht to also match HT configuration Alexander Simon
2011-08-10 13:53   ` Johannes Berg
2011-08-10 15:48     ` Alexander Simon
2011-08-10 16:05       ` Johannes Berg
2011-08-10 17:50         ` Alexander Simon
2011-08-12 12:32           ` Johannes Berg
2011-08-12 14:20             ` Alexander Simon
2011-08-08 12:09 ` [PATCH 3/4] mac80211: Add HT helper functions Alexander Simon
2011-08-10 13:54   ` Johannes Berg
2011-08-10 13:55   ` Johannes Berg
2011-08-08 12:10 ` [PATCH 4/4] mac80211: Add HT operation modes for IBSS Alexander Simon
2011-08-10 14:03   ` Johannes Berg
2011-08-10 15:31     ` Alexander Simon [this message]
2011-08-12 12:35       ` Johannes Berg
2011-08-12 14:25         ` Alexander Simon
2011-08-13 16:05           ` Felix Fietkau
2011-08-10 13:50 ` [PATCH 1/4] nl80211: Parse channel type attribute in an IBSS join request Johannes Berg
2011-08-23 19:39 ` John W. Linville

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=1312990268.3128.22.camel@alex-2 \
    --to=alexander.simon@saxnet.de \
    --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 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).