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? johannes -- 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
