Is this something you know how to fix with usteer? If so, could you somehow submit a PR for it?
I dont know how to do that,
This is the problematic line:
https://github.com/blocktrron/usteer/blob/main/ubus.c#L680
Looks like someone else opened an issue for this? https://github.com/blocktrron/usteer/issues/4
Yep, it's me
But I think usteer is abandoned, DAWN also ..
1 Like
Ah--that's why that issue seemed such a perfect fit for our conversation 
I had been following this usteer (in-tree) location for a while:
https://git.openwrt.org/?p=project/usteer.git;a=summary
But it does seem a good deal of time has passed without updates. Not sure what to make of it.
I thought DAWN was still being developed.
Anyway, one of us could always clone the existing usteer project and test with the change(s) you were proposing. What do you think?
Based on the more recent in-tree code, it seems to me that the measurement mode is known and handled. See here:
https://git.openwrt.org/?p=project/usteer.git;a=blob;f=ubus.c;h=40daf7482eeb40db44c95403ee83ead130185d1d;hb=HEAD#l441
When executing ubus call usteer connected_clients on one of my APs, I do see multiple clients reporting with such:
"beacon-measurement-modes": [
"PASSIVE",
"ACTIVE",
"TABLE"
],
I also see lots of entries in my system log like this:
Sat Mar 4 22:45:18 2023 daemon.notice hostapd: wl1-ap1: BEACON-RESP-RX 20:69:80:xx:xx:xx 9 00 0c06757b710e533ea3000a0000c023...
Let me know if I'm looking at this incorrectly, though.
This repo is old. This other is official and up to date: https://github.com/openwrt/usteer
1 Like
Following that link, the last update was 2022.08.18, so this doesn’t inspire huge confidence 
Is the developer going to answer our questions, and update the wiki?
Or should someone step up to take over.
2 Likes
@stintel, @blocktrron I wonder if you might be willing to give the inquiring minds here a little update as to whether any additional work is going into usteer at this point. It sure would be appreciated!
It does look like there was some effort going into it as of around this post:
Thanks in advance!
That's right
But still, it doesn't send the correct beacon.. something is broken there
I have been using wolfssl (full) until now.
However, the new OpenWRT version 23.05 switches to mbedtls by default.
Can I also run usteer correctly with this?
Yes, they are just different SSL implementations.
The beacons mode usteer use on my case is wrong. How can I change the beacon mode? Can someone spot me to the correct line I should have edit for this?
I think it need to use ACTIVE or TABLE .
hostapd: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:x status_code=7 bss_termination_delay=0
1 is just a rejection with generic reason.
7 is a reserved one, so maybe something nonstandard in Android?
These status codes are defined in IEEE Std 802.11-2012 - Table 8-253. It appears here in android source.
Status code 7 is "WNM_BSS_TM_REJECT_NO_SUITABLE_CANDIDATES", mentioned twice in android's wpa_supplicant - WNM.
"WNM: No BSS transition candidate match found"
"WNM: Candidate list included bit is set, but no candidates found"
Does this mean that usteer is not sending the roaming candidates?
i also have the same issue on my new phone, no roaming and daemon.notice hostapd: wl1-ap1: BSS-TM-RESP xx status_code=7 bss_termination_delay=0 in the log.
Anyone found a way to get it working ?
I also keep getting 2023-11-24 17:40:51 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=1 bss_termination_delay=0
Not sure if the termination delay=0 is the issue, but the client (android phone) does not want to act upon it. I think i am going to check the source code to see if i can change it to a higher value somehow.
I can confirm bss_termination_delay=0 is not accepted by android devices.
You have to set it to a non zero value to make it working.
How do you set it to a non zeto value?
I think I was wrong: in your case, it is a transition_response not a transition_request