summaryrefslogtreecommitdiffstats
path: root/net/rds/info.c
diff options
context:
space:
mode:
authorEmmanuel Grumbach <emmanuel.grumbach@intel.com>2020-12-06 14:54:49 +0200
committerJohannes Berg <johannes.berg@intel.com>2020-12-11 13:20:05 +0100
commit189a164d0fc6c59a22c4486d641d0a0a0d33387a (patch)
tree854dde07263def262c6785af511105824d5c3cfd /net/rds/info.c
parentbbf31e88df2f5da20ce613c340ce508d732046b3 (diff)
downloadlinux-stable-189a164d0fc6c59a22c4486d641d0a0a0d33387a.tar.gz
linux-stable-189a164d0fc6c59a22c4486d641d0a0a0d33387a.tar.bz2
linux-stable-189a164d0fc6c59a22c4486d641d0a0a0d33387a.zip
mac80211: don't filter out beacons once we start CSA
I hit a bug in which we started a CSA with an action frame, but the AP changed its mind and didn't change the beacon. The CSA wasn't cancelled and we lost the connection. The beacons were ignored because they never changed: they never contained any CSA IE. Because they never changed, the CRC of the beacon didn't change either which made us ignore the beacons instead of processing them. Now what happens is: 1) beacon has CRC X and it is valid. No CSA IE in the beacon 2) as long as beacon's CRC X, don't process their IEs 3) rx action frame with CSA 4) invalidate the beacon's CRC 5) rx beacon, CRC is still X, but now it is invalid 6) process the beacon, detect there is no CSA IE 7) abort CSA Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.83470b8407e6.I739b907598001362744692744be15335436b8351@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/rds/info.c')
0 files changed, 0 insertions, 0 deletions