Dawn: a decentralized wireless controller

Apologies that I don't understand fully - does it mean latest dawn in master, will not work due to the change or you made adjustments to make it compatible ? Thank you btw, happy to test it as soon as it will get compiled.

Some people used @IanC GitHub fork. In this repository an important fix is missing, because an important IPC-function of hostapd was removed:

Everything is good, if you use openwrt master with dawn. :slight_smile:

Thank you btw, happy to test it as soon as it will get compiled.

You have to thank @IanC for all the changes. :slight_smile: I just pulled them to my github repository.

4 Likes

Hi, with latest version I'm getting full log of these :

Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: attempted to register memory already registered (M@tcpsocket.c:114)...
Sun Jun 12 22:20:06 2022 daemon.warn dawn: mem-audit: Releasing memory we hadn't registered (tcpsocket.c:142)...

I have same problem with Dawn on two different routers. AP doesn't see other AP clients. Each client has only one AP record in hearing map.

But if I'm restarting dawn or network service, Dawn shows both APs for clients for a short period of time (10-20sec)

Should be fixed with the new update:

3 Likes

I confirm, seems to be fixed, thank you :wink:

1 Like

Merged changes to 22.03 and 21.02. Please also adjust the config files if you update, or remove it before installing.

2 Likes

I just upgraded dawn on following target

Hostname	AC2100
Model	Xiaomi Mi Router AC2100
Architecture	MediaTek MT7621 ver:1 eco:3
Target Platform	ramips/mt7621
Firmware Version	OpenWrt 21.02.2 r16495-bf0c965af0 / LuCI openwrt-21.02 branch git-22.119.37126-a993714
Kernel Version	5.4.179

Upgrading dawn on root from 2022-05-09-2bfd7397-1 to 2022-06-13-58861a1a-1...

Dawn was working fine before upgrade.
Now dawn is failing to start:

Wed Jun 15 20:06:45 2022 kern.info kernel: [230785.846201] epc = 0040972f in dawn[400000+12000]
Wed Jun 15 20:06:45 2022 kern.info kernel: [230785.851097] ra  = 0040972d in dawn[400000+12000]
Wed Jun 15 20:07:00 2022 kern.info kernel: [230800.868293] do_page_fault(): sending SIGSEGV to dawn for invalid read access from 00000010

EDIT:
My mistake!
I removed dawn config file
dawn crashes with no config file

I removed dawn package / reintall to recreate default dawn config file.
Now dawn starts correctly.

1 Like

Hello,

I setup DAWN follow this guide;
https://openwrt.org/wiki/dawn

On the hardware:

Model ASUS Lyra MAP-AC2200
Architecture ARMv7 Processor rev 5 (v7l)
Target Platform ipq40xx/generic
Firmware Version OpenWrt 21.02.3 r16554-1d4dea6d4f / LuCI openwrt-21.02 branch git-22.167.28411-ee8170b
Kernel Version 5.4.188

Run the non CT version drivers.

If i click "View Hearing Map" on the webpage then iget some errors,

Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@ubus.c:2003[3069302112l] - appears to be UNLOCKED!
Mon Jun 20 10:25:17 2022 daemon.warn dawn: MUTEX require = 3700C@datastorage.c:694[3069302112l] - appears to be UNLOCKED!

And the Wifi Client does not switch to another AP.
It keeps trying..

Mon Jun 20 10:28:34 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:28:44 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:28:55 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:05 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:15 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:26 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:36 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:46 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:29:57 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:07 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:17 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:28 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:38 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:48 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit
Mon Jun 20 10:30:59 2022 daemon.info dawn: Client XX:XX:XX:EA:00:90: Kicking due to low active data transfer: RX rate 1.000000 below 6 limit

Looks like the ""Kick" function is not working.
What do I wrong ??

Greets:Mietse

1 Like

im still facing with same issue

Did you install wpad-full or just basic?

These mutex warnings should be fixed with: https://github.com/berlin-open-wireless-lab/DAWN/commit/181549f7bb706f04d6cdd2e8dae80ba4e9549cbe

2 Likes

Pushed an update today that is fixing Preferred NR List thanks to @cotequeiroz :slight_smile:

Also please check if umdns works correctly if not all APs seeing each other. You can check with

ubus call umdns browse

Is this normal? "Kick" not working, wpad-wolfssl already install, what do i do now ?

Tue Jul 19 16:47:48 2022 daemon.warn dawn: Client / BSSID = 56:7B:5A:12:B1:CD / 12:24:A5:A1:CA:00: BEACON REQUEST failed
Tue Jul 19 16:47:48 2022 daemon.notice hostapd: wlan0: BEACON-REQ-TX-STATUS 56:7b:5a:12:b1:cd 1 ack=1
Tue Jul 19 16:47:48 2022 daemon.notice hostapd: wlan0: BEACON-RESP-RX 56:7b:5a:12:b1:cd 1 04 0000000000000000000000008000000000000000000000000000
Tue Jul 19 16:47:58 2022 daemon.info dawn: Client 56:7B:5A:12:B1:CD: Kicking due to low active data transfer: RX rate 6.000000 below 24 limit
Tue Jul 19 16:47:58 2022 daemon.notice hostapd: Beacon request: 56:7b:5a:12:b1:cd is not connected
Tue Jul 19 16:47:58 2022 daemon.warn dawn: Client / BSSID = 56:7B:5A:12:B1:CD / 12:24:A5:A1:CA:01: BEACON REQUEST failed

Did you install wpad-full or just basic?

I used the wpad-wolfssl

Pushed an update to master that is introducing heartbeats for the tcp client connections and also a fix for a memory leak.

You need to add to your config under config times

option con_timeout '60'

or delete the old config an reinstall dawn.

Pushed an update fixing tcp connections:

1 Like

Pushed a new update:

1 Like

@mietse @supperchym Try setting duraiton to something else than 0, e.g. 4, 100 or whatever (just forgot if that is seconds or ms). With that value you set the disassociation_timer to a none-zero value and the AP will kick the client although it does not behave on bss_transition request correctly.

Here is the value you have to change in the config:

1 Like