Thanks! Using bss_transition doesn’t kill the wifi anymore.
I am not sure how to check whether dawn is working though. The package luci-app-dawn only shows me the config file, but no SSIDs or connected stations, which makes me think something is wrong.
That is a tough call, you need to disable all possible client roaming tendency back to 5ghz, then exit 5ghz range and re-enter it and observe being kicked to 5ghz.
I’m not sure why this isn’t talked about more, but DAWN can use 4 different modes of discovery and the default one set that everyone recommends in all guides out there is so buggy! In DAWN option network_option can be set to 0, 1, 2, 3. The default requires umdns service to work flawlessly, and I mean ‘FLAWLESSLY’ and it’s so annoyingly inconsistent. If your DAWN is “working” luci-app-dawn in Status - DAWN tab will show you every node you have connected and how many clients are connected to each, the hearing map will show you all your connected devices by host or mac address, and the mac addresses of your neighbors devices that sent beacons so don’t get confused, and the access points they are connected to and their scores, then and only then can it make kicking decisions reliably or at all. If you go to Status - DAWN tab and all you see is the router or access point you’re currently viewing the status page on, DAWN is not working! It’s so easy to set up dawn with option network_opion ‘0’ and ‘1’ and ‘3’! I use option 3, you leave the server instance as option network_option ‘3’ and don’t define a server ip, it will just listen on tcp port 1026 for other DAWN instances, on all your access pints you set option network_option ‘3’ and option server_ip to point to the ip number of the instance that you dedicated as a server, vlans or any other things you set up don’t matter as long as you can connect your access points to the ip the server instance is running on through tcp port 1026, if you’re setting up complicated networks and segments I’m sure you know how to get from segment to segment to segment to reach a specific internal ip and port on your network, you know how to set up firewall rules and stuff I don’t. You can also use option option_network ‘0’ or ‘1’ and broadcast or multicast on the broadcast_ip you set up and all your other instances will find each other so much easier than depending on umdns working flawlessly. I don’t know why all the guides I’ve come across specify to use umdns, it’s so unreliable and why so many users that tired DAWN can’t get it to work properly, but when it works, even with the default configuration it works so well, from the defaults it’s 5ghz biased and kicks clients pretty well, it can be tweaked so well though when you can see the entire hearing map with all your clients connected and what scores they get based on their connections, my god it can be tuned so well to your needs! Please try setting up your DAWN instances wit the other three discovery options available and share just how much more reliable it is and how well it works. My only other advice is, once you get DAWN working, don’t get tempted to enable 802.11r, it will stop kicking reliably, or rather your clients compatible with 802.11r will ignore DAWN’s bss_transition requests and stick to a “good enough” ap as long as they want, or until DAWN decides to dauth them at which point there won’t be any fast transition happening, from my experience bss_transition is good enough for android, iphone, ipad, and windows laptop all of them seem to switch to different channels on the same ssid without disconnecting so I disabled 802.11r completely because it was causing more problems than it solved. Good luck, and I just want you to know you’re not the only one confused about DAWN and whether it’s working, it took me days to realize that umdns discovery sucks and that just because /etc/init.d/dawn restart showed that it successfully started and is running on tcp port 1026 didn’t meat it was actually working! Install luci-app-dawn, go to Status - DAWN and if all your access points that are running DAWN aren’t there, it’s not working!
To answer that, Luci has been very reliable with showing data once dawn is working correctly, if there was an error, for example if you use fancy quotes in the config file, the luci app will show a red error, if your /etc/inti.d/dawn restart returns a successful restart and the luci status page only shows the router you’re viewing the page on, dawn isn’t working, or isn’t hearing the other dawn instances, so my answer is, if the luci webpage isn’t showing the correct status, there is a problem with dawn steering clients, dawn will not steering clients if it cannot hear, or connect to at least one other dawn instance and get its information from hostapd about clients connected to it, it cannot make decistions without score calculations for each instance.
On my working set up, if I log into any access point, go luci Status - DAWN and look on the hearing map tab, look for my device “Motorola_edge_plus2023.lan” it will have four headings of information from my four WiFi interfaces with the same ssid, two from the MT6000, one for the 2.4ghz radio and one for the 5ghz, and two from the AX4200, one for the 2.4ghz radio and one for the 5ghz radio, each interface showing information like vht availability and other details, but most importantly the score of each radio relative to my device and which one it's currently connected to, confirming that it's connected to the highest scoring radio and verifying that DAWN is constantly calculating scores as they update with each refresh of the data like luci likes to do unless you turn off "refreshing” with the button in upper right of the page. At least that's how it works for me, it took me days to get it working, and now that I can see a live representation of what Dawn sees, it's very easy to tune the scoring of each radio to my liking.
To the op, start where I started when luci wasn’t showing anything for me, ssh into any router that has dawn and run ‘uci show dawn’ and if you get the print out of the whole config file you’re good, if you get a parse error, you used an invalid character or syntax, I copy and pasted so many things off the internet and my parse error was that I was using fancy quotes on many of the options because that’s how some websites formatted the code people were pasting, with parse error nothing was showing in luci for me. If ‘uci show dawn’ shows your config, then go on to ubus calls like ‘ubus call dawn get_hearing_map’ and ‘ubus call dawn get_network’, get_network should show you a print out of all the access points you have dawn running on and the clients connected to them, not just the one you’re running the command from. If the ubus calls are working correctly then I would agree and say that your luci is broken somewhere. And again, if things aren’t working consider using any of the other three options instead of TCP with uMDNS for communication between your nodes, because the way the luci-app-dawn package works is that it automatically updates the configuration when you ‘save and apply’ on all your nodes if they’re connected and communicating correctly which is so convenient for making changes!
For those doubting if DAWN works, here is a screenshot of what a proper hearing map should look like listing your connected devices and if the access points can see them
