| Message ID | 4E0A2F8A.8010102@fedoraproject.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,
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.
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,
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.
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 |