Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1453141 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Johannes Berg <johannes@sipsolutions.net> - 2016-08-01 13:20 +0200
    Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Masashi Honma <masashi.honma@gmail.com> - 2016-08-01 14:40 +0200
      Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Masashi Honma <masashi.honma@gmail.com> - 2016-08-02 06:20 +0200
        Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Johannes Berg <johannes@sipsolutions.net> - 2016-08-02 09:30 +0200
          Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Masashi Honma <masashi.honma@gmail.com> - 2016-08-03 05:00 +0200
            Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template Johannes Berg <johannes@sipsolutions.net> - 2016-08-03 09:00 +0200

#1453141 — Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On Fri, 2016-07-22 at 14:26 +0900, Masashi Honma wrote:
> On 2016年07月14日 05:07, Yaniv Machani wrote:
> > +
> > +	/* if channel width is 20MHz - configure HT capab
> > accordingly*/
> > +	if (sdata->vif.bss_conf.chandef.width ==
> > NL80211_CHAN_WIDTH_20) {
> > +		cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> > +		cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> > +	}
> 
> I have tested this part of your patch and this works for me.
> 
> Previouly, "Supported Channel Width Set bit" in HT Capabilities
> element was 1 even though disable_ht40=1 existed in
> wpa_supplicant.conf. After appllication of patch, the bit was 0.
> 

But why is that behaviour *correct*? We still support 40 MHz bandwidth
things, we just don't use them if we disable HT40.

johannes

[toc] | [next] | [standalone]

#1453188

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.

I could not fully understand your concern...

Do you mean we have 2 bugs about disabling HT40 ?

1) bits in HT capabilities IE
2) HT40 still enabled even if it was disabled by wpa_supplicant or 
hostapd with disable_ht40

And do you mean 1) and 2) should be fixed at one time ?
Indeed, currently on the view point of opposite peer, HT40 was enabled 
even though it was disabled because both 1) and 2) are wrong.
But if only 1) was fixed, this causes unmatch.

Now I do not recognize bug 2).
Do you have any information about 2) ?

[toc] | [prev] | [next] | [standalone]

#1453575

> 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 have tested with hostapd. I compared these 2 configfiles.

hostapd0.conf
	ht_capab=[HT40-]
hostapd1.conf
	#ht_capab=[HT40-]

The IEEE80211_HT_CAP_SUP_WIDTH_20_40 bit in beacon was below.

hostapd0.conf
	IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 1
hostapd1.conf
	IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 0

So I think the bit should be zero if disabled also for mesh peer.

Masashi Honma.

[toc] | [prev] | [next] | [standalone]

#1453641

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

[toc] | [prev] | [next] | [standalone]

#1455599

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.

[toc] | [prev] | [next] | [standalone]

#1455648

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web