On Tue, 2016-08-02 at 11:59 +0900, Masashi Honma wrote: > > > > On 2016年08月01日 19:03, Johannes Berg wrote: > > > > > > But why is that behaviour *correct*? We still support 40 MHz > > > bandwidth > > > things, we just don't use them if we disable HT40. > > Or do you mean difference between "hardware capability" and "software > capability" ? > Do you think IEEE80211_HT_CAP_SUP_WIDTH_20_40 bit should be 1 if the > hardware capable of HT40 even though HT40 is disabled by > wpa_supplicant/hostapd ? I basically think that the CAP_SUP_WIDTH_20_40 bit shouldn't matter at all, so it's not clear to me why there's so much talk about it. After all, if 40 MHz isn't actually *used* as indicated by the HT operation (rather than HT capability) IE, then the fact that the device may or may not support 40 MHz is pretty much irrelevant. > I have tested with hostapd. I compared these 2 configfiles. > > hostapd0.conf > ht_capab=[HT40-] > hostapd1.conf > #ht_capab=[HT40-] > This explicitly configures *HT capability* though - that's even the name of the parameter. If you enable HT40 in the capability, the resulting BSS might still not actually *use* 40 MHz bandwidth, as required by overlapping BSS detection. In this patch, they're taking one thing (current HT channel width configuration) and applying it to another thing (HT capability), and then even selling it as a bugfix - which I simply cannot understand. The HT capability shouldn't matter at all, if HT operation is correct. 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
