Re: help understanding HT capabilities bits

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2018-07-26 at 16:43 -0700, Danek Duvall wrote:
> I'm writing a library using the nl80211 family to, well, do basically what
> iw does (I want a reusable Golang-native implementation, which saves me
> from parsing iw's output).  I have most of the bits that I need, but I'd
> like to fill out more of the library and make it useful to others.

Yes please, don't parse iw output :-)

> I'm a bit stuck on properly naming and describing the pieces of the HT
> capabilities represented by NL80211_BAND_ATTR_HT_CAPA.  While being
> generally impressed with the amount of documentation in nl80211.h and other
> places, I've been unable to find any documentation on this particular
> field, other than what iw prints for each bit or bit combination.

This comes straight from the 802.11 spec, and we usually have less info
on fields like that.

> My first thought was that it was the set of per-band capabilities for the
> device (as defined by either the hardware or the driver, but either way
> below me enough that I don't think I care), and for the most part I still
> think that's right.  

Yes.

> But when it came to trying to represent the SMPS bits,
> it occurred to me that perhaps that wasn't right, since one of the
> supported values gets printed as "disabled", which seems more like a state
> than a capability.  

Yes, also true to some extent.

> Also, "static" and "dynamic" are not representable
> separately, and set together, you get "disabled".  But perhaps "disabled"
> is really "unsupported", and "static" and "dynamic" can't both be supported
> on the same band?

No, you really have "disabled", "static" and "dynamic" as three states
represented in the 2 bits.

> Otherwise, how should I interpret this?  I could simply leave it as a 0-3
> value and let consumers handle the interpretation, but I'd like to be a bit
> friendlier than that, if I can.

They're just the (default) state - disabled, static, dynamic (and
reserved).

However, it really is just the default - the (non-AP) device may change
it on the fly using action frames.

It's not going to be very useful to userspace consumers, I think, since
it doesn't reflect the *current* state.

johannes