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
