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.
Thank you btw, happy to test it as soon as it will get compiled.
You have to thank @IanC for all the changes. I just pulled them to my github repository.
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:
I confirm, seems to be fixed, thank you
Merged changes to 22.03 and 21.02. Please also adjust the config files if you update, or remove it before installing.
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.
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
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
Pushed an update today that is fixing Preferred NR List thanks to @cotequeiroz
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:
Pushed a new update:
@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: