On 03/11/2011 12:05 PM, Felix Fietkau wrote:
When running an AP interface along with the cooked monitor interface created
by hostapd, adding an interface and deleting it again triggers a channel type
recalculation during which the (non-HT) monitor interface takes precedence
over the HT AP interface, thus causing the channel type to be set to non-HT.
Fix this by not overriding HT interfaces with a non-HT channel type.
After staring at that code a bit more, should that list-for-each-entry
loop be entirely different such that it better calculates a proper
super-channel for mixed interface types?
If seems like a bad case of last-one-wins as currently written.
The code probably (mostly?) works right because we limit the
bss_conf.channel_type based on existing super-chan when
adding new interfaces, but it still seems like brittle code to me.
Thanks,
Ben
Signed-off-by: Felix Fietkau<nbd@xxxxxxxxxxx>
---
net/mac80211/chan.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5b24740..8511e60 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -76,6 +76,7 @@ bool ieee80211_set_channel_type(struct ieee80211_local *local,
switch (tmp->vif.bss_conf.channel_type) {
case NL80211_CHAN_NO_HT:
+ break;
case NL80211_CHAN_HT20:
superchan = tmp->vif.bss_conf.channel_type;
break;
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
