On Wed, 2016-08-03 at 11:51 +0900, Masashi Honma wrote: > On 2016年08月02日 16:27, Johannes Berg wrote: > > 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. > > OK, I see. > > HT Capabilities element = Defined by hardware and software spec of > the node. So it does not be modified after boot. It shouldn't really need to be modified, but perhaps for interoperability reasons one might want to, like for example we do in assoc request (we restrict our own capabilities to what the AP supports, because some APs are stupid.) That said, I'm basically only objecting to calling this a bugfix. If the behaviour of restricting the information is desired, I see no real problem with that, I just don't see how it could possibly be a bugfix. > HT Operation element = Defined by surrounding environment and > configuration of the node. So it could be modified after boot. > > So, if the node supports HT40, HT Capabilities shows HT40 is capable. > Now, I understand why you rejected this patch. > > But now, when disable_ht=1, no HT Capabilities element in beacon even > though the node supports HT. > > My trailing patch could solve the issue. Actually, *this* one I'm not sure is correct. If you want to disable HT completely, then HT operation can't actually indicate that, and having HT capabilities without HT operation would likely just confuse peers, so I think in this case it's quite possibly necessary to remove HT capabilities. 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
