[PATCH] ath9k: add module option for disabling 11n functionality

[PATCH] ath9k: add module option for disabling 11n functionality

[Michel Alexandre Salim]

Some wireless base stations implement 802.11n mode in ways that 
open-source drivers cannot handle properly, resulting in very unstable 
connections. This patch introduces an '11n_disable' option to the ath9k 
driver, similar to the same option for the iwlagn driver.

Tested at the internal wireless network of www.cs.fau.de, where 802.11n 
currently only works reliably with Windows clients.

---
  drivers/net/wireless/ath/ath9k/init.c |   10 +++++++++-
  1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 616e30b..9521ca3 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -43,6 +43,10 @@ static int ath9k_btcoex_enable;
  module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
  MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence");

+int ath9k_modparam_disable_11n;
+module_param_named(11n_disable, ath9k_modparam_disable_11n, int, 0444);
+MODULE_PARM_DESC(11n_disable, "disable 11n functionality");
+
  bool is_ath9k_unloaded;
  /* We use the hw_value as an index into our private channel structure */

@@ -231,7 +235,11 @@ static void setup_ht_cap(struct ath_softc *sc,
         u8 tx_streams, rx_streams;
         int i, max_streams;

-       ht_info->ht_supported = true;
+       if (ath9k_modparam_disable_11n)
+               ht_info->ht_supported = false;
+       else
+               ht_info->ht_supported = true;
+
         ht_info->cap = IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
                        IEEE80211_HT_CAP_SM_PS |
                        IEEE80211_HT_CAP_SGI_40 |
-- 
1.7.5.4

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Ben Greear]

On 06/28/2011 12:46 PM, Michel Alexandre Salim wrote:
> Some wireless base stations implement 802.11n mode in ways that
> open-source drivers cannot handle properly, resulting in very unstable
> connections. This patch introduces an '11n_disable' option to the ath9k
> driver, similar to the same option for the iwlagn driver.
>
> Tested at the internal wireless network of www.cs.fau.de, where 802.11n
> currently only works reliably with Windows clients.

Would be lovely if this could be per VIF, and settable through something
dynamic, even if just debugfs or similar....

Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [ath9k-devel] [PATCH] ath9k: add module option for disabling 11n functionality

[Luis R. Rodriguez]

On Tue, Jun 28, 2011 at 12:51 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 06/28/2011 12:46 PM, Michel Alexandre Salim wrote:
>> Some wireless base stations implement 802.11n mode in ways that
>> open-source drivers cannot handle properly, resulting in very unstable
>> connections. This patch introduces an '11n_disable' option to the ath9k
>> driver, similar to the same option for the iwlagn driver.
>>
>> Tested at the internal wireless network of www.cs.fau.de, where 802.11n
>> currently only works reliably with Windows clients.
>
> Would be lovely if this could be per VIF, and settable through something
> dynamic, even if just debugfs or similar....

WTF. Are such APs WFA certified? Can you provide more details as to
why there is a mode that "open-source drivers cannot handle properly".

  Luis

Re: [ath9k-devel] [PATCH] ath9k: add module option for disabling 11n functionality

[Ben Greear]

On 06/28/2011 01:06 PM, Luis R. Rodriguez wrote:
> On Tue, Jun 28, 2011 at 12:51 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 06/28/2011 12:46 PM, Michel Alexandre Salim wrote:
>>> Some wireless base stations implement 802.11n mode in ways that
>>> open-source drivers cannot handle properly, resulting in very unstable
>>> connections. This patch introduces an '11n_disable' option to the ath9k
>>> driver, similar to the same option for the iwlagn driver.
>>>
>>> Tested at the internal wireless network of www.cs.fau.de, where 802.11n
>>> currently only works reliably with Windows clients.
>>
>> Would be lovely if this could be per VIF, and settable through something
>> dynamic, even if just debugfs or similar....
>
> WTF. Are such APs WFA certified? Can you provide more details as to
> why there is a mode that "open-source drivers cannot handle properly".

I'd like the feature for testing purposes (use ath9k to act like
just an a/b/g NIC).  No idea about whatever the original poster
is using.

Thanks,
Ben

>
>    Luis


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [ath9k-devel] [PATCH] ath9k: add module option for disabling 11n functionality

[Andreas Hartmann]

Luis R. Rodriguez schrieb:
> On Tue, Jun 28, 2011 at 12:51 PM, Ben Greear <greearb@candelatech.com> wrote:
>> On 06/28/2011 12:46 PM, Michel Alexandre Salim wrote:
>>> Some wireless base stations implement 802.11n mode in ways that
>>> open-source drivers cannot handle properly, resulting in very unstable
>>> connections. This patch introduces an '11n_disable' option to the ath9k
>>> driver, similar to the same option for the iwlagn driver.

This is a joke, isn't it? If there are problems, why don't you fix them
instead of disabling the feature?

I know, there are problems with the 11n mode (not just with atheros
chips) - but they seem to be just ignored by a lot of the developers
here. There is a bug report [1] but it seems to be handled as if it was
sent against /dev/null.

Why don't you fix the problems? Why do you ignore them? Why don't you
support people who are willing to spent time for testing?


Kind regards,
Andreas


[1] http://w1.fi/bugz/show_bug.cgi?id=402

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Jouni Malinen]

On Tue, Jun 28, 2011 at 09:46:18PM +0200, Michel Alexandre Salim wrote:
> Some wireless base stations implement 802.11n mode in ways that
> open-source drivers cannot handle properly, resulting in very
> unstable connections. This patch introduces an '11n_disable' option
> to the ath9k driver, similar to the same option for the iwlagn
> driver.

What is so special about this that makes it impossible for open source
drivers to handle? The proper approach here would be to figure out what
is causing the interop issue and fix (or more likely, work around) that.

In addition, if this is really needed, why would this be a driver
specific hack rather than providing a shared mechanism in mac80211 to
disable 802.11n support? It would sound strange if there would need to
be a new module parameter in every 802.11n driver to handle something
like this.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Adrian Chadd]

On 29 June 2011 05:57, Jouni Malinen <j@w1.fi> wrote:

> What is so special about this that makes it impossible for open source
> drivers to handle? The proper approach here would be to figure out what
> is causing the interop issue and fix (or more likely, work around) that.

And I'd -really- appreciate it if someone did this, so we could fix
open source 11n implementations. :-)

> In addition, if this is really needed, why would this be a driver
> specific hack rather than providing a shared mechanism in mac80211 to
> disable 802.11n support? It would sound strange if there would need to
> be a new module parameter in every 802.11n driver to handle something
> like this.

+1; it should be in the 802.11 stack, not the driver itself.


Adrian

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Michel Alexandre Salim]

On 06/28/2011 11:57 PM, Jouni Malinen wrote:
> On Tue, Jun 28, 2011 at 09:46:18PM +0200, Michel Alexandre Salim wrote:
>> Some wireless base stations implement 802.11n mode in ways that
>> open-source drivers cannot handle properly, resulting in very
>> unstable connections. This patch introduces an '11n_disable' option
>> to the ath9k driver, similar to the same option for the iwlagn
>> driver.
>
> What is so special about this that makes it impossible for open source
> drivers to handle? The proper approach here would be to figure out what
> is causing the interop issue and fix (or more likely, work around) that.

To be honest, I'm not sure. Similar problems have cropped up over the 
years, with various different base stations. In this case I *might* be 
able to find out what base stations we're actually using in the building 
-- they're managed by a different organization so it might take time. In 
cases where it's a free wifi at a cafe somewhere it'd be harder to try 
and debug.

>
> In addition, if this is really needed, why would this be a driver
> specific hack rather than providing a shared mechanism in mac80211 to
> disable 802.11n support? It would sound strange if there would need to
> be a new module parameter in every 802.11n driver to handle something
> like this.
>
I agree with you and Adrian; it should ideally be in the 802.11 stack. 
But as Ben noted, it does have a useful purpose -- for debugging.

If the maintainers are agreeable to a shared mac80211 mechanism, which 
is the preferred way to handle this -- get this in, then refactor *both* 
iwlagn and ath9k to use it, or to implement a shared mechanism, 
demonstrate it with ath9k, then fix iwlagn later?

Thanks,

-- 
Michel Alexandre Salim
µblog:      http://identi.ca/hircus
             http://twitter.com/hircus
GPG key ID: 78884778

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Jouni Malinen]

On Wed, Jun 29, 2011 at 10:56:33AM +0200, Michel Alexandre Salim wrote:
> I agree with you and Adrian; it should ideally be in the 802.11
> stack. But as Ben noted, it does have a useful purpose -- for
> debugging.
> 
> If the maintainers are agreeable to a shared mac80211 mechanism,
> which is the preferred way to handle this -- get this in, then
> refactor *both* iwlagn and ath9k to use it, or to implement a shared
> mechanism, demonstrate it with ath9k, then fix iwlagn later?

I don't follow this.. Why would we get this into ath9k first if the more
appropriate way of doing this would be to modify mac80211 in the first
place. I see no point in doing driver specific hacks for this unless
there really is some driver specific issues that are being worked around
and that does not seem to be the case here.

As far as being able to disable 802.11n in general is concerned, it
would much better to do that as a parameter for the connection (e.g.,
new nl80211 attribute for NL80211_CMD_ASSOCIATE) rather than a module
parameter. This workaround seems to be needed with some APs and global
disabling of 802.11n does not sound like the ideal mechanism for that.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Michel Alexandre Salim]

On 06/29/2011 03:09 PM, Jouni Malinen wrote:
> On Wed, Jun 29, 2011 at 10:56:33AM +0200, Michel Alexandre Salim wrote:
>> I agree with you and Adrian; it should ideally be in the 802.11
>> stack. But as Ben noted, it does have a useful purpose -- for
>> debugging.
>>
>> If the maintainers are agreeable to a shared mac80211 mechanism,
>> which is the preferred way to handle this -- get this in, then
>> refactor *both* iwlagn and ath9k to use it, or to implement a shared
>> mechanism, demonstrate it with ath9k, then fix iwlagn later?
>
> I don't follow this.. Why would we get this into ath9k first if the more
> appropriate way of doing this would be to modify mac80211 in the first
> place. I see no point in doing driver specific hacks for this unless
> there really is some driver specific issues that are being worked around
> and that does not seem to be the case here.
>
The argument would be that driver-specific implementations are easier to 
get committed, and less intrusive than a general framework, but yes, I 
would prefer a more general solution myself.

> As far as being able to disable 802.11n in general is concerned, it
> would much better to do that as a parameter for the connection (e.g.,
> new nl80211 attribute for NL80211_CMD_ASSOCIATE) rather than a module
> parameter. This workaround seems to be needed with some APs and global
> disabling of 802.11n does not sound like the ideal mechanism for that.

Would this not require modifications to e.g. NetworkManager, ConnMan 
etc.  as well? While a module parameter is not an ideal workaround, it's 
at least easy to use. If this goes in as a connection parameter, it'd be 
nice to still have a way of manually adjusting it through a command-line 
tool.

My first attempt to solve this was to use 'iwconfig wlan0 set rate 54M' 
-- but this yields "Operation not supported". How about making a request 
for a rate of 54M or below switch the device to 802.11g mode (and 
optionally, a rate of 11M or below => 802.11b mode)? That way we don't 
need to invent a new interface at all. How would I go about adding 
support for rate setting requests to the driver?

Thanks,

-- 
Michel Alexandre Salim
µblog:      http://identi.ca/hircus
             http://twitter.com/hircus
GPG key ID: 78884778

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Jouni Malinen]

On Wed, Jun 29, 2011 at 03:43:20PM +0200, Michel Alexandre Salim wrote:
> The argument would be that driver-specific implementations are
> easier to get committed, and less intrusive than a general
> framework, but yes, I would prefer a more general solution myself.

Changes to the driver go through the same review process and if it makes
this any simpler to understand, I'm NACKing the change to ath9k since
that is not the correct place for this and module parameter is not the
proper mechanism for this type of workaround.

> Would this not require modifications to e.g. NetworkManager, ConnMan
> etc.  as well? While a module parameter is not an ideal workaround,
> it's at least easy to use. If this goes in as a connection
> parameter, it'd be nice to still have a way of manually adjusting it
> through a command-line tool.

Yes, doing this properly would indeed require changes somewhere in user
space (at least in wpa_supplicant; potentially in other components,
too). Were you assuming that users would manually unload and reload the
driver module if they happen to hit some issues? Or write some modprobe
config files to force 802.11n to be disabled for every connection?
Neither sounds like a reasonable "fix" to me.

> My first attempt to solve this was to use 'iwconfig wlan0 set rate
> 54M' -- but this yields "Operation not supported". How about making
> a request for a rate of 54M or below switch the device to 802.11g
> mode (and optionally, a rate of 11M or below => 802.11b mode)? That
> way we don't need to invent a new interface at all. How would I go
> about adding support for rate setting requests to the driver?

I would first move from WEXT to nl80211 in order to get any chance of
getting the change accepted.. We have a somewhat similar mechanism in
NL80211_CMD_SET_TX_BITRATE_MASK, but it does not address HT rates at
all, so some additions would be needed. For example, a new attribute to
the command could be used to set TX mask for MCS indexes and if none are
allowed, HT could be disabled. Though, a cleaner mechanism would likely
be to just provide an explicit attribute to disable 802.11n. If that is
done outside the scope of a single connection, that would be available
as a manual workaround even without modifications to
wpa_supplicant/NM/ConnMan.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] ath9k: add module option for disabling 11n functionality

[Michel Alexandre Salim]

On 06/29/2011 03:55 PM, Jouni Malinen wrote:
> On Wed, Jun 29, 2011 at 03:43:20PM +0200, Michel Alexandre Salim wrote:
>> My first attempt to solve this was to use 'iwconfig wlan0 set rate
>> 54M' -- but this yields "Operation not supported". How about making
>> a request for a rate of 54M or below switch the device to 802.11g
>> mode (and optionally, a rate of 11M or below =>  802.11b mode)? That
>> way we don't need to invent a new interface at all. How would I go
>> about adding support for rate setting requests to the driver?
>
> I would first move from WEXT to nl80211 in order to get any chance of
> getting the change accepted.. We have a somewhat similar mechanism in
> NL80211_CMD_SET_TX_BITRATE_MASK, but it does not address HT rates at
> all, so some additions would be needed. For example, a new attribute to
> the command could be used to set TX mask for MCS indexes and if none are
> allowed, HT could be disabled. Though, a cleaner mechanism would likely
> be to just provide an explicit attribute to disable 802.11n. If that is
> done outside the scope of a single connection, that would be available
> as a manual workaround even without modifications to
> wpa_supplicant/NM/ConnMan.
>
Thanks for the pointers -- I'll take a look at it and get back when I 
have working code.

-- 
Michel Alexandre Salim
µblog:      http://identi.ca/hircus
             http://twitter.com/hircus
GPG key ID: 78884778

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments