netdev - Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1470122837.2665.5.camel@sipsolutions.net>
Date:	Tue, 02 Aug 2016 09:27:17 +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 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