[PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support

[Johannes Berg]

Hi Harshita,

> > Should we add a separate netlink attribute for the UHR operation, which
> > hostapd would fill with the _full_ data like it appears in association
> > response etc.?
> > 
> > That way, hostapd doesn't need to build a separate data/attribute
> > structure but can just use hostapd_eid_uhr_operation(..., false) for it.
> > 
> > An alternative would be to add more attributes for everything, but it's
> > probably more complicated on both sides?

> Thank you for the suggestions.
> 
> We feel that using separate nested attributes for each feature is the better approach, as this allows us to reuse the attributes for the Enhanced BSS Parameter Critical Update procedure, where similar information is carried in the UHR parameters update element.

Heh, I'll admit I'm surprised - I'm usually the one advocating for
finer-grained attributes, and here I didn't ;-)

> While this approach is slightly more verbose, we believe it offers better extensibility for the future.

Does it actually, though?

I had sort of expected hostapd to add the UHR Parameters Update element
to the beacons, and configure some way of having firmware set the
countdown ("Countdown Timer"). Turns out this is not only in beacons but
also in probe response, (re)association response and (UHR? [1]) link
reconfiguration response frames.

[1] the spec says "Link Reconfiguration Response" but I think it should
say "UHR Link Reconfiguration Response"

But I guess this is going to end up a continuation of the previous wifi7
discussion from last year [2] which hadn't really completed. And Lorenzo
just posted another thing on this [3].

[2] https://lore.kernel.org/linux-wireless/20250717045540.27208-1-aditya.kumar.singh@oss.qualcomm.com/
[3] https://lore.kernel.org/linux-wireless/20260212-mt7996-link-reconf-v1-0-2b110340d6c4@kernel.org/


So I think maybe we need to figure out how we will do all of this first?

Naively, I would've said ... something stupid. I'm reading the spec as
I'm writing this ;-) The UHR Parameters Update element is actually
included in all the beacons across the entire AP MLD.

Maybe we need to take a step back from our previous discussion as well,
and introduce a broader concept here?


I could imagine, for example, something where you say in the nl80211 API
some variation of

 1) Let's start a new update operation ("NL80211_CMD_START_MLD_BSS_UPDATE"),
    I guess already with some parameters saying:
     - the updated affiliated AP (link)
     - the number of beacon intervals you want to do it for
     - the post-update UHR operation (?)
       (or the new channel if it's CSA? etc.?)

     - maybe - more critical if we use it for CSA - already the beacon
       templates for all the links? with all the things I say in (2)
       below, but that's more complex maybe?

       the reason I say this is that there's a difference here in how
       the counter is done - for CSA etc. the things have to disappear
       from the beacon immediately, for UHR updates they stick around
       and the counter indicates "in the past"

    returning a cookie for the operation.

 2) hostapd updates each link's beacon now including the UHR Parameters
    Update element(s), for each currently ongoing update it includes -
    indexed by the cookie - a list of offsets where the counters are
    updated.

    Thing is that this depends on the operation - CSA will already need
    the post-switch beacon template so the flow can continue without
    involving hostapd, hostapd may however need to update the beacon in
    the interim (both pre- and post-switch ones!) and need to refer
    again to where the counters are filled in ...


Either way, it feels like we've reached the end of where the current
design with CSA and BSS color updates will take us. Lorenzo already gave
up and put the parsing into the driver to find the offsets, but I
personally think that's very inflexible.

Some operations such as link removal may not need to have perfect
timing, but some others like CSA really do want the updates to happen at
the precise moment.

In some way, it's almost good that we haven't completed the WiFi7 part
since the UHR part throws another curveball with the counters
decrementing below zero - for past updates - in a sense.


johannes