summaryrefslogtreecommitdiff
path: root/certs/blacklist_nohashes.c
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2017-10-13 15:26:01 +0300
committerJohannes Berg <johannes.berg@intel.com>2017-10-13 14:29:02 +0200
commitb1b1ae2c1c150f8db5d3523c74e81eaf8cae5cbb (patch)
treef95c6389caae8731706de35d3ae1e82a01056693 /certs/blacklist_nohashes.c
parent88230ef1f31bf2d8fcf42c20e5743ff4b3618a29 (diff)
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 'certs/blacklist_nohashes.c')
0 files changed, 0 insertions, 0 deletions