[PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Johannes Berg]

In some situations it is required that a system be
configured with no support for 40 MHz channels in
the 2.4 GHz band. Rather than imposing any such
restrictions on everybody, allow configuration a
system like that with a module parameter. It is
writable at runtime but only takes effect at the
time of the next association.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 net/mac80211/ieee80211_i.h |    2 ++
 net/mac80211/main.c        |    6 ++++++
 net/mac80211/mlme.c        |    6 ++++++
 net/mac80211/util.c        |   14 +++++++++++---
 4 files changed, 25 insertions(+), 3 deletions(-)

--- wireless-testing.orig/net/mac80211/mlme.c	2009-12-01 18:11:40.000000000 +0100
+++ wireless-testing/net/mac80211/mlme.c	2009-12-01 18:24:18.000000000 +0100
@@ -400,6 +400,12 @@ static void ieee80211_send_assoc(struct 
 
 		/* determine capability flags */
 
+		if (ieee80211_disable_40mhz_24ghz &&
+		    sband->band == IEEE80211_BAND_2GHZ) {
+			cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+			cap &= ~IEEE80211_HT_CAP_SGI_40;
+		}
+
 		switch (ht_info->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET) {
 		case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
 			if (flags & IEEE80211_CHAN_NO_HT40PLUS) {
--- wireless-testing.orig/net/mac80211/util.c	2009-12-01 18:11:40.000000000 +0100
+++ wireless-testing/net/mac80211/util.c	2009-12-01 18:23:38.000000000 +0100
@@ -908,16 +908,24 @@ int ieee80211_build_preq_ies(struct ieee
 	}
 
 	if (sband->ht_cap.ht_supported) {
-		__le16 tmp = cpu_to_le16(sband->ht_cap.cap);
+		u16 cap = sband->ht_cap.cap;
+		__le16 tmp;
+
+		if (ieee80211_disable_40mhz_24ghz &&
+		    sband->band == IEEE80211_BAND_2GHZ) {
+			cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+			cap &= ~IEEE80211_HT_CAP_SGI_40;
+		}
 
 		*pos++ = WLAN_EID_HT_CAPABILITY;
 		*pos++ = sizeof(struct ieee80211_ht_cap);
 		memset(pos, 0, sizeof(struct ieee80211_ht_cap));
+		tmp = cpu_to_le16(cap);
 		memcpy(pos, &tmp, sizeof(u16));
 		pos += sizeof(u16);
-		/* TODO: needs a define here for << 2 */
 		*pos++ = sband->ht_cap.ampdu_factor |
-			 (sband->ht_cap.ampdu_density << 2);
+			 (sband->ht_cap.ampdu_density <<
+				IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT);
 		memcpy(pos, &sband->ht_cap.mcs, sizeof(sband->ht_cap.mcs));
 		pos += sizeof(sband->ht_cap.mcs);
 		pos += 2 + 4 + 1; /* ext info, BF cap, antsel */
--- wireless-testing.orig/net/mac80211/ieee80211_i.h	2009-12-01 18:11:40.000000000 +0100
+++ wireless-testing/net/mac80211/ieee80211_i.h	2009-12-01 18:23:14.000000000 +0100
@@ -881,6 +881,8 @@ void ieee80211_bss_info_change_notify(st
 void ieee80211_configure_filter(struct ieee80211_local *local);
 u32 ieee80211_reset_erp_info(struct ieee80211_sub_if_data *sdata);
 
+extern bool ieee80211_disable_40mhz_24ghz;
+
 /* STA code */
 void ieee80211_sta_setup_sdata(struct ieee80211_sub_if_data *sdata);
 int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
--- wireless-testing.orig/net/mac80211/main.c	2009-12-01 18:11:40.000000000 +0100
+++ wireless-testing/net/mac80211/main.c	2009-12-01 18:23:13.000000000 +0100
@@ -33,6 +33,12 @@
 #include "cfg.h"
 #include "debugfs.h"
 
+
+bool ieee80211_disable_40mhz_24ghz;
+module_param(ieee80211_disable_40mhz_24ghz, bool, 0644);
+MODULE_PARM_DESC(ieee80211_disable_40mhz_24ghz,
+		 "Disable 40MHz support in the 2.4GHz band");
+
 void ieee80211_configure_filter(struct ieee80211_local *local)
 {
 	u64 mc;

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Pavel Roskin]

On Tue, 2009-12-01 at 18:29 +0100, Johannes Berg wrote:
> In some situations it is required that a system be
> configured with no support for 40 MHz channels in
> the 2.4 GHz band. Rather than imposing any such
> restrictions on everybody, allow configuration a
> system like that with a module parameter. It is
> writable at runtime but only takes effect at the
> time of the next association.

That looks like a hack to me.

Maybe it should be treated like other CRDA flags?  In fact, you can find
this in dbparse.py in the wireless-regdb sources:

    # hole at bit 9. FIXME: Where is NO-HT40 defined?
    'NO-HT40':          1<<10,

However, there are no other references to NO-HT40 in the wireless-regdb
or CRDA sources.  I assume it's not implemented.

-- 
Regards,
Pavel Roskin

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Tue, 2009-12-01 at 13:17 -0500, Pavel Roskin wrote:
> On Tue, 2009-12-01 at 18:29 +0100, Johannes Berg wrote:
> > In some situations it is required that a system be
> > configured with no support for 40 MHz channels in
> > the 2.4 GHz band. Rather than imposing any such
> > restrictions on everybody, allow configuration a
> > system like that with a module parameter. It is
> > writable at runtime but only takes effect at the
> > time of the next association.
> 
> That looks like a hack to me.
> 
> Maybe it should be treated like other CRDA flags?  In fact, you can find
> this in dbparse.py in the wireless-regdb sources:
> 
>     # hole at bit 9. FIXME: Where is NO-HT40 defined?
>     'NO-HT40':          1<<10,
> 
> However, there are no other references to NO-HT40 in the wireless-regdb
> or CRDA sources.  I assume it's not implemented.

It's not a regulatory requirement, it's a coexistence requirement.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Luis R. Rodriguez]

On Tue, Dec 1, 2009 at 10:27 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2009-12-01 at 13:17 -0500, Pavel Roskin wrote:
>> On Tue, 2009-12-01 at 18:29 +0100, Johannes Berg wrote:
>> > In some situations it is required that a system be
>> > configured with no support for 40 MHz channels in
>> > the 2.4 GHz band. Rather than imposing any such
>> > restrictions on everybody, allow configuration a
>> > system like that with a module parameter. It is
>> > writable at runtime but only takes effect at the
>> > time of the next association.
>>
>> That looks like a hack to me.
>>
>> Maybe it should be treated like other CRDA flags?  In fact, you can find
>> this in dbparse.py in the wireless-regdb sources:
>>
>>     # hole at bit 9. FIXME: Where is NO-HT40 defined?
>>     'NO-HT40':          1<<10,
>>
>> However, there are no other references to NO-HT40 in the wireless-regdb
>> or CRDA sources.  I assume it's not implemented.
>
> It's not a regulatory requirement, it's a coexistence requirement.

To extend this text a little more, me and Johannes had reviewed usage
of a NO-HT40 flag for regulatory purposes a while back. It was used
mainly on the old Atheros HAL regulatory code and upon a lot of review
even with our own regulatory folks determined that in fact there was
no specific rules about disallowing 40 MHz, but that when this was
disallowed it can be implied by the frequency range not fitting a 40
MHz channel. This is currently computed dynamically now on cfg80211
and its results are outputed through the file:

/sys/kernel/debug/ieee80211/phy0/ht40allow_map

Countries that do not allow HT40 were working on allowing it anyway so
as of now I don't think there are countries that disallow it unless
its implied by the frequency ranges allowed.

  Luis

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Pavel Roskin]

On Tue, 2009-12-01 at 11:18 -0800, Luis R. Rodriguez wrote:
> >> That looks like a hack to me.
> >>
> >> Maybe it should be treated like other CRDA flags?  In fact, you can find
> >> this in dbparse.py in the wireless-regdb sources:
> >>
> >>     # hole at bit 9. FIXME: Where is NO-HT40 defined?
> >>     'NO-HT40':          1<<10,
> >>
> >> However, there are no other references to NO-HT40 in the wireless-regdb
> >> or CRDA sources.  I assume it's not implemented.
> >
> > It's not a regulatory requirement, it's a coexistence requirement.
> 
> To extend this text a little more, me and Johannes had reviewed usage
> of a NO-HT40 flag for regulatory purposes a while back. It was used
> mainly on the old Atheros HAL regulatory code and upon a lot of review
> even with our own regulatory folks determined that in fact there was
> no specific rules about disallowing 40 MHz, but that when this was
> disallowed it can be implied by the frequency range not fitting a 40
> MHz channel. This is currently computed dynamically now on cfg80211
> and its results are outputed through the file:
> 
> /sys/kernel/debug/ieee80211/phy0/ht40allow_map

OK, good to know.

Anyway, I think that using module parameters for any configuration
creates a bad precedent.  Disabling HT40 in the 2.4GHz band is a "fine
tuning" compared to other settings.  But there may be many other such
"knobs" (e.g. ACK timeout), and if they all are controlled by mac80211
parameters, it would be a maintenance nightmare.

If module parameters are discourages for the drivers, mac80211 should be
held to the same standard.

-- 
Regards,
Pavel Roskin

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Tue, 2009-12-01 at 20:19 -0500, Pavel Roskin wrote:

> Anyway, I think that using module parameters for any configuration
> creates a bad precedent.  Disabling HT40 in the 2.4GHz band is a "fine
> tuning" compared to other settings.  But there may be many other such
> "knobs" (e.g. ACK timeout), and if they all are controlled by mac80211
> parameters, it would be a maintenance nightmare.

ACK timeout is a quite different knob. This particular setting is mostly
required for some interoperability testing, but otherwise serves no real
purpose since the AP can always disable 40 MHz anyway, and if it doesn't
then it's very likely that somebody will use 40 MHz with the AP.

In this case, the real solution to the interoperability problem would be
using the frequency broker, but that can hardly be implemented in a
reasonable time frame.

However, the real problem lies with interoperability testing and
certification with a system based around mac80211. In that case, the
frequency broker does not help even if it were implemented.

As such, I believe using a module parameter for a rarely used setting is
a good trade-off, there's no real need to set this on the fly, but it
does sometimes need to be set on boot (which is much easier to achieve
this way) -- yet most of the time, apart from building complete systems
based on the software, nobody cares.

Now, you could make a point that it could be an out-of-tree patch for
those systems that actually do require this type of interoperability
testing and certification that requires this setting, but that is not
very maintainable.

> If module parameters are discourages for the drivers, mac80211 should
> be held to the same standard.

And I would argue that it is -- module parameters are still discouraged,
that doesn't change with adding one. We currently have one in mac80211
to chose the rate control algorithm, but it too is a special case and
ought to not be required.

I don't see this parameter as configuration like ack timeout or 10mhz
channels or ... I think this parameter solves a systems integration
issue, not a configuration issue.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [PATCH] mac80211: allow disabling 40MHz on 2.4GHz

[Pavel Roskin]

On Wed, 2009-12-02 at 02:43 +0100, Johannes Berg wrote:

> And I would argue that it is -- module parameters are still discouraged,
> that doesn't change with adding one. We currently have one in mac80211
> to chose the rate control algorithm, but it too is a special case and
> ought to not be required.
> 
> I don't see this parameter as configuration like ack timeout or 10mhz
> channels or ... I think this parameter solves a systems integration
> issue, not a configuration issue.

OK, fair enough.

-- 
Regards,
Pavel Roskin