Would be awesome if someone can write a simple guide, some documentation or a couple of examples of configurations on how to configure it.
I'm not an wireless expert and I'm struggling to figure out how to properly configure the package.
What I dont understand I how to actually test if it working correctly.
Thanks to all great contributors and tester, I pushed a new fix that hopefully prevents dawn crashes:
Latest master contains some example config that should be okay for using. Just install it on all APs in a layer 2 domain and maybe install luci-app-dawn for visualization.
If you look at the hearing map, you see that APs have now a score. After a while all clients should be connected to the AP with highest score.
I will write better tutorial if finally all crashes are fixed.
I will push the latest changes also into the 21.02 branch.
Please disable symmetric encryption. Something is wrong:
Regarding the LuCI app, how do I translate it?
I have the hearing map showing, but for some reason the devices are sticky.
I have some clients with a hi score that are connected to the 2.4Ghz network.
I've built the image some minutes ago so it should have all the latest fixes.
So I'm doing something wrong for sure. I have 802.11r, 802.11k enabled and bss_trasition set to 1
Do you have also the same config that is in master?
Do you have full wpad installation on? You can also try enabling this. Then DAWN behaves mor brutally as explained here.
For me the last days were more about bug fixing. You can also increase hostapd debug level to see what is happening. Lets see if I can add more interesting debug output. However, you can also use ubus monitor hostapd.wlanX and look for bss-transition-response. 
Next days I try to rollout some testbed at my place to test more.
Yes, current config of master, with the flag you recently patched set to false.
Yes I have full wpad with wolf ssl for WPA3.
I'll try to see if ubus shows something aobout bss transition and see if forcing the transition will do something.
Hi,
I'm new to openwrt, so this is going to be a very basic question.
I do see that the DAWN package has been udpated in the 21.02.X branch for the ramips/mt7621 architecture. However, I also have a device which is based on
ipq806x/generic (TPLink C2600). This one does not show updated DAWN package.
With that context:
Thanks!
Packages are built in a round robin fashion among the buildbots, so yes, packages will randomly appear faster on one target than they will on another (depending on when exactly the update was pushed in the pipeline); especially right now with the buildbots being busy to compile 21.02.1.
Disclaimer: I haven't checked the details in this particular instance, technically it could also be down to a simple build failure on ARMv7 (compared to mips 24k).
Hi,
any idea what is wrong ?
I have removed dawn config after using it for a while following recommendation in the op...
Mon Nov 8 08:22:31 2021 kern.info kernel: [637772.799497] do_page_fault(): sending SIGSEGV to dawn for invalid read access from 00000010
Mon Nov 8 08:22:31 2021 kern.info kernel: [637772.808227] epc = 00407db1 in dawn[400000+d000]
Mon Nov 8 08:22:31 2021 kern.info kernel: [637772.813065] ra = 00407dad in dawn[400000+d000]
When starting DAWN, I get minor? error :
Starting Service...
sh: 2: unknown operand
Dawn instance started!
And I'm not able to set kicking via UCI :
uci set dawn.@metric[0].kicking=1
uci: Entry not found
Using dawn 2021-10-26-ddc007e3-1 on self-compiled openwrt from 31.10.2021 23:11
Thank you.
update I recreated /dawn/config based on https://raw.githubusercontent.com/openwrt/packages/master/net/dawn/files/dawn.config and now it's fine.
Do I have to change in the config anything, in case I have two APs running on 2.4 GHz + 5GHz ?
Mostly :
option server_ip ''
option collision_domain '-1' # enter here aps which are in the same collision domain
option bandwidth '-1' # enter network bandwidth
No. Just make sure they see each other with umdns.
Just installed DAWN from OpenWrt's official repository. (version: 2021-10-26-ddc007e3-2). I have two routers (one gateway and one AP) on a WDS setup.
It seems to be working, but at first the umdns was not fetching neighboring APs, and as a result the DAWN on each of my two routers were not seeing one another. I solved this issue by changing my WDS-client router (i.e. the extension router) to have 'WWAN' added to the list of networks, i.e.
config umdns
option jail 1
list network lan
list network wwan
Then everything started populating. My android phone seems to roam ok too.
Thanks @PolynomialDivision ! One question for you though, when I logread, I see a LOT of these warning in both routers (basically exactly the same, even the mac address is the same - they both show my gateway router's mac address in these warnings) (EDIT: NO the addresses are different now that I looked at the logs again - each router's warnings contain their own mac address. The gateway only has one wireless radio mac address and that's the one in these warnings. For the WDS client router, the warnings show the mac address of the WDS connection side (i.e. wlan0) and not the AP side (i.e. wlan0-1)):
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.949018] net_ratelimit: 12 callbacks suppressed
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.949037] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.964519] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.975103] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.985701] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1641.996293] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1642.006872] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1642.017450] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1642.028025] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1642.038602] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:25 2021 kern.warn kernel: [ 1642.049183] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.085673] net_ratelimit: 12 callbacks suppressed
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.085692] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.101183] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.111763] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.122339] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.132923] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.143522] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.154104] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.164682] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.175281] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:35 2021 kern.warn kernel: [ 1652.185866] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.221758] net_ratelimit: 12 callbacks suppressed
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.221777] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.237262] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.247837] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.258415] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.268998] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.279584] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.290164] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.300764] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.311357] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:45 2021 kern.warn kernel: [ 1662.321938] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.378671] net_ratelimit: 12 callbacks suppressed
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.378689] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.394145] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.404868] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.415445] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.426015] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.436579] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.447170] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.457725] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.468293] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
Wed Nov 17 03:28:56 2021 kern.warn kernel: [ 1672.478876] br-lan: received packet on wlan0 with own address as source address (addr:xx:xx:xx:xx:xx:xx, vlan:0)
As you can see it just repeats once every 10 seconds. This probably is an indication that something is wrong...?
Would be glad to help troubleshoot this indispensable module to make 802.11k and v work. Cheers!
Edit: umdns is what's causing these warnings. Specifically, each time I manually enter the command "ubus call umdns update", it would trigger these warnings. I even tried flashing a new 21.02.1 OpenWrt image, then installed wpad-wolfssl and then umdns. These warnings started appearing sporadically as soon as umdns was installed. So.... nothing can be done I guess?
I did two things and either one of these things (or both) made the warnings disappear.
On the WDS client, in /etc/config/wireless I changed the channel from 'auto' to the same channel as the gateway router.
On the WDS client, in /etc/config/umdns, I added 'list network wan'. I already added 'list network wwan' before (I have no clue if this line does anything at all, but my network list for the AP only has 'LAN' and 'WWAN'. It doesn't even have 'WAN', but there are posts that say sometimes you need to add 'WAN' for multicast to work).
Edit: original comment deleted in its entirety, as the info is false.
(I need to retract on my (false) findings. It all turned out to be a possible bug in my Android phone's wifi that very likely caused all the discrepancies and inconsistencies for my tests.
I will need to go back and figure out what's wrong with my phone instead of what's wrong with Dawn... sorry folks for the false alarm.)
Hmm. So I mainly have iDevices (so I guess I fall in the category of āit just worksā), but your comment about bss_transition '0' is an incredibly odd finding.
Watching intently for feedback.
Interesting discovery youāve made there. Iām in the process of expanding my wireless range in our new home with solely OpenWRT routers (as dumb ap) and Iām testing Dawn. Iāve set up Dawn accordingly to the many posts on the forum. Iāve got mainly Apple equipment and one Android phone.
I was under the impression that Dawn (in itās current version from the 21.02 repo) works just fine because I see my Apple devices roam just fine. My Android phone however, seems very sticky to a particular AP once connected. Iāve used the excellent Wifiman app to verify that. At first I thought itās just a ānot quite optimalā implementation of 802.11kv in Android 8, so Iāve ordered a newer Android phone thatās on itās way. But from reading your findings, you describe exactly what I experience too. Iāll need a few days to find the time to make similar adjustments that you made but thanks anyway for digging deeper
I see youāve edited your post, thank you for the update to us all. Nonetheless I have seen a few checks to be made when I receive my new(er) Android phone. Do you believe the discrepancy is in Android itself, the hardware of that specific model or in device drivers from the manufacturer?