cfg80211: fix extension channel checks to initiate communication
commit3acc1eff9aab5dc224463d6fdc1fc98912f97a6f
authorLuis R. Rodriguez <lrodriguez@atheros.com>
Sat, 13 Nov 2010 00:31:23 +0000 (12 16:31 -0800)
committerAndi Kleen <ak@linux.intel.com>
Tue, 14 Dec 2010 22:40:18 +0000 (14 23:40 +0100)
tree368aa99e27222c8ca6914c84265435585de8ab4e
parentead0b93a89eb1bab781b1812b42b3cffeecda1d0
cfg80211: fix extension channel checks to initiate communication

commit 9236d838c920e90708570d9bbd7bb82d30a38130 upstream.

When operating in a mode that initiates communication and using
HT40 we should fail if we cannot use both primary and secondary
channels to initiate communication. Our current ht40 allowmap
only covers STA mode of operation, for beaconing modes we need
a check on the fly as the mode of operation is dynamic and
there other flags other than disable which we should read
to check if we can initiate communication.

Do not allow for initiating communication if our secondary HT40
channel has is either disabled, has a passive scan flag, a
no-ibss flag or is a radar channel. Userspace now has similar
checks but this is also needed in-kernel.

Reported-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
net/wireless/chan.c