linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Danek Duvall <duvall@comfychair.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: help understanding HT capabilities bits
Date: Tue, 14 Aug 2018 09:48:37 +0200	[thread overview]
Message-ID: <1534232917.3547.2.camel@sipsolutions.net> (raw)
In-Reply-To: <20180813204131.GA10207@lorien.comfychair.org>

Hi,

> Okay, I think I see: it reflects neither the current state of the device,
> nor the capabilities of the device, but the initial, default state of the
> device (at power-on, presumably?).  

It's really the default state for each new connection, unless it's
changed. It is actually changed though by mac80211, for example, so it
probably change these bits before sending them to the AP.

> Presumably if it doesn't represent the
> current state, then it also never changes.  I don't understand in what
> circumstances that's useful.

It isn't really. It's just a side effect of
 * the 802.11 protocol including it in the capabilities
 * nl80211 including the whole protocol struct instead of breaking it up

> I also think I now see that the current SMPS state comes from the SMPS_MODE
> attribute, and the device capability comes from the FEATURE_STATIC_SMPS and
> FEATURE_DYNAMIC_SMPS bits of the FEATURE_FLAGS attribute.  Is that correct?

Yeah, those are more useful than the capability.

> Do any of the other fields in HT_CAPA (or VHT_CAPA) have the same kind of
> meaning as the SMPS bits?  For instance, if the HT20/40 bit is off, then
> can we say anything about whether the device supports 40MHz channels (as
> I've been interpreting it)?  Or is it also some sort of default value (and
> if so, where would I go looking for that particular device capability)?  Is
> the answer to that question related to HT_CAPABILITY_MASK?  Basically I'm
> wondering if I should ignore HT_CAPA for my purposes (which are to choose a
> suitable radio on which to build an AP stack) and pull the data from some
> other attributes.

A lot of these might be possible to change, but I think for the most
part they're static. The 20/40 is a bit special as there's also a
cfg80211 module parameter that controls it on 2.4 GHz though.

johannes

  reply	other threads:[~2018-08-14 10:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 23:43 help understanding HT capabilities bits Danek Duvall
2018-08-13 10:25 ` Johannes Berg
2018-08-13 20:41   ` Danek Duvall
2018-08-14  7:48     ` Johannes Berg [this message]
2018-08-17 19:22       ` Danek Duvall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1534232917.3547.2.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=duvall@comfychair.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).