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


Groups > linux.kernel > #1455648

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

From Johannes Berg <johannes@sipsolutions.net>
Newsgroups linux.kernel
Subject Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
Date 2016-08-03 09:00 +0200
Message-ID <s1YjL-7u6-7@gated-at.bofh.it> (permalink)
References (4 earlier) <s1zlo-7J9-3@gated-at.bofh.it> <s1Cjg-1l9-27@gated-at.bofh.it> <s1Uzv-4PA-15@gated-at.bofh.it> <s1YjL-7u6-9@gated-at.bofh.it> <s1Uzv-4PA-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

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

csiph-web