On 2nd thought, Im actually guessing that it may be just a counter showing how many roams happened from or to the AP where you are looking at the overview. If i add up 2.4 and 5GHz then it more or less matches from my one AP to my other AP. I guess also the reason why they are all zero for "This AP".
Then band steering should be shown at least in my opinion. As roaming between the hostap threads. Does somebody see any roams on this AP?
I agree, it should then also show roaming from band to band, but apparently it does not
usteer has some serious bugs in its core functionality that will definitely prevent the actual roaming from happening. I tried sending patches like https://lists.openwrt.org/pipermail/openwrt-devel/2024-May/042785.html, but they haven't been picked up at all.
Until these obvious bugs in core logic are fixed I wouldn't bother spending any time setting it up.
Really depends of what you expect.
For me, usteer works good (better than DAWN or without any of that services).
I will share my config:
config usteer
option network 'lan'
option syslog '1'
option local_mode '0'
option ipv6 '0'
option debug_level '2'
option roam_scan_snr '-70'
option roam_trigger_snr '-75'
option min_snr '-85'
option roam_scan_tries '0'
option max_neighbor_reports '6'
How do you measure that it works?
By walking around the apartment and at least looking to see if wificalling/pings interrupts.
1 Like
I doubt that's the doing of usteer.
Does a roam request appear in the log to check if it is send? Can see BSS-TM-RESP messages and from reading through all the post and this is mentioned everytime.
I don't know why but after using usteer for a long time, now it seems to not start correctly. I've two nodes, one working perfectly, but the other seems to not start:
root@router-comedor:/etc/config# ubus call usteer local_info
{
}
As you can see, the local_info command does not show anything. The other one works perfectly and shows this information.
Some idea of what has broken this?
The logread does not show any error.
I answer myself... it seems some kind of bug in the openwrt snapshot of two weeks ago. Updated to latest snapshot of openwrt and seems to be fixed... the strange is that it only affected one of the two nodes.
Where to report bugs...is this the correct location as nobody answered: Issues · openwrt/usteer (github.com)
1 Like
Yes, it seems the correct location, but nobody seems to care about it.
3 Likes
I don't know since when, but it seems something is broken in current master about roaming... the devices didn't roam with fast transition, like they did before.
Someone here has noted the same?
Answer to myself: it seems something were wrong with usteer. The ubus call usteer local_info command didn't show the rrm_nr block, so without this info, it was not able to make any device roam with fast transition.
Why this part was missing? Who knows, a restart of the usteer service fixed the issue. I suppose some kind of bug.
I did not spotted such issue. In main/master branch, only that can affect is updated hostapd to newer version.
When I was testing that change - everything was working normally. Could you share your config?
I can, but the issue is not reproducible, it only happens from time to time.
What config file do you need?
Hi.
As I have some issues with devices not roaming correctly I made some changes to the code to have a new option for more aggressive roaming. It helps for my devices answering with BSS-TM-RESP code 1 or 6. There is some more work to do but I would be happy if somebody can tests my packages for ipq806x or mt7622
You have to enable the new behavior with a new option "option aggressive_enabled '1'" in usteer config but also the normal roaming should be work better.
I will add an option to provide mac addresses next. So aggressive roaming can be switched on selectively as it could create "bouncing" devices between APs with the client is forced to move to another AP.
It would be nice to get feedback if it is working fine, the packages are not finished yet. I you like to see the roaming request you can enable debug log level to get messages beginning with ROAMING showing the target selected for the client and some other infos.
Cheers,
Nils
3 Likes
I saw your mail on the dev mailing list . Glad that you triggered discussion. I will try to apply your patch and run some tests (hope soon).
So far, I improved a little bit my usteer configuration, based on the wireless signal in my apartment (yes, it takes few minutes walking through the apartment and check where is poor signal to make the config). In my case, two APs are very close, so the signal goes to -75dBm. In that case, I have done configuration like:
config usteer
option network 'lan'
option syslog '1'
option local_mode '0'
option ipv6 '0'
option debug_level '1'
option roam_scan_snr '-68'
option roam_trigger_snr '-72'
option min_snr '-78'
option roam_scan_tries '0'
option signal_diff_threshold '10'
list ssid_list 'NETWORK'
So far, it works good. Just can not get why (very rary like once per few days) it freeze the hostapd soo much, that killing service does not work - need to reboot router (maybe problem is somewhere else).
NOTE: I don't use band steering, I prefer to use separated networks for 2.4GHz and 5GHz.
EDIT:
on the end, I disabled usteer (one room got an issue and can not get where was an issue) and I also disabled 802.11r (fast roaming) and just leave 802.11w (because I got wpa3) + 802.11k + 802.11v + set proper power for the antenas and it seems that it works best now.
1 Like
A white/black list system will be great, I hope you plan to add this not only for "aggressive" roaming, but for "normal" roaming. For example, my TV was receiving beacons "constantly" for scanning to see if it needs to roam. This scanning makes my cloud gaming to jitter. It will be great if I can mark this device to be ignored by usteer and "not" receive the roam beacon.
2 Likes