local_node: preserve kick_time when BSS-TM is rejected#16
Open
stevescot wants to merge 1 commit into
Open
Conversation
When a client rejects a BSS Transition Management request (status_code != 0), do not cancel the already scheduled fallback hard-kick. The previous behavior cancelled kick_time entirely, which left usteer retrying soft steering via roam_scan_tries until eventually giving up after many minutes. By preserving kick_time on rejection, the existing roam_kick_delay fallback remains effective: ask nicely first via BSS-TM, then deauth if the client refuses to move. This significantly reduces roaming latency on devices that consistently reject BSS-TM (e.g., some iPhones). Tested on multi-AP networks where devices previously experienced 40+ minute roaming delays when rejecting soft steering requests.
Member
|
Hi, Signed-of-by is missing. Apart from that looks good. |
Contributor
|
This feature is Included in aggressive roaming. For a clean implementation the client has to be told in the BSS-TM-REQ that it will be kicked. This meta data changes roaming priorities of the stations so an iPhone will leave immediately. But...there is a missing function to stop disassociation in hostapd that must be available if there is a reason code linked to e.g. 7. So if the correct BSS-TM-REQ is send hostap will hardly kick the client. but anyway it is available since merge of #10 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a client rejects a BSS Transition Management request (status_code != 0), do not cancel the already scheduled fallback hard-kick.
Problem
The previous behavior cancelled kick_time entirely, which left usteer retrying soft steering via roam_scan_tries until eventually giving up after many minutes. On devices that consistently reject BSS-TM (e.g., some iPhones), this could result in 40+ minute roaming delays.
Solution
By preserving kick_time on rejection, the existing roam_kick_delay fallback remains effective:
This significantly reduces roaming latency on non-compliant clients while keeping soft steering for devices that support it.