lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1470207019.2638.7.camel@sipsolutions.net> Date: Wed, 03 Aug 2016 08:50:19 +0200 From: Johannes Berg <johannes@...solutions.net> To: Masashi Honma <masashi.honma@...il.com> Cc: Yaniv Machani <yanivma@...com>, linux-kernel@...r.kernel.org, Meirav Kama <meiravk@...com>, "David S. Miller" <davem@...emloft.net>, linux-wireless@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template 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
Powered by blists - more mailing lists