ath9k: add module option for disabling 11n functionality
PATCH 1/1 ath9k: add module option for disabling 11n functionality
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(-)
(quoted diff) +0 -0
b/drivers/net/wireless/ath/ath9k/init.c
index 616e30b..9521ca3 100644
drivers/net/wireless/ath/ath9k/init.c +9 -1
@@ -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 |
Signature · 1 line
1.7.5.4
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 7 lines · 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.
Would be lovely if this could be per VIF, and settable through something dynamic, even if just debugfs or similar....
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 11 lines · Ben Greear
Quoted 7 lines · 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.
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
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 7 lines · Luis R. Rodriguez
Quoted 6 lines · Ben Greear
Quoted 5 lines · 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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 2 lines
Luis
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 6 lines · Luis R. Rodriguez
Quoted 5 lines · Ben Greear
Quoted 4 lines · 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.
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
PATCH 1/1 ath9k: add module option for disabling 11n functionality
In reply to Michel Alexandre SalimQuoted 5 lines · 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.
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 3 lines · Jouni Malinen
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. :-)
Quoted 5 lines
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
PATCH 1/1 ath9k: add module option for disabling 11n functionality
In reply to Jouni MalinenQuoted 10 lines · Jouni Malinen
Quoted 5 lines · 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.
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.
Quoted 7 lines
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,
Signature · 7 lines
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 attachmentsPATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 8 lines · Michel Alexandre Salim
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 10 lines · Jouni Malinen
Quoted 8 lines · Michel Alexandre Salim
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?
Quoted 6 lines
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.
Quoted 5 lines
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,
Signature · 7 lines
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 attachmentsPATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 3 lines · Michel Alexandre Salim
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
PATCH 1/1 ath9k: add module option for disabling 11n functionality
Quoted 8 lines · Jouni Malinen
Quoted 6 lines · Michel Alexandre Salim
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?
Quoted 11 lines
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.
Signature · 7 lines
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