All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Schaa <helmut.schaa@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: hostap@lists.shmoo.com, Jouni Malinen <j@w1.fi>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs
Date: Wed, 2 Mar 2011 10:13:05 +0100	[thread overview]
Message-ID: <201103021013.05798.helmut.schaa@googlemail.com> (raw)
In-Reply-To: <1299056258.4076.8.camel@jlt3.sipsolutions.net>

CC'ing linux-wireless

Am Mittwoch, 2. März 2011 schrieb Johannes Berg:
> On Wed, 2011-03-02 at 09:53 +0100, Helmut Schaa wrote:
> > Am Mittwoch, 2. März 2011 schrieb Johannes Berg:
> > > On Wed, 2011-03-02 at 09:37 +0100, Helmut Schaa wrote:
> > > > Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
> > > > associated. This will force _all_ HT transmissions to be protected.
> > > > 
> > > > 802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
> > > > STAs but instead the HT information element contains a flag if non-GF
> > > > STAs are present. All STAs are required to protect GF transmissions in
> > > > that case. Hence, setting HT Mixed mode if non-GF STAs are present is
> > > > superfluous.
> > > 
> > > It seems like this would still be relevant for the AP's TX?
> > 
> > Why? hostapd will configure the new ht_opmode (including the non-GF-STA flag)
> > to the driver. And the driver should do the right thing and enable protection only
> > for GF transmissions in that case, no?

Ok, doing a quick grep through drivers/net/wireless/*:


wl1271 doesn't honor this flag right now but seems trivial to fix:

1347 int wl1271_acx_set_ht_information(struct wl1271 *wl,
1348                                    u16 ht_operation_mode)
1349 {
...
1361         acx->ht_protection =
1362                 (u8)(ht_operation_mode & IEEE80211_HT_OP_MODE_PROTECTION);
1363         acx->rifs_mode = 0;
1364         acx->gf_protection = 0;
1365         acx->ht_tx_burst_limit = 0;
1366         acx->dual_cts_protection = 0;


rt2800 does the right thing:

1240 static void rt2800_config_ht_opmode(struct rt2x00_dev *rt2x00dev,                    
1241                                     struct rt2x00lib_erp *erp)                       
1242 {
1243         bool any_sta_nongf = !!(erp->ht_opmode &
1244                                 IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT);   
...
1310         /* check for STAs not supporting greenfield mode */
1311         if (any_sta_nongf)
1312                 gf20_mode = gf40_mode = 2;


mwl8k also doesn't honor it, no idea how to fix it:

2603 static int
2604 mwl8k_cmd_set_aid(struct ieee80211_hw *hw,
2605                   struct ieee80211_vif *vif, u32 legacy_rate_mask)
2606 {
...
2623                 switch (vif->bss_conf.ht_operation_mode &
2624                         IEEE80211_HT_OP_MODE_PROTECTION) {
2625                 case IEEE80211_HT_OP_MODE_PROTECTION_20MHZ:
2626                         prot_mode = MWL8K_FRAME_PROT_11N_HT_40MHZ_ONLY;
2627                         break;
2628                 case IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED:
2629                         prot_mode = MWL8K_FRAME_PROT_11N_HT_ALL;
2630                         break;
2631                 default:
2632                         prot_mode = MWL8K_FRAME_PROT_DISABLED;
2633                         break;
2634                 }
2635         }
2636         cmd->protection_mode = cpu_to_le16(prot_mode);


iwlwifi/iwllegacy seems correct (as long as the fw is doing the right thing):

560 void iwlagn_bss_info_changed(struct ieee80211_hw *hw,
561                              struct ieee80211_vif *vif,
562                              struct ieee80211_bss_conf *bss_conf,
563                              u32 changes)
564 {
...
608                 ctx->ht.protection = bss_conf->ht_operation_mode &
609                                         IEEE80211_HT_OP_MODE_PROTECTION;
610                 ctx->ht.non_gf_sta_present = !!(bss_conf->ht_operation_mode &
611                                         IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT);
612                 iwlagn_check_needed_chains(priv, ctx, bss_conf);
613                 iwl_set_rxon_ht(priv, &priv->current_ht_config);



Helmut

       reply	other threads:[~2011-03-02  9:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1299055031-25080-1-git-send-email-helmut.schaa@googlemail.com>
     [not found] ` <201103020953.17701.helmut.schaa@googlemail.com>
     [not found]   ` <1299056258.4076.8.camel@jlt3.sipsolutions.net>
2011-03-02  9:13     ` Helmut Schaa [this message]
2011-03-02  9:18       ` [PATCH] hostapd: Don't force HT Mixed Mode for non-GF STAs Johannes Berg
2011-03-02  9:20         ` Helmut Schaa
2011-03-02  9:24           ` 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=201103021013.05798.helmut.schaa@googlemail.com \
    --to=helmut.schaa@googlemail.com \
    --cc=hostap@lists.shmoo.com \
    --cc=j@w1.fi \
    --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.