[PATCH] wnm_ap: optional disassociation for bss_tm_req

[Nils Rottgardt]

Hi Jouni,

have you had time to look at this? Perhaps it could be also an option to 
add a new call to cancel a running dissociation timer to handle 
BSS_TM_RESP responses...could be more complex perhaps instead moving the 
"timer" to the controller application.

Cheers,

Nils

Am 26.12.2024 um 00:45 schrieb 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?
>>