On 03/11/2011 12:24 PM, Johannes Berg wrote:
On Fri, 2011-03-11 at 12:17 -0800, Ben Greear wrote:
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.
The fix seems right.
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.
But I'm not sure what you mean?
With the fix, we go through and use the widest possible channel of all
interfaces. The only conflict can happen with HT40- and HT40+, but we
should never get into that situation since we can't have one interface
with HT40- and another with HT40+ at the same time to start with. Am I
missing something?
Maybe I'm missing something, but from what I can tell:
If we have two interfaces:
first interface is HT40, second is HT20:
-> superchan == HT20
first interface is HT20, second is HT40:
-> superchan == HT40
It seems wrong that the ordering would influence superchan before we go into
the "switch (superchan)" logic.
Thanks,
Ben
johannes
--
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
