"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?
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
