Re: Extended Capabilities bit values overwritten by the kernel

On 23/10/2025 17:24, Johannes Berg wrote:
> On Thu, 2025-10-23 at 15:13 +0200, Pablo MARTIN-GOMEZ wrote:
>> Hello all,
>>
>> I've encountered an issue with an ath12k & hostapd based AP: whatever
>> value I put in `he_twt_responder` and `he_twt_responder` in the hostapd
>> config, I always have the bit `TWT Responder Support` set to 1 in the
>> Extended Capabilities IE. This happens because hostapd overwrites all
>> the bit values of the Extended Capabilities bitmap set in the config
>> with the values coming from the kernel (ext_capa_mask) since commit
>> 8cd6b7bce8b8f1fe2803bc17ddf0f51bd07330b1 (hostapd), and in the case of
>> the ath12k (and also ath11k), the driver sets
>> WLAN_EXT_CAPA10_TWT_RESPONDER_SUPPORT in ext_capa_mask. I'm unsure on
>> how to fix this: should hostapd be change so the kernel values can be
>> overwritten by the config, or are the kernel values an invariant that
>> shall not be overwritten and therefore ath12k should be modified
>> so WLAN_EXT_CAPA10_TWT_RESPONDER_SUPPORT is only set in the user space
>> or elsewhere in the driver dynamically. I'm taking the example with TWT
>> Responder and ath12k, but I believe other drivers are concerned (e.g.
>> TWT Requester Support and iwlwifi).
> You're probably the only/first person to ever want to _remove_
> capabilities that the driver has :)
It is more a question of testing a capability and its performance's 
impact than to remove it completely :)
> 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.
It's bit more complicated than that, at least in the case of TWT 
Responder in ath12k.  When we don't set NL80211_ATTR_TWT_RESPONDER flag 
in hostapd, the ath12k driver sends a command to the device to disable 
TWT, so we end up in a situation where the device does not support the 
feature anymore but we are still advertising its support in the 
capabilities IE.
> 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?
Ok, so for my case, I just need to clear the bit, the feature is already 
disabled in the lower levels. If I go for that solution in 
hostapd/wpa_s, the issue is going to be can it break another driver?
>
> johannes