On Wed, 2011-08-10 at 17:31 +0200, Alexander Simon wrote: > In short: The HT parameter shall behave similar to the frequency: > Non-fixed mode: Only used when starting an IBSS or starting HT in an > non-IBSS. > Fixed mode: Only join when HT modes match. Ok, that makes sense. So you need the get_bss_ht() only for fixed mode I guess. > This should answer your last questions: > When not fixed, the BSSID configuration always is preferred. Thus, we > would join as HT40 even though not requested. > So, when we requsted HT40-, but the IBSS is HT40+, we would work on -. ? I think I know what you mean but your example seems .. the wrong way around? > I wanted to have the opportunity to start HT on an existing IBSS. Well that should always be OK? > The problem is that legacy station may "kill" the HT configuration: > If STA A starts in HT IBSS and lets say Windows STA B joins, B would > advertise that IBSS as non-HT as it ignores our HT IE. > Then, if STA A dies and STA C joins, it will be non-HT. mac80211 is STA C? Would it be a problem to use HT if the IBSS was previously non-HT? The old members will ignore it, but other new HT members may work OK? IOW -- is it not possible to have a mixed HT/non-HT IBSS? > No, pretty sure not. We *are* already joined. That means the TSFs of all > stations *within* our BSSID match. TSFs can only tell whitch BSSID is > older... > So there is no way to distinguish which station first joined. > Or am i wrong? That would be good in that case :) Oh, no, you're right of course. 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
