| Message ID | 1365849071-2389-1-git-send-email-jogo@openwrt.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi, On 13 April 2013 03:31, Jonas Gorski <jogo@openwrt.org> wrote: > Do not advertise the non standard rates 22 Mbps and 72 Mbps to mac80211, > they will make it into the probe responses and cause clients checking them > to refuse association, e.g. wpa_supplicant says: Are these "turbo" mode rates? ie, 40MHz wide channels with pre-11n rates on them? 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 Sat, 2013-04-13 at 07:29 -0700, Adrian Chadd wrote: > Hi, > > On 13 April 2013 03:31, Jonas Gorski <jogo@openwrt.org> wrote: > > Do not advertise the non standard rates 22 Mbps and 72 Mbps to mac80211, > > they will make it into the probe responses and cause clients checking them > > to refuse association, e.g. wpa_supplicant says: > > Are these "turbo" mode rates? ie, 40MHz wide channels with pre-11n > rates on them? 22 actually *is* a standard rate, it's just that almost nobody implements it. The original problem seems a bit strange though, seems those should just not be marked basic? johannes -- 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 13 April 2013 09:18, Johannes Berg <johannes@sipsolutions.net> wrote: >> Are these "turbo" mode rates? ie, 40MHz wide channels with pre-11n >> rates on them? > > 22 actually *is* a standard rate, it's just that almost nobody > implements it. Well, is it the 20mhz rate or a 40mhz turbo rate? > The original problem seems a bit strange though, seems those should just > not be marked basic? Again, if its a custom rate for 11a/11g 40MHz static turbo style configurations, it should only be exposed when the AP is running in that particular mode. And yes, if the hardware does support it, then it should really only not be configured for basic rates. That way mwl8k<->mwl8k hardware can take advantage of it when those stations are talking to each other. (Yeah, I come from a world where FreeBSD users still want to run Turbo/Static-40MHz operation with things like fast frames and turbo rates.. damned legacy hardware. :-) 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 2013-04-13 8:59 PM, Adrian Chadd wrote: > On 13 April 2013 09:18, Johannes Berg <johannes@sipsolutions.net> wrote: > >>> Are these "turbo" mode rates? ie, 40MHz wide channels with pre-11n >>> rates on them? >> >> 22 actually *is* a standard rate, it's just that almost nobody >> implements it. > > Well, is it the 20mhz rate or a 40mhz turbo rate? > >> The original problem seems a bit strange though, seems those should just >> not be marked basic? > > Again, if its a custom rate for 11a/11g 40MHz static turbo style > configurations, it should only be exposed when the AP is running in > that particular mode. > > And yes, if the hardware does support it, then it should really only > not be configured for basic rates. That way mwl8k<->mwl8k hardware can > take advantage of it when those stations are talking to each other. > > (Yeah, I come from a world where FreeBSD users still want to run > Turbo/Static-40MHz operation with things like fast frames and turbo > rates.. damned legacy hardware. :-) I really don't think this is a 40 MHz thing, the driver does not seem to have any concept of a non-standard legacy 40 MHz mode. I think they simply added different modulation for the 72 MBit/s rate. Keeping this rate doesn't even make sense for mwl8k<->mwl8k, as it's a non-standard legacy rate, whereas the device can do much better with plain 802.11n :) - Felix -- 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 13 April 2013 18:18, Johannes Berg <johannes@sipsolutions.net> wrote: > On Sat, 2013-04-13 at 07:29 -0700, Adrian Chadd wrote: >> Hi, >> >> On 13 April 2013 03:31, Jonas Gorski <jogo@openwrt.org> wrote: >> > Do not advertise the non standard rates 22 Mbps and 72 Mbps to mac80211, >> > they will make it into the probe responses and cause clients checking them >> > to refuse association, e.g. wpa_supplicant says: >> >> Are these "turbo" mode rates? ie, 40MHz wide channels with pre-11n >> rates on them? > > 22 actually *is* a standard rate, it's just that almost nobody > implements it. > > The original problem seems a bit strange though, seems those should just > not be marked basic? After looking at the standard, it became clear that it is only the 72 Mbps rate that's creating the havoc: It will be put in the extended rates, but since 72 * 2 is 144, it will overflow the data rate field and set the basic rate flag/MSB, causing the bogus 8 Mbps "basic" rate. I'll respin this patch with just removing the 72 Mbps rate. Jonas -- 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/mwl8k.c b/drivers/net/wireless/mwl8k.c index ee1778c..04f9051 100644 --- a/drivers/net/wireless/mwl8k.c +++ b/drivers/net/wireless/mwl8k.c @@ -193,10 +193,10 @@ struct mwl8k_priv { struct rxd_ops *rxd_ops; struct ieee80211_supported_band band_24; struct ieee80211_channel channels_24[14]; - struct ieee80211_rate rates_24[14]; + struct ieee80211_rate rates_24[12]; struct ieee80211_supported_band band_50; struct ieee80211_channel channels_50[4]; - struct ieee80211_rate rates_50[9]; + struct ieee80211_rate rates_50[8]; u32 ap_macids_supported; u32 sta_macids_supported; @@ -357,7 +357,6 @@ static const struct ieee80211_rate mwl8k_rates_24[] = { { .bitrate = 20, .hw_value = 4, }, { .bitrate = 55, .hw_value = 11, }, { .bitrate = 110, .hw_value = 22, }, - { .bitrate = 220, .hw_value = 44, }, { .bitrate = 60, .hw_value = 12, }, { .bitrate = 90, .hw_value = 18, }, { .bitrate = 120, .hw_value = 24, }, @@ -366,7 +365,6 @@ static const struct ieee80211_rate mwl8k_rates_24[] = { { .bitrate = 360, .hw_value = 72, }, { .bitrate = 480, .hw_value = 96, }, { .bitrate = 540, .hw_value = 108, }, - { .bitrate = 720, .hw_value = 144, }, }; static const struct ieee80211_channel mwl8k_channels_50[] = { @@ -385,7 +383,6 @@ static const struct ieee80211_rate mwl8k_rates_50[] = { { .bitrate = 360, .hw_value = 72, }, { .bitrate = 480, .hw_value = 96, }, { .bitrate = 540, .hw_value = 108, }, - { .bitrate = 720, .hw_value = 144, }, }; /* Set or get info from Firmware */ @@ -1003,7 +1000,7 @@ mwl8k_rxd_ap_process(void *_rxd, struct ieee80211_rx_status *status, if (rxd->channel > 14) { status->band = IEEE80211_BAND_5GHZ; if (!(status->flag & RX_FLAG_HT)) - status->rate_idx -= 5; + status->rate_idx -= 4; } else { status->band = IEEE80211_BAND_2GHZ; } @@ -1111,7 +1108,7 @@ mwl8k_rxd_sta_process(void *_rxd, struct ieee80211_rx_status *status, if (rxd->channel > 14) { status->band = IEEE80211_BAND_5GHZ; if (!(status->flag & RX_FLAG_HT)) - status->rate_idx -= 5; + status->rate_idx -= 4; } else { status->band = IEEE80211_BAND_2GHZ; } @@ -3080,17 +3077,9 @@ struct mwl8k_cmd_update_set_aid { static void legacy_rate_mask_to_array(u8 *rates, u32 mask) { int i; - int j; - /* - * Clear nonstandard rates 4 and 13. - */ - mask &= 0x1fef; - - for (i = 0, j = 0; i < 14; i++) { - if (mask & (1 << i)) - rates[j++] = mwl8k_rates_24[i].hw_value; - } + for (i = 0; i < 12; i++) + rates[i] = mwl8k_rates_24[i].hw_value; } static int @@ -3972,7 +3961,7 @@ static int mwl8k_cmd_set_new_stn_add(struct ieee80211_hw *hw, if (hw->conf.chandef.chan->band == IEEE80211_BAND_2GHZ) rates = sta->supp_rates[IEEE80211_BAND_2GHZ]; else - rates = sta->supp_rates[IEEE80211_BAND_5GHZ] << 5; + rates = sta->supp_rates[IEEE80211_BAND_5GHZ] << 4; cmd->legacy_rates = cpu_to_le32(rates); if (sta->ht_cap.ht_supported) { cmd->ht_rates[0] = sta->ht_cap.mcs.rx_mask[0]; @@ -4407,7 +4396,7 @@ static int mwl8k_cmd_update_stadb_add(struct ieee80211_hw *hw, if (hw->conf.chandef.chan->band == IEEE80211_BAND_2GHZ) rates = sta->supp_rates[IEEE80211_BAND_2GHZ]; else - rates = sta->supp_rates[IEEE80211_BAND_5GHZ] << 5; + rates = sta->supp_rates[IEEE80211_BAND_5GHZ] << 4; legacy_rate_mask_to_array(p->legacy_rates, rates); memcpy(p->ht_rates, sta->ht_cap.mcs.rx_mask, 16); p->interop = 1; @@ -4889,7 +4878,7 @@ mwl8k_bss_info_changed_sta(struct ieee80211_hw *hw, struct ieee80211_vif *vif, ap_legacy_rates = ap->supp_rates[IEEE80211_BAND_2GHZ]; } else { ap_legacy_rates = - ap->supp_rates[IEEE80211_BAND_5GHZ] << 5; + ap->supp_rates[IEEE80211_BAND_5GHZ] << 4; } memcpy(ap_mcs_rates, ap->ht_cap.mcs.rx_mask, 16);
Do not advertise the non standard rates 22 Mbps and 72 Mbps to mac80211, they will make it into the probe responses and cause clients checking them to refuse association, e.g. wpa_supplicant says: wlan1: hardware does not support required rate 8.0 Mbps Fix this by removing the rates and adapt shifts accordingly. This fixes at least association with Android ICS or newer as well as wpa_supplicant with ath9k to a mwl8k running AP. Signed-off-by: Jonas Gorski <jogo@openwrt.org> --- I'm sending this patch as RFC/RFT because I'm not 100% confident I caught everything - the length of the rate arrays are hardcoded in several places, and some use an offset into it to make it even more confusing. So please test that I did not break anything. drivers/net/wireless/mwl8k.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-)