Yes. Same here, pity that usteer can't blacklist Mac addresses...
Does usteer ask devices to scan when their signal level drops below roam_scan_snr or is there some other trigger?
IIUC, Usteer is doing like "please make scan near devices if there is some with better signal" (exactly it is option: roam_scan_snr) and by using roam_trigger_snr it just says to the device "you need to make scan now".
And when it goes to min_snr, it says "you will be kicked out soon"
I'm asking because it isn't clear for me what is the full algorithm. It would be great to have some kind of a graph of the various states that devices/signal etc are in and what happens then. I've noticed that iOS devices do the scan anyway when they reach -70 dBm. I think usteer then picks up these probes from all APs and reports the signal level.
That would be easy to implement.
Could you check the features of your TV with the following command on the AP it is connected to: ubus call usteer connected_clients
Normally stationary devices like Alexas, etc. does not support roaming as they are stationary by definition.
Devices can also trigger assisted roaming like you described. Then the devices asks for a better AP to roam, but I never saw this in my network. If I finished by enhancements I plan to update the Wiki Guide for usteer on OpenWRT homepage.
It isnât assisted, I think. But only Wireshark can tell the whole story.
Yes, you're right, but if affects I don't know how exactly. Using Amazon Luna a message of "poor wifi" appears and the lag is noticeable each X seconds if the TV is under the snr scan value. I had to modify it to fix the issue.
You can install screen or something and monitor ubus via: ubus monitor | grep "method":"bss_transition_request" | awk '{ print strftime("[%Y-%m-%d %H:%M:%S]"), $0 }'
Then you can see if there is a roaming request created by usteer.
I have usteer-initiated roaming disabled, so this shouldnât show anything. My devices roam by themselves just fine. Of course with adjusted tx power for all APs.
What makes usteer interesting for me is the Hearning Map and its ability to fill in neighbor lists.
Post the output of the command and we can check. Also set usteer logging to "some debug". The requests of your screen should be visible then in the log. If link-measurement is not supported usteer should not request it.
Perhaps there is a timing issue in the TV implementation as normally a device should not behave like this like a iPhone does not lost connection during a call if a scan is triggered.
You should not use this setting...it not the behavior you described. It is the minimum snr of a possible target to roam. So if you are far away from an AP Usteer will not roam to it if under the snr set even if the connection is far better.
If you are actually on -85 and you have set this option to -70 usteer ignores every AP that is under -70 even if it is better than -85.
1 Like
Cannot make a third reply so have to edit my last post...
I added an option to set the roaming aggressiveness per station. So all active roaming events like scanning could be deactivated but the station is still tracked and also if it issues a roaming on its own it will be processed.
NEW
- Roaming aggressiveness levels from 0 = passive to 3 = active disassociation
- MBO frame used to tell the client why it should roam (still in development) and also delay reassociation (avoid instant jump back to the old AP)
- MAC list to set behavior station wise to e.g. make sticky clients like my AX201 Wifi disassociated and only assist all other devices.
- Send correct disassociation reason to client
- Added some new debug messages to watch roaming in VERBOSE level
- 802.11 specific disassociation timer countdown if roam_kick_delay is higher than validation_period
Recommendation what you should set for a good roaming (which includes band steering but SSIDs must be the same):
option roam_scan_snr '-65'
option signal_diff_threshold '8'
New options
# Timeout (s "1024ms") a station is requested to avoid reassociation after bss transition
#option reassociation_delay 30
# Aggressiveness of roaming to push STA to another node
# 0 = no active roaming / 1 = passive roaming / 2 = roaming with disassociation imminent
# 3 = roaming with disassociation imminent and active disassociation
#option aggressiveness 2
# List of MACs (lower case) with aggressiveness per STA (ff:ff:ff:ff:ff,2)
#list aggressiveness_mac_list ''
Nothing else, this shows the best behavior in my home with 5 APs. It would be much important that 2,4Ghz and higher bands has the same SSID as usteer can only roam/band steer between same SSIDs. Be aware that band steering event is only raised on sticky clients on 2,4Ghz band. Standard roaming take also 2,4Ghz into account.
Feedback appreciated.
3 Likes
The supported transition is done the same way. You can see that in the code here: https://github.com/NilsRo/usteer/blob/0c52090380d1347f913e90754581453ecb469dc1/local_node.c#L729-L753
But it is without disassociation, so as a suggestion to the station only. But to your question, roam_scan_snr triggers the scan and also the logic to check if a staton should roam,kicked, etc. But devices can trigger scans on there own also and also could ignore a scan request.
1 Like
It is nice to see some development on usteer, thank you for the effort @NilsRo.
Am I right that we are waiting for the patches posted on the mailing list to be reviewed/merged?
Yes.
I also post a patch for hostap to finally fix an unnecessary disassociation. If that is available I can post the last patches for usteer with the version running fine at my home for weeks now.
That is my first contribution so hopefully somebody will take care of the review/merge.
6 Likes
I am rooting for it as well. Maybe we should post our experiences with your patches on the mailing list.
3 Likes
Replying with a âTested by:â or âReviewed by:â is helpful yes.
Big lengthy gushing stories less so.
1 Like
I think usteer is very important daemon..
Thanks for trying of maintenance it. @NilsRo
Sounds like a good idea and also if you have feedback to the changes I done.
Would be also nice to test and comment this patch: [PATCH] wnm_ap: optional disassociation for bss_tm_req
It will fix an issue with a disassociation done by hostap instead of usteer/dawn.
1 Like
How bad is to use infinite beacon requests (every 5 sec) when client is on -55dbi signal ?