[PATCH] wnm_ap: optional disassociation for bss_tm_req

[Nils Rottgardt]

"right reason code":

This would be an option as well. I gone this way as Usteer does the 
disassociation on its own and it would be flexible and easy to still use 
this.


"avoid a disassociation part":

 From IEEE specs I know the disassociation is not played that hard. 
Clients have some options to handle the disassociation imminent flag and 
also reacts differently of the disassociation timer value is provided or 
not. E.g. my Intel AX201 or iPhone will roam only sometimes with 
disassociation imminent = false or true...the roaming behaviour changes 
if disassociation timer is set only. Actually Usteer using roaming with 
disassociation imminent = true without disassociation to handle 
BSS_TM_RESP. This leads into Clients ignoring the BSS_TM_REQ.

- disassociation imminent not set: a suggestion to roam, client handles 
it with very low priority

- disassociation imminent set, disassociation timer not set: the client 
should roam/react on the roaming request as it will be disassociated 
sometimes in the future. Actually Usteer using this flag without using 
disassociation timer. This leads into an issue as according IEEE this 
tells the client that it will be disassociated to a random time in the 
future. Some clients like Intel AX201 or iPhone will mostly handle it 
like disassociation imminent = false.

- disassociation imminent set, disassociation timer set: the client is 
told the exact time after it will be disassociated if it does not 
roam/react. As it is set explicitly Intel AX201 and iPhone will follow 
this BSS_TM_REQ instantly. Sometimes they answers with a BSS_TM_RESP 
different from 0 like BSS_TM_RESP 2 (denied) or 6 (Delay requested). 
Then it should be allowed to stay but this is not possible as it will be 
hardly disassociated by hostap. This leads into stuttering with e.g. 
VoIP sessions if the client cannot associate with the new AP somehow...

Usteer implemented a workaround not setting disassociation timer and 
force the disassociation on its own but clients reacts differently 
knowing the exact time... 
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/201015-802-11v-Basic-Service-Set-BSS-on-AireO.html#anc10


My idea was to do the whole disassociation handling in Usteer so if the 
client responded with a deny nothing has to be done. If the client does 
not answer it will be disassociated with UBUS: del_client command. I did 
not checked what is exactly called in hostap but it is 
hostapd_drv_sta_deauth and ap_sta_deauthenticate.


To sum it up: It is crucial for some Wifi clients to have disassociation 
timer published in the BSS_TM_REQ frame as it leads into a higher 
priority. Disassociation imminent is unrewarding without...but is using 
disassociation timer the BSS_TM_RESP is senseless as the disassociation 
is hardcoded in hostap and cannot be stopped.



Am 25.12.2024 um 18:25 schrieb Jouni Malinen:
> On Sat, Nov 30, 2024 at 10:20:17PM +0100, Nils Hendrik Rottgardt wrote:
>> To give controllers like usteer or DAWN the opportunity to disassociate
>> with the right reason code and also avoid a disassociation if it is
>> not neccessary.
> For the "right reason code" part, I would prefer to have an option for
> such external components to provide that reason code with the command to
> send the BSS Transition Management Request frame instead of expecting
> them to handle the timeout.
>
> For the "avoid a disassociation part", why would the AP send a
> notification of imminent disassociation if it is not going to
> disassociate the STA? If I remember correctly, the disassociation is
> actually required to happen at least for some cases, so it would be good
> to understand why there would be desire to avoid that.
>
> Furthermore, this patch does not actually provide any means for using
> this proposed functionality since nothing here calls
> wnm_send_bss_tm_req_disassoc() with disassoc = false. Even if such
> option were added, it should also be noted that set_disassoc_timer()
> does two things: removes a cached PMKSA for the STA (to force new
> association) and starts a timer to disassociate the STA. Is there really
> need to skip that first part as well?
>