diff options
author | Adrian Chadd <adrian@FreeBSD.org> | 2015-02-27 04:45:47 +0000 |
---|---|---|
committer | Adrian Chadd <adrian@FreeBSD.org> | 2015-02-27 04:45:47 +0000 |
commit | b83391bf44038c9944e724188d98120013dd1f04 (patch) | |
tree | 26eb658799972f6ebf3ddce59c8a609d6cab51f0 /sys/net80211/ieee80211_output.c | |
parent | 0567b6cc16673727a15578ef6e69e163e55a11eb (diff) | |
download | src-b83391bf44038c9944e724188d98120013dd1f04.tar.gz src-b83391bf44038c9944e724188d98120013dd1f04.zip |
Fix kern/196290 - don't announce 11n HTINFO rates if the channel is
configured as 11b.
This came up when debugging other issues surrounding scanning and
channel modes.
What's going on:
* The VAP comes up as an 11b VAP, but on an 11n capable NIC;
* .. it announces HTINFO and MCS rates;
* The AP thinks it's an 11n capable device and transmits 11n frames
to the STA;
* But the STA is in 11b mode, and thus doesn't receive/ACK the frames.
It didn't happen for the ath(4) devices as the AR5416/AR9300 HALs
unconditionally enable MCS frame reception, even if the channel
mode is not 11n. But the Intel NICs are configured in 11b/11a/11g
modes when doing those, even if 11n is enabled and available.
So, don't announce 11n capabilities if the VAP isn't on an 11n
channel when sending management assocation request / reassociation
request frames.
TODO:
* Lots more testing - 11n should be "upgraded" after association,
and I just want to make sure I haven't broken 11n upgrade.
I shouldn't have - this is only happening for /sending/ association
requests, which APs aren't doing.
Tested:
* ath(4) APs (AR9331, AR7161+AR9280, AR934x)
* AR5416, STA mode
* Intel 5100, STA mode
PR: kern/196290
Notes
Notes:
svn path=/head/; revision=279350
Diffstat (limited to 'sys/net80211/ieee80211_output.c')
-rw-r--r-- | sys/net80211/ieee80211_output.c | 19 |
1 files changed, 17 insertions, 2 deletions
diff --git a/sys/net80211/ieee80211_output.c b/sys/net80211/ieee80211_output.c index 8cb1f51ac77e..5647c03636b5 100644 --- a/sys/net80211/ieee80211_output.c +++ b/sys/net80211/ieee80211_output.c @@ -2322,18 +2322,33 @@ ieee80211_send_mgmt(struct ieee80211_node *ni, int type, int arg) ic->ic_curchan); frm = ieee80211_add_supportedchannels(frm, ic); } + + /* + * Check the channel - we may be using an 11n NIC with an + * 11n capable station, but we're configured to be an 11b + * channel. + */ if ((vap->iv_flags_ht & IEEE80211_FHT_HT) && + IEEE80211_IS_CHAN_HT(ni->ni_chan) && ni->ni_ies.htcap_ie != NULL && - ni->ni_ies.htcap_ie[0] == IEEE80211_ELEMID_HTCAP) + ni->ni_ies.htcap_ie[0] == IEEE80211_ELEMID_HTCAP) { frm = ieee80211_add_htcap(frm, ni); + } frm = ieee80211_add_wpa(frm, vap); if ((ic->ic_flags & IEEE80211_F_WME) && ni->ni_ies.wme_ie != NULL) frm = ieee80211_add_wme_info(frm, &ic->ic_wme); + + /* + * Same deal - only send HT info if we're on an 11n + * capable channel. + */ if ((vap->iv_flags_ht & IEEE80211_FHT_HT) && + IEEE80211_IS_CHAN_HT(ni->ni_chan) && ni->ni_ies.htcap_ie != NULL && - ni->ni_ies.htcap_ie[0] == IEEE80211_ELEMID_VENDOR) + ni->ni_ies.htcap_ie[0] == IEEE80211_ELEMID_VENDOR) { frm = ieee80211_add_htcap_vendor(frm, ni); + } #ifdef IEEE80211_SUPPORT_SUPERG if (IEEE80211_ATH_CAP(vap, ni, IEEE80211_F_ATHEROS)) { frm = ieee80211_add_ath(frm, |