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:

quoted

On 2016年08月01日 19:03, Johannes Berg wrote:

quoted

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

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.

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.

Masashi Honma.