help understanding HT capabilities bits

help understanding HT capabilities bits

[Danek Duvall]

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.

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.

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.  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.  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?

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.

I've tried navigating the code from iw into nl80211.c, the mac80211 driver,
and the various 802.11 headers, but between the transitions from one layer
to the next and the distinctions between things named rdev and wiphy and
sta, I'm a bit lost trying to determine what represents an underlying
capability and what represents some sort of current state.  I'm a complete
newbie to this, both in code and concepts, but I hope I'm not so far in
over my head that a little help won't be very useful.

Thanks,
Danek

Re: help understanding HT capabilities bits

[Johannes Berg]

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

Re: help understanding HT capabilities bits

[Danek Duvall]

On Mon, Aug 13, 2018 at 12:25:55PM +0200, Johannes Berg wrote:

> 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 :-)

Believe me, I'm trying to get away from that as fast as possible.  :)

> [ ... ]
> > 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.

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?).  Presumably if it doesn't represent the
current state, then it also never changes.  I don't understand in what
circumstances that's useful.

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?

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.

Thanks,
Danek

Re: help understanding HT capabilities bits

[Johannes Berg]

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

Re: help understanding HT capabilities bits

[Danek Duvall]

On Tue, Aug 14, 2018 at 09:48:37AM +0200, Johannes Berg wrote:

> 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.

Okay, I think I got it.

Thanks!
Danek