[PATCH] wnm_ap: optional disassociation for bss_tm_req

[Nils Rottgardt]

Hi Jouni,

any comments to this thoughts? Actually the interface is not entirely 
available as needed to control roaming at best for a wifi controller.

Cheers,

Nils

Am 07.02.2025 um 12:54 schrieb 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?
>>>