diff options
author | Johannes Berg <johannes.berg@intel.com> | 2017-10-13 15:26:01 +0300 |
---|---|---|
committer | Johannes Berg <johannes.berg@intel.com> | 2017-10-13 14:29:02 +0200 |
commit | b1b1ae2c1c150f8db5d3523c74e81eaf8cae5cbb (patch) | |
tree | f95c6389caae8731706de35d3ae1e82a01056693 /Documentation | |
parent | 88230ef1f31bf2d8fcf42c20e5743ff4b3618a29 (diff) | |
download | linux-b1b1ae2c1c150f8db5d3523c74e81eaf8cae5cbb.tar.bz2 |
mac80211: don't track HT capability changes
The code here (more or less accidentally) tracks the HT capability of
the AP when connected, and we found at least one AP that erroneously
toggles its 20/40 capability bit when changing between 20/40 MHz. The
connection to the AP is then broken because we set the 40 MHz disable
flag based on this, as soon as it switches to 20 MHz, but because the
flag then changed, we disconnect.
I'd be inclined to just ignore this issue, since we then reconnect
while the AP is in 20 MHz mode and never use 40 MHz with it again,
but this code is a bit strange anyway - we don't use the capabilities
for anything else.
Change the code to simply not track the HT capabilities at all, which
assumes that the AP at least sets 20/40 capability when operating in
40 MHz (or higher). If not, rate scaling might end up using only the
narrower bandwidth.
The new behaviour also mirrors what VHT does, where we only check the
VHT operation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions