> Yeah it would be an option to just always join as HT if HT is available, > but not create as HT unless asked. Ok. I just had a few thoughts about this: This way an ht ibss has to be created from a (patched) mac80211 HT hardware. There would be no way to "convert" an existing g network into n. Additionally, if a non-ht implementation joins the network, it will advertise it as non-ht. If a second ht-station joins from one of these beacons, it won't use ht. This way a single non-ht station could destroy a ht ibss. I Think the best way to go would be to obey HT information when joining HT but using the HT iw parameter when joining non-ht. Then we could have the following scenario: Non-HT station A creates non-HT. HT station B joins and sets HT- (from iw). HT station C joins from A but doesn't see B. It's iw parameter says ht+. But when B comes closer to C do a "HT merge", comparing TSFs. Conclusion: - Create an ibss with the iw parameter - When joining a ht ibss, use its parameters - When joining non-ht, add ht from iw parameter - When encounter a different ht config, do a ht merge. -- 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
