| Message ID | 20241130212017.593-1-n.rottgardt@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | wnm_ap: optional disassociation for bss_tm_req | expand |
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?
"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? >
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? >>
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? >>>
diff --git a/src/ap/wnm_ap.c b/src/ap/wnm_ap.c index af8cccaef..d4770c072 100644 --- a/src/ap/wnm_ap.c +++ b/src/ap/wnm_ap.c @@ -961,6 +961,16 @@ int wnm_send_bss_tm_req(struct hostapd_data *hapd, struct sta_info *sta, const u8 *bss_term_dur, u8 dialog_token, const char *url, const u8 *nei_rep, size_t nei_rep_len, const u8 *mbo_attrs, size_t mbo_len) +{ + return wnm_send_bss_tm_req_disassoc(hapd, sta, req_mode, disassoc_timer, valid_int, bss_term_dur, dialog_token, url, nei_rep, nei_rep_len, mbo_attrs, mbo_len, true); +} + + +int wnm_send_bss_tm_req_disassoc(struct hostapd_data *hapd, struct sta_info *sta, + u8 req_mode, int disassoc_timer, u8 valid_int, + const u8 *bss_term_dur, u8 dialog_token, + const char *url, const u8 *nei_rep, size_t nei_rep_len, + const u8 *mbo_attrs, size_t mbo_len, bool disassoc) { u8 *buf, *pos; struct ieee80211_mgmt *mgmt; @@ -1050,7 +1060,8 @@ int wnm_send_bss_tm_req(struct hostapd_data *hapd, struct sta_info *sta, #endif /* CONFIG_IEEE80211BE */ /* send disassociation frame after time-out */ - set_disassoc_timer(hapd, sta, disassoc_timer); + if (disassoc) + set_disassoc_timer(hapd, sta, disassoc_timer); } return 0; diff --git a/src/ap/wnm_ap.h b/src/ap/wnm_ap.h index f86c6b2af..4e0aa1f9e 100644 --- a/src/ap/wnm_ap.h +++ b/src/ap/wnm_ap.h @@ -23,6 +23,11 @@ int wnm_send_bss_tm_req(struct hostapd_data *hapd, struct sta_info *sta, const u8 *bss_term_dur, u8 dialog_token, const char *url, const u8 *nei_rep, size_t nei_rep_len, const u8 *mbo_attrs, size_t mbo_len); +int wnm_send_bss_tm_req_disassoc(struct hostapd_data *hapd, struct sta_info *sta, + u8 req_mode, int disassoc_timer, u8 valid_int, + const u8 *bss_term_dur, u8 dialog_token, + const char *url, const u8 *nei_rep, size_t nei_rep_len, + const u8 *mbo_attrs, size_t mbo_len, bool disassoc); void ap_sta_reset_steer_flag_timer(void *eloop_ctx, void *timeout_ctx); int wnm_send_coloc_intf_req(struct hostapd_data *hapd, struct sta_info *sta, unsigned int auto_report, unsigned int timeout);
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. Signed-off-by: Nils Hendrik Rottgardt <n.rottgardt@gmail.com> --- src/ap/wnm_ap.c | 13 ++++++++++++- src/ap/wnm_ap.h | 5 +++++ 2 files changed, 17 insertions(+), 1 deletion(-)