Re: Extended Capabilities bit values overwritten by the kernel

On Thu, 2025-10-23 at 15:13 +0200, Pablo MARTIN-GOMEZ wrote:
> Hello all,
>=20
> I've encountered an issue with an ath12k & hostapd based AP: whatever=20
> value I put in `he_twt_responder` and `he_twt_responder` in the hostapd=
=20
> config, I always have the bit `TWT Responder Support` set to 1 in the=20
> Extended Capabilities IE. This happens because hostapd overwrites all=20
> the bit values of the Extended Capabilities bitmap set in the config=20
> with the values coming from the kernel (ext_capa_mask) since commit=20
> 8cd6b7bce8b8f1fe2803bc17ddf0f51bd07330b1 (hostapd), and in the case of=
=20
> the ath12k (and also ath11k), the driver sets=20
> WLAN_EXT_CAPA10_TWT_RESPONDER_SUPPORT in ext_capa_mask. I'm unsure on=20
> how to fix this: should hostapd be change so the kernel values can be=20
> overwritten by the config, or are the kernel values an invariant that=20
> shall not be overwritten and therefore ath12k should be modified=20
> so=C2=A0WLAN_EXT_CAPA10_TWT_RESPONDER_SUPPORT is only set in the user spa=
ce=20
> or elsewhere in the driver dynamically. I'm taking the example with TWT=
=20
> Responder and ath12k, but I believe other drivers are concerned (e.g.=20
> TWT Requester Support and iwlwifi).

You're probably the only/first person to ever want to _remove_
capabilities that the driver has :)

The original intent (and note the age of that commit) was that we'd have
some capabilities that are implemented by the kernel (mac80211 sets some
such as WLAN_EXT_CAPA8_OPMODE_NOTIF) or device (driver sets some such as
the TWT ones you're looking at) and in that case they're exported to
wpa_s/hostapd to use in the association request/response (respectively);
other capabilities are implemented by hostapd and wpa_supplicant (such
as WNM sleep mode or BSS transition) and then hostapd/wpa_s set the bits
appropriately.

This way, you can add new features purely in the kernel without updating
wpa_supplicant to match, or add some in wpa_supplicant without updating
the kernel, and it all still works.

For mixed features that need both mac80211/driver/device and hostapd or
wpa_s involvement we typically would add an nl80211 extended feature
flag (rather than 802.11 extended capability), and then hostapd/wpa_s
would set the extended capability bit. This, for example, is the case
for FTM responder with NL80211_EXT_FEATURE_ENABLE_FTM_RESPONDER (as well
as some others working slightly differently, e.g. QoS mapping.)

Somehow it appears that we never considered the case of a capability
that's _completely_ implemented in mac80211/driver/device but someone
explicitly does _not_ want to advertise it.

I'm not sure I know what the right solution is ... Obviously not
advertising some features could easily be done in hostapd/wpa_s by just
clearing the bits you don't want, but that wouldn't actually disable the
feature in the lower level. So it'd probably work for TWT responder, but
not for TWT requester maybe, if the request would be triggered by
something in lower levels?

johannes