Lets talk about usteer

I have Cisco Aironet 3700 APs that use this and the other technologies discussed seamlessly and without a problem. They are running Autonomous AP IOS Software Release 15.3.3-JPQ1 without a controller.

Cisco Aironet's are often used as reference systems in OpenWrt. I suggest you build a lab to better understand the way these systems should perform. I can share my configs, PM me.

This looks to have been the issue, I have successfully resolved it by loading the ath10k firmware below. I am running the QCA9880 chipset.


Devices now roam correctly and prefer the higher bands. I am using the usteer stock config.

That recently changed, it is now available for 23 and 22 branch


Just installed it on 23.05.2, it looks great! Thanks for the tip.

1 Like

Hi there, i have two of this access points: https://openwrt.org/inbox/toh/d-link/dap-x1860

I want to try usteer. Do i have to installed on both access points or only on one of theme?

At least on antthing which provides a wifi access. But installing in addition on the main router can be useful as the actual host names are available, which gives a beter overview in e.g. the luci app

FWIW, I push out ethers file updates from my main OpenWrt router on dnsmasq hotplug events. This way, each of my RT3200s are able to resolve hostnames within the UI and such.

If anyone is interested in the methods I use for this, I'll be happy to post some snippets of how I have it set up.

Made this tutorial almost a year ago

1 Like

Very cool :slightly_smiling_face: Looks like our processes overlap in several ways. Would you be open to suggestions for improvement, as well?

make a package out of it?

The approach @eR2022 takes with hotplug is the same direction I went as well. However hotplug events for dnsmasq are….chatty. So I incorporated a hash check to see if any changes actually occurred to the leases data to determine if a re-push to the APs is even required. That’s an improvement I’d love to see adopted. :+1:t2:

1 Like

Hi! I've a problem with usteer, I don't know if some of you have noticed the same and/or there is some workaround. I have all the info of the problem here:

but in summary: I'm trying to play Amazon Luna cloud games. I receive a lot of stuttering each few seconds and messages about "bad connectivity" that I think it only implies very bad ping (not a lost of real connectivity). After a lot of digging, I've discovered that the culprit is usteer. I think that when usteer sends the beacon to the device for "search better APs" or similar, the device (phone, TV, etc.) starts a search of new networks producing for some seconds a bad increment in wifi response times, enough to make the game unplayable.

Some idea about what can I do, apart of stop usteer to play or use only ethernet devices?


Try to set

option link_measurement_interval '0'

In /etc/config/usteer and see if it improves anything

I tried it without luck. I think this parameter asks the device for the current signal value, this does not need to "scan" for other networks, so it seems to not affect.

I have mitigated the problem lowering a little the roam_scan_snr, in this way in the place where I usually play the signal is better than this value so the router does not send the scan beacon, that is what caused the problem.

With this change now I can play, from time to time I've a little of stuttering, but maybe in this case the problem is other. The game is playable most time.


1 Like

802.11k is enabled? That should limit the amount of searching a client needs to do.

Did you try setting 'roam_scan_snr' back to default (0) and lower the AP transmit power instead? Usually it is better if the client itself decides it needs to move instead of forcing it, kinda like not invented here syndrome. I have my 2.4 GHz power tuned all the way down to 3 mW.

Yes, I have 802.11k enabled. The problem is that my Android phones (Pixel 4 and Pixel 3a), ignore it until they almost lost the connectivity (the Pixel 7 seems to go a little better in this aspect).

I want a good signal to have a good speed, so be always connected to the best AP, with a good power. So in my case, roam_scan_snr is almost mandatory. It works flawlessly except this case, when I was playing in the cloud, but the workaround of adjusting the value has worked well.


To be honest i don't want my clients to be constantly scanning, takes battery power, but whatever works for you. One other thing you can try is the coverage cell density. That pretty much forces clients to have a good snr to maintain the high bit rates

Me neither, for this reason I will try to adjust to values where they don't need to scan when static, only when moving from one place to other. As I say I need to have something configured because my Android devices doesn't roam without help. I only have two APs so I think I can find a good value looking at your app :wink:

I didn't know how this works, but I will try. Thanks for the suggestion!

1 Like

I am using 3 different APs with usteer. How am I supposed to configure this properly? Should I enter all usteer settings in all 3 APs? Or is it sufficient to configure just one of them? It feels weird repeating the exact same settings 3 times. Isn't there a way for usteer to smartly share its configuration across all APs?

I am also getting a constant spam of the following:

daemon.notice hostapd: wl0-ap0: BSS-TM-RESP 11:22:33:aa:bb:cc status_code=1 bss_termination_delay=0

From my understanding, this is because usteer does not send out a neighbor report? How do we get it to do that properly?

1 Like